Code Works in One Template but Shows 'Unavailable' in Another – Mysterious Behavior in Availability Template

Hi everyone,

I’m facing a puzzling issue in my Home Assistant setup. I have two template sensors with nearly identical logic, but one works flawlessly while the other is always marked as “unavailable.”

To provide context, both sensors depend on a binary sensor (binary_sensor.delayed_ct_gpos_power_a_availability) for their availability template. Below is the complete configuration for the binary sensor, along with the two template sensors.

Binary Sensor Code (Referenced in Both Template Sensors):

- binary_sensor:
  - name: "Delayed CT GPOs Power A Availability"
    unique_id: "8459716d-1ee0-43ef-9cf7-184c5871d6c2"
    state: >
      {% set gpos_state = states('sensor.ct_gpos_power_a') %}
      {% set uptime = (now() - (states('sensor.uptime') | as_datetime(default=now()))).total_seconds() %}
      {{ gpos_state not in ['unknown', 'unavailable'] and uptime > 60 }}
    delay_on:
      minutes: 1

Template Sensor Code A (Shows as “Unavailable”):

- sensor:
  - name: "GPOs Power A - Excluding Smart Plugs NEW 3"
    unique_id: aa8763f7-b818-45f6-a024-898631832f91
    unit_of_measurement: "W"
    device_class: power
    state: >
      {% set ct_gpos = states('sensor.ct_gpos_power_a') | float(0) %}
      {% set plugs = [
        'sensor.livingr_fridge_plug_power',
        'sensor.livingr_vacumerobotic_powerboard_plug_power',
        'sensor.kitchen_dishwasher_smart_plug_power'
      ] %}
      {% set plugs_total = plugs | map('states') | select('string') | map('float', 0) | sum %}
      {{ (ct_gpos - plugs_total) | round(2) }}
    availability: >
      {% set is_delayed = is_state('binary_sensor.delayed_ct_gpos_power_a_availability', 'on') %}
      {% set is_valid = states('sensor.ct_gpos_power_a') not in ['unknown', 'unavailable'] %}
      {% set uptime = states('sensor.uptime') | as_datetime %}
      {% set current_time = now() %}
      {% if uptime is not none %}
        {{ is_delayed and is_valid and (current_time - uptime).total_seconds() > 60 }}
      {% else %}
        false
      {% endif %}

Template Sensor Code B (Works Perfectly):

- sensor:
  - name: "GPOs Power A - Excluding Smart Plugs NEW 2"
    unique_id: bab2b166-c99c-4800-a421-d333ffa9c9ef
    unit_of_measurement: "W"
    device_class: power
    state: >
      {% set ct_gpos = states('sensor.ct_gpos_power_a') | float(0) %}
      {% set plugs = [
        'sensor.livingr_fridge_plug_power',
        'sensor.livingr_vacumerobotic_powerboard_plug_power',
        'sensor.kitchen_dishwasher_smart_plug_power'
      ] %}
      {% set plugs_total = plugs | map('states') | select('string') | map('float', 0) | sum %}
      {{ (ct_gpos - plugs_total) | round(2) }}
    availability: >
      {% set is_delayed = is_state('binary_sensor.delayed_ct_gpos_power_a_availability', 'on') %}
      {% set is_valid = states('sensor.ct_gpos_power_a') not in ['unknown', 'unavailable'] %}
      {% set uptime = states('sensor.uptime') | as_datetime %}
      {% set current_time = now() %}
      {% if uptime is not none %}
        {{ is_delayed and is_valid and (current_time - uptime).total_seconds() > 60 }}
      {% else %}
        false
      {% endif %}

What I’ve Verified So Far:

  1. Entities Exist:
  • binary_sensor.delayed_ct_gpos_power_a_availability exists and appears to work correctly (state is on after startup delay).
  • sensor.ct_gpos_power_a exists and is not unknown or unavailable.
  • sensor.uptime is valid.
  1. Template Logic:
  • Tested the availability templates for both sensors in Developer Tools > Template, and they both evaluate as true.
  1. Unique ID Conflicts:
  • Verified that there are no duplicate unique_id values.
  1. Restart/Reload:
  • Reloaded YAML and restarted Home Assistant, but the issue persists.

Questions:

  1. Could the binary_sensor.delayed_ct_gpos_power_a_availability be causing a race condition or initialization timing issue?
  2. Why would one sensor work while the other fails when they share identical logic and dependencies?
  3. Are there any known quirks with the delay_on property in binary sensors that might affect dependent template sensors?

Any help or suggestions would be greatly appreciated! Let me know if you need logs or additional context to assist.

Thank you!

Only one sensor: is needed

- sensor:
  - name: "GPOs Power A - Excluding Smart Plugs NEW 2"
    unique_id: bab2b166-c99c-4800-a421-d333ffa9c9ef
    unit_of_measurement: "W"
    device_class: power
    state: >
      {% set ct_gpos = states('sensor.ct_gpos_power_a') | float(0) %}
      {% set plugs = [
        'sensor.livingr_fridge_plug_power',
        'sensor.livingr_vacumerobotic_powerboard_plug_power',
        'sensor.kitchen_dishwasher_smart_plug_power'
      ] %}
      {% set plugs_total = plugs | map('states') | select('string') | map('float', 0) | sum %}
      {{ (ct_gpos - plugs_total) | round(2) }}
    availability: >
      {% set is_delayed = is_state('binary_sensor.delayed_ct_gpos_power_a_availability', 'on') %}
      {% set is_valid = states('sensor.ct_gpos_power_a') not in ['unknown', 'unavailable'] %}
      {% set uptime = states('sensor.uptime') | as_datetime %}
      {% set current_time = now() %}
      {% if uptime is not none %}
        {{ is_delayed and is_valid and (current_time - uptime).total_seconds() > 60 }}
      {% else %}
        false
      {% endif %}

  - name: "GPOs Power A - Excluding Smart Plugs NEW 3"
    unique_id: aa8763f7-b818-45f6-a024-898631832f91
    unit_of_measurement: "W"
    device_class: power
    state: >
      {% set ct_gpos = states('sensor.ct_gpos_power_a') | float(0) %}
      {% set plugs = [
        'sensor.livingr_fridge_plug_power',
        'sensor.livingr_vacumerobotic_powerboard_plug_power',
        'sensor.kitchen_dishwasher_smart_plug_power'
      ] %}
      {% set plugs_total = plugs | map('states') | select('string') | map('float', 0) | sum %}
      {{ (ct_gpos - plugs_total) | round(2) }}
    availability: >
      {% set is_delayed = is_state('binary_sensor.delayed_ct_gpos_power_a_availability', 'on') %}
      {% set is_valid = states('sensor.ct_gpos_power_a') not in ['unknown', 'unavailable'] %}
      {% set uptime = states('sensor.uptime') | as_datetime %}
      {% set current_time = now() %}
      {% if uptime is not none %}
        {{ is_delayed and is_valid and (current_time - uptime).total_seconds() > 60 }}
      {% else %}
        false
      {% endif %}

@Holdestmade Thanks for the suggestion about consolidating into a single sensor: definition. I gave it a try, but unfortunately, the behavior remains unchanged.

Where are you adding this yaml ?

@Holdestmade I have a template: entry in my configuration file with !include templates.yaml, and I’ve added the template sensor directly within templates.yaml.

can you show your templates.yaml ?

there should only be one sensor: entry in your templates.yaml

Thank you for pointing that out! Right now, my templates.yaml looks like this:

- sensor:
  - name: "Sensor 1"
    # Sensor 1 configuration...

  - name: "Sensor 2"
    # Sensor 2 configuration...

- sensor:
  - name: "Sensor 3"
    # Sensor 3 configuration...

- binary_sensor:
  - name: "Binary Sensor 1"
    # Binary Sensor 1 configuration...

  - name: "Binary Sensor 2"
    # Binary Sensor 2 configuration...

  - name: "Binary Sensor 3"
    # Binary Sensor 3 configuration...

- sensor:
  - name: "Sensor 4"
    # Sensor 4 configuration...

  - name: "Sensor 5"
    # Sensor 5 configuration...

  - name: "Sensor 6"
    # Sensor 6 configuration...

Could you kindly clarify how the improved version should look? Specifically:

  1. Should the binary_sensor configuration be placed at the beginning of the file?
  2. Should all sensor: entries be consolidated into a single sensor: block?

If you have an example of how the consolidated structure should look, that would be incredibly helpful!

Doesn’t matter if it’s sensor: or binary_sensor: first, as long as they are all together

Yes, as well as binary_sensor:

- sensor:
  - name: "Sensor 1"
    # Sensor 1 configuration...

  - name: "Sensor 2"
    # Sensor 2 configuration...

  - name: "Sensor 3"
    # Sensor 3 configuration...

  - name: "Sensor 4"
    # Sensor 4 configuration...

  - name: "Sensor 5"
    # Sensor 5 configuration...

  - name: "Sensor 6"
    # Sensor 6 configuration...

- binary_sensor:
  - name: "Binary Sensor 1"
    # Binary Sensor 1 configuration...

  - name: "Binary Sensor 2"
    # Binary Sensor 2 configuration...

  - name: "Binary Sensor 3"
    # Binary Sensor 3 configuration...