Smarthome: Rule triggers before Item state changed

[cbfief]

Using Example 1 from the Separation of Behaviors Design Pattern, when triggering a rule based on "received command" rather than "received update," the rule appears to trigger before the Items state has been updated. This result in the previous state of the Item being used and sent in the notification instead of the new state.

Some logs
`2018-01-24 15:23:29.072 [ome.event.ItemCommandEvent] - Item 'Notification_Proxy_Info' received command Laundry;Dryer Done

2018-01-24 15:23:29.091 [vent.ItemStateChangedEvent] - Notification_Proxy_Info changed from Laundry;Washer Done to Laundry;Dryer Done`

`2018-01-24 15:23:29.073 [INFO ] [pse.smarthome.model.script.InfoNotif] - Notification rule start

2018-01-24 15:23:29.073 [INFO ] [pse.smarthome.model.script.InfoNotif] - Washer Done`

Adding a small (25ms) delay to the beginning of the rule solves the issue. In this case there is a rather long 19ms between the command being received and the state updating. In some cases it is only 1 or 2ms. Regardless, I think that the expected behavior would be that by the time a rule is triggered, the Items state would be updated.

[sjsf]

That's why you should listen to state updates using the received update trigger if your are interested in item state events. The received command is simply the wrong trigger in your case.

[maggu2810]

See also: https://github.com/eclipse/smarthome/issues/4881#issuecomment-356623238

[cbfief]

I was asked to open an issue by others who thought that a discussion of the actual vs expected behaviors was worth having. My apologies for not searching existing issues thoroughly enough.

I understand that a received command does not imply that the state will be updated, but a sendCommand _does_ in fact update the state if it differs. Given that, I don't believe that there is any scenario in which one would expect a rule to act upon anything but the new state.

[kaikreuzer]

but a sendCommand does in fact update the state if it differs

That's not correct. This only happens when the autoupdate is enabled for the item (which is the default), but it must not be the case. And also the auto-update should be considered to be an asynchronous operation (which might happen at some later moment in time).