I’m using the MQTT library (latest version) on an Argon. For my specific application, the Argon acts as a “bridge” between 6 different sensors that I have on a Boron in my RV. The Boron sends a Particle.publish and the Argon translates that into the proper MQTT publish command inside my home network. I have defined 6 separate MQTT instances, one for each sensor, that way if a given sensor goes offline, it will publish “offline” on the predetermined availability topic for that MQTT connection. I also have code that if it has not seen a reading in over 1 hour, it will disconnect that MQTT instance from the server. All these sensors are shown in Home Assistant, so with this method I can easily tell if a sensor is unavailable and needs to be inspected.
Everything compiles and flashes properly. The device never generates an S.O.S. The memory of the Argon in the Particle console shows 62k out of 163k used. However, when I run the 6 separate mqtt.connect calls, only the first 4 are successful. The final 2 fail. I have re-ordered the connect commands, and it;s always the first 4 that work (this proves all my connect settings are proper for all 6). Is there some network connection limitation that is causing this?
At this point, the only solution I can think of is to setup a 2nd Argon/Photon and have only 3 MQTT connections per device.
I think you are running into the limited number of available sockets at any given time.
When your clients connect and stay connected they also keep the respective socket occupied.
When you only want to send MQTT messages and don’t need to receive any from the broker you could connect/publish/disconnect each time your Argon receives an event.
Alternatively you could go with a single client instance and make the distinction via the MQTT topic - these can be structured hierarchically and you can use wildcards on the subscriber side.
Yes, I originally had a single MQTT client that published on different topics. However, this didn’t allow me to take advantage of the built in “keep-alive” functionality of the library to indicate to Home Assistant when a sensor went offline individually. This is a critical feature as I need to know when a sensor has gone dark so I can look into fixing it.
Now that I think about it, I guess I could construct the single MQTT and manually publish to the “keep-alive” topic every 10 seconds. I could then publish “offline” when the individual sensor goes dark.
How do you check the actual sensor being online/offline?
Since the client’s presence would only indicate whether the Argon based endpoint for the respective sensor is online you’d only be able to infer the status of the actual sensor.
Hence I’d see that as mere “perception of mission critical data” rather than actual trustworthiness.
So I’d think the actual monitoring of your sensors’ respective availability needs to be put into the Argon’s logic and a dedicated MQTT-state-report might be the way to go.
Alternatively you could setup port-forwarding (providing your network has a (virtually) static IP) in your local network to have the Boron report to the MQTT broker directly (considering the keep alive period for their UDP route).
I don’t use Mqtt and I want to address ‘sensors going offline’. I have a fleet of temperature, wattage, voltage and humidity sensors at a remote cabin. They run on esp8266, esp32’s and boron. I found that the esp8266’s could not run 24/7 without eventually locking up and going offline. At first I put smart switches on every one of them and when readings stopped coming in, I would turn that one off and then back on, remotely. After awhile I just programmed a software reboot at 4 in the morning and now each device recovers for itself and I don’t need the smart switches now. I don’t know if the esp32’s have the same problem I just put the same reboot code in them as well.
To detect offline sensors, I just use a variable to record the System.millis() whenever a sensor posts a value. If the variable ever gets above 1 hour, I call mqtt.disconnect. This way it shows up as “unavailable” to Home Assistant.
It’s funny you mention ESP devices. I got an esp32 recently just to try out what I was missing. It too seems to lock up after 24 hours or so. I’ll have to try the 4am reboot trick to see if that helps.
For my gang of sensors, I found that sometimes they where trying to report in to the central hub but were ‘colliding’, I call it, with other units reporting at the same time. I gave each sensor a number and they report in when the seconds from the time match that number. The sensors communications are spread out and don’t conflict with each other.
Given the problems I had with the esp32, I’m going to stick with particle devices.