I have 2 rules set up on the same switch. One for when the state is updated (regardless of change), and one for when the state changes. However they both do things the other relies on (setting other switches etc) so it can get out of sync.
So I want to consolidate the script: whenever the switch receives a command and if it has changed, do something. If it has not changed, do something else.
I’m using blockly (and would prefer to continue to do so) and still quite new to the ecosystem, so just not sure exactly what blocks to use to make the comparison between the previous and new value. I saw some persistence ones but I’m not sure they are what I want. There were also context ones which look promising but I haven’t found them again.
You are correct that the context variables are the way to go. You can find them again in the Run and Process group in the contextual info block’s dropdown menu:
When the rule was triggered by a Received command trigger, you will not get a previous state or new state data, because it’s irrelevant in this instance.
You will get received command data instead, because at the time of the trigger, that’s all the system knows and is telling you about.
Those previous state and new state context / data is available on a item changed state trigger event.
So one way to fix your script is to change your trigger from received command to changed as shown here:
If you want another rule when the state is updated (regardless of change), you’d use the was updated trigger. In this case, onlynew state is available. There’s no previous state context for an updated event.
For completeness:
You can have one rule with multiple triggers, and the triggers can be of different types. It’s still the same situation though:
When your rule got triggered by an actual change event, you’ll get previous + new state info.
When your rule got triggered by an update event, you’ll only get new state info
When your rule got triggered by a received command event, you’ll get what command was received? info
and so on. There are all sorts of events and their corresponding / relevant information for the event. You can see the list here: JSR223 Scripting | openHAB
Your trigger and your context information do not match.
Your trigger is “received a command” so the context information available is the command that has been received. If you want to have the state context information then you need one of the triggers that relates to an item state: “was updated” or “changed”.
I’m hoping I can work with it. At the moment I have separate change/update events but I only want the update event to fire after the change event has been run (which can take 15 seconds), so am hoping I can get them in the same rule to control for that.
In my experience things can usually be simplified rather than trying to rely on really specific timing back and forth issues like this. I think you might be able to accomplish what you want with these updates.
Modify the item so that it doesn’t automatically update its state when a command is received. This will keep the state the same when you send a command until you choose to change it.
Keep your command received rule the same, but add another step after your inline script to post an update to the item. This takes care of the timing issues if I understand your desire correctly.
Run a separate command on updated state like described above.
You could also potentially put a “from” and “to” in your state change trigger or “command” in your received command trigger which would allow you to split out the commands into all the different bits. Something to consider, but up to you if it’s useful or not.
Thanks Jonny. I couldn’t get #1 and #2 working as well as I’d like. I was able to simplify my solution a bit but it’s pretty janky, It works though so I’m not really game to optimise it!
