yep, sorry. was just doing it now
1 Like
by the way: if your rule is triggered with received command
then the Item predicted story shouldn’t affect it
See here: What is ItemStatePredictedEvent?
This was my original rule. the problem is the state of allblinds is updated by the predictedstate before the run runs. Even with Autoupdate=false removed. the state is staying as NULL as that is what the old rule has set it to. So even with autoupdate removed, the state is not staying as what the command is set.
rule "All Blinds"
when
Item AllBlinds received command
then
val percent = AllBlinds.state as Number
logInfo("log","Blinds rule Running")
LoungeBlinds1.sendCommand(percent)
LoungeBlinds2.sendCommand(percent)
LoungeBlinds3.sendCommand(percent)
MainBedBlinds1.sendCommand(percent)
MainBedBlinds2.sendCommand(percent)
MainBedBlinds3.sendCommand(percent)
end
can you try:
val percent = receivedCommand as Number
interesting that ItemStatePredictedEvent will change the state of the AllBlinds item to NULL…
I haven’t tested the predicted stuff to see how you can work around this when you are using a dummy item
I’ll give it a shot when I get home.
The weird thing is even though I have autoupdate off it still changes the value back to the previous value
That’s expected. To be clear, sending a command to an Item does not change its state by itself.
Normally a binding does something to a device, the device responds eventually with a new status and the binding updates the state.
Autoupdate is a shortcut to that - acting like a binding, it listens for commands and guesses what would be a sensible state for the Item and issues an update. That update may or may not take place while any rules triggered from the command are started or still running.
So autoupdate=“false” means the Item will never change state unless the binding does it - or a rule updates it.
Maybe you need your “All Blinds” rule to do those?
So I need to use receivedCommand instead of item.state for all my rules then I suppose. And then have the rule update the state of the item?
Even though this item is a fake item that is not linked to a binding or Mqtt topic? Seems a little wrong to me
If it’s not linked to a binding or Mqtt topic the item predicted state shouldn’t even have anything to do with it.
after using val percent = receivedCommand as Number
It seems as though receivedCommand is not working at all. i errors when i try to log what receivedCommand as number is. it stays as NULL.
any other ideas?
Can we look into why a switch that is not linked to any binding or object, is being predicted to become something else.
This switch should just have whatever state i tell it.
what happens if you simply try to log the incoming command?
something like:
rule "capture incoming command"
when
Item AllBlinds received command
then
logInfo("log","Item AllBlinds got:" + receivedCommand)
end
did you try without as Number also?
val percent = receivedCommand
Yep tried both. Get a null error. Can’t remember exactly but I’ll check again in the next 10 minutes
this is strange and it could explain also why the dummy item gets its state updated to NULL.
but… I don’t think that you can have a receivedCommand with a value of NULL… this is only applicable to states.
I think the actual issue is even though I have autoupdate false. It still returns the state to null before the command is sent properly. The rule runs fine if I set it to received command 50. But I can’t get the command into the rule at all. There’s an issues with the predicted state
these are 2 different subjects (command and state). Of course, the command may result to a later state update.
Getting the receivedCommand and using it within your rule should have nothing to do with the ItemStatePredictedEvent which affects the state.
Even if there is a bug with the ItemStatePredictedEvent for dummy items (not bound to a binding config), you should be able to control what happens within your rule with the receivedCommand part.
I don’t have any comment on the behavior of the ItemStatePredictedEvent (don’t know in details how it works)
careful on the syntax:
all small letters for received command
one capital Letter for receivedCommand
1 Like
Are the blinds operated by MQTT and you switched to the new MQTT?
I have seen such log entries when the item wasn’t really linked to the thing , although the link was logged to be created and the thing was online.
I did switch to the new MQTT, and then switched back. So i assume its from that. Its somehow linked.
I was able to get receivedCommand working by deleting the item and readding it as another name.
and then readding it as the old name again. Still predicts to become the wrong thing. But receivedCommand works.
Hi, So I was trouble shooting the same issue on 2.4 where I had a dummy item with the fan mode that should be updated and next rule would take it’s state and set relays accordingly. It was a nightmare until I found this thread, thank you. Relying on the receivedCommand and posting a self update does the trick but it takes .3 second to get that state updated and can sometimes confuse a rule if someone is trigger happy with setting setpoints up and down with the arrows like maniac.
Anyone is already on the 2.5? has the issue been fixed
With no idea what “issue” you are talking about, it would be difficult to say.
Just about every hurdle encountered in this thread is actually openHAB working as designed, but not understood by the user.
2 Likes
Let me clarify.
So if I have a dummy unconnected switch …
What is a logic that I can’t simply update it from another rule by sending postUpdate to it?
I need to sendCommand and then in the rule that is based on receivedCommand i need to self update it ?
Also why is that in that script if I do self update, and read state in the next line imediately it most likely will not be updated yet, the state will still hold the old state.
rule "{{actor_fc}} fancoil update"
when
Item {{actor_fc}}_fancoil_mode received command
then
val recieved_fc_mode = receivedCommand
postUpdate ({{actor_fc}}_fancoil_mode,recieved_fc_mode)
var Number fancoil_mode = {{actor_fc}}_fancoil_mode.state
to work around i need to add some if statements to compare them and check recieved_fc_mode and state are the same.
And I just spent another hour on that I see that sometimes if the dummy switch receives the command it state updates on it’s own, me not touching postUpdate. And sometimes it does not.
What type of Item is involved? This affects what you can do with it.
That is not a valid Item name, it contains characters which are not permitted.
That is because openHAB is asynchronous.
When you send an update or command to an Item, it gets placed on OH event bus for all to see. Maybe there are other rules to trigger, bindings to act, UIs to update etc. And of course, actually update the Item.
Your rule does not stop and wait for that to complete.
So if you read the Item state again in the next line, you will almost certainly get the old value.
There is no workaround needed for this intended behaviour. Your rule already knows what it just sent to the Item, there is no need to fetch it back.
If you need to take some action after the Item state really has changed, you can have another rule triggered from that.
1 Like