[SOLVED] Item predicted to become

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


Dimmer AllBlinds "All Blinds"					[ "Switchable" ] {autoupdate="false"}


Switch item=AllBlinds label="All Blinds" icon="windows" mappings=[50="Open", 0="Close"]


rule "All Blinds close"
        Item AllBlinds received command 0



rule "All Blinds open"
        Item AllBlinds received command 50

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.

no description can replace the actual code (best case is to have them both :slight_smile:)

post all relevant Items, rules, sitemap and log entries

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"
        Item AllBlinds received command
val percent = AllBlinds.state as Number	
logInfo("log","Blinds rule Running")


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"
	Item AllBlinds received command
	logInfo("log","Item AllBlinds got:" + receivedCommand)

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.


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"
  Item {{actor_fc}}_fancoil_mode received command
  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.