Binary_sensor - How to deal with 'unknown'?

How are people dealing with the new unknown state of a binary sensor?

Here is a trivial example of my dilemma.

Say I want to know the day when the season changes. It is easy to set up a sensor to tell me (see below)

However any restart during the 24hrs the sensor is on will cause it to revert to unknown with no way of ascertaining what to set it to after an HA restart.

The only two (remotely sensible) ways I can think of is to have an input_boolean tied to the sensor which feels like unnecessary redundancy - I might as well do away with the sensor altogether and use an automation. Or to use MQTT, but taking that to it’s logical conclusion implies that all sensors might as well be (better?) handled in MQTT…

What would you do?


  - trigger:
      - platform: state
        entity_id: sensor.season

    binary_sensor:
      - name: TTS Season Changed
        state: >
          True
        auto_off:
          hours: 24
        attributes:
          from: >
            {{ trigger.from_state.state }}
          to: >
            {{ states('sensor.season') }}

For new unknown state I needed to update the template binary_sensors with extra logic to handle this.
I your case you don’t the date of the season change after a start of HA, so the’s no way to determine if the sensor must be True of False. The value ‘unknown’ is a logical state.
You need a persistant way to remember the state and your input_boolean is a way.
Alternatively you can remember the day the season changes (in an input_datetime) and use that date in a template sensor.

Add a home assistant restart trigger

And some extra logic.

Yeah… I’ve read all the discussion around this and I think it is one of those cases where both sides of the argument make a fair case.

Which is equivalent to an input_boolean really so doesn’t answer the (I admit somewhat philosophical) question.

Yes, I do this but I am thinking of cases where the knowledge that something changed is lost.

As I said, I can workaround it, I was hoping I’d missed something more elegant and to my mind more sensible than having an entity record the state of a sensor.

That’s my question… how?

In my specific example I need

Jut to add that I do have a real world use for the answer to this not just the season change.

I have a sensor that senses when I have arrived home from holiday1 which is on for 24 hours to cover anything automations that run that need to know (I didn’t use that in my original question because it is a more complex template)

1Holiday? I’ve almost forgotten what one of those is!!

I really think you’re over complicating this.

  1. You know that you want to ignore changes that occur coming from the state unknown.
  2. You know you only want to it to turn on when the sensor itself changes from one known state to another.
  3. You know if either above occur, that you don’t turn this on.
  4. You know that there are 4 states that are valid for 4 seasons.
- trigger:
      - platform: state
        entity_id: sensor.season
        from:
        - list
        - states
        to:
        - list
        - states
    binary_sensor:
      - name: TTS Season Changed
        state: >
          True
        auto_off:
          hours: 24
        attributes:
          from: >
            {{ trigger.from_state.state }}
          to: >
            {{ trigger.to_state.state }}

and if you want to account for a turn on…

- trigger:
      - id: change
        platform: state
        entity_id: sensor.season
        from:
        - list
        - states
        to:
        - list
        - states
      - id: start
        platform: homeassistant
        event: start
    binary_sensor:
      - name: TTS Season Changed
        state: >
          {{ True if trigger.id == 'change' else False }}
        auto_off:
          hours: 24
        attributes:
          from: >
            {{ trigger.from_state.state if trigger.id == 'change' else states('sensor.season') }}
          to: >
            {{ trigger.to_state.state if trigger.id == 'change' else states('sensor.season') }}

I’m sure there’s more logic you could add to make it more robust, but it’s still not too complicated. Not to mention, if you didn’t use a template sensor and you used an input_boolean, it would be easier:

automation:
- alias: seasons changed
  trigger:
      - platform: state
        entity_id: sensor.season
  condition:
  - platform: template
    value_template: >
      {{ trigger.to_state.state != trigger.from_state.state and trigger.from_state.state not in ['uknown','unavailable'] }}
  action:
  - service: input_boolean.turn_on
    target:
      entity_id: input_boolean.season_changed

- alias: Done changing
  trigger:
  - platform: state
    entity_id: input_boolean.season_changed
    to: 'on'
    for:
      day: 1
  action:
  - service: input_boolean.turn_off
    target:
      entity_id: input_boolean.season_changed
  

This is a decent idea, thanks.

Possibly, but from the purist point of view I still maintain a single sensor is by far the most sensible.

I did see someone suggest that a binary sensor could have an option to remember the last state on a restart. I think that would be a good addition.

But I entirely accept that the devs almost certainly wouldn’t accept this proposition. There seems to be an aversion to ‘allowing users to do things that they didn’t really want to do’.

Anyway, thanks for your thoughts, I’m ‘happy’ to use a workaround.


I don’t agree with this though, I’m trying to make it less complicated :wink:

Old way - 1 binary sensor
New way - 1 binary sensor + another helper or a helper and an automation

New way still has a single binary sensor…. See above. The easier method with an automation has the helper. You could always just leave what you have and account for unknown…