I can stay right off the bat without even looking at the code that there is a better way than replicating the same two rules over and over.
First, let’s consider the alerting part. Actually, you’ve stumbled upon a fairly elegant way to keep getting the same alert over and over as long as the freezer is too warm. If this were your only sensor that you need to alert in this way I would absolutely leave it as written.
However, you’ve more than one of these to report on and it’s generally not the best idea to have a lot of duplicated code. So let’s rework it. In fact I actually just rewrote my own code that does this for some of the services and machines my home automation depends upon. Unfortunately, my code only works with Switches and it’s written in Python. I’ll post it below for the curious.
The general approach is to set a flag when you send the alert that the temp is above the threshold. When that flag is true, you know that you’ve already sent the alert that the temp is too high. When the temp drops again, send the alert and set the flag to false. As long as the temp stays below the threshold and the flag is false don’t sent the alert.
var freezer_alert_sent = false
rule "Freezer Temp Alarm"
when
Item Freezer_Temp changed
then
var temp_high= Freezer_Temp.state > -10
if(temp_high && !freezer_alert_sent){
logInfo("notifications", "Sending Freezer Alarm: " + Freezer_Alarm.state + ", Current Temp is " + Freezer_Temp.state)
freezer_alert_sent = true
}
else if(!temp_high && freezer_alert_sent){
logInfo("notifications", "Cancelling Freezer Alarm")
freezer_alert_sent = false
}
end
So in the above we figure out whether the temp is too high. If so and we haven’t already alerted, we generate the alert and set the flag to true. If the temp is not too high and we’ve previously alerted, we send the cancelling message and set the alerted flag to false.
But what if we can make this even more generic. What if we use String Items for the alert Item and we move the alerting checking into one central place?
Why a String? Because that will let us have a unique message for each sensor. It also lets us use the transform Profile which we could use with the JavaScript transformation or the Scale transformation to eliminate the Rule that checks the temp.
-
Create a Group to hold all the Alarm Items. Group:String Alarms
-
Change Freezer_Alarm to be a String and add a JS transform.
String Freezer_Alarm { channel="zwave:device:cc323ca9:node21:sensor_temperature"[profile="transform:JS", function="freezer_alert.js"] }
- Create
freezer_alert.js:
(function(i) {
if(isNaN(i)) return "alarm";
if(i > -10) return "alarm";
else "normal"
})(input)
This moves the freezer check out of the Rule. Of course, this could also be done in the Rule. I just wanted to show an alternative approach. Neither is better or worse as an approach.
- Make a generic alerting Rule.
import java.util.Map
val Map<String, Boolean> alerted_flags = newHashMap
rule "Alerting"
when
Member of Alarms changed to "alarm" or
Member of Alarms changed to "normal"
then
// We don't care about changes from UNDEF and NULL
if(oldState == NULL || oldState == UNDEF) return;
var alerted = alerted_flags.get(triggeringItem.name)
if(alerted == null) flag = false
val device = triggeringItem.name.split("_").get(0)
if(newState == "alarm" && !alerted){
logInfo("notifications", "Sending " + device + " Alarm!")
alerted_flags.put(triggeringItem.name, true)
}
else if(newState == "normal" && alerted){
logInfo("notifications", "Cancelling " + device + " Alarm")
alerted_flags.put(triggeringItem.name, false)
}
end
It’s also possible to include the sensor reading in the alert message itself using Design Pattern: Associated Items - #25 which I’ll leave as an exercise.
Here is my Python code. It works on Switches but the overall concept is the same. I do use access to Item metadata to convert the name of my Item to something more human friendly (see Design Pattern: Human Readable Names in Messages - #11 by NCO and Design Pattern: Using Item Metadata as an Alternative to Several DPs - #13 by TI89).
from core.rules import rule
from core.triggers import when
from core.metadata import get_key_value, set_metadata
from personal.util import send_info, get_name
@rule("Offline Alert",
description="Triggers when a status Switch Item changes state",
tags=["admin"])
@when("Member of gSensorStatus changed to ON")
@when("Member of gSensorStatus changed to OFF")
def offline_alert(event):
if isinstance(event.oldItemState, UnDefType):
offline_alert.log.debug("{} changed to {} from {}, ignoring."
.format(get_name(event.itemName), event.itemState,
event.oldItemState))
return
alerted = get_key_value(event.itemName, "Alert", "alerted") or "OFF"
# If we were OFF (alerted == "ON") and we are now ON, or visa versa, alert.
if str(event.itemState) == alerted:
on_off_map = { ON: "online", OFF: "offline" }
send_info("{} is now {}".format(get_name(event.itemName),
on_off_map[items[event.itemName]]),
offline_alert.log)
set_metadata(event.itemName, "Alert",
{ "alerted": "OFF" if alerted == "ON" else "ON" },
overwrite=True)
# Log a warning if the alerted state doesn't match the Item state.
else:
offline_alert.log.warn("Item {} changed to {} but alerted is {}, ignoring."
.format(event.itemName, event.itemState, alerted))
@rule("Offline Status Reminder",
description=("Send a message with all the offline sensors at 08:00 and "
"at system start"),
tags=["admin"])
@when("Time cron 0 0 8 * * ?")
@when("System started")
def offline_status(event):
nullItems = [i for i in ir.getItem("gSensorStatus").members
if isinstance(i.state, UnDefType)]
nullList = ", ".join(["{}".format(get_name(s.name)) for s in nullItems])
offItems = [i for i in ir.getItem("gSensorStatus").members
if i.state == OFF]
offList = ", ".join(["{}".format(get_name(s.name)) for s in offItems])
if len(nullItems) == 0 and len(offItems) == 0:
offline_status.log.info("All sensors are online")
msg = ""
if len(nullItems) > 0:
msg = "The following sensors are in an unknown state: {}".format(nullList)
if len(offItems) > 0:
msg = ("{}{}The following sensors are known to be offline: {}"
.format(msg, "" if len(msg) == 0 else "\n", offList))
[set_metadata(s.name, "Alert", {"alerted" : "ON"}, overwrite=True)
for s in offItems]
send_info(msg, offline_status.log)
personal.util.send_info and personal.util.get_name are functions that implement Design Pattern: Separation of Behaviors and Human Readable Names (link above) respectively. I also posted the rule that runs every day with an alert summarizing the current status of all the devices if there are any in an unknown state or are offline. Instead of tracking a flag in a Map, I set metadata on the Item with the alerted flag.
What is not shown is for some of these offline sensors there can be times when it freaks out and starts flapping on/off/on/off lots of times in a second. To filter those out I use debounce from GitHub - rkoshak/openhab-rules-tools: Library functions, classes, and examples to reuse in the development of new Rules. which, when installed, lets you apply a debounce to an Item just by defining Item metadata.
Contact vNetwork_cerberos "cerberos Network [MAP(admin.map):%s]"
<network> (gSensorStatus, gResetExpire)
{ expire="2m",
name="cerberos" }
Contact vNetwork_cerberos_Raw
{ channel="network:servicedevice:cerberos:online",
debounce="vNetwork_cerberos"[timeout="1s", states="OPEN,CLOSED"] }
The config above will update vNetwork_cerberos only when it remains in an OPEN or CLOSED state for a full second (UNDEF and NULL are forwarded to vNetwork_cerberos immediately).
Note, the expire config above is using openhab-rules-tools’ drop in replacement for Expire 1.x binding.
