Thoughts on MQTT

Some Thoughts on MQTT

Life has gotten in the way of my pool project, but I do have some thoughts. I’ve gotten small Sonoff plugs set up to turn on and off bug zappers on a cron schedule. I reflashed the units with Tasmota. From earlier robotics experiments I was fond of MQTT as a message bus. Not so much anymore.

Things do break. Not often, but they do. The node I was running MQTT on got a little flaky and it impacted ALL my devices. That’s a classic single point of failure (SPoF) problem. Not good. That got me thinking about the larger IoT ecosystem. So much of it these days assumes MQTT. Well, at least what I see. That makes me uncomfortable. Even for data collection I am not sure it’s the right model. I was thinking about polling my sensors over MQTT topics and then flowing that data to both a local system and the cloud for analysis. I love Prometheus and was thinking I’d use the cool looking Prometheus Blackbox Exporter.

So let’s take a step back and look at this system. I have a collection of WiFi-devices all configured to talk on MQTT topics. I have a mosquitto MQTT broker. I have Prometheus running, and Grafana, and now I add the exporter. You know, I could just poll the devices directly with an exporter and that’s one less common-to-eveything component. In fact, contrary to the way MQTT works I could take a page out of k8s thinking and have a node controller that has a map of declarative state - the desired state of bug zappers at what times (e.g. like a crontab) and it would be easy to have code check the devices and if they are not in the desired state command them to be in that state. I could run more than one of that service and be totally idempotent, and thus quite resistant to the loss of any one node of that service. Tell me again why I am using MQTT?

Yes, of course there are lots of use cases where MQTT is great. I’m not sure that mine is one of them. So life is going to keep me from doing much on the personal hobby front this week, but my brain is sure active on it. I suspect I can design a very small service that just polls a given device every X seconds and if it’s not in the desired state it executes a command to put it in that state. I could get that desired state from a distriibuted store so that I don’t have to worry about configuring every controller. Then I can run a few of those and they will be very lightweight, and since they are simple they probably won’t fail much anyway.

And my damn bug zappers will turn on and off when they are supposed to.

See? The power of technology.

Clicky

Clicky

 Share!