Yes, that was added recently to is_state
I did, but it was not helping
It is full of Traceback but not related to this, like
2023-02-15 13:57:50.202 WARNING (MainThread) [aioesphomeapi.connection] nodemcu @ 192.168.0.101: Connection error occurred:
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 537, in send_message_await_response_complex
await fut
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 536, in send_message_await_response_complex
async with async_timeout.timeout(timeout):
File "/srv/homeassistant/lib/python3.10/site-packages/async_timeout/__init__.py", line 129, in __aexit__
self._do_exit(exc_type)
File "/srv/homeassistant/lib/python3.10/site-packages/async_timeout/__init__.py", line 212, in _do_exit
raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 320, in _keep_alive_loop
await self._ping()
File "/srv/homeassistant/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 645, in _ping
await self.send_message_await_response(PingRequest(), PingResponse)
File "/srv/homeassistant/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 554, in send_message_await_response
res = await self.send_message_await_response_complex(
File "/srv/homeassistant/lib/python3.10/site-packages/aioesphomeapi/connection.py", line 539, in send_message_await_response_complex
raise TimeoutAPIError(
aioesphomeapi.core.TimeoutAPIError: Timeout waiting for response for <class 'api_pb2.PingRequest'> after 10.0s
Because one of my ESPHome sensor has no power right now.
EDIT But yes, a race condition could set the value to unknown, I can understand that, that is the point of this topic, understand why, even if it is virtually impossible (except restart) for that sensor to be something else than true or false, in reality, because of <insert here a reason> it might randomly show as unknown. And not captured by the logbook.
I hide those warnings with logger. You might want to do the same
As above initial logs from the UI, timeout-connection-errors in general on several templates/services etc. … i would interpret this as the cause that your “template-sensor” can’t receive status of the "
binary_sensor.smoke_1 " , so you get your “unknown”
EDIT: Yes im only guessing 
… and would have jumped direct to my automations, and secured that they would ignore this state, or throw a message/Warning, as it could be do to the fact that the "
binary_sensor.smoke_1 " was Smoked ! 
I did, but then I was like, maybe I can solve some, and as a computer scientist, I don’t like warning either.
Old habbits
If it’s used in an automation, then what’s wrong with triggering from off to on? This ignores “unknown” or “unavailable” states.
Here is how I detect if a door switch is on for one second:
Because on to off or on to unknown or on to unavailable are all the same to alert.
But from on to “something else than off” for the smoke detector itself is a different story.
Moreover, as the off is coming from the last will in mqtt, it can be before the unavailable or after and I wanted to trigger on the first of the 2 and only once.
That is what I’m trying to achieve, with timer, knowing that my D1mini is sending an on state instantly then every 10 seconds, knowing that the D1mini can burn, or the detector but not the D1mini (yet) or, or, or
And that is the reason why I wanted to “externalise” the alert mechanism outside the “basic” AI that I’m building around my sensors, the last_updated and other things like ping sensors and other stuffs and simplify it to the maximum:
on : my house is burning
off : stop sounding, in any case either the house is just a pile of ashes or it was a false alarm. But it is too late anyway.
I think you should move to an automation then. If you have the template you were trying to use, I can help you tailor an automation (with a template that combines the result) that turns on/off a input_boolean and that will always be available & known. I do this in 1 case with my washing machine because it’s finicky and I don’t want unknown values mucking with my wash cycle detection.
Apparently during reload templates are unavailable not unknown, during startup they are unknown.
Thanks a lot!
All these things about sensors are sometimes a bit complicated for me…
Thanks but at the end I got a trigger sensor from Taras and it is working well.
I marked that topic as solved but it was not really a solution, more a workaround.
I did open a new one, this one, to go to the bottom of the reason why it was not always true or false.
Even if I don’t have the end of the story yet, I’d assume that it is about the performances of my RPi and will see how it behaves the day I’ll change it. It will be fairly easy to assess as today, this sensor is unknown at least 2 or 3 times per day.
P.S.: For who is interested in the trigger sensor, here is the link to the topic, look at the post marked as solution.
If I may ask a follow-up on the topic of unknown states as something I’ve wondered about, but never asked: Some sensors will have their states restored. Under what circumstances is that the case and are template sensors part of that? I think the latter part is a yes, since I have a trigger-based binary sensor that does and I remember the release that brought that change. If states can be restored, why in general wouldn’t the last known state then be kept instead of being unknown? Basically, it would then be the same as an MQTT sensor with a retain flag. Or is it the case that it is restored, but restoring itself takes time and during that time it would be unknown?
1 Like
The unknown comes from the time when the integration is booting up, depending on the speed of your machine, you may or may not see this state. My trigger based template sensors usually don’t have these state changes in the logs or database. But CommandCentral from the dev team confirmed that this unknown to known state change does not trigger automations.
Unknown or unavailable. I have never seen a sensor go to “Unknown” unless I physically remove it (I.E., unplug it).
With this, do you mean including to restore states? Are states restored by the integrations or by the core?
The current code leaves this decision up to integrations. HA core handles state restore but does not decide which entities to capture and restore state for. The python classes for entities which restore state inherit from RestoreEntity to make this happen.
Trigger template entities do restore state. This is because their state can’t be easily reconstituted otherwise. Their state isn’t updated until the trigger fires and that could be a long time after startup.
Non-trigger template entities do not restore state. Their state can be easily reconstituted by simply evaluating the template. Which is what HA does on startup already for all non-trigger template entities.
Because HA is already doing enough writes to the disk, it does not want to add more unless absolutely necessary. The way restore state works is every time the state of an entity which needs to be restored is updated HA writes its state to .storage/core.restore_state. So basically every state change of that entity is written to disk twice - once to history in the DB and once to this JSON file.
There’s no reason to do this if the state of the entity can be easily reconstituted as part of integration load. By re-running a template, contacting a service/device to ask for its current state, etc.
Even if the state can’t be easily reconstituted sometimes the integration author decides that it shouldn’t restore state. This can happen if the entity has very frequent updates. That would be a lot of disk noise or very little value since the integration will receive a state update shortly after startup.
Or perhaps the restore state feature really can’t work for a particular integration. Like the filter integration for example, which calculates the state based on a collection of recent state updates. Even if it kept the last known state through a restart that wouldn’t be helpful because it would’ve lost the collection of state updates it used to figure out that state. Now it becomes just one data point when before it was based on a whole bunch.
There are other examples. The point is its a bit complicated and as a result the integration has to decide what to do. Feel free to submit a Feature Requests for a particular integration if you think it should be restoring state and isn’t though.
2 Likes
From dev to dev: Thanks for that in-depth answer. I can see that various options are needed and there’s no (single) default behaviour. I have no specific issue with an integration. It was about understanding the general behaviour better — which turns out are valid in plural.
1 Like
And that’s the tricky part. According to the logbook, it is not switching to unknown. Nevertheless, it is switching to off (from off if you look at logbook, from unknown if you look at history).
And that transition is triggering the automation “to off”.
Weirdly enough (or logically, I don’t know), if I do the automation “to unknown” or “to unavailable”, that one is not triggered.
So, it is like the automation is more like the logbook, not detecting the transition to unknown but detecting the one to off from “I don’t know” as the previous state, according to logbook, was already off.
That’s so confusing.
Thank you for that explanation, I was wondering why the trigger template given by Taras was working better than the non-trigger template I did. Now I know. As the smoke detector is expected to not trigger hopefully, it is definitely something to put as a trigger template.