Optimizing House Shutdown: Room-based Control with Multiple Occupants

Hello everyone,

I’m working on optimizing my house shutdown automation and need some advice on implementing a more granular room-based control system, especially with multiple family members.

Current Setup:

  • 4 family members (2 adults, 2 children)
  • Each person has three states: “absent”, “sleeping”, or “awake”
  • I have created computed items that combine these states for different zones and floors (e.g., “sleeping_or_absent”, “awake_or_absent”) to manage intermediate states for each area of the house

What I’m trying to achieve:

  1. Different shutdown scenarios based on who is sleeping/absent:

    • When my wife goes to bed: shutdown bedroom and her office (turn off lights, shutdown PC, etc.)
    • When I go to bed after her: no need to shutdown bedroom again, but shutdown additional areas (e.g., living room media box)
    • The same applies in reverse: if I go to bed first, my rooms are shut down, and when my wife follows, her additional rooms are shut down
    • When Child1 goes to bed: shutdown their bedroom
    • When Child2 goes to bed: shutdown their bedroom and complete shutdown of remaining upstairs areas
    • Again the same applies in reverse
  2. Morning scenarios:

    • On weekends, when one child wakes up (deactivates sleep item): activate their room, kitchen, and living room (lights, devices, etc.)
    • When both children are awake: activate all devices and systems in the entire upstairs area
  3. Future expansion:

    • This is just the beginning - I plan to add many more rules for different scenarios and combinations of presence/absence/sleeping states
    • Need a solution that scales well with additional rules

Current Challenges:

  1. Rule conflicts: For example, when I’m the last person going to bed, my “sleeping” state triggers multiple rules simultaneously:
    • A rule for bedroom and ground floor
    • Another rule for the rest of the house (which includes the ground floor)
      This leads to error messages about rules not being able to execute because they’re already running, as they’re trying to control the same devices at the same time.
  2. Avoiding duplicate commands: Need to prevent sending redundant ON/OFF commands to devices that are already in the desired state
  3. Managing the complexity of 81 possible states (3 states × 4 people)

Current Implementation Attempt:
I initially tried using helper items for each room to prevent multiple activations, but this seems to make things more complicated. I understand I should check item states before sending commands to avoid unnecessary switching, but I’m struggling with how to implement this complex state management efficiently. I’ve read about using state machines, but I’m not sure how to adapt this to my use case.

Through a thread about reusable code, I’ve found a potential solution for this, but I don’t want to mention it here to avoid influencing your suggestions.

Has anyone implemented something similar? What would be the most efficient way to manage these multiple states and conditions?

Thank you for any guidance!

  • Create an Item that represents whether the room is shutdown or not and test before issueing the commands
  • just issue the commands again (it doesn’t hurt to command a device to OFF it’s it’s already OFF)
  • test to see if the Items are already in the desired state before issuing the commands. In JS Scripting there’s a sendCommandIfDifferent() method that only sends the command if it’s different from the current state.

For the complete shutdown actiity just on every person changing state to asleep check to see if all are asleep before doing the rest. It shouldn’t be based on any one person going to sleep last but on all being asleep or away.

Again, trigger when either one wakes and based on who it is do the actions. Then when both are awake do the rest.

You can possibly use a Group Item with an aggregation function to aid in the checks.

You may need to generalize more. The most specific the rules are the more complex it’s going to become.

Scenes can be pretty handy here though. You can set up a scene with the desired states of the Items and then call those scenes from a rule that triggers on and tests the status of each person and Groups of people. This separates the when (when do I start up/shutdown stuff) from the what (what gets started or shutdown). That should make the configuration and overall maintainence easier in the long run.

There should be locks in place to prevent this now. Show the errors and the rules. If you are using the cache and you’ve put JS objects into the cache however, that is not supported. But in all other cases there should be locks to prevent stuff from running at the same time which can’t run at the same time.

But in general, why is the ground floor handled by two rules? There should only be one rule for the ground floor which gets triggered or called occordingly based on state changes in the person Item.

Why? It doesn’t hurt. But regardless see above.

Separate the what from the when (as mentioned above). You’ll have one set of rules for the when which call scenes which handle the what. If the what is more complicated than just commands to Items, you can use a rule or a script instead of a scene.

State machines sound complciated but they are pretty simple in imolementation (which is why they are great).

You can initially set it up in a spreadsheet but I like to draw state transition diagrams. What you do is define all the relevant states (in this case the status of each person) and what event occurs to move from one state to another state. All asleep would be one state. You being up and everyone else asleep would be another state, and so on. You’d have 4! states which is handlable, but I think you’ll find that a lot of those will collapse into the same state (e.g. if one or more people are up would be one state instead of needing to create a separate state for every combo of everyone being up).

Then for each state you would define what needs to happen (i.e. the scenes mentioned above, the commands sent to each Item).

You only really need to focus on the common areas, not the areas that are specific to one person. Those are easy to handle outside the state machine because they depend on the status of only one person.

I never got past the initial problem of detecting who is home and what state they are in reliably enough to even approach something like this. So while my automations can be complex, they are based on any one person being home and time. But I do use a time state machine for that (see Time Based State Machine [4.0.0.0;4.9.9.9]).

Use Groups and aggregation function to track aggregate states (e.g. at least one person is up) and then you can trigger rules and have rule conditions or tests in rules based on the Group’s state instead of needing to test each person individually.

@rlkoshak Thank you very much for your answer!

Actually, I’ve already done that but I don’t know if this is the right way.

I have an item for each room that is switched when the room is activated or deactivated.

In this example it’s the spleeping room.

You can hear the relays click when the light or shutter switches are activated even though they are already in the desired state, so I would like to politely disagree with you on this point.

That’s very good, then the library I just created is now obsolete :smiley:

That’s what I meant by “computed” items

I have tried to achieve this by creating a rule for each room, which is then called up by other rules. Is that what you meant?

If people sleep on the upper floor, this floor is deactivated; if people sleep on the first floor, this floor is deactivated. When everyone is asleep, the house where the first floor and the upper floor belong is deactivated. So the last person to go to sleep triggers two rules in any case, at least so far.

Visualization is always a good thing. I’m going to start visualizing my status changes there, which should make it easier for me to keep track of things and also make it easier to explain what I want to achieve.

This one I don’t understand. Why do I have four states for 4 people with 3 states?

Am I right in assuming that this is what I have already done with the computed items?

It is unusual to have both an inlkine script and additional actions in a rule. Typically you would do it all in the script action.

Beyond that, as far as I can tell that’s a typical use for a rule condition.

Under Settings → Scenes. A scene is special UI rule that consists of a list of Items and what you want to command those Items to when the scene is activated.

My point though is that the rule to handle the top floor and the rule to handle the first floor should be separate rules. You shouldn’t be handleing both firts floor stuff and top floor stuff in the same rule. Where necessary, you can trigger both rules on the same event, but don’t duplicate the same activities in both rules.

This is indeed where a state machine approach helps. I forces you to think about the problem in this way.

4! as in 4 factorial as in 432*1.

There isn’t enough information to tell. But based on the information available so far I would expect there to be a Group which aggregates the states of all the people into one state. For example, if one person is awake the Group’s state shows awake. Only if all are asleep set the Group to asleep. Then in your rule triggers, conditions and actions you can see if at least one person is awake and do what needs to do. You never have to mess with who is awake or anything like that except for the single rooms that are controlled by the state of single people in which case you just use that one person’s state Item in the rule conditions, triggers, and scripts.

Are there any downsides of splitting?

I once read somewhere that a scene is just a slimmed-down rule and that you can also use rules directly, isn’t it?

I forgot to mention that the groups have the aggregate functions.

House deactivation is triggered by “all_away_or_asleep changed to ON”, which triggers the rules for the individual floors (including deactivating first floor which is a separate rule). Deactivation first floor is triggered by “groundfloor_away_or_asleep changed to ON”, but when I go to sleep, both events are triggered.

In the long run it’s probably a little harder to maintain since you can’t really see everything the rule does all at once in one palce. Everything that the script does is hidden when looking at the rules’ page.

It’s a special type of rule. But it’s very different in use and form from a “regular” rule. But it can indeed be called same as any rule.

items:
  FrontPorchLight: OFF
  PatioLights_Switch: OFF
  FamilyRoomOutlet: OFF
  PeanutPlug4_Switch: OFF
  FrontRoomOutlet: OFF
  FamilyRoomLampShelves: OFF
  FamilyRoom_Lamps: OFF
triggers: []
conditions: []

out of curiosity, how do you detect people sleeping/waking up?

I have gadgetbridge (smart watch companion android app) that supports integration with openhab android app, so the OH item gets updated when a person wearing a watch falls asleep or wakes up. but there is like 5-10min delay (until the watch understands you are really awake or asleep)
Also, it could false trigger awake state if you walk over to a toilet in the middle of the night (you dont want rules triggering music and lights all over the place).

Merry Christmas everyone! :hugs:

Provided there are no other disadvantages, I’ll stick with it for now. It shouldn’t be too much trouble to merge things if it gets too confusing.

So scenes represent certain states and a state machine should/can be represented by scenes, have I understood that correctly?

I’m still curious about what might need tweaking in my rules/triggers setup, since the ground floor is still triggering twice. :slight_smile:

At the moment, everyone still has a switch that they turn on in the evening and off in the morning via Alexa. In the long run, however, it should be something like this.
https://www.youtube.com/watch?v=VCEgeDN0RLw
https://www.youtube.com/watch?v=3ufUkOIXGAo

We bought our bed before I started with Smart Home, so it’s not so easy with our bed and I still have a lot of things I want to do first :smiley:

Going back to the previous discussion, the scene would be the “what” to do when entering a given state. The state transitions are the status of the people. The scenes are what you want the equipment to do when the people are in a certain state.

No matter what this rule is going to trigger twice so long as you have two events that cause it to trigger. So you need to figure out how to have only one event to trigger it. A state machine approach helps with this.

The alternative is to make it such that it does not matter of it’s triggered twice.

I will now define my states and transitions in the tool. Maybe then things will become clearer to me. If I still have any questions, I’ll get back to you here. Many thanks for your help!

I have started to implement the Statemachine, which looks like a decent task.

What I don’t understand, however, is how you arrive at 4! or 24 states.
In my opinion, that should be 3^4 states, i.e. 81, shouldn’t it?

I was just counting the number of peo.ple and not counting the number of states per people. The exact number doesn’t really matter. I’m too far out of my numerical analaysis classes to remember how to calculate “choose from among three choices four times” but it doesn’t really matter.

What really matters though is you don’t need to deal with each and every combinantion of the three states for the four people individually. You have states like “1 or more people are awake”. It doesn’t matter who is awake. It doesn’t matter how many are awake so long as it’s more than one. That means this one condition covers a bunch of potential combinations of states.

You really only have a few states total plus some singleton situations where one person controls one specific room.

I have 3 zones and 3 states of zone/whole house
Each zone covers a specific area…2 ground floor 1 1st floor
3 states are home…away…night represents whole house state however the states of eg lightimg or heatimg can equally be applied to individual zones…or indeed rooms.
Each zone is mainly heating but can equally do lighting.