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! 