This is what comes to mind, to address the above.
Need to do some testing, not decided yet…
Suggestions are welcome
Options to prevent message loops:
Prevent calling the /set topic, when the device state is changed from mqtt (state topic)? Make this configurable (on/off)?
Keep track of the last message send to the state topic, skip duplicates if the device state did not change in between?
Always check equality with rounded values if the capability type is integer or a percentage (0...100) to prevent inequality due floating point/scaling differences?
…?
Additional MQTT Device improvements:
Set default percentage scaling to ‘keep original’ (for newly added MQTT Devices)?
If the percentage scaling is set to ‘int (0…100)’ (current default) update the capability details min & max values accordingly? Same goes for booleans and true/false vs. 'on'/'off' etc.
Add ‘advanced options’ to MQTT Device configuration, when adding a new MQTT Device (percentage scaling, on/off value, etc.)?
Allow these options to be configured for each capability seperately (currently per device)?
OR…remove all these options from the MQTT Device completely, it overcomplicates things and can now be controlled using the value templates anyway?
I have hit exactly the same issue on my MQTT app for Hubitat. It is very easy to get these MQTT loops. On that platform too it is not possible to determine from the resulting event what/who triggered the update eg MQTT.
So when an MQTT state update comes in from MQTT I store this as the ‘latestDevice’ and its new ‘latestState’ . I update the Hubitat device which consequently generates an event. On examination if the event comes from the ‘latestDevice’ and the state equals the ‘latestState’ I drop sending the /set back to MQTT. Otherwise I assume the device was changed within Hubitat and send the /set.
This seems to work well and requires only the latest MQTT device to be stored. I am not sure how rapid overlapped device state changes might confuse it, maybe several lastDevices should be pushed and popped. The looping is self cancelling.
The issues of rounding or even devices that when you set to say 53 but report 52 back in state is awkward and so I stored additionally the latestValue that I set the Hubitat internal device to and if that gets immediately evented as the same value I drop the /set . So a device reporting 99 in state gets updated to 100 in Hubitat but I check against the 100 (not the 99) and drop the set.
Not sure I’m doing this right either but I have almost no loops except the ones where you set 53 and it returns 52 causing a loop eventually dropping to 0.
I just wanted to mention another MQTT awkwardness I encountered.
A device that supported 11 dim levels (well 10 dims and off) it needed a 0-100 value so 0,10,20 etc were valid. You could also send a /set of say 7 though and it would return a state of 10. This then appears as a state change and trapping sending another /set of 10 I never found a viable way of avoiding so I just let it do that.
From what I can tell so far everything works as it should.
There’s no extra /set values.
Since Homey doesn’t react with sending extra /set then there is no loop if I only use value*99/100 on the set template. The dim-slider jumps down once 1% as expected until I change the state template to value*100/99 as you suggested and now everything looks great.
One thing that happened before was that I got a loop on a binary switch blinking back and forth. I never really looked in to what was going on but my guess is that I changed state in HA too fast between on/off so that it got out of sync with Homey so it posted on or off to /set when the lamp had already changed state in reality which made another endless loop. But with this change it shouldn’t happen either so I’m happy.
An anecdote that happened is that I added a “Turned on” capability. The trouble here is that while the set topic accepts true/false the state topic will always show 0-99 where 0 means off.
So I had to set the template to not(not(value) It works great, maybe there’s a better way to do it but it shows on/off as it should. (Not saying that this is something for you to do anything about of course).
Not yet…therefore the BluePrint needs to be extended.
Covers are on the list. They are already implemented the other way around (Homey => HA), so it won’t be that hard to add them.
Excuse my ignorance but what is the difference between those two? Covers and blinds. When I read a bit I indeed noticed covers being available for exposure to mqtt. They seem to support everything I need; open, close, stop.
What I currently have is the Home Assistant app installed, have created scripts for UP, DOWN and STOP for every blind and imported those to Homey (the app doesn’t support blinds directly) and have created flows to bind the virtual device buttons to those scipts.
@Martijn_Hoogenbosch The auto discovery creates MQTT Devices based on the provided /config info.
So you could first try to manually add an MQTT Device?