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