Updating Status with a rule

Hi All.
i have been trying to get this to work and i have tried everything.
my alarm status gets its updates from a raspberry pi that is monitoring my alarm by using node red. and sends the statuses via mqtt. my issue is that when my laptop restarts that runs openhab. my Alarm status is just a - and my rules depends on that status.

so i have tryde a rule to update it to Disarmed when the system restarts.

Rule tested 1:

rule "alarm notify"
when
	Item Alarm_Status changed
then
	// do something
   sendBroadcastNotification("Alarm " + Alarm_Status.state.toString + " - " + now.toString("MM/dd HH:mm "))	
end


rule "Alarm Correction"
when
	System started
then

  Alarm_Status.postUpdate( Disarmed )
	 
	
end

And Also 2:

rule "Alarm Correction"
when
	System started
then
 if ( Alarm_Status.state == NULL)  {
  Alarm_Status.postUpdate( Disarmed ) }

But it just does not do anything.

just get a error on it ?

The Rule that is dependend on the status :

rule "Stoep Light Off"
when
    Item vTimeOfDay changed to "BED"
   
then
 if ( Alarm_Status.state == "Armed-Stay" ) {
  Kitchen_Light_Stoep.sendCommand(OFF) }
 if ( Alarm_Status.state == "Disarmed"|| Kitchen_Light_Stoep == "ON" )  {
  sendBroadcastNotification("Stoep Light Still On" + " - " + now.toString("MM/dd HH:mm ")) }
 
end

Use MapDB persistence with the restoreOnStartup strategy. It should work with your described issue. Persist the items that you want a last value after startup. My 2 cents.

If you examine your Item state at this time, it is likely to be NULL.
This is something you can test for in your rules, and handle in whatever way you think appropriate.

if (myItem.state == NULL) {
   logInfo("test", "item not initialized yet")
} else {
   // ordinary processing
}

Sometimes persisting and restoring the last state of an Item across a reboot is a good idea. But not always, sometimes you actually want to know “don’t know yet” as opposed to “maybe it still X”.
The choice is yours.

That is where my thing comes in.
this might be a whole devrant issue.
the alarm statuses gets read from the alarms outputs (12v) to raspberry pi’s GPIO
that sends a mqtt message to openhab with the status.
issues with the design .

  1. if there is a panic / dures it is a pulsed output. ( once cleared it goes to Disarmed)
  2. the burglary if it is made and the siren reset time on alarm silences the alarm. node red sends a Disarmed msg to openhab. (need to sort it out still)
  3. when openhab restarts (remote work done on system) if alarm is in any state being armed away or stay & disarmed. ) you don’t

get any status on openhab til you rather rearm the alarm.to get the new status.

and thats where the issue with the rules come in.

Will i use the system started as trigger ?
and then just post state as update to that item ?

i don’t get any errors with the Rule if i only post the update to the alarm status. but it seems like none of my rules work. just the standard one that turns the light on when TOD changes to evening ?

somthing els i found in the log.

2020-05-26 10:14:56.868 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Alarm.rules'

2020-05-26 10:14:56.871 [WARN ] [el.core.internal.ModelRepositoryImpl] - Configuration model 'Alarm.rules' is either empty or cannot be parsed correctly!

2020-05-26 10:14:58.230 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'Alarm.rules'`

So long as the last thing that happens is the “good” loading message, that’s fine, it’s just the way your editing tool works.

Thank you. i use Github and do all the editing remotely and then pull all changes once a day to my server.

No idea what you are trying to achieve, really.

You can choose what to do

Write your other rule(s) to deal with the NULL case. You know that means “don’t know yet” and can take actions or not that you want.
or
You can use persist/restore to “remember” the last good value, and hope that is still true
or
You can force the state to a known value at system startup, and hope that might be correct.

For that last, you kept secret the error you had with your little rule, but it is straightforward. Not -
Alarm_Status.postUpdate( Disarmed )
but
Alarm_Status.postUpdate("Disarmed")

Sorry 1 more dumb question.
does your rule differ from a string or number to just a item state ?

example.
Site Map :

 Default item=Alarm_Status label="Alarm Status" icon="siren"

Item :

String  Alarm_Status    "Alarm Status"                              {channel="mqtt:topic:mosquitto:Alarm_Stat:alarm_status"}

Rule :

rule "alarm notify" //* Only Works Now and Then*//
when
	Item Alarm_Status changed
then
	// do something
   sendBroadcastNotification("Alarm " + Alarm_Status.state.toString + " - " + now.toString("MM/dd HH:mm "))	
end


rule "Alarm Corection"
when
	System started
then

  Alarm_Status.postUpdate ( "Disarmed" )
	 
end

I don’t know what you mean. What rule?

Explanation of NULL
Every Item is born with state NULL at system startup. That’s the way it stays until something happens to it. An update from a rule or binding, a restore from persistence, etc.
Every type of Item has the same special state NULL, it’s like a system constant for using in rules.

if (myNumberItem == NULL) ...
if (myDimmerItem == NULL) ...
if (myStringItem == NULL) ...

Note that last one, because myStringItem == "NULL" is not the same thing at all. If that were true, the Item state would the characters “N”,“U”,“L”,“L” that is to say just a string, and not the special value NULL

Something you might also have to deal with, because your Item is linked to MQTT binding, the binding (depending on version) can set special state UNDEF until the first MQTT message comes.
UNDEF is very like NULL of course, but can be forced by bindings.
If that is going on here, it will be in your logs. Remember we cannot see those, so if you do not look in them and say what you see, we have to guess at your problems.

just need to read how. then will get them for you to see.

Thank you got that sorted and working.
thanks alot. just got the logs now i see that i have a bunch of weird warnings.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.