[SOLVED] Item predicted to become

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

Items are named properly, I accidentaly pasted the code from mustache template as I autogenerate many rules for every room in building based on the bulding config file (rooms can have 1 to 6 controlable radiators)

And I just noticed that this Item was still attached to the Thing that, could maybe affect behaviour of the state. Will now unpin that leave that Item a dummy item and test again

Type switch : fancoil_mode "Fancoil_mode" [ stateTopic="BF155_actor_fc_1/fancoil_mode" , commandTopic="BF155_actor_fc_1/fancoil_mode"]

Number BF155_actor_fc_1_fancoil_mode "BF155_actor_fc_1 fancoil mode " <fan> { channel="mqtt:topic:eui:BF155_actor_fc_1:fancoil_mode" }

Okay, it’s a Number type Item

You can, nothing stops that.

You can, nothing stops that.
In the case of the Item shown, you have an MQTT commandTopic configured so the binding will take notice and pass the command out to MQTT
(postUpdates are ignored by your binding config)

Up to you. Maybe you could let autoupdate do that. Maybe you could wait for response to command from your remote device, the MQTT stateTopic you have configured would I guess update your Item?

Is this all really about which button lights up pink in your UI ?
See


I think however there may have been recent work, perhaps only for some UIs, to get mapped “buttons” more closely tracking Item state and not just user pokings.

ok so unpining the Item from the MQTT did the trick.

2020-01-28 12:41:16.844 [ome.event.ItemCommandEvent] - Item 'BF158_actor_fc_1_fancoil_mode' received command 0
2020-01-28 12:41:16.850 [vent.ItemStateChangedEvent] - BF158_actor_fc_1_fancoil_mode changed from 3 to 0

From minimal testing I did in last 10 min now the state does not get stuck being different from the commandRecieved via rule change.

The mode buttons in PINK Are required for the enduser/operator that does not know what combination of 4 relays are switching what gear on the ancient ventilator i’m automating.

Some MQTT binding versions are “badly behaved” in openHAB terms, and will force updates to Items of last known incoming payload, even when there has been no MQTT message.

Please forgive me if this is the wrong place to note my own insights: I also had the very strange output “predicted to become NULL” for the temperature dimmer item of one of my LIFX bulbs, making it impossible to control this light via openHAB. In the end, it turned out that there was a typo in the channel name of the temperature and the logs did not give me any clear feedback on the fact that the channel was unavailable. I have no idea how this typo has arisen because the item had worked in the past, but by looking up the thing in the OH3 UI I found out that the channel was not assigned correctly and could fix the issue.

HNY! :slight_smile: