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.

• Select Library
• Integrate WiFi and make sure minimally configurable
• Figure out structure for retrieving, storing and then acting on changes (see comment below)
• Define APIs to hook this into sensors, logic and actuators
• 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.
  • Need to handle authentication (in client.connect)
• Put a MQTT "broker" somewhere - probably on Mitra's server for now
• Figure out a way to interogate, or be notified of state changes through that server
• Build local broker - so message is dispatched locally as well as sent to server MQTT: Local broker #26
• Build stand alone broker - so a network of sensors can collaborate, via WiFi or LoRa hub without backhaul. Broker should also send on to upstream broker.
• MQTT - seperate out WiFi and make non blocking  #28
• Build higher level MQTT protocol - how devices self-announce, and get backlog of updates etc etc MQTT - higher level protocol #29
• HTML - simple MQTT client #30 - partially done - lots more to do
• MQTT - how to obtain client id #31
• MQTT - dont send inside message receivers #33
• MQTT - local broker should work without WiFi #34
• MQTT - big  #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 .....

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