Interesting - have you read posts about it or how do you come to this conclusion?
Maybe I’m misremembering. But I recall seeing some comments in PRs and issues to that effect when Tasmota dropped HA MQTT support.
I don’t know - I’m just curious. I know that they seem to make extensive use of web sockets for their service-to-service communication. But we’re getting off topic …
For sending commands to devices, it would likely be pretty easy to add. Would it be useful, though? We don’t currently send commands as retained at all.
For receiving messages, I’d have to look into it in more detail. It would depend on the use case (i.e. discovery messages, availability messages, or state messages), and even then it’s probably down in the lower level handling in mqtt (not even mqtt.generic) which I don’t go into much (last time was to fix an issue with handling of retained messages, though). But until someone has an example of a device that uses this feature, I’m not inclined to spend much time investigating it. So many other things that are higher priority!
No, I wouldn’t use it for retained commands but not all messages published by MQTT are commands.
For sensors it’s not unusual to publish messages as retained. That’s how the MQTT Event Bus rule template does it. Without a timeout that last sensor reading stays there forever. With a timeout eventually the reading goes away and there isn’s a false sense of a sensor reading that’s working but is in fact stale. Clients don’t know when a message was published. All they know is when they connected to the broker they got a message.
I was mainly thinking about the publishMQTT Action though, not the Generic MQTT Thing. But it wouldn’t be awful to be able to set a timeout where ever we can set the retained flag itself.
That’s transparent to OH. It’s the publisher that sets the timeout.
It’s a call on the chain in the call to the publishWith method.
Publish - HiveMQ MQTT Client It would be passed along and handled the same as the retained flag.
How set up the "native Tasmota discovery"? - #9 by Johann_Obermeier is the best reference I can find. I would guess he’s a non-native English speaker, so the grammar isn’t completely clear. I read it as “Home Assistant [discover in Tasmota] has deprecated” not that “Home Assistant has deprecated MQTT discovery”. AFAICT MQTT discovery in Home Assistant is alive and well… there have been some recent additions to it. A bit of browsing around looks like the Tasmota was dissatisfied with how their specific features map to Home Assistant’s discovery “schema”, as well as how much code it took for them to implement it, so they made their own that maps more directly to their features, and is more compact. In Tasmota, this is implemented in Sonoff-Tasmota/tasmota/tasmota_xdrv_driver/xdrv_12_discovery.ino at development · stefanbode/Sonoff-Tasmota · GitHub, and it sounds like the Python library Home Assistant uses to parse it is GitHub - emontnemery/hatasmota. It looks like someone started implementing an openHAB binding at openhab-addons/bundles/org.openhab.binding.mqtt.tasmota at main · JoergOstertag/openhab-addons · GitHub, but looks abandoned. I don’t run Tasmota, so don’t have much interest in continuing that work. But if someone else were to finish that binding, I would definitely keep it in mind when doing other MQTT maintenance work.
2 Likes
What I have gathered about HA from using ZUI is that the websocket server is preferred over the MQTT discovery.
edit: Regarding stale data: I have been using the ZUI lastActive (via items) in OH widgets.
I was under the same impression as Rich, but it was from a couple of years ago and I can’t remember where I got the information. I think it’s very likely (in my case) that it started out as “Tasmota has deprecated HA discovery” and turned into “HA discovery is deprecated”.
Yes. To summarize:
- Tasmota: Home Assistant Discovery over MQTT has been completely removed. Tasmota Discovery over MQTT is the only supported method.
- zwave-js-ui: Home Assistant Discovery over MQTT is not supported by the main contributors, but still exists, and PRs are accepted for it. Home Assistant Discovery over WebSocket (and thus protobufs) is the highly recommended method for integrating with Home Assistant.
- ESPHome: Home Assistant Discovery over MQTT is well supported. Though Home Assistant Discovery over WebSocket (and thus protobufs) is recommended, but almost every component works equally well over MQTT.
- zigbee2mqtt: Home Assistant Discovery over MQTT is the only way that it can communicate with other software.
Most/all of these solutions also have a specific Home Assistant add-on that usually just embeds their native UI into Home Assistant’s UI, but I think some of them (obviously Tasmota) do more to extend Home Assistant.
I just want to add a note that it (and everything else related to mqtt) can also be manually configured without paying any attention to tasmota, or home assistant discovery stuff.
1 Like
That was the subject of this topic 
and how my production environments are set-up.
If you have a lot of Zwave, Zwave-JS-UI is a great option (IMO) for the reasons listed above and you don’t have to migrate to HA to take advantage of them. However, I’m sensitive to the fact that there is a certain fraction of the OH community that need auto discovery, just like there is a fraction that will always want textual configuration (and everything in between). I don’t have the coding skills like @ccutrer but have submitted github issues on the problems I encountered using the HA configs when I started this adventure, so that option may be available someday to those that want it.
I have 2 door sensors in my zwave network
but have some issues with ther configuration
The first node id 14 is showing everything and also the basic topic:
But node id 15 is not showing any basic topic at all
How can i get this back?
Try the reinterview option then wake the device. Could be remote. What does the network map look like for hops and speed?
I reincluded them … everything now fine
I have also taken the plunge and moved to zwave-js-ui last week after reading this thread. I have 60 devices and automated the migration using the OH API to add new things and link my existing items. I’m using an Aeotec Gen5+ controller but plan to upgrade to a 700 series controller soon. Everything has been very reliable so far and I’ve updated firmware on over 20 Aeotec devices OTA without any issues.
Few features of zwave-js-ui that make operating a zwave network much easier
- firmware updates
- replace nodes (node id retention)
- useful network map
One problem that I did run into was battery level reporting. The OH zwave binding automatically polls battery levels daily for devices that don’t support unsolicited battery level reporting but zwave-js-ui currently only does this weekly. There’s a facility to configure regular polling of a specific device attribute in the general settings screen in zwave-js-ui which I’ve been able to use to reinstate battery level reporting but it doesn’t seem to work if you poll every 24hrs so I’ve had to poll every 12hrs for now. It’s also possible to perform a poll of a value via MQTT so this could be written as a rule in OH.
Noticed this too. At first I tried the configured poll (and I thought it was working at 24 hours?) but I decided to pick up the device last activity (They still wake about every 24 hours). My battery devices do not degrade very fast and I figured less polling was okay.
UID: mqtt:topic:f06f8352c2:Time_Stamps
label: Time Stamps
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:f06f8352c2
location: Time Stamps
channels:
- id: Last_furnace_flood_n
channelTypeUID: mqtt:datetime
label: Last Activity Furnace flood
description: null
configuration:
stateTopic: zwave2/Furnace_Area_Leak/lastActive
- id: Last_water_heater_flood_n
channelTypeUID: mqtt:datetime
label: Last Activity Water Heater flood
description: null
configuration:
stateTopic: zwave2/Water_Heater_Leak/lastActive
FYI Another difference on the battery devices is that zwave-js will validate both the wakeup node and wakeup frequency if the device wakes up late. This is done for the Zwave specification suggestion.
CL:0084.01.52.03.1 A controlling node SHOULD read the Wake Up Interval of a supporting node when the delays between
Wake Up periods are larger than what was last set at the supporting node.
I have found that some of my battery devices have bad internal clocks so get reminded daily (or so) that they are supposed to wakeup at or before 86400 seconds. Possibly your 24-hour battery poll is missed if the device wakes up early (Does the poll happen the next day?)
I don’t know what this means. Am I correct in thinking it’s an openHABian image that you’ve installed Docker on top of? I know very little about Docker
Also, do you think it would be possible to add ZUI as an option in openHABian? Or are there performance concerns?
It just means don’t ask for support.
It is more of a side by side situation
In the future yes. I do think it could be tight on a rpi3 1GB and with all the forum comments on capacity re OH4 would need to be looked at.
1 Like
Just want paste (not advertise it):
Any suggestions if we could benefit of that hardware? (not software please!!)
This feels a little off-topic.
There’s a similar discussion for the HA boxes. In both cases I’d think its more effort than it’s worth, relative to an RPi 4/5 or similar SBC.