Optimizing House Shutdown: Room-based Control with Multiple Occupants

[rlkoshak (Rich Koshak)]

@Neolinger

• 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

• 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.

@Neolinger

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

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.

@Neolinger

1. • 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

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.

@Neolinger

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.

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.

@Neolinger

Avoiding duplicate commands: Need to prevent sending redundant ON/OFF commands to devices that are already in the desired state

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

@Neolinger

Managing the complexity of 81 possible states (3 states × 4 people)

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.

@Neolinger

I’ve read about using state machines, but I’m not sure how to adapt this to my use case.

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.

@Neolinger

Has anyone implemented something similar?

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.