First: thanks for optimizing things, much easier to read now
Ahm that’s definitely a new behaviour.
I use several hundreds of template sensors and I did not see that with the old template sensor definition (without the newly added trigger part), I could reload template sensors as often I want, it always had it’s correct value directly and never was unknown.
And I also did not build it for the first time, keeping the UID the sensor is well known to the state machine already, basically only the trigger part was added.
Either that’s a bug with trigger based template entities or I need to somehow work around that (which leads back to the original question: “how to manually set state/value of sensor?” as I have a monitoring system reporting unknown and unavailable entities. Simply suppressing the warning for this template sensor is just the last resort. I think I really want to set the state correctly when reloading/initializing the template sensor. Like it always did.
That’s what I’m talking about. In plain text: this is the first time I use trigger based template entities.
…and I really don’t like that unknown state behaviour. Why? It has all information to render the actual state. I guess it simply waits for one of the triggers to actually…well, trigger - in this two trigger case for a state change of the input sensor. Somehow logical.
So how can I motivate the sensor to leave its unknown state? Thinking bout a fix-automation like “when sensor switches to unknown, do ”. If I could set an entities state, I’d read the input sensor’s state and simply set the same once again, hoping this will trigger the trigger based template sensor to render fine. Aaaaaaah well everything get’s so complicated under the hood, doesn’t it.
Well, at least the “stuck” trigger is working, tested after 30 minutes now. So I swapped one deficiency (stuck sensor) with a new issue (unknown sensor).
Update:
Forget it. After reloading the sensor two more times (after applying the state and availability template optimizations of petro), there’s now unknown state anymore. Seems to work, hopefully
It does not, because you aren’t providing triggers for it.
Trigger based template entities only update when a trigger occurs. You don’t have a trigger for when it reloads, you don’t have a trigger for when you restart. So it gets assigned an unknown state when either of those things occur.
now i can set the attribute “last_room” to person.ben but after some seconds the attribute “last_room” get deleted. Is there any way to store the attribute permanent ?
If I could piggyback from this, hope you don’t mind.
I have Midea Integration installed and one of the entities available is:
binary_sensor.141837000261236_full_dust
I can manually change the state in the Developers tab under states, but it seems to only change it in Hass for a few seconds and then reverts back to the state the unit is displaying.
How can I get Hass to change the state on the AC Unit so that I can use that in an automation for when I clean the filter, I can simply use Hass to turn off the alert; rather than having to load the MIdea SmartHome App to do it? Isn’t this possible?
That means the state is coming from the unit. I’m not familiar with this device but I’d wager you just need to wait for it to report that it’s “not full of dust”.
Okay. Well for now I will just use my IR gateway and see if I can control it that way. I hope the integration opens up this functionality but I am not holding my breathe. LOL Thanks for your response!
Ya, I tried both waiting to see if it sees that it’s clear, to clear that alert on its own, but also turned it off/on several times yesterday trying to get my IR Gateway programmed (which doesn’t have the option to clear the alert).
It looks like I’m stuck having to go into the Midea SmartHome App every time to clear the alert. Sucks!!
I have them both installed LOL. At one point, one would work and the other didn’t. Then it flipped. So I kept both installed just in case one stops working. Haha
Hi,
sometimes the garage door sensor doesn’t detect when it closes and stays set to “open,” even though it’s actually closed. I saw that through the developer tools I can force the state to “closed” (off), and the sensor stays in this state until the next opening.
Now, I would like to set up a button that changes the state to “off” when necessary.
I tried with the script described here, but unfortunately, it doesn’t work.
The script is installed correctly because I can see it among the action options, but I can’t get the button to work. Here is the code:
sorry for the off topic here, but replying to your specific Garage door issue:
my Somfy does the same, and it has to do with delays in the communication in various directions… what you can do is close it again, and it will immediately show the right state?
seems using this python script isnt the right approach for the issue you have.
I stumbled across this thread many moons ago, and used the python script for a while.
As others have said on this thread, if you are manually setting the state of a sensor, you are almost certainly fixing a symptom (hey my thing doesnt always update when it should) and not a problem.
It works, it does what it says on the box, but its just not the right way to do it. In almost every case, a template will be more robust.
thanks for your replay. I am aware that the issue is with communication, but I don’t have good Wi-Fi coverage in the garage. The only way I can solve it is by checking that it’s actually closed and forcing the sensor. For now, this solution is fine.