I now provided a pull request that fixes this issue:
I strongly hope that this soon get into the main such that it can be released with the next milestones build. My devices are really suffering from this issue…
It’s good to get that QoS fixed.
But reminder that it’s only speculation this has to do with your problem.
We still haven’t seen how quickly you send messages, closest estimate is three within one second.
I meanwhile have worked-around in my code a lot and ensure that all messages have a minimum delay - sacrificing wait time for my users. And still I experience that openhab swallows messages from time to time - meaning the broker sends them to openhab and openhab does not process them. Likewise, some messages from openhab to the device were dropped, which makes my device waiting for logical acknowledgement and reports false negatives to the user.
To alleviate the latter problem, I found a non-standard setting of mosquitto according to which it raises qos level of subscribers to match their request level even if the publisher uses lower qos. My device subscribes with qos=2 but because openhab only sends with qos=0, according to the standard mosquitto sends them with qos=0 to my device. Now with setting upgrade_outgoing_qos=true, at least the path between the broker and the device is safe, as the broker sends it to the device with qos=2 given it received the message from openhab.
With those workarounds I felt now save enough to bring the fingerprint device into productive use for my family, but there are still some rare error cases.
With the openhab fix I’m confident that I don’t loose any messages anymore and that I eventually even can speed up the message throughout again.
I did have an issue with MQTT messages being too close together. I was using a encoder for dimming that I couldn’t get working stable so I just moved from MQTT to interact directly with the REST api.
Hi denominator,
Thanks for that hint, that’s a good idea for a workaround.
I don’t like it as an ultimate solution, because using the REST interface means that my device has to know the Item name in openHAB, and then I must recompile the device firmware if the item name is changed (not speaking of the risk to forget about that dependency and breaking the function with a simple rename).
I more and more get the feeling that the mqtt binding is not as stable as one would assume, given the number of users and the time it is already available.
I had it two days in a row, that everything worked fine for the first two hours of openHAB being up, and then suddenly the binding did not react anymore on certain messages - as if it had forgotten that it subscribed to that message. In this case, I can see that mosquitto transmitted the message to openHAB, but the binding didn’t react.
Strange thing is, that other channels of the same Thing still worked without problems, and only some were dead - consistently and repeatable…
If I knew how to reproduce this state, I could track it better down, but with only getting sporadically into it, after hours of running fine, this is cumbersome. If the system is in that state, only mitigation possibility is to restart openHAB. In that attempt, it also reports that the handler of the mqtt binding did not react within 5000ms…
A gut feeling tells me that this is related with the SamsungTV binding, which seems to have some internal lock problem if it hits connection issues with the TV. Is it possible, that a locked thread in the SamsungTV binding also makes mqtt binding stop working? Are those operated by the same threads??
Regards,
Stedon81
Most stuff in oh operate it of thread pools so that is very much a possibility.