Comms: MQTT

[mitra42]

Part of #20

The node needs to connect to a MQTT broker and send/receive messages from it.

There are a LOT of MQTT libraries, and its not clear which is the best - comments are welcome.

My plan is to build on one of them for the POC, and then allow for coming back and re-engineering, ideally just this module, if there is a better one to use.

Its dependent on WiFi connectivity.

• [x] Select Library
• [x] Integrate WiFi and make sure minimally configurable
• [X] Figure out structure for retrieving, storing and then acting on changes (see comment below)
• [x] Define APIs to hook this into sensors, logic and actuators
• [x] Build demo to send humidity and set LED accordingly (see comment)
• [ ] Potential issues to come back and check
  • [ ] In arduino-mqtt/README.md is a comment about "millis" not continuing during deep sleep, and since we'll need deep sleep for the MVP this will need revisiting.
  • [x] Need to handle authentication (in client.connect)
• [x] Put a MQTT "broker" somewhere - probably on Mitra's server for now
• [x] Figure out a way to interogate, or be notified of state changes through that server
• [x] Build local broker - so message is dispatched locally as well as sent to server #26
• [ ] #40 - so a network of sensors can collaborate, via WiFi or LoRa hub without backhaul.
• [x] #28
• [ ] Build higher level MQTT protocol - how devices self-announce, and get backlog of updates etc etc #29 - mostly done, but some loose ends with configuring.
• [ ] #30 - partially done - lots more to do
• [X] #31
• [x] #33
• [x] #34
• [x] #35

[mitra42]

I'm leaning towards lwmqtt because it claims to be simple and light/

There is also a wrapper arduino-mqtt which uses callbacks. And it looks like this is what is needed as the other is a non-arduino (e.g. uses pthreads)

[mitra42]

Base level works as a demo - sends and receives a hello world message. Probably needs some kind of broker on my naturalinnovation.org server, and then to add authentication.

[mitra42]

Need to also think through structure for MQTT variables and payloads. I think this will need copying the payload out of the buffer which might mean dealing with the type.

[mitra42]

Design straw person .....

• [x] sensor_xxx::loop calls xMqtt:send(topic, value) when value changes.
  • [X] calls ok with floating point, but needs to test for change
• [x] - cDemoMqtt::setup calls xMqtt_subscribe(topic, *cDemoMqtt::messageReceived)
• [x] - xMqtt_subscribe calls client.subscribe(topic)
• [x] - xMqtt::messageReceived looks up topic and calls cXxx::messageReceived with the payload
• [x] - cDemoMqtt::messageReceived converts incoming floating text to point
• [x] - makes a copy of the payload if required.
• [x] - takes action e.g. calling an actuator.
• [x] - cDemoMqtt::messageReceived send actuator result back via MQTT
• [x] - aLedbuiltin::setup calls xMqtt_subscribe(topic, *aLEDbuiltin::messageReceived)
• [x] - aLedbuiltin::messageReceived to control LED based on result

Next steps would be to do this with the SHT31 sensor, and then an actuator (which could be on a separate device) to turn on LEDS when humidity exceeds base level

[mitra42]

There is now a live working demo where a SHT30 sensor detects humidity , sends it to the MQTT broker. Then control_demo_mqtt receives that value, checks against a reference humidity and sends a value via the MQTT server to actuator_ledblinken.

Note that this should work even if the LED and SHT30 are on different devices, but I don't currently have a way to test that.

[mitra42]

Closing as all minor issues (with own issues) and MQTT is working well -