So I got around to creating two Bayesian sensors for Presence, and they work great. I then realized I had a lot of automations that used
from: not_home
to: home
and of course the Bayesian sensor is Boolean, so Off and on. Initially I just changed my automations to use from Off to ON, but then had issues when I restarted HA. The state would be off for a second, then to on, so of course the automation would kick off.
Then I changed the Bayesian sensor to a presensce template.
This did seem to keep the automations from kicking off when I restarted HA. Soā¦ Seems good, but not quite. I also have a group I use for my wife and I. I use this for a āeveryone is goneā or āSomeone has come homeā automations,
When I used actual device trackers, this was working. But now it does not seem to work.
for a device tracker I believe youāll indeed need home and not_home, though personally Iād use home and != home.
If you create other zones (say work), the not_home will not be true as the value will be work (as opposed to awayā¦
I agree, my automations seem to not be working with not_home with the template. Iāll have to look closer, maybe I have something spelled wrong somewhere.
I like the idea of !=home, might have some use for that in the future.
Iāve looked at my automations, and they seem correct. I have a feeling that a template sensor does not use the same logic. When I look at the states they show as on, or off, when I click on them, they show home or away. All my device trackers show home, not_home, or one of my zones.
Iāll do some searching and see if anyone else has anything similar, in older posts
@ptdalen didnāt provide the context, but I believe his multiple_presence_paul and group_presence_for_routines are Template Binary Sensors, and for that, it is valid.
Sorry, one last question. I think this has helped me with figuring out why my automation has not been triggering since I started using Bayesian sensors for Presence, One issue I did have with one of my binary sensors like this was when I restarted the initial state of the sensor was off, then quickly turned to on (as it should have done), but that triggered my āIām backā automation.
Iāve been reading and it does not look like I can set an initial state of a binary sensor.
Is there a simple way or condition I could add to my some of my automations to keep them from triggering after a HA restart.
Well, in general, I would say it doesnāt make sense to be able to set the initial state of most sensors, since itās up to the sensor itself to decide its state. Itās not the same as components like input_boolean, etc.
But for template sensors, I suppose you could add something in the template for this. But itās probably better to handle it at the automation level. E.g., maybe somehow make the automation ignore triggers for a short time after HA starts.
There may be a better way to do this, but one thing you could do is:
input_boolean:
startup:
initial: 'on'
automation:
- alias: Startup Period
trigger:
platform: homeassistant
event: start
action:
- delay:
seconds: 5
- service: input_boolean.turn_off
entity_id: input_boolean.startup
- alias: Use input_boolean.startup as a condition
trigger:
<something>
condition:
- condition: state
entity_id: input_boolean.startup
state: 'off'
action:
<something else>
I suppose you could also use input_boolean.startup in a template sensorās template to force a particular value during this startup period.
I know you didnāt ask for this , but since weāre kind of on the topic, for what itās worth, this is what I do:
input_boolean:
guests:
name: We have guests
icon: mdi:account-multiple
input_select:
home_mode:
name: Home Mode
icon: mdi:home-account
options:
- Home
- Away
- Returning
binary_sensor:
- platform: template
sensors:
people_home:
friendly_name: People Home
device_class: presence
value_template: >
{{ is_state('group.all_devices', 'home') or
is_state('input_boolean.guests', 'on') }}
automation:
- alias: Home Mode - Leaving
trigger:
platform: state
entity_id: binary_sensor.people_home
to: 'off'
condition:
condition: state
entity_id: input_select.home_mode
state: Home
action:
service: input_select.select_option
entity_id: input_select.home_mode
data:
option: Away
- alias: Home Mode - Arriving
trigger:
- platform: state
entity_id:
- device_tracker.person1
- device_tracker.person2
- device_tracker.person3
to: home
- platform: state
entity_id:
- input_boolean.guests
to: 'on'
action:
service: input_select.select_option
entity_id: input_select.home_mode
data:
option: Home
Then all my automations (that care about āHome Modeā) use input_select.home_mode as a trigger and/or condition.
This configuration has the following advantages:
If a device_tracker entity doesnāt update properly (which used to happen a lot when I used SmartThings, but not so much now that Iām on HA ), or more likely, someone forgets their phone at home, I can still manually override Home Mode via the frontend.
Even if the above were to happen, Home Mode will still automatically switch back to Home whenever someone arrives. This is why the arrive automation uses the individual entities instead of binary_sensor.people_home.
I have three states for home_mode since I use the Returning state to cause my thermostat to come out of āECOā mode, yet my cameras are still active, lights are still simulating presence, etc.
The input_boolean.guests switch can effectively prevent āaway modeā automations if we have guests in the house that are not integrated with my HA setup.
Since I only trigger on binary_sensor.people_home going to āoffā, luckily itās not affected by the āoffā -> āonā transition at startup.
Thatās great stuff. Iām also a previous ST user. One of the first things I set up was a āhome modeā
Mine is
Home
Away
Night
I have had it switching modes, but never used it to trigger the automations, but instead had the automations switch the modes, haha. I like the thinking above, seem easier to use.
I have not had Guests yet, but created a group where I figured Iād throw devices that were discovered by my asuswrt component, and use that for some automations. But being able to manually set a guest switch makes a lot of sense too.
I didnāt include it above, but I also have an input_boolean.person4 that is updated by automations that effectively use IFTTT as a trigger. So far Iāve used that for my son who isnāt in my Life360 circle (which is where my device_tracker entities come from. The automations for that input_boolean are a bit complicated to deal with the fact that you canāt always count on IFTTT Applets working promptly, or at all sometimes.) The main point, though, is you can just add something like this (or what you were describing) as another entity in binary_sensor.people_home and as another trigger to the āHome Mode - Arrivingā automation (in fact just list it as another entity along with input_boolean.guests, as long as itās a binary sensor of some sort.)
Awesome, quick question I think is an easy answer. Since Iām using the Bayesian sensor for our presence, this should work right? I made a couple small entity name changes to match my enties a bit more, but overall mostly the same
- alias: Home Mode - Arriving
trigger:
- platform: state
entity_id:
- binary_sensor.multiple_presence_me
- binary_sensor.multiple_presence_person2
- input_boolean.guests_present
to: on
action:
service: input_select.select_option
data_template:
entity_id: input_select.house_mode
option: Home
If I use house mode as a trigger or condition do I need
quotes around the
trigger:
- platform: state
entity_id: input_select.house_mode
to: 'Home'
like above? Looking through some of my automations I seem to have several without the quotes, so I think not. Not sure how to tell when I need them and when I donāt.
Thatās a great question. Yes, it is indeed hard to tell when you need to quote.
I believe the issue is that some strings (e.g., 1, true, yes, on, enable, 0, false, no, off & disable, in any capitalization, and there may be others, I donāt know) can, in some circumstances, be interpreted as, and converted to, boolean values (i.e., True & False.) If this were to happen in, e.g., a to: parameter of a state trigger, then it wouldnāt match properly and the trigger (probably) wouldnāt fire when it should.
So, the bottom line is, it never hurts to quote these. But, except for a small list of strings, itās not necessary. The trick is knowing which strings in which contexts. That I really donāt know for sure. But I can say from experience that you donāt need to quote Home in this case.
Throwing my 2 cents, if the string is simple (all low caps, no special characters, no spaces) HA should handle workout quotes. But as soon as you go out of the above, you can pretty much guarantee youāll need quotesā¦
, but since weāre kind of on the topic, for what itās worth, this is what I do: