Prevent false triggering

I have the following binary sensor:

- platform: template
  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"
      entity_id:
        - sensor.master_bed_sensor
      value_template: >-
        {{ (states('sensor.master_bed_sensor') | float | default(1.0)) < 0.7 }}

Unfortunately when it goes offline it triggers this automation:

- id: in_bed_automation
  alias: 'In Bed Automation'
  trigger:
    entity_id: binary_sensor.master_bed_occupied
    platform: state
    to: 'on'

Which turns everything off.

I thought | default(1.0) would have fixed it but it didn’t.

Any ideas how to prevent it happening?

1 Like

turns out | default() does nothing indeed, so try this instead:

{{ states('sensor.master_bed_sensor') != 'unknown' and (states('sensor.master_bed_sensor') | float ) < 0.7 }}

Thanks. I’ll give it a go.

Dammit. It didn’t work.

Using this template:

      value_template: >-
        {{ (states('sensor.master_bed_sensor') != 'unknown') and (states('sensor.master_bed_sensor') | float < 0.7) }}

Just had sensor.master_bed_sensor go off-line and the binary sensor tuned on, triggering my everything turn off automation.

EDIT: the off-line state appears to be ‘unavailable’ not ‘unknown’. I’ll hedge my bets with:

  value_template: >-
    {{ (states('sensor.master_bed_sensor') != 'unavailable') and (states('sensor.master_bed_sensor') != 'unknown') and (states('sensor.master_bed_sensor') | float < 0.7) }}
1 Like

I think you should move to a tri-state sensor.

‘on’, ‘off’, and ‘unavailable’.

sensor:
- platform: template
  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"
      entity_id:
        - sensor.master_bed_sensor
      value_template: >
        {% if states('sensor.master_bed_sensor') not in ['unavailable', 'unknown', 'none' ] %}
          {{ 'on' if states('sensor.master_bed_sensor') | float < 0.7 else 'off' }}
        {% else %}
          unavailable
        {% endif %}
 

I’m only using the ‘to: on’ as a trigger. I don’t really care about off or invalid states.

The tristate sensor removes [‘unavailable’, ‘unknown’, ‘none’ ] from the on state.

This would place them in the off state

sensor:
- platform: template
  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"
      entity_id:
        - sensor.master_bed_sensor
      value_template: >
        {% if states('sensor.master_bed_sensor') not in ['unavailable', 'unknown', 'none' ] %}
          {{ states('sensor.master_bed_sensor') | float < 0.7 }}
        {% else %}
          False
        {% endif %}

Why wouldn’t you do this with a binary_sensor template sensor? It resolves to true/false no?

(Curious, I absolutely bow to your jinja skills @petro !)

I only moved it to a tristate if he cared about the off’s. But he doesn’t so, just plop the false triggers into the off value instead.

1 Like

I was able to follow that, I meant the last code you posted, that could have been a binary_sensor template instead?

sensor:
- platform: template
  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"

This could have been the following with the same end result?

binary_sensor:
- platform: template
  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"

Not sure if there would be any advantage to using binary_sensor instead?

I’m curious about something else also. You specified a entity_id in the template. I’ve read the template sensor docs (actually just went and re-read them) but I still don’t understand what it’s really for? I’ve never used it and haven’t seen anyone else use it until now. If you’re specifying the entity id in the template with things like states( ‘sensor.master_bed_sensor’) why do you need to specify it in the sensor dictionary?

  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"
      entity_id:
        - sensor.master_bed_sensor

This was actually an informative post. I see where I could use the state not in array values thing to save a lot of if/elif lines in a couple of my templates. I’ve also never seen an if/else statement written with the value at the front like this:
{{ 'on' if states('sensor.master_bed_sensor') | float &lt; 0.7 else 'off' }}

That’s a neat little shortcut. Is an endif really not required when written like this?

I recently learned that you can specify what float returns when it fails to convert a string. By default it’s 0.0 but you can change it.

If I use it in your template, it produces the result you want. Compare the difference in how your template works on my system (which does not have your bed sensor).

Give it try on your system:

{{ (states('sensor.master_bed_sensor') | float(default=1.0)) < 0.7 }}
1 Like

Yeah, that was a typo on my part.

Advantage of a binary sensor is all the device classes and the constrained states.

The entity_id field is for templates when you don’t have something that triggers the update to the sensor. For example, if you want to use {{ now().hour }} as a template which gives you the current hour, there is no entity_id for home assistant to watch to make updates. So it will never update. Add an entity_id to it, and every time the entity_id updates, the sensor w/ {{ now().hour }} will update.

He doesn’t need to specify it. I think he was just being over cautious.

These shortcuts are python. If you learn some python, alot of the shortcuts there will translate into jinja. Sometimes they don’t.

1 Like

lolouk44’s, petro’s and 123’s solutions work but I’m going with 123’s as it covers any possible failure. I’ll be applying this default value on conversion failure solution to all my float and int conversions to ensure a more robust system.

Thanks to all for helping. I’m no longer pestered by occasionally sitting in the dark and swearing at home assistant.

Again, technically it doesn’t cover all scenarios, only this one will with the following automation:

sensor:
- platform: template
  sensors:
    master_bed_occupied:
      friendly_name: "Master Bed Occupied"
      entity_id:
        - sensor.master_bed_sensor
      value_template: >
        {% if states('sensor.master_bed_sensor') not in ['unavailable', 'unknown', 'none' ] %}
          {{ 'on' if states('sensor.master_bed_sensor') | float < 0.7 else 'off' }}
        {% else %}
          unavailable
        {% endif %}
- id: in_bed_automation
  alias: 'In Bed Automation'
  trigger:
    entity_id: binary_sensor.master_bed_occupied
    platform: state
    to: 'on'
    from: 'off'

The one @123 posted will trigger if the sensor goes dark when the sensor is on. If it goes dark when the sensor is on, it will switch to off, then back on when it comes online. Hence why I originally stated you should go to a tri-state.

I see what you are saying. It’s ok in this case though. It doesn’t matter if everything gets turned off if it’s already off. It’s only the case where the sensor is off (thus lights and stuff could be on) and it falsely goes on and turns everything off that is a problem. I will implement your solution in this case though as I don’t like unneeded state changes on an overtaxed pi platform.

I have to find time to get HA moved to my mini PC, hopefully the Easter break. It’s not just moving HA there’s PI GPIOs to move to an mqtt solution as well as other wiring to do.

As for other cases, having defaults available in things like this:

- platform: template
  sensors:
    lounge_ac_heat_required:
      friendly_name: "Lounge AC Heat Required"
      entity_id:
        - sensor.lounge_room_temperature
        - input_number.lounge_ac_heat_temp_set
      value_template: >-
        {{ states('sensor.lounge_room_temperature') | float(default=19) < states('input_number.lounge_ac_heat_temp_set') | float(default=18) }}

Are a great safeguard to unwanted power usage.

and once you get a better system, you can just incorporate the filter sensor instead. It will filter out ‘fliers’ like disconnects.

Wait. What?

Will your solution not do this?

The one I wrote will, but the filter sensor removes spikes in data. It’s just a different way of doing things. You’d layer the filter sensor between the binary_sensor and the master_bed_sensor. It would remove the spikes of data in your master_bed_sensor output, i.e. remove the disconnects. Granted it may not work if the disconnects last for long periods of time.

Ah right. I misunderstood what you meant. All clear now. Thanks.