The ‘setTopic’ is called when the MQTT Device state (capability value) is changed.
A change can be triggered manually, via a flow / script or a message on the state topic…
Why is the set topic called when the MQTT Device state changes? Is this wanted behavior?
Yes, that’s wanted behaviour.
If you change the value in Homey (dim slider / button press) you want the value to be send to the listening party(ies). It’s 2-way communication…and I have no clue who is listening an who changed the value.
This loop will break if the incoming value equals the current value (state). But I agree is not stable the way it’s implemented now. Needs some attention…
But this isn’t what I’m talking about.
It’s very clear from the Mosquitto log and from my tests that when I change the value of the device from OTHER sources than homey and homey sees this state change of the state topic it puts this change into the SET topic.
The /set topic should never be updated by Homey on device state change
This is absolutely what is happening here.
Homey receives a new value for the capability (unregarding the source) and therefore calls the setTopic (in a seperate process). My above statement is not correct…
Why though? Since /set is not a state topic why does it need to reflect the state? I don’t get it. HA does NOT work this way either.
Do you want the dim level to be send to the set topic when changing the value from within Homey (adjusting the slider)?
I do yes. When I change the value of a device in Homey I want Homey to post to /set.
When I change the value of the device from another source ideally I want Homey to read the state topic and change the state shown in Homey to reflect the real state of the device. I do not want Homey to adjust the /set topic to reflect this because it increases traffic in the MQTT stream with no benefit that I can think of at the moment.
Two things:
- I don’t know who changed the value (the slider, script, flow, or mqtt input).
I’m not sure what you mean by this. What value?
If the state changes then something has made it change and Homey should update its device to reflect the current state. Why involve /set?
Maybe I’m just not understanding some part of this.
- There can be multiple listeners, these also need to know the new value if adjusted from mqtt.
But these listeners are listening to the state topic that updates from zwavejs2mqtt after it has performed the /set task. I’m not pointing my listeners to the /set topic. The only subscriber to /set should ideally be zwavejs2mqtt and noone else. That’s the only device that should care what’s written there.
The Homey capability value. That’s what’s being updated when the external device state changes (message on value/state topic). A value changed listener on this capability fires the /set message. That SAME capability value gets updated when moving the slider.
I’m sorry I don’t really understand this.
What’s Homey capability value?
“capability”: “dim”,?
Yes
Basically I’m starting to believe that this is a limitation of Homey.
When you change state of the Homey device it might be that Homey sees this as the same thing as moving the dim-slider which then triggers /set.
(Maybe that’s what you’ve been trying to tell me)
correct. It’s like the same variable getting changed.
Thanks for explaining. That’s a bit disappointing then since it seems impossible to solve.
We’re not done yet!
Next thing would be to try to detect if the change is just triggered by an incoming mqtt message (we know ofcourse) and adjust the behaviour if needed.
Yeah if that’s possible!
All is possible 
, but I’m not sure yet if its the correct solution.
Breaking the loop when the values are equal (meaning all devices got the correct value), should also do the trick. But obviously, it’s not working as expected the way it’s currently implemented…
Did some re-reading and there are some additional points to make:
Since the introduction of the value template (i.e. mathJS), this ‘percentage scaling’ option is obsolete (and even confusing sometimes). I already planned to change the default setting from int (0...100) scaling to keep original value, for newly created MQTT Devices. The downside: the value template is probably needed for every percentage value, because Homey scales all percentages between 0…1 while the rest of the world uses 0…100 (or 0-99 in your case). But it removes the ‘magic’ behavior and the values line up with the displayed capability details.
