Jython rules. Timing of Item being updated and Event generated

[Mr-JR (James R)]

I think I remember seeing something about this but can’t find it …

I just had a event that missed processing the data … looking at the log it is seems that the event data wasn’t actually updated before the event started processing … not sure if that makes sense … here is a code snippet:

@rule("Parse Ohm Hour Event", description="Handles parsing OhmTime email data")
@when("Item OhmHour received command")
@when("Item TestSwitch changed to ON")
def parseOhmTimeEvent(event):

     eventTime = str(items[event.itemName])
     parseOhmTimeEvent.log.info("eventTime= " + eventTime)

Is it possible that the event is generated before the String OhmHour is actually updated? My log shows that the old value of items[event.itemName] is accessed.

[JustinG]

It’s not only possible, it’s to be expected. @rossko57 laid out a very simple explanation the other day:

Previous Item State not always working correctly

It’s completely predictable that this will fail, crops up regularly. Item states may or may not respond in some way to Item commands eventually, but any response is totally asynchronous. This is a fundamental openHAB design feature, not a flaw. Usually requires a bit of thinking about how to deal; if a rule is reliant on Item state, maybe trigger on state not command. The most important cycle in openHAB - a) Item gets command (from rule or UI) b) Item passes command to binding c) bin…

[Mr-JR (James R)]

Thank Justin - I remember reading this … but couldn’t get my google search to find it Thank you!

[Mr-JR (James R)]

So just to follow up after reading the that thread … it seems to say that if I use:

@when("Item OhmHour received update")

instead of:

@when("Item OhmHour received command")

that will eliminate the possibility that the value of event.itemName is old. Do I have that right? I dont understand the nuance between a “command” and an “update” but I’ll take it for granted.

(just a note: I do know that that implies unless the value changes it wont trigger an update)

[JustinG]

@Mr-JR

I dont understand the nuance between a “command” and an “update” but I’ll take it for granted.

Command uses the flow as laid out in rossko57’s post to change the item state. Update is for usages where you want to change an item’s state without triggering the command series of events. There’s a brief explanation here: Rules | openHAB. Said another way, if you have a rule that triggers on item X received command then that rule will not be called if you post an update to item X but will be called when you send a command to item X.

There are a couple of ways around the problem of the item state lagging behind the command in rules:

1. Instead of reading the state of the item, you can use the event variable that contains the command that triggered the rule to work out what the item state should be
2. As you suggested, change the rule trigger to something more appropriate. Whether that is item X received update or item X changed depends on the exact behavior you want out of your rule.

[rossko57]

Item Command
“Hey you, do something!”
As in life, there is no guarantee when something gets done, or even gets done at all.

Written orders
There are none. That’s to say, a command is a passing event. If you missed it, you can’t find out if there was one, or what it was.

Item state
“This is the way it looks.”
The last time somebody told us how it is, or we looked out the window to see, this is how it was.
We can check this state any time we like.

state received update
“Somebody just told us.”
Again, it’s a passing event.

state changed
“Somebody just told us, and its different from before”
Passing event again.
Note that this is going to be in the company of an update event as well.

[rlkoshak (Rich Koshak)]

@Mr-JR

that will eliminate the possibility that the value of event.itemName is old. Do I have that right? I dont understand the nuance between a “command” and an “update” but I’ll take it for granted.

One other difference here is that are commands that do not correspond to an Item’s state.

For example if you have a Dimmer Item you can send the command INCREASE. If you trigger a Rule with received command, the event.itemCommand will be INCREASE. But what’s the Item’s state? INCREASE can never be a Dimmer Item’s state.

What will happen is something (a rule, the binding, autoupdate) will interpret that command and act upon it. In most cases that action will result in an update to the Item with the new state that the Item achieved after responding to the INCREASE command.

So if you want to do something in response to the Dimmer receiving an INCREASE command, you’ll use received command INCREASE. But you can’t rely on the Item’s state in that rule. The command hasn’t been acted upon yet, the Item will still be in the old state. If you care about the Item’s actual state you need to use received update or changed.

There really is much more than just nuance between the two.

[Mr-JR (James R)]

thank you @rossko57 and @rlkoshak for the examples … helps drive the points home.