Closed infeeeee closed 1 year ago
Hi @infeeeee, your solution was in the right way, correct to edit only the configurations for hass and not also the way states are sent. I preferred using a link between command and sensor to explicit the fact that the command has a state in the entire system.
The state_topic
and the command_topic
have to be the same on a linked command. If they are different, than the switch "blinking" on HA, as when you change the switch the state doesn't change automatically, so the flow is something like this:
So on HA it looks like ON-OFF-ON, not nice.
The optimistic
flag should solve this, but it changes the switch to a double command on the UI, it's not nice :(
https://www.home-assistant.io/integrations/switch.mqtt/#optimistic
So I recommend using the same KEY and topic for both the sensor and the command. Is there any bad side effect for this? That was the reason I linked them by key, not by another parameter.
Or the callback should also update the sensor automatically, but simply using the same key would be easier.
I just added a really simple FileSwitch entity, it's easier to debug linked commands with this, you can see this "blinking" behavior, I'm speaking about, why I recommend having the same topic for state and command topic.
Okay, got the problem. The reason I wanted to use a different key is because if the sensor data is sent as sensor (for non homeassistant warehouse), the key of the sensor may not define what the sensor value is, if equal to command key (maybe not in this case for monitor)
So currently the solution I found is to send state value to command topic if it's linked to a command in the home assistant warehouse and do not use its key for the topic
@infeeeee but if we send sensor state on command state we continue to call the command callback; I don't think it is a correct behavior.
No solution found, I think we have to set different topics for sensor and command :(
If you want to have different topics, other option would be to update the sensor after a callback. Not with the other sensors, but an extra update.
Also still don't get why is it a problem, if they have the same topic. I get it's a problem, if the key is the same, but another solution could be in this case NOT use the key as the topic, but something else. Both MQTT and HA should let you use the same topic, it's only the KEY is the problem.
That's 2 possible solutions
The problem is not with the key, but with the message that the sensor sends to home assistant. Sending the message to the same topic the command is subscribed to, will trigger the command. So the command are now triggered by
And the command triggered every 10 seconds is not a great thing in my opinion. What do you think ?
I see. Maybe a check in the callback, to only run if the command state is not the same as the current state? Do nothing if it's the same.
Or my other solution with different topics: send one out of loop update to the sensor, instantly, from the callback. I can't see a downside of this way. Maybe miss the next sensor update, in this case, so they won't run at the same time accidentally.
With this commit, when a command is triggered from HA warehouse, if the command is a switch, also send the just received state to the topic of the sensor relative to the switch
So with this edit we can use different topics for sensor and command in my opinion. What do you think ?
Now I need to separate the two topics (sensor and command) which were re-joined
I will take a look
With these changes it seems solid
I will check tomorrow, or later today, don't pull it yet
Yes I would have waited for you anyway :)
So I added some small fixes:
data_type == 'switch'
!= entityData.SupportsState()
:
I tried to solve this, adding a new local variable entitycommand_supports_state
was easier, than adding a lot of multi level if
s
If it's ok for you, you can pull it, I don't want to add any more changes. :rocket:
Nice ! Yes I think it's time 🚀
Retrying #29