I have multiple items that are just acting as a switch to run a rule
For instance
I have a dimmer. For blinds
And a switch on my sitemap that sends 0 when pushing close and 50 when pushing open.
I have a rule that runs when the item received command and sends the percentage to all my blinds using Mqtt.
But the problem is the item predicts to become the opposite of what I send it so when the rule runs it grabs the wrong percentage and does not work.
I have tried auto update false bit that just stops it predicting to become, it still sends the opposite percentage.
I have had to change my rules into two rules that runs when the item specifically received command 0 and another when it received command 50. Which is ok when using my sitemap as I only have open or close (50 or 0). But when using Google home to brighten or darken it adjusts the item using a dimmer and will send numbers inbetween
How can we stop the item predicted to become crap when it’s not actually linked to a binding. It’s just linked to Google home using the switchable tag
Items
Dimmer AllBlinds "All Blinds" [ "Switchable" ] {autoupdate="false"}
rule "All Blinds close"
when
Item AllBlinds received command 0
then
LoungeBlinds1.sendCommand(0)
LoungeBlinds2.sendCommand(0)
LoungeBlinds3.sendCommand(0)
MainBedBlinds1.sendCommand(0)
MainBedBlinds2.sendCommand(0)
MainBedBlinds3.sendCommand(0)
AllBlinds.postUpdate(NULL)
end
//***************************************************************************
rule "All Blinds open"
when
Item AllBlinds received command 50
then
LoungeBlinds1.sendCommand(50)
LoungeBlinds2.sendCommand(50)
LoungeBlinds3.sendCommand(50)
MainBedBlinds1.sendCommand(50)
MainBedBlinds2.sendCommand(50)
MainBedBlinds3.sendCommand(50)
AllBlinds.postUpdate(NULL)
end
and log
2018-12-22 11:15:26.436 [ome.event.ItemCommandEvent] - Item 'AllBlinds' received command 0
2018-12-22 11:15:26.445 [nt.ItemStatePredictedEvent] - AllBlinds predicted to become NULL
2018-12-22 11:15:30.839 [ome.event.ItemCommandEvent] - Item 'AllBlinds' received command 50
2018-12-22 11:15:31.193 [nt.ItemStatePredictedEvent] - AllBlinds predicted to become NULL
2018-12-22 11:15:31.758 [ome.event.ItemCommandEvent] - Item 'AllBlinds' received command 50
2018-12-22 11:15:31.761 [nt.ItemStatePredictedEvent] - AllBlinds predicted to become NULL
That log is because i have my rule updating the state back to NULL. so the switch on the sitemap is not highlighted
That is also when i remove the auto updated false from the items.
If i put the autoupdate false in the items then it updates the state correctly.
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
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
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?
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.
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
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
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.
)