(Solution found) Rules are not triggered by "Changed to ON"

Setup, Configuration and Use Runtime
,
1

Hi,
I’m observing problems using rules which are triggered by item changes.
What I’m seeing is that a rule with a trigger “…Item xx changed to ON” does not get triggered, however if I use “…Item xx changed to OFF” or “…Item xx changed” and the item gets a change to OFF, the rule is triggered.
As of the nightly build from yesterday checking for “ON” or just “changed” and switching to ON will result in a warning in the logs:

22:29:47.726 [WARN ] [pse.smarthome.core.items.GenericItem] - failed
notifying listener
‘[org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl@e785b0,
TestSomething, null]’ about state update of item
java.lang.NullPointerException: {}

Rules using a cron statement are working correctly, a check for “System started” does NOT.

Since I have this problem for some time now, it has been reported/discussed in those threads https://community.openhab.org/t/partly-solved-rules-are-not-triggered-as-expected/12492/9 and https://community.openhab.org/t/rules-in-oh2/13198/5

2

Found the problem, however I don’t understand why?
If I delete all things on PaperUI the rules are working as they should.

I had all discovered things aded in PaperUI and had them as well in the .items file.
Don’t I have to add the things on PaperUI?

It looks to now as if I can just have all things in the items file and do not use the discovered things in PaperUI

3

Thanks for posting…I actually tried to navigate a similar issue by adding a rule trigger:

when
	Item ... received update 
then

and then checking whether the item.status is on or off. When I tried a rule trigger like you described it simply never triggered. My solution above works, but looks like a work around rather than a well formulated rule.
Maybe my problem has the same root cause?

4

To be more specific on what I did wrong.
I had all my things discovered and renamed in PaperUI. Since I used my Items file as in OH I had them also declared with that name in there.
That caused the trouble.
Now I just accept the discovered Things in PaperUI without changing the name.

1 Like
5

Similar issue here; my rules are not working for some time now, maybe since the beginning of Openhab2 distro upgrade. Neither received update nor change works…

6

Same issue here… “Item XXX change” sometimes works but most of the time does not.
When changing the rule to “Item XXX received update” and then looking at the state of the item seems to leave me with a working setup for now…

I agree that this feels like a bit of a workaround… especially as the behaviour seems to be erratic.

I’m running OH 2 build 460 on Pine64 Ubunte 16.04 with a 32-bit Oracle Java 1.8.0_101 build.
Below errors are often seen in my logs:

2016-08-31 21:48:49.033 [WARN ] [pse.smarthome.core.items.GenericItem] - failed notifying listener ‘[org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl@180ca30, MotionSensor_Corridor_Motion, null]’ about state update of item java.lang.NullPointerException: {}

2016-08-31 21:36:29.935 [ERROR] [.script.engine.ScriptExecutionThread] - Rule ‘Hall light motion’: Script interpreter couldn’t be obtain

7

I just took distro #462, installed the demo-package and added this rule to demo.rules:

rule Test
when
  Item DemoSwitch changed to ON
then
  logInfo("Test", "My rule triggered!")
end

Then started the runtime, used the UI to send an ON command to DemoSwitch and I see in the log:

18:25:05.391 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'DemoSwitch' received command ON
18:25:05.392 [INFO ] [marthome.event.ItemStateChangedEvent] - DemoSwitch changed from OFF to ON
18:25:05.394 [INFO ] [.eclipse.smarthome.model.script.Test] - My rule triggered!

If anyone of you has a reproduceable scenario (best based on the OH2 demo package as in my example), please describe it and report it at https://github.com/eclipse/smarthome/issues.

8

Build #462 solved my issues too. When I updated to 462 some days ago I rewrote my rules from being triggered by an update and then checking for the status to just say

…changed to ON (or OFF as it were)

and it worked perfectly. My thanks to the developers!

9

As stated in the title, I have found the reason for the “not triggered rules”. It was Stupid.Me!
Since I used my .Items file from OH1 and named some discovered things as they “should” according the .Items file, I ended up with Things and Items having the same name (at least that is what I understand).

Now I use my old .Items file and do NOT rename the discovered things! The needed and discovered channels of the things are connected to the items in the .Items file (no change to OH1 needed!).

All of my “non working rules” are working again!
I can’t say if that is also the cause for the other posters.

10

I’m running build #463 and seeing similar behaviour. Here are my test rules:

rule “Light Test Updated”
when
Item Light_GF_Dining_Main received update
then
logInfo(“Dining Room”,“Light Updated”)
end

rule “Light Test On”
when
Item Light_GF_Dining_Main changed to ON
then
logInfo(“Dining Room”,“Light On”)
end

rule “Light Test Off”
when
Item Light_GF_Dining_Main changed to OFF
then
logInfo(“Dining Room”,“Light Off”)
end

I tested physically turning the switch on and off and using HABmin. The only time I get any log notification is if I use HABmin and then it only recognizes the “received update” but that also triggers even if I just do a HABmin refresh item.

11

The reported “solution” was not correct. See this thread of me https://community.openhab.org/t/sonos-binding-causes-problems-with-rules-after-a-reboot/13796/3

12

Thanks Jurgen, but that didn’t seem to be my issue. I double checked the item list ahead of installing build #465 and didn’t see any duplicate items. After #465, I’m getting the same issues. Wonder if I need to just go to a config file as well…

13

If you only have log-entries when using habmin it looks to me as if you only get item events and nothing from a thing. Are they connected at all? Can you switch anything with habmin?

14

I can control from HABmin or my sitemaps with no problems. Though they will only trigger a “received update” rule and not a “Changed to” rule when doing so from the UI (which is more then happens if I do a manual switch).

15

@opus Here is what I got from a debug log file with physically turning the dimmer on, setting a dim level and turning it off.

2016-09-05 14:44:41.761 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 3: Application update request. Node information received.
2016-09-05 14:44:41.762 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2016-09-05 14:44:41.762 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@8a8d9b already registered
2016-09-05 14:44:41.763 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Poll, dest=6, callback=120, payload=06 01 00 
2016-09-05 14:44:41.764 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 
2016-09-05 14:44:41.764 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=120, expected=SendData, cancelled=false      MISMATCH
2016-09-05 14:45:25.364 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 17 00 49 84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 24 
2016-09-05 14:45:25.375 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-09-05 14:45:25.379 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 17 00 49 84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 24 
2016-09-05 14:45:25.384 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 17 00 49 84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 24 
2016-09-05 14:45:25.388 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 
2016-09-05 14:45:25.389 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 3: Application update request. Node information received.
2016-09-05 14:45:25.390 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2016-09-05 14:45:25.391 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@8a8d9b already registered
2016-09-05 14:45:25.393 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Poll, dest=6, callback=120, payload=06 01 00 
2016-09-05 14:45:25.396 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationUpdate[0x49], type=Request[0x00], priority=High, dest=255, callback=0, payload=84 03 11 04 11 04 26 27 75 86 70 71 85 77 2B 2C 72 73 82 87 
2016-09-05 14:45:25.397 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationUpdate, callback id=120, expected=SendData, cancelled=false      MISMATCH
16

I’m sorry., but I do not use ZANE, therefore I can’t anything to those DEBUG messages.

Other questions from me:
Do you have all Item linking done by PaperUI, or do you have them in an .Items file?
Are you using the the “simple mode” for items linking?

17

No worries, thanks.

I have Paper set for simple and then create my items in HABmin. I did try a test item through my.items file but same results.

18

If you use the simple mode,PaperUI will automatically link channels for the detected things. By using habmin for the same ( which I don’t use ) those links might be created twice. Which could be the cause of the problem.
In simple mode OFF only those channels that are linked by habmin ( or an .items file) will be created.

19

Sorry, mispoke. I have simple mode off.

20

@chris I think there is something going on in how the zwave binding is passing state changes back to OH. I can see the physical changes in HABmin (sometimes requires a refresh) but I can’t get rules using either “received update” or “changed to” checks to pickup the changes. I remember seeing a while back a similar issue with Cooper dimmers (which I’m using), so it might be unique to them. Though I do have a couple of Linear’s that I was having issues with as well (though did not run the same full rule test I did above, but could do so if that would help).

Let me know your thoughts and/or any tests I can run to help narrow down if this is just my system or a broader issue.