Weird item behaviour

Setup, Configuration and Use Beginners
1
  • Platform information:
    • Hardware: _RPI3*
    • OS: _Lastest version RAsbian
    • Java Runtime Environment:latest version
    • openHAB version: 2.5.1
  • Issue of the topic:
    When running OpenHab I noticed something weird on its behaviour what I have not been able to explain, maybe someone can help me with that.
    I create a scene to change modes in a room and use the hueswitch to select the mode that i want. I have two Huew Switches that can be used. When i Handle the hue switch I have created a item called button change that is set to ON ( using .sendCommand) when pressed, and another rule “Item buttonchange changes to ON)” triggers the processing of the button and the modes.
    Now this worked all fine , however at some point I had to restart the RPI ( and openhab) because i was working on other rules. After that the buttonchange did not work. I saw in the log that pushing a button on the hueswitch resulted in “button change received ON” but the rule ( "Item buttonchange changes to ON) was not fired.
    I then renamed the item in the items and rule file and all was working again , i also renamed it back to the original name and all worked again.
    Is there any explnation for this behaviour ?

Thanks in advance , frank

2

The full text would be received command ON, it’s a subtle but important difference.

Sending a command to any Item may or may not eventually result in Item state change. There’s no direct connection.

You were relying on the default autoupdate action, which listens for commands to Items and shortly afterwards updates the Item state to a predicted result of the command. e.g. a Dimmer commanded ON will get updated to 100

So when it works, you send command ON to your Switch item, autoupdate updates state to ON, your rule was triggered from change to ON.

We can guess somethng stopped the autoupdate happening.
It is an option you can turn off for each individual Item.
Further, when linked to some bindings, they can veto autoupdate.
I believe in the case of a misconfigured or broken link on the Item, autoupdate will also veto.
I’d suspect something like this happened to you.

You might consider your rule trigger … if you want to trigger from a command ON, you can do so directly

when
   Item someItem received command ON

but remember in the body of your rule that any resulting state change may or may not have happened yet.