Automatic Room Occupancy - Room-based occupancy based on activity

I tried to migrate from gdeboos version at the weekend, but it would not work for me. I reverted back and it’s fine, but I noticed afterwards that someone had posted that the household group is mandatory. I suspect that this was my problem.
Has it been fixed in this release?

Can you post log errors when reloading automations after the swap? The current published code is close enough that it should work to swap over.

The other updates I am working on do update the documentation but the group.household group is required with all tracked people included.

Thanks, Kevin. I am back on the old version at the moment as some of my automations rely on it. At the time, I couldn’t see anything in the logs, just that the occupancy wasn’t being updated.
I’ll try your updated version at the weekend along with the household group & report back.

How do you make a group of people? From what I can tell, presence sensors aren’t something that can be grouped.

This is done via groups.yaml code:

image

Household:
  entities:
    - person.1
    - person.2
    - person.3
  icon: mdi:home-account

Edit: Is located in the same place as your configuration.yaml location. File Editor add-on or Studio Code Server add-on (recommended) should find this file.

I think household group should ideally be optional, as quite often not all people in a house will be tracked. I’ve worked around it by creating a dummy group for now.
Any further thoughts on the option of variable timeouts?

Thanks

Hey Borat, I am back and ready to optimize here. Would it work to have an input number from 0-120 (in minutes) for each of the timeouts within the blueprint setup itself?

I am also going to work to try to remove the household group requirement.

Hey Pat, here is the logic driving the “at_home” state (boolean). It seems to me that household group is NOT mandatory:

image

But I see that if both are none it will never be false, which is required to choose the turn off option:
image

I’ll try to figure out a way to work around this case.

Stand by!

NCO3 please see above. The at_home should be true always if ‘none’ for both household and guest. I’m not sure what is happening but I am willing to help as possible.

For at_home to be false, one of them would have to be defined and not_home/off. Perhaps the state doesn’t match the desired “true” type?

Thank you for the details.
It working, but I don’t use the guest group if this matters.

1 Like

Hey there… Yes I think this would work fine… I am guessing this would mean loss of the front end control, but personally I’m fine with that. Just to check though, this would mean different timeouts for motion each time you use the blueprint? Where would it store the timeout in that case?

Thanks

The timeout value would be a part of the automation created from the blueprint. It would store that value and could be changed within each space that has an automation independently.

I’ll work to get it incorporated, but first I need to ensure it works with the universal timeouts as backup.

@kreene1987

Thank you very much for this blueprint.
That really helps in my use case.

However, I have a question:
I would like to put the Occupancy (input_boolean) into a group to have a global House Occupancy.
I cannot create a group though accepting input_booleans as members in the UI.
Do you have a recommendation for me?

Any help would be greatly appreciated!

I use scripts to turn on/off all booleans in my instance.

FYI after timeout all booleans will turn off if not disabled.

Thanks - I will give it a shot and play around with this option.

And I have another issue :slight_smile:

I would like to switch the garden occupancy on if the door to the garden opens.
Unfortunately my contact sensor (z-wave binary_sensor = “Gartentor” below) is not accepted by your blueprint:

alias: Occupancy - Garten hinten (Gartentor)
description: ""
use_blueprint:
  path: kreene1987/automatic-room-occupancy.yaml
  input:
    motion_sensor: binary_sensor.none
    occupancy_switch: input_boolean.garten_hinten_occupancy
    occupied_on_shut_door: true
    occupied_on_media_enabled: true
    occupied_on_presence_enabled: true
    household_group: group.persons
    occupied_on_motion_enabled: true
    door_sensor: binary_sensor.gartentor_home_security_intrusion

the log says:

2022-09-04 20:42:08.421 ERROR (MainThread) [homeassistant.components.automation] Blueprint [Occupancy] Auto Room Occupancy generated invalid automation with inputs OrderedDict([('motion_sensor', 'binary_sensor.bewegung_garten_vorne'), ('occupancy_switch', 'input_boolean.garten_hinten_occupancy'), ('occupied_on_shut_door', True), ('occupied_on_media_enabled', True), ('occupied_on_presence_enabled', True), ('household_group', 'group.persons'), ('occupied_on_motion_enabled', True), ('door_sensor', 'Gartentor'), ('guest_mode_switch', 'input_boolean.guest')]): Entity Gartentor is neither a valid entity ID nor a valid UUID for dictionary value @ data['entity_id']. Got None

And if I want to deactivate some of the occuppancy triggers (e.g. media) the system won’t ask for saving this change.
Means: I need to set those to false in YAML (which is not a big deal, but maybe worth mentioning)

I finally got around to trying your multipe-true PR today on HA 2022.9 and I cannot add sensors to it. The text boxes have the description but no place to enter data:

Reverting to the previous version restores functionality.

Agreed. It’s a logical mess, I did figure out the first solution though, remove the default fields. That will allow the dropdown to show.

But again, the logic is very complex for multiple items. I’ve ceased development at the moment as we are moving.

Yes, I had commented out the default: none fields and it seems to work OK, but I wasn’t sure what effect it would have on the logic. I will test it over the weekend.
Thanks for the reply, moving is never pleasant!

The door sensors field are not seeing any of my door sensors. It looks like in the blueprint that the entity domain for this field is binary_sensor and the device_class is opening. Is there a reason that device_class is not door? All of my door contacts are device_class: door.

I’m not sure exactly how blueprints work, but can you define more that one devce_class? If so, can you add the door device_class?

I know that I can change the device_class, but opening is the generic class and door is what it actually is so I would rather not change the device_class.