If you set a valid value for initial this integration will start with the state set to that value. Otherwise, it will restore the state it had prior to Home Assistant stopping.
For one of my Input Booleans (created in configuration.yaml), which is controlled via some automations, I do not have a specific “initial” value set, so it should follow the default behavior.
To be clear: I do not have an “recorder:” entry in configuration.yaml, so as I understand it the recorder is (via the History integration) running in the default configuration.
It looks like the last state is not preserved after a restart of HA: the value changed from “true” to “false”.
So is the “Restore State” information incorrect?
Shouldn’t this be:
If you set a valid value for initial this integration will start with the state set to that value. Otherwise, it will start with the default state “false”.
No, it restores the state prior to shutdown. Don’t provide initial and it will always restore state and the default you see in initial will be ignored completely.
Do you have automations that look at this boolean and react to it? On startup, entities will have a state of ‘unavailable’. If you have an automation that turns on or off this boolean, look there and verify that you’re not reacting to a startup.
Thanks.
There currently are two automations that control the input_boolean state, and there is one template sensor monitoring the state.
I don’t think these automations are triggered by startup somehow, and I cannot find any traces from this in the logs, but I will dig into this further and do some more testing.
However, I still think that there is some inconsistency in the documentation.
Normally a default state is valid when a specific setting is not configured. So if the state prior to shut-down is always restored when the initial is not set, then in what situation can the “default” state of the input boolean ever be valid?
As a test I did this:
input_boolean:
cover_status:
name: Cover status
icon: hass:curtains
initial:
But that resulted into:
Configuration invalid
Invalid config for [input_boolean]: invalid boolean value None for dictionary value @ data[‘input_boolean’][‘cover_status’][‘initial’]. Got None. (See /config/configuration.yaml, line 136).
So if the “initial:” option is used it always has to be set specifically, and so can never have a default setting. But if the “initial:” option is not used at all the state prior to shutdown will be restored, so no default either.
Or am I missing something here?
- id: '1634971700221'
alias: De lamellen kunnen open
description: ''
trigger:
- platform: numeric_state
entity_id: sensor.mean_bh1750_lux
above: '75'
condition:
- condition: state
entity_id: input_boolean.blinds_status
state: 'off'
action:
- service: input_boolean.turn_on
target:
entity_id:
- input_boolean.blinds_status
mode: single
- id: '1634971895797'
alias: De lamellen moeten dicht
description: ''
trigger:
- platform: numeric_state
entity_id: sensor.mean_bh1750_lux
below: '10'
condition:
- condition: state
entity_id: input_boolean.blinds_status
state: 'on'
action:
- service: input_boolean.turn_off
target:
entity_id:
- input_boolean.blinds_status
mode: single
This is still a test setup, so only gives a signal that the blinds should be opened or closed.
Could it be related to the lux sensor used as trigger? This currently is a mean value from several bh1750 sensors.
Yes it could be. The logic is a bit off. your availability should be looking at all sensors, not just the first one. Anways, all that can be avoided if you just didn’t use the input boolean and you used the new template sensor platform that allows for triggers to drive template sensors.
Thank you!
That’s looking very interesting and I will certainly implement it.
Most of it is completely new to me, like the grouping and map function, but I will try to fully understand it.
Just to be sure: do I understand it correctly that if I use your code I can use the binary_sensor state as signal to use for further processing?