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: {}
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.
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!
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.
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.
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…
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?
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).
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?
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.
@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.
The binding uses the standard channel update methods, so I don’t think there’s much I can do to influence this (as far as I know). What does the events log show (or even the main log)?
So I saw @Kai 's note about the rule bug fix - [Partly solved] Rules are not triggered as expected So I got hopeful that would solve my issue. I installed the latest build and reran my test. What I’m noticing is if I physically change the switch nothing is updating in HABmin or PaperUI for the light status. If I refresh the thing in HABmin then both register the new status and I get an item updated in my info file related to my rules above (still nothing from changed to registering).
So I ran a full test of:
Setting system into Debug
Turning on the switch (nothing registered in HABmin/Paper)
Doing a refresh in Habmin (now registering change in both)
Turning off the switch (nothing registered in HABmin/Paper)
Doing a refresh in Habmin (now registering change in both)
So I noticed the 1800 polling and sure enough when I looked at the Thing Device Configuration, sure enough it’s set for an 1800 polling. Also, these are Cooper dimmers which should be broadcasting their status changes to OH I wouldn’t think it would matter on the polling?
Ok, solved the issue with OH not updating. When the Device was created it didn’t associate itself with the OH Controller in Group 1. Once I manually added the Controller to the Group 1 association I’m getting real time updates in HABmin and PaperUI. And I’m seeing the Log showing the device was Updated. Still not getting the rule to recognize “Changed to” but at least the first piece is solved.
Though interesting enough I have other versions of the same switch in the house and they reflect instantly w/o the need to add the Controller to the Group 1 association. So I tried removing it from the switch in question and it quit updating. The only other difference between the two switches is the one having issues is associated with an Aux switch (also Cooper) and the second one is a standalone setup…
So I tested just using “Item XXXX Changed” as a condition state, and that triggers it just like “Received Update” What I can’t seem to get to work is if I try to include a condition state of “On” in either one. I also was trying to use an if(item.state=ON) and kept getting errors like:
An error occured during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.LogAction.logInfo(java.lang.String,java.lang.String,java.lang.Object[]) on instance: null
And in Eclipse designer it would tell me that the “The method or field item is undefined”
So it seems that there is no reported State for this dimmer switch and that might be why my rules that are State specific aren’t working.
-