Threshold Alert and Open Reminder [4.0.0.0;4.9.9.9]

tophee · April 17, 2024, 10:09pm

Thanks a lot for spending so much time on this! It’s a lot to wrap my head around , so I will try to do that this weekend. Do you want the logs now or after I followed the tl;dr?

That’s exactly what I am trying to achieve. It doesn’t matter how the lights were turned on, I want them to go off if there is no motion for 10 minutes. The thing is that there are many ways how the lights can be triggered on:

the door is opened
motion is detected
light switch is pressed.

These are the most common scenarios, but I can also turn the lights on via the Shelly app, the openHAB app, or they can go on after there was a power cut, in which case the Shelly is set to go back to the state it was in before it lost power, i.e. if the power cut occurred when the lights were on, they will go on when power is restored.

In the bathroom, where I created my own set of rules, I solved this through a dummy item for “bathroom occupancy” which is the item that triggers all the switching: if occupancy goes on or off, lights are switched on or off, but when the lights go on, no matter how, occupancy is also updated to ON.

So, as I think about it, I should probably follow the same approach in the toilet and make that dummy item the alert trigger. But I seem to remember that I already tried that and it didn’t work because in the template the item that we want to monitor also needs to be the trigger (or at least that is how the rule is initially set up via the GUI). That is why I need the second trigger that you want me to remove.

rlkoshak · April 18, 2024, 2:08am

That’s not what I said though. I said if the light should turn OFF ten minutes after being turned ON, not ten minutes after the last motion is seen.

However, you can just create a rule that triggers when the motion sensor is updated to OPEN that sendCommand ON to the lights. Then set an expire on the light Item to command it to OFF after 10 minutes of no commands. There’s no need for something as complicated as this rule template to achieve that.

Furthermore, this rule template can’t support this requirement. It can only work based on one event. It can turn off the light ten minutes after the last motion is sensed, but it has no and can have no knowledge about whether the light was turned ON by some other means. All it can know is whether the light turned ON, or whether motion was detected, not both. Those are two separate events and would be handled independently and separately by the rule.

But it could work with just the motion sensor. The rule doesn’t need to know if the light is already ON when motion is detected. I just needs to try to turn it OFF ten minutes after motion is no longer seen. So you could drive it with just the motion sensor.

But, like I said, you don’t really need this rule template to do that. You can use a simple rule to command the light to ON every time motion is detected and rely on Expire to turn the light OFF again. If no motion is ever detected, the light will turn OFF in ten minutes. If motion is detected, the light will turn OFF ten minutes after the last motion is detected.

The rule template doesn’t work like that. You are trying to use the rule template as if it all the triggers are integrated somehow. But the rule template treats each trigger as a separately managed and tracked event. Each Item that triggers the rule gets it’s own timer. If you add a second trigger, for example triggering when the lights change, then that light change event is managed completely independently from the motion sensor events. The two are not associated with each other.

It doesn’t follow the pattern of “when Item X remains in state Y for Z minutes, call rule A”. You need " When Item X or B changes, after Z minutes after the last change to Item X, call rule A". This template can’t do that.

But it doesn’t really need to. Just using the motion sensor is sufficient. And you don’t need the template either. You can use a simple rule and expire.

Ltty · June 4, 2024, 2:33pm

@rlkoshak, thanks for pointing me to the right version of the plugin. So I have the following setup:

var group = 'gHumidityWarnings';
var thresholdStr = '65';
var operator = '>';
var invert = false;
var namespace = 'humidityAlert';
var alertRuleUID = 'fb29dcd466';
var endAlertUID = 'fb29dcd466';
var hystRange = '3';

If I understand correctly, his will trigger “fb29dcd466” as soon as the humidity threshold of any item exceeds 65 and calls the rule. The end rule will be executed when the threshold returns below 65-3. Is this correct?

Now I added a Metadata Item called “humidityAlert” to one of my humidity sensors with

value: " "
config:
  hysteresis: 10

And the alert/end rule looks like this:

if(isAlerting) {
    dehumidifier.sendCommand('ON');
  } else {
    dehumidifier.sendCommand('OFF');
  }

The dehumidifier turns on as soon as humidity reaches 66%, as expected. However, I would expect that it turns off at 55. Instead it turns off as soon as the humidity parameter changes below the threshold.

What am I doing wrong?

rlkoshak · June 4, 2024, 2:56pm

Yes assuming your Items do not carry units. If they do, your threshold and hyst also need to carry compatible units (e.g. 65 %).

Unfortunately this rule template is by far my most complex.

When you run the rule manually do you see anything in the logs to indicate an error? A typical output looks like this:

2024-06-04 08:45:05.092 [INFO ] [Threshold Alert.humidityLowDetection] - Rule triggered without an Item event, ExecutionEvent checking the rule config
2024-06-04 08:45:05.094 [INFO ] [Threshold Alert.humidityLowDetection] - Cancelling any running timers
2024-06-04 08:45:05.254 [INFO ] [Threshold Alert.humidityLowDetection] - No initial alert rule configured, no rule will be called when the alert state is first detected                            
2024-06-04 08:45:05.264 [INFO ] [Threshold Alert.humidityLowDetection] - These Items do not have humidityAlert metadata and will use the default properties defined in the rule: Mainfloorsensors_Humidity, JennsOfficeSensors_Humidity 
2024-06-04 08:45:05.298 [INFO ] [Threshold Alert.humidityLowDetection] - Threshold Alert configs check out as OK

You should expect all your Items except the one you’ve added metadata to in the second to last log statement. That will show if there is a typo in the namespace between what the rule expects and what you added to the Item. If there is a problem there should be a log statement indicating what’s wrong.

If that checks out, put the rule into debug level logging and post the logs of the Item changing above the alert threshold and then stops alerting.

Ltty · June 4, 2024, 5:42pm

Ok, can confirm that the hysterese is not overriden by the metadata. I can confirm I am using the correct name space.

For now I created two separate rules with different hysterese values which works fine.

If I have time, I take a look at the code and see if I can find the issue.

rlkoshak · June 4, 2024, 6:37pm

If you post debug logs I can work out what is going on.

The line in the script that pulls the hysteresis from metadata is 472:

  record.hysteresis    = stateToValue((md['hysteresis'] !== undefined) ? md['hysteresis'] : hystRange);

And once it’s done it logs out the “record” of values that will be used to process the event.

Ltty · June 10, 2024, 9:31am

There might be a bug with hysteresis settings overall. I tested another rule that should fire an alert when it starts to rain, i.e. when the rain amount in the past hour exceeds 0.3mm/h.

The item that holds the rain in mm/h is a dimensionless number item with a custom state description %.1f mm/h
The rule uses 0.3 as the initial threshold and 0.3 as the hysteresis, so alerting stops after reaching 0.0 again

var group = 'gRainWarnings';
var thresholdStr = '0.3';
var operator = '>=';
var alertRuleUID = '9586d73c23';
var hystRange = '0.3';
var initAlertRuleUID = '9586d73c23';

I am using the initAlertRule because at first, I noticed multiple events with alerting whenever the item received an update. Thus the rule now looks as the following:

if(isInitialAlert) {
  console.log('It started to rain');
  actions.NotificationAction.sendBroadcastNotification('It started to rain');
 }

I would expect a single notification, the first time the threshold is above 0.3. What I currently get is a notification everytime the item is updating and above 0.3.

I ran the script config without the event and it does not show any errors in the log:

2024-06-10 11:36:44.428 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - Rule triggered without an Item event, ExecutionEvent checking the rule config
2024-06-10 11:36:44.433 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - Cancelling any running timers
2024-06-10 11:36:44.434 [DEBUG] [org.eclipse.jetty.io.ChannelEndPoint] - flushed 7 SocketChannelEndPoint@140f6ab{l=/192.168.0.15:8080,r=/192.168.0.23:59196,OPEN,fill=-,flush=W,to=10/30000}{io=0/0,kio=0,kro=1}->HttpConnection@d18037[p=HttpParser{s=CONTENT,0 of -1},g=HttpGenerator@13eaf63{s=COMMITTED}]=>HttpChannelOverHttp@106026e{s=HttpChannelState@73aa79{s=WAITING rs=ASYNC os=COMMITTED is=IDLE awp=false se=false i=false al=2},r=3,c=false/false,a=WAITING,uri=//192.168.0.15:8080/rest/events?topics=openhab/rules/3ac6b6a352/*,age=51895}
2024-06-10 11:36:44.438 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - Items without thresholdAlert alertDelay metadata will alert immediately
2024-06-10 11:36:44.440 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - Items without thresholdAlert remPeriod metadata will not repeat alerts
2024-06-10 11:36:44.496 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - No end alert rule configured, no rule will be called when alerting ends
2024-06-10 11:36:44.559 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - These Items do not have thresholdAlert metadata and will use the default properties defined in the rule: Netatmo_Rain_Sensor__Rain_1h
2024-06-10 11:36:44.621 [INFO ] [les_tools.Threshold Alert.3ac6b6a352] - Threshold Alert configs check out as OK

It started to rain a few minutes ago. This is what I see in the logs:

2024-06-10 15:06:33.128 [INFO ] [nhab.automation.script.ui.9586d73c23] - Rain threshold triggered with Item Netatmo_Rain_Sensor__Rain_1h, state 0.32123123 initialAlert true and alerting false
2024-06-10 15:06:33.341 [INFO ] [nhab.automation.script.ui.9586d73c23] - It started to rain
2024-06-10 15:06:33.992 [INFO ] [nhab.automation.script.ui.9586d73c23] - Rain threshold triggered with Item Netatmo_Rain_Sensor__Rain_1h, state 0.32123123 initialAlert false and alerting true
2024-06-10 15:16:33.828 [INFO ] [nhab.automation.script.ui.9586d73c23] - Rain threshold triggered with Item Netatmo_Rain_Sensor__Rain_1h, state 1.399999976158142 initialAlert true and alerting false
2024-06-10 15:16:33.831 [INFO ] [nhab.automation.script.ui.9586d73c23] - It started to rain
2024-06-10 15:16:33.982 [INFO ] [nhab.automation.script.ui.9586d73c23] - Rain threshold triggered with Item Netatmo_Rain_Sensor__Rain_1h, state 1.399999976158142 initialAlert false and alerting true

Any ideas?

rlkoshak · June 10, 2024, 2:32pm

Do you mean Number:Dimensionless (which doesn’t make sense) or Number? If you know it’s in mm/h, why not use a Number:Speed with unit of mm/h?

Add an endAlertRule to log out when the alerting ends. Based on the logs and the timing it looks like the rain rate fell to 0 at least once after 15:06:33:992 which ended the alert. So when the next value over 0.3 came in it’s a brand new alert. If that’s the case, the rule is behaving as expected.

But there isn’t enough information presented to confirm. I’d need both the relevant events.log and logs generated on an endAlert.

That or I need debug level logs from the rule.

Ltty · June 13, 2024, 3:06pm

Hey,

After fixing all my UoM settings, I may have found the issue with the custom meta data.

2024-06-13 17:02:49.987 [INFO ] [les_tools.Threshold Alert.43d0ae47f6] - These Items do not have humidityAlert metadata and will use the default properties defined in the rule: GF_Toilet_HomematicTemperatureSensor_Humidity, GF_LivingDining_HomematicTemperatureSensor_Humidity, FF_Bedroom_HomematicTemperatureSensor_Humidity, FF_BathRoom_HomematicTemperatureSensor_Humidity, FF_GuestRoom_HomematicTemperatureSensor_Humidity, FF_KidsRoom_HomematicTemperatureSensor_Humidity
2024-06-13 17:02:50.405 [ERROR] [les_tools.Threshold Alert.43d0ae47f6] - Item C_HobbyRoom_HomematicTemperatureSensor_Humidity has a hysteresis 10 % with units incompatible with Percent

The item is a Number:Dimensionless with Unit %.

Best,
Florian

rlkoshak · June 13, 2024, 3:33pm

Again, without debug level logs I won’t be able to do much to help. All In can guess is that “stateToValue” function isn’t identifying the “10 %” as a QuantityType correctly. But without the debug level logs I can’t say why.

The error is coming from:

    else if(md['hysteresis'] && item.quantityState !== null && stateToValue(md['hysteresis']).unit !== undefined) {
      try {
        item.quantityState.equals(stateToValue(md['hysteresis']));
      } catch(e) {
        error = true;
        console.error('Item ' + item.name + ' has a hysteresis ' + md['hysteresis'] + ' with units incompatible with ' + item.quantityState.unit);
      }
    }

which is happening because something in stateToValue or the call to equals is throwing an exception.

If you can’t post debug level logs, you can modify this consle.error statement and log out the exception e and maybe that will provide more details. But the debug level logs would be better.

Ltty · June 27, 2024, 4:42pm

Hey, managed to get debug logs working. I didn’t see an output because there’s a space in Threshold Alert:

 var loggerBase = 'org.openhab.automation.rules_tools.Threshold Alert.'+ruleUID;

Removed the space and debug logs started to show up after setting the debug level. Will now collect logs and share the results.

Best,
Florian

rlkoshak · June 27, 2024, 8:28pm

Hmmm, I didn’t think that a space would be a problem with logger names. I swear I’ve successfully used that before. Maybe I’m mistaken. Glad you got some logs and look forward to figuring out what’s going on.

Ltty · July 12, 2024, 2:15pm

Ok here we go…

To simplify things, I used a group with a single item. The item in the group contains rainfall in mm in the past hour. The rule is configured to alert if rainfall in the last hours exceeds 0.3 mm. Hysteresis is set to 0.2 mm.

In the following screenshot you can see that initial alert and alerting is triggered every time the item changes and is above the 0.3 mm threshold.

Debug logs from your rule:

2024-07-12 15:41:05.209 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Rule 9586d73c23 has been called for Netatmo_Rain_Sensor_Rain_1h
2024-07-12 15:41:05.244 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Processing state 0.9 of type object
2024-07-12 15:41:05.245 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a QuantityType, converting to Quantity: 0.9
2024-07-12 15:41:05.247 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Populating record from Item metadata or rule defauls
2024-07-12 15:41:05.288 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Converting threshold to value
2024-07-12 15:41:05.290 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Processing state 0.3 mm of type string
2024-07-12 15:41:05.291 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a string: 0.3 mm
2024-07-12 15:41:05.292 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a Quantity: 0.3 mm
2024-07-12 15:41:05.299 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Converting hysteresis to value
2024-07-12 15:41:05.300 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Processing state 0.2 mm of type string
2024-07-12 15:41:05.301 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a string: 0.2 mm
2024-07-12 15:41:05.302 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a Quantity: 0.2 mm
2024-07-12 15:41:05.306 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Processing event for Item Netatmo_Rain_Sensor_Rain_1h with properties:
 Threshold          - 0.3 mm
 Operator           - >=
 Invert             - false
 Reschedule         - false
 Alert Delay        -
 Reminder Period    -
 Alert Rule ID      - 9586d73c23
 End Alert Rule ID  - 9586d73c23
 Init Alert Rule ID - 9586d73c23
 Gatekeeper Delay   - 0
 Hystersis          - 0.2 mm
 Rate Limt          -
 DnD Start          - 00:00
 DnD End            - 00:00
2024-07-12 15:41:05.308 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Alert timer expired for Netatmo_Rain_Sensor_Rain_1h with dnd between 00:00 and 00:00 and reminder period
2024-07-12 15:41:05.309 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Timeout  is not valid, using null
2024-07-12 15:41:05.311 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Checking if we are in the alerting state: 0.9 mm >= 0.3 mm
2024-07-12 15:41:05.316 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Result is true
2024-07-12 15:41:05.317 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Netatmo_Rain_Sensor_Rain_1h is still in an alerting state.
2024-07-12 15:41:05.319 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Calling 9586d73c23 with alertItem=Netatmo_Rain_Sensor_Rain_1h, alertState=0.9 mm, isAlerting=true, and initial alert false
2024-07-12 15:41:05.331 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Waiting until null to send reminder for Netatmo_Rain_Sensor_Rain_1h
2024-07-12 15:41:05.349 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Processing state 0.9 mm of type string
2024-07-12 15:41:05.350 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a string: 0.9 mm
2024-07-12 15:41:05.352 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - state is a Quantity: 0.9 mm
2024-07-12 15:41:05.354 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Checking if we are in the alerting state: 0.9 mm >= 0.3 mm
2024-07-12 15:41:05.359 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Result is true
2024-07-12 15:41:05.367 [INFO ] [nhab.automation.script.ui.9586d73c23] - Rain threshold triggered with Item Netatmo_Rain_Sensor_Rain_1h, state 0.9 mm initialAlert false and alerting true
2024-07-12 15:41:05.378 [DEBUG] [c6b6a352.Netatmo_Rain_Sensor_Rain_1h] - Rule 9586d73c23 has been called for Netatmo_Rain_Sensor_Rain_1h

Ten minutes later, the debug logs look exactly the same with the the value being 1.2 mm instead of 0.9 and so forth. Does this help?

It looks like the rule identifies the item as still being in alerting state, but still triggers a new alert…

rlkoshak · July 12, 2024, 2:57pm

This will take some analysis but some things I notice on a first scan through the logs:

You are using the same rule for alerting, end alerting and initial alerting but you have no alert delay. That makes either the alert rule or the initial alert rule redundant. You don’t need both. For example, if the alert delay is 5 minutes, as soon as the state exceeds the threshold the initial alert rule is called. If it remains in the alerting state for five minutes the alert rule gets called. Finally, if the alert rule was called and the state falls back below the threshold (minus hysteresis) the end alert rule is called. If you have no alert delay, you don’t need the initial alert rule. Leave that blank.
I think what I need is the full set of logs, not just one run through the rule. I need the logs when the Item initial enters the alerting state, any time it calls your rule after entering that alerting state, and then when it exits the alerting state. All this log tells me is that the Item changed to 0.9 mm and it’s already alerting. But I can look into why it called the rule again.
I don’t see the hysteresis being applied. Though I might not have proper logging for that.

I might need to add some more logging and have you try again with a new version of the rule to figure out what is happening. But for now, either edit the rule or recreate the rule and do not supply an initial alert rule.

Ltty · July 13, 2024, 5:53am

I know. I intentionally wanted to monitor the full cycle, so the rule has an if/else statement to differentiate between initial, alerting and end.
Sure, let’s do that. I am wondering, is it possible to configure the rule so logs are written to its own log file? That way I don’t have to sit in front of the computer everytime it starts to rain.
I am not sure either, but from my humidity items in a different rule, I saw the hysteresis working. In the case of the rain rule for whatever reason, the end rule however is never triggered.

Anyways, if you can provide me a version of the rule for testing, and we ideally pipe those logs in it’s own file to get a full history of all events, I am happy to dig deeper.

rlkoshak · July 13, 2024, 3:31pm

you can do that in log4j2.xml. You’ll need to create a new appender. Use the events.log appender as the example. Then you need to create a logger at the bottom for the rule’s logger name and configured to use the new appender. It should be easy to figure out beard on the stuff already on log4j2.xml.

ErikDB · July 13, 2024, 4:55pm

I bookmarked this for when I want to log in a separate file: Javascript - logging into different file - #6 by ErikDB

Ltty · July 15, 2024, 7:50am

Thanks. Last question, does a change to the log4j.xml require a restart of openhab or is the config reloaded at runtime atuomatically (or if it is not, is there a way to reload the config without restarting openhab)?

ErikDB · July 15, 2024, 7:51am

No restart necessary.

Ltty · July 16, 2024, 1:05pm

Hey Rich,

here’s a complete log for a CO2 threshold: threshold.log (154.8 KB)

The log file starts with the initialization of the rule, I manually triggered it to validate the configuration.
You can then see a couple of events, where the item value changes/updates until the threshold of 1000 ppm is reached
After it reaches the threshold of 1000 ppm every change triggers the alert rule. You can see that nicely in the logs
After going below the threshold of 1000 ppm the alerting rule is not triggered anymore and the alerting stops.
The end rule is never called after reaching the hysteresis, which you can also see in the logs. The hysteresis is set to 200 ppm

Here’s the configuration:

configuration:
  dndEnd: 00:00
  rateLimit: ""
  invert: false
  initAlertRule: ""
  dndStart: 00:00
  alertRule: b67eaa65f0
  endAlertRule: b67eaa65f0
  thresholdState: 1000 ppm
  defaultRemPeriod: ""
  operator: ">"
  hysteresis: 200 ppm
  reschedule: false
  namespace: thresholdAlert
  gkDelay: 0
  defaultAlertDelay: ""
  group: gCoWarnings

Just to be complete: The channel reports CO2 as Number:Dimensionless, the unit set on the item is ppm according to the Openhab docs.

The overall behavior is the same as for the rain threshold, the only difference except from the threshold values is that the channel reports Number:Length, and the unit set on the item is mm.

Best,
Florian