Looks like my driver already well tested and it is the right time for making it publicly available
Main functionality here is relying on feedback from the device when it is actually toggled, eliminating black hole issues.
Currently, I've uploaded
Switch driver with polling/refresh/ping capabilities
IR Blaster driver for sending via MQTT to tasmota or any other mqtt based subscribers
H801 dimmer ( tasmota )
These will be added soon ( ~2-6 weeks) once arrived and tested
No - I connect continually to a broker and have no issues.
Update - a couple of hours after this post one user is reporting disconnects .. I am putting this down to my reconnect implementation being poor, mainly because I've never needed it. She also reports slowdowns but that may be because I am still sending quite a lot of messages out even with no connection in place. Dont know if that is likely ?
(The only issue I might have is that LWT seems to pre-pend some topics to the message it publishes.)
My issue was - when some switch was not used for some time - switching it led to "Client disconnected" message in logs + Switch tile freeze in Wait state in Dashboard
The code was running for more than 2 weeks. Then I decided to remove checking and force connecting every time there is a command push ( no more issues at all )
@podarok One other way to approach this might be to watch for any disconnect message continuously and action a reconnect.
I haven't done this simply because it hasn't ever happened. However I am not handling a reboot of the MQTT broker very well currently as there are a lot of pending messages to send causing a flood of error messages..
the issue is that I found 0 disconnected messages.
But I have different mqtt clients connected to same topics. I have node-red automation all around the network which sends MQTT messages to broker to the same topics as MQTT Driver in HE.
Glitch usually happens when I was trying to ON/OFF from Cloud - it was failing.
With this reconnection and polling I found 0 issues to date, that's why shared a driver to gather feedback.
Thank you all for asking questions.
I tested https://community.hubitat.com/t/mqtt-alpha/15504?u=podarok and it was pretty stable except of the cases when Switch displayed ON, but the real device was OFF
After that I started to build my driver to get rid of
lack of feedback from device
MQTT disconnecting issues
hub and device reboot issues ( unknown state, that's why I'm using retain everywhere )
These are with my app ? You didn't post anything about them in that thread
So you were having disconnect issues with my code too. I have one other user reporting this. I am about to release alpha 4 which includes broker reconnect, which is not currently in alpha3, but I'll have another check over it before I do.
MQTT state feedback should be instant and accurate. Cloud updates within HE dashboard are polled. If you connect/disconnect then you have to poll and that defeats one of the great 'realtime' advantages of MQTT.
Sent a pull request on Github to add polling to the driver itself so that the RM rule is not necessary. Should schedule the poll function to whatever number of minutes are set in the preferences and never if the preference is set to 0. Fee l free to use or not but thought I would pass it along.
Does this require a separate MQTT broker device? O can I achieve this with a Tasmota device and just the HE? (I managed to install Tasmota on a tuya smartlife Outlet and it works great when connecting via the devices webpage, but I don’t want to also have a MQTT broker. I want a simple HE, WiFi router, and end device only setup)
I think it will need it. Unless it's in the tasmota device. But I don't believe so. HE does not run a broker. Though why wouldn't you want a broker on a different device.
And would you happen to have a NAS or some other Linux driven device which never goes off?
There is a driver for tasmota here in a forum where you don't need a broker. It works via http rest api. The only difference is that in current case you have 100% guarantee your switch was toggled. In that case - could be not