Can't write to a custom Characteristic through EspruinoHub (stuck at "Getting Service")

I can't find a way to write to a custom service/characteristic exposed on the Puck from Node-RED through EspruinoHub.

However:

• Writing from Node-RED to /ble/write/puck/nus/nus_tx through EspruinoHub works
  
• Writing to the custom service/characteristic using nRF Connect app on an Android phone works
  
  

The problem only appears when writing to the custom characteristic through EspruinoHub.
It seems it's not related to Node-RED since the same problem appears also when the MQTT message is published using mosquitto_pub.

Following the guidance in https://www.espruino.com/Puck.js+Node-RE­D ...:

The format is /ble/write/de:vi:ce:ad:dr/service/charac­teristic, so you don't have to write to the Nordic UART on Puck.js. You can define your own services and write directly to those.

...and the guidance in http://www.espruino.com/Reference#l_NRF_­setServices, this is the code I have on the Puck (first part unrelated (?), but adding for completeness):

setInterval(() =>
    NRF.setAdvertising({
        0xFFFF: String(Math.round(Puck.light() * 1000) / 1000).split(""),
        0xFFFE: String(E.getTemperature()).split(""),
        0xFFFD: String(Puck.getBatteryPercentage()).spli­t("")
    }, { interval: 5000 }), 60000
);

NRF.setServices({
    0xAAAA: {
        0xAAA0: {
            writable: true,
            onWrite: function (evt) {
                LED1.set();
            }
        }
    }
});

And publishing to /ble/write/puck/0000aaaa0000100080000080­5f9b34fb/0000aaa000001000800000805f9b34f­b yields:

<Connect> de:vi:ce:ad:dr: Getting Service...
<Connect> de:vi:ce:ad:dr: Disconnecting due to lack of use (after 30 secs)
<Connect> de:vi:ce:ad:dr: Disconnecting.
<Connect> de:vi:ce:ad:dr: Disconnected

Even extending the CONNECTION_TIMEOUT to 30s and the "getting services" timeout to 15s didn't help.

Any ideas?

Is there some interplay between setAdvertising and setServices?
Am I using the wrong format for specifying service/characteristic ID? (Tried short aaaa, long 0000aaaa00001000800000805f9b34fb, hex 0xaaaa, capitalized, non-capitalized, etc.).

Environment:

• Puck.js 1v90
  
• EspruinoHub up to date
  
• Node-RED 0.15.2
  
• MQTT Broker is hbmqtt built into Home Assistant
  
• All running on the same Raspberry Pi 3
  

Hi,

Is there some interplay between setAdvertising and setServices?

Occasionally - when you specify a second argument to setServices for the services you want to advertise (but you're not doing that here so I don't think it's an issue).

Am I using the wrong format for specifying service/characteristic ID?

That all looks good to me.

I'd maybe try using a newer firmware on Puck.js just in case?

I just tried your code here and while /ble/write/puck/0000aaaa0000100080000080­5f9b34fb/0000aaa000001000800000805f9b34f­b doesn't work, /ble/write/puck/aaaa/aaa0 does seem to work great for me.

Thanks for the tips. Finally figured it out – turning off the WiFi module of the Raspberry Pi (putting dtoverlay=pi3-disable-wifi into /boot/config.txt) has helped big time, basically resolved the issue. I saw the advice somewhere else before, not sure where, but tried it only now.

Now it works nicely most of the time. It just occasionally times out with:

<Connect> de:vi:ce:ad:dr: Getting Service...
<Connect> de:vi:ce:ad:dr: Disconnecting due to lack of use (after 10 secs)
<Connect> de:vi:ce:ad:dr: Disconnecting.

Is this expected? Do you see the same behaviour? Any ideas how to achieve more reliability, apart from maintaining a persistent connection?

Interesting about the WiFi - I haven't had to explicitly disable it on my Pis however I believe I'm running the Lite Raspbian which doesn't have the desktop and so I imagine won't be using WiFi to scan for access points of anything.

If you actually use WiFi for connections you'll have huge issues though since it's trying to use the same aerial.

Occasionally it will fail, it's pretty much guarantees - I guess potentially that code could be improved to retry after a timeout, or you could make the service readable and could perform a read after the write in order to check that everything was ok?