[RELEASE] MQTT UA Client driver(switch, ir blaster) | tasmota

⚙️ Custom Apps and Drivers
1

Good time of the day, dear community

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.

See

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

TODO

  • H801 dimmer ( tasmota )

These will be added soon ( ~2-6 weeks) once arrived and tested

3 Likes
2

Why is it connecting to MQTT on every action?

3

I found having it connected forever - unstable
Even mqtt.isConnected() shows connected status while it is not anymore.
Broker - mosquitto on raspberry pi

4

If it has to connect to the broker on every command is there a delay?

5
6

@kevin @andrew.rowbottom are you guys seeing this issue when connected to an mqtt broker?

7

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.)

8

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 )

def off() {
log.info "Set OFF"
mqtt = interfaces.mqtt
try {
if (!mqtt.isConnected()) {
mqtt.connect(settings?.MQTTBroker, device.getDeviceNetworkId(), settings?.username, settings?.password)
mqtt.subscribe(settings?.statusfrom)
}
mqtt.publish(settings?.publishto, settings?.publishoff, 1, true)
} catch (e) {
log.error e.message
}
}

9

@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..

10

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 )
11

These are with my app ? You didn't post anything about them in that thread :frowning:
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.

12

Sorry for not posting bugs. Your driver had no ability to set switch state based on response from device. That's why.
Also I found "stuck" issues for the Switch tile. Decided to start from scratch.

13

OK - well you seem well on your way..

I'll leave you to it..

1 Like
14

Slowest speed to date

15

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. :slight_smile:

1 Like
16

Thank you
Merged

1 Like
17

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)

18

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?

19

You still need a broker somewhere in your network. HE team seems like can't still see a value of having MQTT broker installed on HE. Unfortunately

20

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