I think so …
Just trying, and immediatly first problem to create a “switch” with 3 states I want:
Switch item=AlarmArmed label=“Alarmanlage” icon=“siren” mappings=[OFF=“Aus”,STARTING="(start)",ON="! ARMED !"]
Shure, this can not work: switch has only ON/OFF.
Found this: klick
Do I need a mapping file under ./transform or use Text-item? Sorry …
Actuall I get: “… invalid status ‘Starting’ …”
I don’t think you need a three-state switch for simple function. The alarm is set or not. The timer is running or not.
If you are planning something fancier, like beeping and flashing during arm or disarm periods, then you could use a String type Item to take any values you choose.
Hmmm, I’m talking about to activate (Arm) the alarm.
This should be done with a delay, so after switching the (soft) alarm “switch” to “starting” (the new option), the next 20s open contacts will not result in a real alarm.
So I thought the three position switch will be the best way, to activate (press: starting) the alarm with delay and if inside (or from remote) I can see the alarm is “activ” (“ARMED”; after the delay).
(at the end also the hard-button should activate the alarm (arm) with a delay so we have a chance to leave the house)
Yes. Set the alarm state to whatever represents “armed” in 20 seconds time. During that 20 seconds, the alarm state is not armed. That’s just a binary, on/off function still.
If you want to represent more than two states for the alarm - and why not, real alarms do - then use a different Item type like a Number or a String.
So, here my changed part for the soft-button.
Think it should work, also with (simple) delay I added.
(0: Off, 1=start delay/activating; 2: Alarm is activ)
Is it possible to add “into” the delay from 30s a function, that the LED will switch on/off periodically (1s on, 1s off, …) til the 30s are over (than the LED should be “off”). So in the floor we can see: “Timer is running …”
rule "Alarm Softbutton changed"
when
Item AlarmArmedState changed
then
if (AlarmArmedState.state == 1)
{
logInfo("alarm.rules", "aaa deley here to activate alarm.... AlarmArmedState: {}",AlarmArmedState.state )
createTimer(now.plusSeconds(30))
[ |
logInfo("alarm.rules", "bbb delay over; Status AlarmArmedState: {}",AlarmArmedState.state )
AlarmArmedState.sendCommand(2)
]
}
if (AlarmArmedState.state == 2)
{
logInfo("alarm.rules", "ccc Alarm now actic, Alarmstate: {}",AlarmArmedState.state )
AlarmCtrlLED.sendCommand(OFF)
}
if (AlarmArmedState.state == 0)
{
logInfo("alarm.rules", "eee Alarm switches off, Alarmstate: {}",AlarmArmedState.state )
AlarmCtrlLED.sendCommand(ON)
}
end
You can find a “flashing LED” rule here
Thanks for the hint,
now the LED is blibking, and will not stop.
Still blinking, also when pressing “Armed” or “Off” …
How can I stop the rule, because I thought I have add a break-point (TimerH.cancel) and rule for starting the rule (AlarmArmedState changed from 0 to 1):
Also wondering, the loginfo (for debugging) appear only one time in the log, I thought must appear every second …
Don’t forget, I never use before a timer-function, so maybe a simple thinking- or coding error on my side is possible!
rule "blinking LED"
when Item AlarmArmedState changed from 0 to 1
then
if (TimerH != null)
{
TimerH.cancel
TimerH = null
}
TimerH = createTimer(now.plusSeconds(1)) [|
if (Alarma.state==ON)
{
Alarma.sendCommand(OFF)
logInfo("alarm.rules", "222222222222222222222222222 inside blinking timer, AlarmArmedState: {}",AlarmArmedState.state )
AlarmCtrlLED.sendCommand(OFF)
}
else
{
Alarma.sendCommand(ON)
logInfo("alarm.rules", "111111111111111111111 inside blinking timer, AlarmArmedState: {}",AlarmArmedState.state )
AlarmCtrlLED.sendCommand(ON)
}
logInfo("alarm.rules", "hhh inside blinking timer, AlarmArmedState: {}",AlarmArmedState.state )
if (AlarmArmedState.state != 1)
{
TimerH.cancel
}
TimerH.reschedule(now.plusSeconds(1))
]
end
Did you forget to add var Timer TimerH = null at the top of the rule?
No, I added already 
restarting oH, now the LED works as expected (in first tests)!
Seems a died rule was running in the background … on…off…on…
What i see now, when using the “3 position” softbutton (Off, activating, Armed), a status change from i.e. “Off” to “Armed” done on tablet A is not visible on another tablet (or PC browser) (must reload the page). The red “Off” is going to color grey on other devices, but the new status “Armed” is not going “red” (till I reload => than red)
On Tablet A colors are immediately changed as expected. Also before when having only a regular switch (on/off) the change was immediately vissible on all devices.
Must I add an “Update” option ??
In detail, here the code from the delayed activation from the alarm (switching from 1=activating to: 2=armed):
…
AlarmArmedState.sendCommand(2)
postUpdate (AlarmArmedState,2) // I try this to fix update-issue =>nok (still nothing “red”, activ in the GUI)
…
The status from the (3. position) switch is updated, must “refresh” the screen to see actuall state. Hmmm
The status is set to “2” (armed, see in log and also after refresh), but not shown in the GUI (all positions are grey)
Anyone an idea?
Actual it’s not so fine because the actual alarm state is not vissible (3x greyed)
(another simple “switch” is updated in real time everywhere)
PS: Happy new year !!
To aid understanding, if you have a Timer running when you reload a .rules file, that Timer continues to run. Very often, with things like lighting timers, you’ll get a mystery error some minutes later when the time expires. (Because other variables it refers to have been destroyed by the rules reload.)
I’m not quite sure what the blinking LED timer loop does when “cast adrift” in this way, but I expect that’s what you saw.
The various UI’s often have trouble reflecting an up to date view, without refreshing the view.
Issue with the not automatic updated “switch position” still exists.
But I also find out an issue with the alarm-state after a restart from oH instance.
I write the alarm-state in a influxdb and restore the value after an oH restart (… restoreOnStartup).
Here I see that the values are restored, but in a incorrect format.
I.e., the last value is correct “2” (vissible using the console (openhab> smarthome:status AlarmArmedState => 2" and when get value from influxdb: “2”).
After an oH restart the console give as alarm-state “2.0” !
Influxdb still give the value “2”
And the vaule 2.0 is now the reason, that also after refreshing the screen the actual-alarm state is not shown/updated, because it’s not “2”.
Switching manualy to position “2”, the consoel shwo again the correct value (format) “2”.
Where have I to set a “format”, so after oH restart the value is “2” and not “2.0” ?
Thx for this information, strange that influxdb add the .0 …
Strange issue today, after a reboot from the Rasbperry (and I have not changed anything in the Alarming-part for 2 weeks), the LED is contentious (endless) blinking after first alarm start.
(Definition: AlarmArmedStat 0= alarm off; 1= alarm delay start, 2= alarm activ)
After the delayed time the AlarmArmedState is changing from 1 to 2, correct.
now the if-part (AlarmArmedState.state != 1) is executed (I see in loginfo) and this should cancel the time (TimerH,cancel). But this is not done, no “break” out from the loop => blinking never ends.
But this if-part (and also the sendCommand on/off for the LED) is executing every second …
So in log I see:
…
2222…
hhh
zzzzz // And this SHOULD CANCEL the timer becasue the AlarmArmedState != 1
11111
hhh
zzzz
2222
…
Don’t know why? Was there a chage how to cancel a timer?
Because this code works before!
Here the code from delay, as i sayed the change from the AlarmArmedState is done correctly 0 => 1 => delay => 2 (but LED still blinking)
And yidea whats going wrong, or how I can break / stop the LED blinking?
rule "blinking LED"
when Item AlarmArmedState changed from 0 to 1
then
if (TimerH !== null)
{
TimerH.cancel
TimerH = null
}
TimerH = createTimer(now.plusSeconds(1)) [|
if (Alarma.state==ON)
{
Alarma.sendCommand(OFF)
logInfo("alarm.rules", "222222222222222222222222222 inside blinking timer, AlarmArmedState: {}",AlarmArmedState.state )
AlarmCtrlLED.sendCommand(OFF)
}
else
{
Alarma.sendCommand(ON)
logInfo("alarm.rules", "111111111111111111111 inside blinking timer, AlarmArmedState: {}",AlarmArmedState.state )
AlarmCtrlLED.sendCommand(ON)
}
logInfo("alarm.rules", "hhh inside blinking timer, AlarmArmedState: {}",AlarmArmedState.state )
if (AlarmArmedState.state != 1)
{
logInfo("alarm.rules", "zzzz Should cancel: TimerH.cancel ...., AlarmArmedState: {}",AlarmArmedState.state )
TimerH.cancel
}
TimerH.reschedule(now.plusSeconds(1))
]
end
Has anyone here an idea, still same issue as post before, but i make some tests and check the logfile little bit deeper:
The rule-part “TimerH.cancel” (fifth line from the end) is reached, because “AlarmArmedState.state” changed from “1” to “2” (vissible in log, I see the logInfo from “…zzzz Should cancel”)
But why did “TimeH.cancel” not cancel the rule / ends the rule?
Is this syntax incorrect? Unshure where I find this code, but also I thought it works before,
So: How can I “break out” from the blinking-loop when AlarmArmedState != 1 ?
The next line that gets executed after that is
TimerH.reschedule(now.plusSeconds(1))
You need to re think your if-else logic in some way. When do you want to reschedule - and when you don’t.
As I wrote, I found this code in the www (will search for the source);
but what I “want”:
When the AlarmArmedState changed from 0 to 1 the LED should be blink.
When the AlarmArmedState is no longer 1 (= 0 or 2), the LED should switch of (and no blinking anymore)
And this code is not correct for this case?
Well, does it do what you want? Apparently not, so we’ll have to change it.
Here’s what it does.
When the AlarmArmedState changed from 0 to 1 the rule runs, and creates a Timer that keeps rescheduling itself to flash LEDs.
Okay so far.
When the AlarmArmedState changed from 1 to anything else, nothing in particular happens. The rule doesn’t run.
But the timer is still doing its thing. Sometime within the next second, it will run its code block (that usually flashes the LEDs and reschedules itself).
This time, it will do its thing with the LEDs as usual.
After that, it will check what AlarmArmedState is just now - it will not be 1 this time, so it does the timer cancel. That won’t have any effect because the timer has just expired and we are running the time’s code block. cancel just says don’t do the next scheduled run - but we don’t even have a next scheduled run yet.
After that, whatever AlarmArmedState is, we reschedule the Timer for next LED flash.
There’s two ways you can go at this.
You could have another rule that triggers from AlarmArmedState, looks for the timer, cancels and destroys it. And probably makes sure the LEDs are ON or OFF or whatever you want to be tidy.
Or you can change the timer codeblock so that it doesn’t reschedule itself if AlarmArmedState is 1. And also tidies up the LEDs if you wish.
That’s probably easiest.