1. 14

  2. 2

    I still don’t understand necessity of centralized message brokers for IoT setups. Especially for home IoT (as opposed to industrial/commercial). Even if setup requires central control node, I don’t understand why this node should run message broker and processing node connected to this message broker as a client.

    If a sensor pushes data to the processing node, why it should push it via message broker and not directly? Pull is even worse: sensor should get request from message queue and then reply to the same queue, it’s worse than if a sensor would be just a listening server.

    A controllable device (i.e. light switch) should receive control message as quickly as possible, but it can stuck into thinking that it’s connected to MQTT server, but at the side of MQTT TCP connection is closed. It will not receive that message until next keepalive or something like that.

    Even putting NTP-like time protocol on top of MQTT is too quirky (and IoT devices always want to ask what’s time, they are frequently restarting, including when waking up from hibernation, and don’t have proper clocks).

    Message queues have no data aggregation built-in (unlike time-series systems, like all these monitoring systems). They do nothing interesting. Why they’re better than direct connection? I can understand message queues for “put long task for asynchronous processing”, i.e. for web apps, but what’s purpose for it in IoT?

    1. 3

      Consider sensors that are on battery: they’ll wake up every few seconds (for things that need to respond quickly) or every minute (for simple sensors). The control node might want to send a command to it, but if the sensor is just listening, the control node would need to keep trying to connect in hopes that it manages to catch the sensor in the 50ms or so that it’s online. What happens if the sensor gets a different IP the next time it tries to connect? It’s lost.

      How about if the sensor connects to the control node? It may be that there are multiple systems interested in readings. For example, I have a separate process that logs time series next to the control node, because home-assistant does a crap job of tagging its influxdb time series. I may also want to send commands to the sensor outside of the control node, e.g., for firmware updates. Once again, the decoupling provided by MQTT helps.