Keep 'when Item received update' rules from running during RestoreOnStartup

rgerrans · February 27, 2017, 4:51am

True, I was referring more to Java and getting use to the syntax structure of needing things like ‘.state’ vs just calling out a variable…

Dries · May 30, 2017, 7:07am

Hi,
I’m having the same problem. All my rules that are triggered by a “Item xxx received update” are triggered when OpenHAB is (re)started. I guess it’s the RestoreOnStartup of my MapDB.

I tried to implement some of the suggested workarounds:

Use “changed from … to …” wherever possible (and meaningful). However, that does not work for string-items that can have many values.
For some rules, it is acceptable that they are triggered on start up.

A new rule I want to set up is to send a text-message (SMS) when something happens around the house that needs my attention.

The text message itself is a string obviously. So what I would do (I’m just quickly writing this in pseudo-code):
When
Item textmessagestring received update:
Then
If textmessagestring = null => do nothing;
Else => send the actual test message and set textmessagestring to null.
End

I think this avoids text messages being sent when restarting OpenHAB.

But I think a fundamentally better solution is that OpenHAB first does a “RestoreOnStartup” and then start up the rules-engine.

rlkoshak · May 30, 2017, 11:46am

Did you try:

changed from NULL

You don’t need both the from and the to.

Is there a reason you are persisting and restoring this item? It might be easiest to simply not include this item in restoreOnStartup.

See my persistence design pattern for how to manage this using groups.

It used to work that way where restoreOnStartup happened before the rules engine started executing rules, but suspect that was caused by an accident of timing. On really fast machine or based on timing it may not always work out.

Another thing you can do is use an if(previousState != NULL) in the body of your rule and only send the message when the previous state isn’t NULL.

Dries · May 30, 2017, 1:11pm

That is indeed a better way. I don’t need to check if my item = null. However, after processing I should still change the value of that item back to NULL.

I’ve read your post(s) with great detail. I currently have two persistence strategies:

In MAPDB I persist everything on change for RestoreOnStartup;
In InfluxDB I persist a selection of groups (everyminute) for graphs and stuff.

As far as I know, you can’t define a “persist everything except…” in your persistence strategy.
My current MAPDB persistence file is pretty simple:

Items {
		* : strategy = everyChange, restoreOnStartup
}

I could decide to not use the wildcard and mention all relevant groups more explicitly. But that implies I would need to update this .persist file more often.

rlkoshak · May 31, 2017, 2:03am

Yes, that is true. Otherwise, the rule won’t fire.

No, just define a restoreOnStartup group and add all Items that should be restored to that group. Then you never need to touch the .persist file again.

Dries · May 31, 2017, 4:45pm

Will do. Thanks!

Dries · November 21, 2017, 7:09pm

Hi,
I wanted to come back on this older topic.

I’m still in a situation where many rules get triggered because the restoreOnStartup is still doing it’s job when rules are initialized.

I do have many rules that have a trigger like:

when   
    Item  MyItem received update
then

These are typically string items.
A trigger like “Item MyItem received update from anything but NULL” would solve the problem. But that is not an option.

Sometimes (in 10% of the cases), my rules are even triggered before all my items are loaded. Then I get something like this in my log:

2017-11-19 22:22:26.696 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'some.rules'
2017-11-19 22:22:30.524 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule 'Some rule': The name 'someItem' cannot be resolved to an item or type; line 286, column 8, length 35
2017-11-19 22:22:35.540 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'some.items'

Wouldn’t it make sense that OH has a more controlled process of doing certain things in a predefined sequence at start up?

Load all things & items;
Load persistence strategies and perform restoreOnStartup;
Load rules;
Load sitemaps;

Thanks,
Dries

rlkoshak · November 21, 2017, 10:26pm

It might make sense but it is a lot more challenging than you might think since all of these happen in separate threads at the same time and trying the schedule and synchronize them is not always so easy.

But I think there is an issue open to address this.

Dries · November 22, 2017, 4:20pm

Hi Rich,
Thanks for your input. I can imagine it’s not that easy. And maybe the people contributing to the code have more pressing matters to look into.

I tried locating that issue that would address this. I couldn’t find it. Unless you can tell me the issue number, I’ll create a new one.

rlkoshak · November 22, 2017, 4:28pm

I don’t know it. I’m going off a foggy memory. Open one and if it is a duplicate it will be closed. Note this is an ESH issue so it needs to be on that repo.

KjetilA · November 22, 2017, 4:30pm

@rgerrans : From your other rule (where you do SystemStarting.postUpdate()) I presume “SystemStarting” is an Item (of type Switch), right?

If so, the following piece of code needs to be modified:

to this:

if(SystemStarting.state != ON) {

I hope this helps!

Dries · November 22, 2017, 6:50pm

I thought it was an OH issue, so I was looking in the wrong place. Here it is:

github.com/eclipse-archived/smarthome

rule cannot be processed because of uninitialized script

opened 08:53PM - 09 Mar 17 UTC

maglnet

DSLRules

Hello, I sometimes (about 25%-50% of restarts) experience the following log m…essages at startup: ``` 2017-03-07 21:48:19.057 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model '_default.rules' 2017-03-07 21:48:28.091 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Public Holiday': Script 'holiday' cannot be found. 2017-03-07 21:48:28.335 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'holiday.script' ``` my rule: ```xBase rule "Public Holiday" when Time cron "0 0 0 * * ?" or System started then callScript("holiday") end ``` When the log message appears the holidays wont be calculated at startup, at midnight the script is called normally and holidays are calculated. I feel like scripts should be loaded prior the rules? I'm running `openHAB 2.1.0-SNAPSHOT Build #816` on a RaspberryPI 3. best regards, Matthias

Or this one:

github.com/eclipse-archived/smarthome

Introduce a "ESH start level" functionality

opened 11:46AM - 22 Jul 16 UTC

tomhoefer

enhancement Core

Hi all, in our project we have a lot of event subscribers and registry change l…isteners implemented which are called during startup / shutdown of ESH as a matter of course. In shutdown phase these services will update their model accordingly which results in the problem that the model cannot be re-built after next startup (because the subscribers / listeners have been assumed that the item / thing / link has been really deleted). We should distinguish between event sending / listener notification for adding / removal of items / things / links **during framework startup / shutdown phase and normal runtime.** For this reason I would like to disable in our project that events are sent / listeners are notified during startup / shutdown. I could imagine two ways to implement this: 1. Providing a `RuntimeStateService` that can be requested in order to get the information if the runtime is started. So for the beginning the service would only consist of a single operation `boolean : isStarted()` and it will be injected as dynamic dependency into the registries (things, items, links, rules). Then I would skip sending events / notification if the service is present and the runtime / framework is not fully started. 2. Each service that requires the runtime state has to implement a `RuntimeStateListener` interface which is tracked by a central `RuntimeStateService` to be provided by solutions based on ESH. As soon as the runtime state has changed to started the service will inform all listeners about this. Once the runtime left the started state again all listeners are informed about this. For the beginning I will implement the new RuntimeStateListener interface by the AbstractRegistry (concrete registries can decide if the runtime state listener is to be provided as a service). I think that 2 is the only valid option to implement this requirement. In 1 the runtime state service could unregister too early so that the events are sent / listeners are notified again. What do you think?

I haven’t seen an update since May. I guess they have other priorities at the moment.

Mihai_Badea · November 23, 2017, 6:13am

My approach on preventing the rules to run on system startup is to check previousState.
Something like this:

rule "whatever"
when
    Item myItem received update
then
    if(previousState != NULL){
        //do stuff
        myItem.sendCommand(NULL)
end

rlkoshak · November 27, 2017, 6:58pm

That is inspired. Excellent tip!

Mihai_Badea · November 27, 2017, 7:55pm

Actually, the last sendCommand should not send NULL.
Instead one should use “” (emtpy string) or 0 or some other value depending on the item type.
NULL should be only on system startup

rlkoshak · November 27, 2017, 10:01pm

Not necessarily. For example, I use the expire binding to set Items back to NULL when the sensor has not reported in a long time. This tells me that the sensor is not functional and therefore whatever it is sensing is in an unknown state and I write my rules accordingly.

You are right one would not want to sendCommand NULL but it is perfectly reasonable to postUpdate(NULL) or let Expire do it for you.

wawa79 · September 17, 2018, 4:45pm

I also implemented the “previousState != NULL” trick to prevent rules from triggering with RestoreOnStartup but the use of the implicit variable previousState is generating an error:

Rule 'Scene CMD_mCR_command': An error occurred during the script execution: index=0, size=0

Below is the rule:

rule "Scene CMD_mCR_command"
when
    Item CMD_mCR_command received update 15 //triple-click
then
    if(previousState != NULL){
        DW_mCR_portail.sendCommand(50)//TOGGLE
    }
end

When replacing by CMD_mCR_command.previousState().state it works but this is not what I need.
Any idea?

rlkoshak · September 17, 2018, 4:54pm

previousState only exists when a Rule is triggered by a changed trigger.

There is no way I know of to determine if an Item’s previous state was NULL with any other Rule trigger.

wawa79 · September 18, 2018, 4:27pm

Thank you! I should read the doc with more concentration

wawa79 · September 25, 2018, 5:42pm

I applied a workaround with a global boolean variable that is set to true when the rule is first triggered at startup (due to RestoreOnStartup behavior).

var my_item_initialized = new Boolean(false)

rule "Rule that must not be triggered during RestoreOnStartup"
when
	Item MyItem_WithRestoreOnStartup received update
then
	if(my_item_initialized){
		//code that must be executed only after RestoreOnStartup is completed
	}
	else{
		my_item_initialized = true
	}
end