Timeout for rule, although Item is updated

Hello everyone

I started to setup my blinds rules but I’m currently stucked with one key feature.

Is there something like a timeout for rules?

Here is my current setup and the detailed problem:
First I have a rule which uses astro items to locate the position of the sun:

Number           Azimuth            "Azimuth [%d]"                            { channel="astro:sun:home:position#azimuth" }
Number           Elevation          "Elevation [%d]"                          { channel="astro:sun:home:position#elevation" }

And then a rule which updates 4 “proxy”-variables about the postion:

import math
val house_east = 67
val house_south = 157
val house_west = 247
val house_north = 337

rule sun_position
  Item Azimuth received update
  val azimuth = Math::round((Azimuth.state as DecimalType).intValue)
  val elevation = Math::round((Elevation.state as DecimalType).intValue)

  //logInfo("sendInfo","Sonne steht bei " + azimuth + " und " + elevation + ".")

  // größer 337° und kleiner 360° oder größer 0° und kleiner 157° --> Sonne aus Richtung Osten
  if (((azimuth > house_north && azimuth < 360 ) || (azimuth > 0 && azimuth < house_south)) && elevation > 10) {
    logInfo("sendInfo","Sonne auf Ostseite.")
  // größer 67° und kleiner 247° --> Sonne aus Richtung Süden
  if (azimuth > house_east && azimuth < house_west && elevation > 10) {
    logInfo("sendInfo","Sonne auf Südseite.")
  // größer 157° und kleiner als 360° --> Sonne aus Richtung Westen
  if (azimuth > house_south && azimuth < 360 && elevation > 10) {
    logInfo("sendInfo","Sonne auf Westseite.")
  // größer 157° --> keine Sonne aus Richtung Osten
  if (azimuth > house_south && elevation > 10) {
    logInfo("sendInfo","keine Sonne aus Richtung Osten.")
  // größer 247° --> keine Sonne aus Richtung Süden
  if (azimuth > house_west && elevation > 10) {
    logInfo("sendInfo","keine Sonne aus Richtung Süden.")
  // größer 337° --> keine Sonne aus Richtung Westen
  if (azimuth > house_north && elevation > 10) {
    logInfo("sendInfo","keine Sonne aus Richtung Westen.")

And then a rule which uses these “Sun_On_*side” variables to roll down the blinds:

rule "close if sun hits window westside"
  Item Sun_On_Westside received update
  //    ( cloud_percentage < 50 ) &&
  //    ( sensor == CLOSED ) &&
  //    ( setting not changed in <timespan> ) &&
  if ( Sun_On_Westside.state == ON ) {
    logInfo("sendLogInfo","Fenster Westseite schließen.")

Now every time the azimuth variable is updated, the Sun_ON_*side is updated, and that triggers the rule to close the window. Which is basicly what it should do, but if a the blind is raised manually, after the next azimuth update, the blinds go down again. But that’s good because all the other condition (cloud_percentage, close_sensor, Sun_on_*side) can change and therefore should be able to trigger the rule anytime. But that’s also not that good, if you go out on the terrace and the blinds close behind you ;-).

What I would like to use, is some sort of timeout mechanism, something like “if button_for_blinds is used, then don’t use rule for 60 minutes, no matter the other changes”.
Does anybody know, how I could achieve this?

Many thanks in advance

Sure. I do something like this with lighting. For each lighting zone, I have a corresponding switch Item like Lightzone_Manual.
If the light wallswiches are used, that gets turned ON
Expire binding can be used to auto-OFF that after some period after last manual operation.

Obviously, you use the state of this manual flag as a blocker in rules invoking auto actions.
You may have to decide whether you should take special action at the end of this “manual mode” period. In your case I think the next calculate-set cycle would take care of that. (In my case I’ll douse the lights IF there is no recent presence detection)

The tricky part for you will be detecting the manual operation, separately from auto actions.

Note that you’l still be able to walk out through auto-opened blind and have it auto-close behind you :crazy_face:

As a general comment, I don’t know why people don’t seem to implement this kind of thing more often. If a user is poking buttons, they want it thus and the auto systems better stop interfering!

Thanks for your quick answer.
Yes, Expire is the correct search word not timeout for this problem.
So if I understood this correctly, this should work:

Switch eg_az_contact_button_up "Taste hoch" { channel="homematic:HmIP-BROLL:ccu:numbers:1#BUTTON", expire="1h,command=OFF" }
Switch eg_az_contact_button_down "Taste runter" { channel="homematic:HmIP-BROLL:ccu:numbers:2#BUTTON", expire="1h,command=OFF" }

This will hold the state of the switch 1 hour at “ON”. And my rule can use this state as stop

rule "close if sun hits window westside"
  Item Sun_On_Westside received update
  if (( Sun_On_Westside.state == ON ) && ((eg_az_contact_button_up == OFF) || (eg_az_contact_button_down == OFF)) {
    logInfo("sendLogInfo","Fenster Westseite schließen.")

For the moment it looks like the actor BROLL don’t send these status, although there exists channels for buttons up and down.

I fully agree on your remark, regards the priority of buttons over auto systems. External manual input, if it occur,s should always be prioritised over automatic decision (also prevents SKYNET :rofl:)

I will update this topic, asap I get the status of the button working.

If openHAB has direct visibility of the user controls, that’s great and simplifies enormously.
Otherwise you need some kind of logic, maybe with timing elements, to work out whether a detected movement was caused by OH action or user action.

I was thinking more of a ‘virtual’ Item, unbound to devices. Makes sense to me as it represents a conceptual state - “a button was pressed within the hour”.
Personally I would not try to “stretch” button detection the way you suggest, but use them to set this virtual Item instead via rule. That way, your button Items still represent actual button status without fakery, which may have some other uses?

I suppose it is feasible to do it that way though, if it’s purely for noting a “manual action has occurred”. Once you have individual Items working, I suspect you could apply both button channels to a single Item to simplify. Multiple channels are allowed.

The techniques of “associated Items” Item naming convention together with Group based rules are likely to be useful here, after you’ve got a solution for one shutter.

I completely agree, at least for a time, any manual override should override the automation, at least for a time. That’s why I wrote Design Pattern: Manual Trigger Detection. Pretty much all of my automatons have some sort of override like this.

I took the next step and “somehow” managed to get the Homematic CCU to send button events to OPENHAB

2019-05-02 14:17:23.330 [vent.ChannelTriggeredEvent] - homematic:HmIP-BROLL:ccu:001118A9A75DE0:1#BUTTON triggered SHORT_PRESSED

I created a generic item which should combine every type of button press (up, down, short, long double):

Switch eg_az_roll_manual "Switch EG AZ ROLL used" { expire="10s,command=OFF" }

And a matching rule for the triggering of this channel:

rule "eg az switch manual override"
  Channel "homematic:HmIP-BROLL:ccu:001118A9A75DE0:1#BUTTON" triggered or
  Channel "homematic:HmIP-BROLL:ccu:001118A9A75DE0:2#BUTTON" triggered
  logInfo("sendLogInfo","Knopfdruck erkannt")

After the initial NULL and after the button is pressed the item changes to ON. but not back:

openhab> items list | grep roll_manual
eg_az_roll_manual (Type=SwitchItem, State=NULL, Label=Switch EG AZ ROLL used, Category=null)
openhab> items list | grep roll_manual
eg_az_roll_manual (Type=SwitchItem, State=ON, Label=Switch EG AZ ROLL used, Category=null)
openhab> items list | grep roll_manual

The openhab.log shows no errors after editing the files. Did miss something?

You have to instal the expire binding

Thanks for the hint. I thought that expire is a basic functionalty but after installing expire it looks like the next step is done:

2019-05-03 09:26:23.271 [ome.event.ItemCommandEvent] - Item 'eg_az_roll_manual' received command ON
2019-05-03 09:26:23.273 [vent.ItemStateChangedEvent] - eg_az_roll_manual changed from OFF to ON
2019-05-03 09:26:24.304 [ome.event.ItemCommandEvent] - Item 'eg_az_roll_manual' received command ON
2019-05-03 09:26:26.310 [ome.event.ItemCommandEvent] - Item 'eg_az_roll_manual' received command ON
2019-05-03 09:26:36.491 [vent.ItemStateChangedEvent] - eg_az_roll_manual changed from ON to OFF

I will test it as a variable within my rules and will update this thread with the finished configuration.

It’s proven so useful, I’m sure something like it will be built in to OH3