Confused about Input Boolean initial state

On the Input Boolean page there is some confusing information about the “initial” setting.

Under Configuration Variables it says:

initial boolean (Optional, default: false)
Initial value when Home Assistant starts.

But under Restore State it says:

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?

Just post your triggers and I’ll tell you.

You’re welcome to put in a PR to change the docs. The behavior is simple: It will restore a state if initial is not set.

OK, so this currently is the related code in configuration.yaml:

input_boolean:
  blinds_status:
    name: Blinds status
    icon: hass:blinds

binary_sensor:
  - platform: template
    sensors:
      blinds_status_sensor:
        value_template: "{{ is_state('input_boolean.blinds_status', 'on') }}"
        friendly_name: Luxaflex Status Sensor
        device_class: opening

sensor:
  - platform: template
    sensors:
      mean_bh1750_lux:
        friendly_name: "BH1750 - Gemiddeld"
        icon_template: hass:brightness-5
        device_class: "illuminance"
        unit_of_measurement: "lx"
        value_template: >
          {{ ( ( ( states('sensor.d1pv2_01_bh1750_illuminance_1') | float(0) ) 
          + ( states('sensor.d1pv2_01_bh1750_illuminance_2') | float(0) ) 
          + ( states('sensor.d1pv2_01_bh1750_illuminance_3') | float(0) ) 
          + ( states('sensor.d1pv2_01_bh1750_illuminance_4') | float(0) ) 
          + ( states('sensor.d1pv2_01_bh1750_illuminance_5') | float(0) ) )
          / 5 ) | round(2) }}
        availability_template:  "{{ states('sensor.d1pv2_01_bh1750_illuminance_1') not in ['unknown', 'unavailable'] }}"

And this is in automations.yaml:

- 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.

template:
- trigger:
  - platform: numeric_state
    id: 'off'
    entity_id: sensor.mean_bh1750_lux
    above: '75'
  - platform: numeric_state
    id: 'on'
    entity_id: sensor.mean_bh1750_lux
    below: '10'
  binary_sensor:
  - name: Blinds Stratus
    unique_id: blinds_status
    state: >
      {{ trigger.id }}

To fix your lux…

make a group:

group:
  bh1750_lux:
    entities:
    - sensor.d1pv2_01_bh1750_illuminance_1
    - sensor.d1pv2_01_bh1750_illuminance_2
    - sensor.d1pv2_01_bh1750_illuminance_3
    - sensor.d1pv2_01_bh1750_illuminance_4
    - sensor.d1pv2_01_bh1750_illuminance_5

then template

template:
- sensor:
  - name: BH1750 - Gemiddeld
    unique_id: mean_bh1750_lux
    device_class: "illuminance"
    icon_template: hass:brightness-5
    unit_of_measurement: "lx"
    state: >
     {{ expand('group.bh1750_lux') | map(attribute='state') | map('float',none) | reject(none) | list | average }}
    availability: >
     {{ expand('group.bh1750_lux') | selectattr('state','in', ['unknown','unavailable']) | list | length > 0 }}

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?