What items (sensor platforms/ helper integrations) survive a home assistant restart? Am I taking things for granted?

Hi all,

Hoping you all can shed some light on the subject of this post. I know it is a very general statement but I’ve read some things that has me concerned.

Do input types such as input_number…, input_boolean… etc. maintain their last state before the restart? How about a sensor such as an mqtt sensor? How about when you create a template sensor? How about a statistics sensor? How about a history sensor? I’m just trying to make sure I am guarding myself against a device/ sensor that is holding a certain value (calculated/ state determined etc.) clearing itself after a home assistant restart. Thank you all ahead of time for the conversation!!

I was hoping someone could give me a general overview of things to watch out for in this situation.

After a restart, Helpers and Trigger-based Template Sensors are restored to their previous state.

For an MQTT Sensor, it always gets whatever value is specified by its topic. So if the topic’s value is retained by the broker, it will get that value on startup. If the topic’s value isn’t retained, on startup the sensor’s value will be unknown.

Template, Statistics, and History Stats sensors compute their values on startup.

FWIW, if a Template Sensor is dependent upon an entity that may take a long time to initialize on startup, the Template Sensor’s initial value may be unavailable for a short time. To mitigate this, the Template Sensor should employ the availability feature.

This isn’t 100% true for template anymore. Trigger-based template sensors and binary sensors do not do this anymore. They have restore state functionality and their last known state is carried over restarts. Non-trigger based template sensors work as you describe.

Also I believe the delay_on, delay_off and auto_off options now survive restarts for trigger-based template sensors as well. So if a restart occurred while a trigger-based template sensor was delaying turning on or off it stashes the expected time of change and either continues waiting or changes the state after the restart completes, depending on whether that time is now in the past or not.

But yea @wtstreetglow most integrations that reprocess other data in HA (like template) don’t restore state. There’s not clear cut rules here though, it’s kind of a per integration question. The input_* helpers do, other things vary. Testing is probably your easiest way to determine whether it does or not. Else you can review the code. In the code what you would be looking for is an inheritance to RestoreEntity (or something that inherits from RestoreEntity like RestoreSensor). For example Trigger template sensor entities have this here:

But non-trigger template sensor entities don’t so they are calculated on startup:

The first line of my post did mention Trigger-based Template Sensors are restored. By association, that includes Trigger-based Template Binary Sensors.

I believe this functionality was added in the April release (because many people found it inconvenient for the Trigger-based sensor/binary_sensor to report unknown on startup). It was the users employing the delay-oriented options that were one of the first to express their dislike for how the entity persisted as unknown regardless of the option’s use.

Right, sorry, I missed that.

Haha yea I was definitely one of those people. Although I actually found it the most painful for trigger template selects since without restore they have no options on startup until the next trigger comes in. So not only is their state unknown, the select.select_option service call will simply fail even if you know an option should be there. Unfortunately those have not been given restore functionality yet, only sensors and binary sensors so far.

@Taras thank you for your response and all of the help you have given me in the past.

This is good to hear.

I am still very new at all of this, what exactly is a “Trigger- based Template Sensor”, could you give me an example of this? Is the below possibly a “Trigger- based Template Sensor”? (This is the package and automation)

###################################################################################################
## Package - Unavailable Entities Sensor
## Count and list entities with a state of unavailable, unknown, or none (null)
## See README for customization options.
## https://github.com/jazzyisj/unavailable-entities-sensor/blob/main/README.md
###################################################################################################

# NOTE: Home Assistant v2021.12 required.  For older versions please see README
# REQUIRED - This is the template sensor
template:
  - sensor:
      - name: "Unavailable Entities"
        unique_id: unavailable_entities
        icon: "{{ 'mdi:alert-circle' if states('sensor.unavailable_entities')|int(0) > 0 else 'mdi:check-circle' }}"
        unit_of_measurement: entities
        state: >
          {% if state_attr('sensor.unavailable_entities','entity_id') != none %}
            {{ state_attr('sensor.unavailable_entities','entity_id')|count }}
          {% endif %}
        attributes:
          entity_id: >
            {% if state_attr('group.ignored_unavailable_entities','entity_id') != none %}
              {% set ignore_seconds = 3600 %}
              {% set ignore_ts = (now().timestamp() - ignore_seconds)|as_datetime %}
              {% set entities = states|rejectattr('domain','in',['group','button','automation','scene'])|selectattr('state','in',['unavailable','unknown','none'])|list %}
              {% set buttons = states.button|selectattr('state','eq','unavailable')|list %}
              {{ (entities + buttons)
                |rejectattr('entity_id','in',state_attr('group.ignored_unavailable_entities','entity_id'))
                |rejectattr('entity_id','search','keymaster')
                |rejectattr('entity_id','search','weatherbit_')
                |rejectattr('entity_id','search','media_player')
                |rejectattr('last_changed','ge',ignore_ts)
                |rejectattr('entity_id','search','search4text')
                |map(attribute='entity_id')|list }}
            {% endif %}

# REQUIRED - Add any entities you do not wish to monitor in this group.
# IMPORTANT - This group MUST exist even if empty for sensor template to render.
group:
  ignored_unavailable_entities:
    entities:
      - sensor.unavailable_entities # prevent template loop warnings?
      - binary_sensor.back_porch_outlet_heat_alarm_overheat_detected
      - binary_sensor.garage_door_access_control_barrier_sensor_low_battery_warning
      - binary_sensor.garage_door_access_control_barrier_sensor_not_detected_supervisory_error
      - binary_sensor.garage_door_access_control_barrier_unattended_operation_has_been_disabled_per_ul_requirements
      - binary_sensor.garage_door_home_security_tampering_product_cover_removed
      - binary_sensor.garage_door_low_battery_level
      - light.desk_lamp
      - sensor.clarice_charger_type
      - sensor.gym_active_app
      - sensor.gym_active_app_id
      - sensor.living_room_active_app
      - sensor.living_room_active_app_id
      - sensor.master_bedroom_active_app
      - sensor.master_bedroom_active_app_id
      - select.living_room_channel
      - select.gym_channel
      - select.master_bedroom_channel
      - sensor.activewindowsensor
      - binary_sensor.namedwindowsensorretrobat
      - sensor.holiday
      - sensor.weatheralerts_alert_3_last_changed
      - sensor.weatheralerts_alert_4_last_changed
      - sensor.weatheralerts_alert_5_last_changed
      - sensor.weatheralerts_alert_3_most_recent_active_alert
      - sensor.weatheralerts_alert_4_most_recent_active_alert
      - sensor.weatheralerts_alert_5_most_recent_active_alert
      - sensor.washer_last_complete
      - sensor.pirateweather_precip
      - sensor.front_door_motion_away_count
      - sensor.lightning_near_home_lightning_azimuth
      - sensor.lightning_near_home_lightning_distance
# OPTIONAL - filter template loop warnings from the Home Assistant log.
logger:
  filters:
    homeassistant.components.template.template_entity:
      - "Template loop detected while processing event"
# OPTIONAL Example automation to demonstrate how you can utilize this sensor
# SEE Automation.yaml
alias: (ACTION- AUTOMATIC- SECURITY- NOTIFICATION) Unavailable Entities Notification
description: >-
  Create persistent notification if there are unavailable entities, dismiss if
  none.
trigger:
  - platform: state
    entity_id: sensor.unavailable_entities
    to: null
condition:
  - condition: template
    value_template: |
      {{ is_number(trigger.from_state.state)
          and is_number(trigger.to_state.state) }}
action:
  - if:
      - condition: numeric_state
        entity_id: sensor.unavailable_entities
        below: 1
    then:
      - service: persistent_notification.dismiss
        data:
          notification_id: unavailable_entities
    else:
      - service: persistent_notification.create
        data:
          title: Unavailable Devices
          message: |-
            - {{ expand(state_attr('sensor.unavailable_entities','entity_id'))
                  |map(attribute='name')|join('\n- ') }}
          notification_id: unavailable_entities
      - service: notify.mobile_app_weston
        data:
          title: Unavailable Devices
          message: >-
            {{
            expand(state_attr('sensor.unavailable_entities','entity_id'))|map(attribute='name')|join('\n')
            }}

So for these mqtt sensors, do I need a line to tell it to retain whatever is in these sensor? Especially the
“Washer Status” one. It seems like I wouldn’t want these to reset after a restart because I imagine they would go back to an “unknown” status almost as if they have never been instantiated. I believe these are first loaded with data after the first run of an automation related to each the sensors.

Ahh, exactly what I was thinking, sorry, I should’ve read your reply fully before I typed the above.

How do I go about making the topic value “retain”

sensor:
   # MQTT Sensor for Washing Machine Status. 
  - platform: mqtt
    name: "Washer Status"
    state_topic: "house/washer/status"
  - platform: mqtt
    name: "Washer Last Complete"
    state_topic: "house/washer/time_complete"
  - platform: mqtt
    name: "Washer Last Emptied"
    state_topic: "house/washer/time_emptied"

As a side question, why do my time sensors show these crazy numbers rather than a date and time? (YYYY/MM/DD, 12:53 PM)

Nice, I understand this.

Thank you for clarifying this detailed point and thank you for being so helpful, one day I will know what I am doing, at least at a level that is sufficient for the simple stuff.

Also, one last random question about home assistant in general, do you feel like they are trying to make it more “main stream”, in terms of useable for new adoptees? I feel like compared to a few years ago when I gave up on it to be honest, things have changed immensely for the better, expecially, all of the UI improvements, are “they” trying to make home assistant mostly UI dependent now to increase adoption amongst the more incapable with code as myself?

Thank you again @123, and sorry this got so long.

@CentralCommand thank you for your replies here and in the past when you have helped me also. It is very much appreciated.

So for these, you have to specify when you are instantiating it that you want it to “restore state”

Nice, I’m not advanced enough to have used this yet but this knowledge may come in handy in the future.

Thank you for this, I had a feeling this was the case.

Thank you for these ideas. I’m following you. (That was the next thing I was going to ask)

I feel my brain melting when the python examples come out. I follow what you are saying though.

I am finding this to be annoying in a bunch of instances. I have an automation that runs to tell me of entities that are in unknown statuses (actually the one I posted just a bit earlier) and I have an ignore section that just keeps getting longer and longer. I always feel like there has to be a better way for home assistant to deal with this but I don’t think there is. Is this just poor integration from the people writing software for home assistant? (I’m not a programmer, but I always feel like home assistant shouldn’t mix attributes/ variables (whatever you want to call them), it’s hard for me to determine when something is broken in my setup or when a variable/ attribute/state just hasn’t been assigned to the entity/ attribute being looked at. ----Maybe you could provide a little guidance on this for me? —even though I know it is off subject here.

It’s literally a Template Sensor with a trigger. Its template is evaluated when one of its triggers is triggered.

It’s the responsibility of whatever device is publishing to house/washer/status to publish it as a retained message.

I don’t know anything about the device that’s publishing that value but it appears to be publishing a Unix timestamp value (which can be converted into datetime value).

I follow you

I follow you now.

I’m sure you’re correct. Below is the publish message. And, as I’m sure you can already tell, I usually have no clue what I am doing with HA but am getting better everyday. Thank you for putting up with me. You are very helpful. So I believe the below is the culprit of the funky time message. I just need to look into how to convert it?

    - service: mqtt.publish
      data:
        topic: house/washer/time_complete
        payload: '{{ now().timestamp() }}'
        retain: true

You can do this:

    - service: mqtt.publish
      data:
        topic: house/washer/time_complete
        payload: '{{ now().isoformat() }}'
        retain: true

Then add device_class: timestamp to the configuration of sensor.washer_last_complete.

  - platform: mqtt
    name: "Washer Last Complete"
    state_topic: "house/washer/time_complete"
    device_class: timestamp


NOTE

If the suggested new sensor configuration doesn’t work as expected, change the payload template to:

        payload: '{{ utcnow().isoformat() }}'

@123 Thank you for helping me with this. I feel like everytime I turn around you’re having to help me with something. Thank you so much again for offering your expertise as I get more accustomed to home assistant. Also, I’m going to go through before I go to bed tonight and select a solution on all of threads I have started here since the start of my migration to home assistant.

If I choose to go this route. I don’t use the device_class line at all within the sensor setup/ platform area? Sorry, and thank you for the clarification ahead of time.

Use device_class: timestamp in either case.

I appreciate this @Taras. Could I add one additional question to this revolving around the integration of my “dumb” washer within HA. My “washer status” mqtt sensor keeps going to “unknown”. I believe this is happening after HA restarts but I’m not 100% sure. Below I have posted everything that revolves around this appliance. Could you help me troubleshoot if there is anything you see that is causing this issue (I think I am missing some logic or an automation to stop this but in all honest, I feel like this should never happen after the first time data is pushed to this mqtt topic). I will try my best to post the things involved below. These are all in a package:
Sensor Creation:

sensor:
  # # MQTT Sensor for DishWasher Status.  
  # - platform: mqtt
  #   name: "DishWasher Status"
  #   state_topic: "house/dishwasher/status"
  # MQTT Sensor for Washing Machine Status. 
  - platform: mqtt
    name: "Washer Status"
    state_topic: "house/washer/status"
    device_class: timestamp
  - platform: mqtt
    name: "Washer Last Complete"
    state_topic: "house/washer/time_complete"
    device_class: timestamp
  - platform: mqtt
    name: "Washer Last Emptied"
    state_topic: "house/washer/time_emptied"
    device_class: timestamp

There are 4 Automations. “Washer Running”, “Washer Complete”, “Washer Notification”, and “Washer Emptied”:
Pasted below the automations is the history screenshot of the “house/washer/status” sensor. I’m confused on why it is going to “unknown”?
Thank you for your guidance on this and if you believe I should put this in a new post, I can delete this and post in a new one.

automation:

  - id: washer_running
    alias: Washer Running
    trigger:
    - above: 4
      entity_id: sensor.washer_power_consumed_w
      platform: numeric_state
    condition:
      condition: or
      conditions:
      - condition: state
        entity_id: sensor.washer_status
        state: idle
      - condition: state
        entity_id: sensor.washer_status
        state: complete
    action:
    - service: mqtt.publish
      data:
        topic: house/washer/status
        payload: running
        retain: true
    initial_state: true

  - id: washer_complete
    alias: Washer Complete
    trigger:
    - below: 2
      entity_id: sensor.washer_power_consumed_w
      platform: numeric_state
    condition:
    - condition: state
      entity_id: sensor.washer_status
      state: running
    action:
    - service: mqtt.publish
      data:
        topic: house/washer/status
        payload: complete
        retain: true
    - service: mqtt.publish
      data:
        topic: house/washer/time_complete
        payload: '{{ utcnow().isoformat() }}'
        # payload: '{{ now().timestamp() }}'
        retain: true
    initial_state: true

  - id: washer_notification
    initial_state: true
    alias: Washer Notification
    trigger:
    - platform: state
      entity_id: sensor.washer_status
      from: running
      to: complete
    action:
    # - service: script.status_annc
    #   data:
    #     who: '{{ states.sensor.room_presence.state }}'
    #     call_interuption: 1
    #     speech_message: It appears the washing machine has completed its cycle.
    - service: script.speech_engine
      data: 
        who: 'kitchen'
        message: 'Just a quick heads up, It appears the washing machine has completed its cycle'
    - service: script.turn_on
      entity_id: script.washer_finished_notification_audible

  - id: washer_emptied
    initial_state: true
    alias: Washer Emptied
    trigger:
    - platform: state
      entity_id: binary_sensor.washer_door
      from: 'off'
      to: 'on'
    action:
    - service: mqtt.publish
      data:
        topic: house/washer/status
        payload: idle
        retain: true
    - service: script.turn_off
      entity_id: script.washer_finished_notification_audible
    - service: mqtt.publish
      data:
        topic: house/washer/time_emptied
        # payload: '{{ now().timestamp() }}'
        payload: '{{ utcnow().isoformat() }}'
        retain: true

You can only specify timestamp for a sensor’s device_class if its state value is a proper date and time string in ISO format like 2022-06-23T23:50:00+00:00. You specified it for sensors whose value is not a date and time string. For example, sensor.washer_status has a value like “running”.

Remove the device_class option for the non-time-based sensors.

You always catch me doing such dumb things. This has been corrected.

Thank you for that @123, I will see if the unknown situation goes away after the next few days or the next time I run the washer.

Hi @123
I have been reviewing this Washer automation a bit more and still haven’t got this working quite right just yet.-- I am just taking things one issue at a time to see if I can get everything working properly.

One question I have is, it looks like the below is giving UTC time. Is there a way to get it to give Eastern Standard time (I guess this gets more complicated during daylight savings time, I don’t even know if it’s possible to adjust for that)

'{{ utcnow().isoformat() }}'

For instance, right now, it is 9:57 am where I am but UTC looks to be 4 hour difference showing 13:57 pm.

The last question would be, can we get the reporting to be on a 12 hour clock rather than a 24 hour clock?

I’m sorry for always having to ask additional questions, but I believe I’m at the point of I don’t even know the questions to ask without the trial and error.

Thank you@123 for all of the help you have provided me in the last bit!!

Developer Tools → States displays an entity’s actual state value. Timestamp sensors store their datetime value in UTC so that’s why Developer Tools → States shows it in UTC.

If you view a Timestamp sensor in an Entities Card in the Dashboard, it’s displayed as a time difference between now and the Timestamp sensor’s value adjusted for your local timezone. That conversion is performed by the card.

Displaying time in 12 or 24 hour format is controlled by your User profile. Click the last icon in the menu and modify Time Format. Whatever option you choose is used exclusively for displaying the time on that device (phone/tablet/PC). In addition, it doesn’t change how time is displayed in Developer Tools → States.

Thank you for your guidance on this. I understand.

Ahh, I follow you. I was mostly talking about in developer tools but I think you answered this with your previous response. And I see your extended response now after reading the full answer in your 3rd paragraph. Thank you for all of the help you have provided me with @123. I really do appreciate it.

1 Like