I made some BLE modules and BLE-MQTT gateways, and I’ve been experimenting with OpenHAB’s MQTT plugin. It seems like when I’m subscribe to multiple topics that are always published in quick succession, OpenHAB’s MQTT plugin will fail to process some amount of those MQTT messages. This seems to be true even when the QoS is changed from the default 0 to 1 or 2.
My BLE modules (and the gateway) tends to publish groups of topics together (RSSI, battery voltage, the pertinent BLE sensor data, etc…). If I subscribe to, say, both voltage and RSSI, I’ll often miss the RSSI because it’s published after voltage. The problem goes away if I delete the item that subscribes to voltage and only subscribe to RSSI. Then I consistently get RSSI.
I can see this in the </var/log/events.log> missing MQTT events. I’m also persisting the MQTT data to InfluxDB via OpenHAB’s persistence service. At the same time, I’m using Telegraf to subscribe to the same MQTT events (a component service of Influx). I can see that the data from OpenHAB’s Influx persistence isn’t as complete as the Telegraf MQTT-to-Influx series.
It seems like Telegraf is much better at ingesting MQTT data, and the QoS setting actually effects reliability. I’m not sure the QoS setting in OpenHAB’s MQTT plugin is effecting subscription performance much.
So that setting only affects the messages that OH itself publishes. You must set the QOS on the publisher. Setting it on the subscriber doesn’t affect the QOS on received messages.
I would recommend doing both of the following:
File an issue on the openhab1-addons repo tagged with MQTT. It should not be dropping those messages, though if the publishers are sending the message with QOS 0 then OH missing those messages is within the specifications of MQTT.
Try this same test using the new work-in-progress 2.x version MQTT binding which is still under development and I’m not sure whether it is at an alpha stage yet. This will certainly need to be fixed in that binding too.
Unfortunately, I suspect the “fix” for this will be to use some other MQTT library which can be a pretty big deal.
OK, I’ll take a look to see if 2.x version is available for test.
Just to check my syntax, I’ve been using this syntax since v1.4 when all addon configs were in the same .cfg, but now that I’m looking through the Github documentation, the example configuration uses a different syntax.
My URL line seems to work, so I’m assuming the bindingName:broker.property syntax is still acceptable? Or am I screwing up the config and that’s explaining the QoS issue?
Yes, I have found that it works also with
mqtt: in front of the config lines within mqtt.cfg
It’s not really needed and you can remove it but this shouldn’t be the root cause of your problems.
You should file an issue as @rlkoshak said above with as much details as possible.