Avatar for urbiman

urbiman

Member since Mar 2016 • Last active Feb 2017
  • 1 conversations
  • 11 comments

Most recent activity

    • 8 comments
    • 1,148 views
  • in General
    Avatar for urbiman

    Thanks @Wilberforce , can you maybe point me to a list or other source where I can find the area where the code is stored?

  • in General
    Avatar for urbiman

    @Ducky you are completely right, this is exactly what I would like to achieve. Any hints?

  • in General
    Avatar for urbiman

    Is there any way to bake JavaScript into the firmware so it gets flashed with the firmware? I mean a JavaScript that gets executed after startup of the chip just like if I would have transferred it using the IDE?

  • in JavaScript
    Avatar for urbiman

    My JavaScript is based on the wsx.js from the first post here which should be widely identical to the current ws.js available from the espruino site so it is compatible to what is in place now. Just give me a few days as I would like to further improve the http handshake as it could still fail under certain circumstances and I would like to add support for larger messages (more than 127 chars).

  • in JavaScript
    Avatar for urbiman

    Ok, I fixed it myself. The reason why the code was disconnecting all the time when using cloudflare was the following: The handshake was transmitted in two chunks (each chunk has a wrapped around it here):

    <DATA>HTTP/1.1 101 Switching Protocols
    Date: Sun, 08 May 2016 08:59:10 GMT
    Connection: upgrade
    Set-Cookie: __cfduid=xxx; expires=Mon, 08-May-17 08:59:10 GMT; path=/; domain=.urbiworx.de; HttpOnly
    Upgrade: websocket
    Sec-WebSocket-</DATA>
    <DATA>Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
    Server: cloudflare-nginx
    CF-RAY: 29fbb6cda43e26d2-FRA
    </DATA>
    

    So what happend here was, that during the handshake one data packet was received with an "H" at the beginning (first chunk) that did not contain the "Accept" Header (that is in the second chunk) and so was interpreted as WS message. "H" in hexadecimal is "48" which is the worst that could happen as it means opcode "8" - terminate connection.

    I now changed the code accordingly so that chunks do not get interpreted as message as long as the handshake is not finished.
    It is not yet implemented optimal right now however it works much better than before.

  • in JavaScript
    Avatar for urbiman

    I had problems getting WS to work with the latest nodejs ws version (1.1.0) as a server.

    The trick for me was to add a "return" statement in the first if block of the "parseData" method (roughly line 117 of wsx.js) to prevent the other statements to execute and produce unexpected results in some cases. After I did this change the connection was not directly terminated any longer.

    My ultimate goal is to get it running together with cloudflare (as they now support websocket connections in free plans).
    I did some changes that significantly improved the behaviour:

    Added the hostname to the handshake (otherwise reverseproxies can not handle the request)
    Removed the Origin from the handshake (otherwise correct WS servers would decline the connection because of CORS problems, however it is optional for devices like espruino)
    Added XOR encryption for the send method as this is mandatory for clients to do

    Further I also try handle binary data, however this is experimental and has nothing to do with cloudflare.

    Now cloudflare finally accepts the connection and even forwards my first message, however the connection is terminated right after that. When not using cloudflare (and connecting directly) everything works as it should. Does anyone have a clue what could be the problem?

  • in ESP8266
    Avatar for urbiman

    I did a pull now to merge the deepSleep and modemSleep stuff (#825).

    Regarding the lightSleep it seems that this is only possible with wifi off if you want to enforce the sleep (which is what is supposed as far as I understand):

    Yes, wifi_station_disconnect(); and wifi_set_opmode_current(NULL_MODE); are needed before calling force sleep function. We will add more description on this in the documentation.
    Source

  • in ESP8266
    Avatar for urbiman

    Ok, good to hear :) I will do a pull in the next days first adding deepsleep and modemsleep. However it seems to be possible to implement what you have done for the STM boards by using lightsleep. I found the following code (using light sleep and a timer):

    //sleep over.
    void fpm_wakup_cb_func1(void)
    {
       wifi_fpm_close();   //disable sleep function
       wifi_set_opmode(STATION_MODE);      //set wifi mode to station mode
       wifi_station_connect();         //connect ap
    }
    
    void user_func(...)
    {  
    wifi_station_disconnect();
    wifi_set_opmode(NULL_MODE);      //set wifi mode to null mode.
    wifi_fpm_set_sleep_type(LIGHT_SLEEP_T);      //set force sleep type, clsoe rf&cpu
    wifi_fpm_open();            //enable force sleep fucntion
    wifi_fpm_set_wakeup_cb(fpm_wakup_cb_func­1);   //Set fpm wakeup callback function 
    wifi_fpm_do_sleep(10*1000);         // do sleep
    ...
    }
    

    Source

    I think that would be the next step then...

  • in ESP8266
    Avatar for urbiman

    Actually I do not interact with setTimeout. In the case of deepsleep it wouldn't make too much sense either I think, as after deepsleep the chip is resetted and therefor all timers are lost. In case of modemsleep it should be uneccessary as the CPU runs normal.

    I am not sure about lightsleep (I did not implement that) but my current understanding is, that lightsleep needs an external trigger to wakeup:

    Under the light-sleep mode, the CPU will not respond to the signal and interrupt from the peripheral hardware interface under the pause state. Therefore, the ESP8266 need to be waked up via external GPIO, and the wake process is less than 3 ms.
    (Source)

    To me currently it seems that there is no way where the ESP8266 could interact with setTimeout (however I am not completely sure when it comes to lightsleep as RTC is running according to the document above).

Actions