I have difficulties getting my OpenHAB2 alarm system to work (on a Synology DS, so still on OpenHAB 2.2 with KNX1.9).
I read Design Patterns and other stuff, and installed the Epire-binding for the Timers. But I don’t even get the flag for alarm armed (“AlarmScharf”) switched, so I’ll leave out integrity breach and and inner actitiy detection items and logic for now.
I have two keys that trigger some auto-functions when I leave and when I come home (hardware configuration, works flawless):
“Anmeldung” = at home, ETS-GA type switch,
“Abmeldung” = away, ETS-GA type 1 byte for some reason, not sure if that has to do with it (created by my electrician).
There is no dedicated hardware storing the keys’ status, so I wanted to organize the alarm by virtual items that finally (de-)activate the surveillance and alarm functions.
I can see all gAL member items in the sitemap, but I don’t see any changes in them (not even in the timers) when pressing the keys, even with reloading the page. Only “Anmeldung” is displayed ON for a fara more thatn 2m after pressing the AtHome key. RestAPI shows Anmeldung = ON and Abmeldung = OFF, all other items/timers = NULL
.items:
// Alarm
//====================
Group gAL "Alarmanlage"
Switch Anmeldung "Anmeldung" <present> (gAL) {knx="<key's GA>"} // switch key (type switch) at door to arm and trigger auto-functions for arrival/being home. No hardware stores that => virtual item AlarmScharf = OFF
Switch Anmeldung_Timer "Anmeldung Timer" <time> (gAL) {expire="2m,command=OFF"}
Switch Abmeldung "Abmeldung" <present-off> (gAL) {knx="<other key's GA>"} // switch key (type byte, for some reason I do not know) at door to disarm and trigger auto-functions for leaving/being away. No hardware stores that => virtual item "AlarmScharf" = ON
Switch Abmeldung_Timer "Abmeldung Timer" <time> (gAL) {expire="2m,command=OFF"}
Switch AlarmScharf "Alarm Scharf" <alarm> (gAL) // Alarm system armed
Switch FensterOffen "FensterOffen" <shield> (gAL) // any door lock / window contact open = external shell integrity breach (external surveillance)
Switch Praesenz "Präsenz" <motion> (gAL) // any internal presence detectors registered activity (interior surveillance)
Switch Praesenz_Timer "Präsenz Timer" <time> (gAL) {expire="2m,command=OFF"}
Switch Prasenz_Override "Praesenz Override" (gP) // Set to ON to make Presence alway be true
(... plus alarm hardware, works)
.rules:
rule "System started"
when
System started
then
Anmeldung.sendCommand(OFF) // assume no one disarmed alarm on startup
Abmeldung.sendCommand(OFF) // assume no one armed alarm on startup
AlarmScharf.sendCommand(OFF) // assume alarm is disarmed on startup
Praesenz.sendCommand(OFF) // assume no presence detected on startup
end
rule "Alarmanlage scharf schalten" // disarm OpenHAB2 alarm system
when
Item Anmeldung received command
then
if(receivedCommand == ON && AlarmScharf.state == ON) { ////if armed
AlarmScharf.postUpdate(OFF) // disarm
Abmeldung.postUpdate(OFF) // I do not know if other keys status is stored in hardware (should nt), but just to be sure.
Abmeldung_Timer.postUpdate(OFF) // cancel expire-binding timer for leave tolerance if necessary
Anmeldung_Timer.postUpdate(ON) // start expire-binding timer for arrival tolerance (for future use)
}
}
else {
Anmeldung.sendCommand(OFF) // covered by Alarmanlage entschärfen
}
end
rule " Alarmanlage entschärfen" // disarm OpenHAB2 alarm system
when
Item Abmeldung received command
then
if(receivedCommand == ON && AlarmScharf.state != ON) { //if disarmed
AlarmScharf.sendCommand(ON) // arm
Anmeldung.postUpdate(OFF) // I do not know if other keys status is stored in hardware (should not), but just to be sure.
Anmeldung_Timer.postUpdate(OFF) // cancel expire-binding timer for arrival tolerance if necessary
Abmeldung_Timer.postUpdate(ON) // start expire-binding timer for leave tolerance (before alarm works)
}
}
else {
// Abmeldung.sendCommand(OFF) // covered by Alarmanlage scharf schalten
}
end
rule "Anmeldung_Timer expired"
when
Item Anmeldung_Timer received command OFF
then
Anwesenheit.sendCommand(OFF)
end
rule "Abmeldung_Timer expired"
when
Item Abmeldung_Timer received command OFF
then
Abwesenheit.sendCommand(OFF)
end
With Your support and the RestAPI, I found out that my “Abmeldung” Switch actually works reverse - which really entangled me in debugging. So I had to substitute “OFF” for Abmeldung active state, and “ON” for Abmeldung inactive state… weird, but probably the electrician took a short cut in the ETS configuration, leading to a not so clean setup. I will debug that later and go with the inversed logic for now.
Here is the rules code that works (specific for my system, so please remember to exchange OFF and ON at the marked places when using the code):
In the system started section:
Abmeldung.sendCommand(ON) // assume no one armed alarm on startup (inverse configuration in ETS, so ON=inactive)
The rules themselves:
rule "Alarmanlage entschärfen" // disarm OpenHAB2 alarm system
when
Item Anmeldung received command
then
if(receivedCommand == OFF && AlarmScharf.state != OFF) { // if armed
AlarmScharf.postUpdate(OFF) // disarm
Abmeldung.postUpdate(ON) // deactivate counter status (inverse configuration in ETS, so ON=inactive)
Abmeldung_Timer.sendCommand(OFF) // cancel expire-binding timer for leave tolerance if necessary
Anmeldung_Timer.sendCommand(ON) // start expire-binding timer for arrival tolerance (for future use)
}
/*else {
Anmeldung.sendCommand(OFF) // covered by "Alarmanlage entschärfen"
}*/
end
rule " Alarmanlage scharf schalten" // arm OpenHAB2 alarm system
when
Item Abmeldung received command
then
if(receivedCommand == ON &&*/ AlarmScharf.state != ON) { //if disarmed. Inverse configuration in ETS, so ON=inactive)
AlarmScharf.postUpdate(ON) // arm
Anmeldung.postUpdate(OFF) // deactivate counter-status
Anmeldung_Timer.sendCommand(OFF) // cancel expire-binding timer for arrival tolerance if necessary
Abmeldung_Timer.sendCommand(ON) // start expire-binding timer for leave tolerance (before alarm works)
}
/*else {
// Abmeldung.sendCommand(OFF) // covered by "Alarmanlage scharf schalten"
}*/
end
rule "Anmeldung_Timer expired"
when
Item Anmeldung_Timer received command OFF
then
Anmeldung.sendCommand(OFF)
end
rule "Abmeldung_Timer expired"
when
Item Abmeldung_Timer received command OFF
then
Abmeldung.sendCommand(ON) // inverse configuration in ETS, so ON=inactive
end
This kind of thing is routine in alarms.
A closed circuit, a switch at on, is used to to indicate a “good” status. This is because it includes a check on the wiring (or nowadays other subsystems) inbetween, for tampering or faults.
An open circuit, switch at off, is used to signal an “alarm” - it might be a real alarm or a fault, but you want to know about it.
It’s basic integrity checking e.g. cut wires cause alarm.
When writing rules for Openhab, you should bear in mind that say a switch status can be ON or OFF - or also Unav or Undefined in the case of a fault or error.
Pay attention in alarm rules to distinguishing between testing for i.e. OFF, and testing for NOT ON - which isn’t quite the same thing.
You’d usually test for whichever is your ‘safe’ condition and assume anything else is an ‘alarm’ condition.
Thank you, I haven’t noticed it so far, because I assumed the topic or OP to be flagged, not the replies (which does make sense, on second thought).
[quote=“rossko57, post:9, topic:42571”]
This kind of thing is routine in alarms.[/quote]
I’m aware of that logic, but I’m quite confident this did not arise on purpose… One switch one way, the other the other way, both not directly critical… That fits better my bill of my electrician not activating many GAs and functions to prepare a server-based surveillence than a purposeful fail-safe design.
Thanks for pointing that out - I already noticed that those details should be considered as soon as the basics are up and running. For the time being, I do not expect the system to meet industry standards, but I shall be happy if it responds correctly to basic attacks. The logic of professional solutions is obviously not created in the wink of an eye…
Absolutely right. Good habits can be built in though. I find worrying about the fine detail of whether to trigger a rule from changed to OFF or trigger from changed only but then test to see if the Item is ON - can be headache inducing!
