In binary_sensor, even if is_state is always true or false, the template is not

[arganto]

@CentralCommand

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.

So even if HA was switched off for 24h, after restart it has the value from before and the history is showing no unavailability or unknown gap for these 24h and shows the same/old state for this 24h as well?

@CentralCommand

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.

Why is the DB-Value not taken and this double-store needed?

[CentralCommand (Mike)]

@arganto

So even if HA was switched off for 24h, after restart it has the value from before and the history is showing no unavailability or unknown gap for these 24h and shows the same/old state for this 24h as well?

I’d guess there’s a gap but idk, haven’t really tried that. Give it a shot I suppose.

@arganto

Why is the DB-Value not taken and this double-store needed?

Well for one, it may not be in the DB. Users can control what is is or isn’t recorded to the DB via the options in recorder. If the DB was used for restore state then excluding an entity there would prevent it from working correctly as its state could no longer restore.

Plus lots of users use external services like MariaDB and Postresql for DBs. If HA depended on the DB for restore state then a poorly timed restart or connection issue with that service (during HA startup) would completely hose HA. Its window to restore state would be missed and many things would just be in the wrong state with no way to recover what they’re supposed to be.

I also think in general the HA team does not want anything in the DB that is integral to getting HA into a working state. That means no config, auth info, and (it would seem) state restore info. By exclusively using the db for history, the worst issue a connection issue or downtime could cause is missing a few events and the history UI doesn’t load for brief window. HA won’t break if the DB goes missing no matter when that happens.

Perhaps if sqlite3 was the only option for DB some of this could change. Then HA would no longer have to worry about the connection issues or downtime with the DB service since its fully internal and local. But the DB service option means HA has to treat it as a service and assume there will be issues to handle.

[sholofly (Rudolf Offereins)]

I experience something similar with a template sensor based on an attribute. I’ve got an automation with a trigger on the update for that sensor value . When reloading my template entities the automation is triggered. In the trace of the automation I see the value changes to null and then back to the original value. I’ve tried to catch that one by adding an empty not_from and not_to option to the trigger. But that didn’t work. End up with adding a template condition: {{ trigger.from_state is not none and trigger.to_state is not none}} But expected this to work according to the documentation of the state trigger.