Window & shutter: how to enforce open/close dependencies?

Setup, Configuration and Use Items & Sitemaps
1

Good morning,

I’m looking for a best practice to execute a command on one item only if another item is in a specific state.

Background: We have a Velux roof window with a motorized opener and a motorized roller shutter. For safety and mechanical reasons, the window should only open when the shutter is fully up, and the shutter should only close when the window is fully closed. Unfortunately, Velux doesn’t enforce this dependency, so I want to handle it in openHAB.

My initial idea is to use a proxy item: the user interacts with the proxy, and a rule checks the relevant states before forwarding the command to the real item.

Does this sound like a reasonable approach, or is there a better pattern for this kind of logic?

2

yes that’s reasonable. But don’t call it a proxy item. Make it just an all-virtual one.

1 Like
3

An alternative approach might be to use a script profile on the channel linked to the shutter and window items. This can intercept any command sent to the Channel and check the states of the other Item(s) and if those are in a bad state, change the command to the state the window or shutter is already in. Something like this for the shutter:

function(input) {
  if(items.Window.state != "CLOSED") return items.RollerShutter.state;
  return input;
}(input)

This is simple enough it could be an inline script as well:

JS: | (items.Window.state != "CLOSED") ? items.RollerShutter.state : input

This would go on the “from Item to Channel” property of the profile.

I’m not sure there’s any advantage to this approach except for removing the need for an extra Item. However, it comes at the cost of becoming somewhat hidden and easily forgotten. Of course it becomes more complicated if you have more than one Item you need to check.

4

Yeah and you don’t know where you’ll end with all of it at this stage.
My own code to handle door-window-blinds- openings if my house has grown to 1000 lines of code meanwhile.

5

I bumped into this thread while searching for templates/design patterns for shutter/blind control. This topic has been haunting me for a while, because there is so much to consider if you want to do it “properly”: open/close dependencies, time of day, season, weather alerts, weather forecasts, fire alarm, manual overrides, presence, etc. etc. On the other hand there is lot to be gained, when done right, e.g. improved energy efficiency, passive cooling and safety.

Unfortunately, most shutter automation threads I can find are either related to low-level hardware- or vendor-specific issues or they barely scratch the surface - far from 1000 lines of code. Am I missing something or are best practises/patterns/templates in shutter control really an open topic?

6

This is years old but still valid for a starting point

1 Like