Problems with EspruinoHub

Posted on
  • Hi!
    I try to implement better BlueTooth control of my greenhouse and I have a few problems with EspruinoHub.
    First of all, when I try to send stringifyed JSON from node-red I have a crash of EspruinoHub. It is because of the function in its code in mqttclient.js:

    function convertMessage(data) {
      data = data.toString();
      try {
        data = JSON.parse(data);
      } catch (e) {
        // if it's not parseable, we just use the string as-is
      }
      return data;
    }
    

    The code converts string to string (nothing happens), then converts it back to JSON, and then the JSON can not be sent. My JSON is created from {c:{w:20,a:1},id:2}
    My workaround is to comment JSON.parse().

    Second problem is that EspruinoHub often stops to connect to device without any resonable log. I do not know why. Usually I can see that after device reprogramming. When I try to send something to device nothing happens. There is nothing like that:

    Scanning stopped.
     dc:0f:df:1e:d4:72: Connecting...
     Connected.
     dc:0f:df:1e:d4:72: Getting Service...
     dc:0f:df:1e:d4:72: found service: fffe
     dc:0f:df:1e:d4:72: found characteristic: 1
     dc:0f:df:1e:d4:72: Written.
     dc:0f:df:1e:d4:72: Disconnecting due to lack of use (after 10 secs)
     dc:0f:df:1e:d4:72: Disconnecting.
     dc:0f:df:1e:d4:72: Disconnected
     Restarting scan
     Scanning started.
    

    I've added logging to start of write processing (after 'if (path[1]=="write") {') and I can see that it is called with correct data. But there is nothing after that.
    After it happens EspruinoHub come to state when it will not send anything to device.
    After restart EspruinoHub returns to working state.

    Third problem is packet reassembling at device. I'd want to propose some change in EspruinoHub logic. Now when EspruinoHub sends more then 20 bytes of data to BLE characteristic it split the data to 20 bytes chunks. And It is hard to check on device if everything is already sent. It will be quite easier if Espruinohub always sends last chunk of smaller size. It may be zero size if data size is multiple of 20.
    The logic is similar to USB. I've implemented that. It makes packet reassembling very simple.

  • @SergeP , you are spot on: for robust software, choosing affirmative implementation patterns are always helpful! With packages, the information wether it is the first, second, n-th and especially the last one helps. It is easy on the transmitting side, and simplifies live extremely on the receiving side... and allows even to put in a watchdog / timeout for abandoning incompletely received messages.

  • Ahh, ok - for the first problem, if you send "{c:{w:20,a:1},id:2}" then I guess you'll be fine. The parsing is because Espruino is expecting you might want to use [1,2,3,4] to send binary data. I've just made a tweak that should make your old code work fine though.

    EspruinoHub often stops to connect to device without any resonable log

    If you go to http://yourdevice:1888/status do you still see the device you're trying to connect to shown? Maybe for whatever reason it isn't seeing it in the advertising data?

    Third problem is packet reassembling at device

    That's an idea. So the only actual change would be if packet size =20 it'd send a blank packet? If you're just sending JSON I'd suggest just adding a newline to the end though - then you could send through normal Nordic UART endpoint and handle it really easily?

  • I've just made a tweak that should make your old code work fine though.

    Great! I've changed EspruinoHub to my code can work, but it is good to use regular one. Because the problem may be not only my problem.

    If you go to http://yourdevice:1888/status do you still see the device you're trying to connect to shown? Maybe for whatever reason it isn't seeing it in the advertising data?

    It seems to me, device is in place and advertizes carefully :) But string 'Scanning stopped' and subsequent strings will not appears anymore before EspruinoHub restart. I'll try to mine additional info.

    So the only actual change would be if packet size =20 it'd send a blank packet?

    Exactly! If last packet chunk size =20, send a blank packet after. It is like USB works (I'm not sure that USB3.2 uses the same, but up to 3.0 it uses the method to reassemble data). I've implemented that in EspruinoHub (but my code is ugly while correct) and I'm happy. I think it may be useful not only for me.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Problems with EspruinoHub

Posted by Avatar for SergeP @SergeP

Actions