Since some time now I experience the situation that from time to time all things configured stop working. The items are still updated and e.g. correctly shown in UI, but the link to the things seem to be broken in a kind that information received by items are not forwarded to things anymore.
Logs do not show anything relevant during the time this happens and performing a restart of the complete openHAB instance is necessary to resolve the problem.
I’m using openHAB 5.1.0.M2, but I experienced the same also with other 5.x versions. openHAB runs in a docker container on a Linux system.
Could someone help in this matter and maybe answer following questions:
Does anyone have some ideas what could be behind this behaviour?
What could I do to get better logs?
Is there a possibility to restart the thing/link handling without restarting the complete openHAB instance?
This is the first something exactly like this has been reported so it’s hard to say. It could be any number of things.
But just to be clear, the Items are still updated from the Things but sending commands to the Items do not cause the devices to do anything, correct?
When you send these commands, do you see the event in events.log?
It could be useful to see the debug level logs of a binding from the point where an Item is sent a command until the binding processes the command (or we see that the binding never got the event).
Yes but there’s no guarantee that will fix it since we don’t know what the problem is. But you can restart bundles from the Console. See The Console | openHAB for details.
When this happens then all installed bindings are affected at the same time: Shelly, MQTT to Z2M, Z-Wave
No, it’s the other way. A item is changed, e.g. by a rule. The item is changed successfully and the UI shows the right, new item value. BUT the new value, command, etc. is not forwarded to the thing channel, which is connected to the item.
As one example I could share my monitoring mechanism that I use to (at least) immediately realize that the issue happend.
Rule to regularly trigger a MQTT message:
rule "OpenHAB Ping"
when
Time cron "0 0/1 * 1/1 * ? *"
then
OpenHAB_MQTT_Ping.sendCommand ( now.toInstant.toEpochMilli/1000 )
end
Item receiving this commands:
version: 1
items:
OpenHAB_MQTT_Ping:
type: String
label: MQTT Ping für OpenHAB Service
channel: mqtt:topic:878f5db5:ping:openhab2
I did not check during the outtake, but what I can see when looking to persisted data it seems that the way from Things to Items still works. It’s just the way from Items to Things which is in error.
The log shows nothing special around the time of loss of function (13:08):
2025-12-13 13:06:55.157 [WARN ] [ternal.converter.ZWaveBasicConverter] - No conversion in ZWaveBasicConverter to QuantityType
2025-12-13 13:08:35.953 [WARN ] [ternal.converter.ZWaveBasicConverter] - No conversion in ZWaveBasicConverter to QuantityType
2025-12-13 13:10:44.277 [WARN ] [ternal.converter.ZWaveBasicConverter] - No conversion in ZWaveBasicConverter to QuantityType
What’s not working (examples):
Dimmer Item → Shelly Dimmer Thing
Roller Item → zWave Rollershutter Thing
Dimmer Item → Zigbee2MQTT Thing
Switch Item → ESPHome Thing
Switch Item → HTTP Thing
What’s working (examples):
MQTT Thing → Switch Item
Shelly Thing → Switch Item
sendHttpPostRequest in a rule
So it is in that way your question was pointing. It works in direction of Things to Items, but not from Items to Things. Do you have anything in mind about the reason?
Please note that the two mentioned MQTT actions are in different directions. So, sending a Dimmer Item value to a Zigbee2MQTT Thing does not work, but receiving a Switch Item from a MQTT Thing works. The arrow shows the direction of data/action flow.
(on Linux) to see if there is traffic on topics related to commands or external object status change.
Maybe I am saying the obvious, but I noticed that in the channel configuration example that you show, there is no a stateTopic, but only a commandTopic. According to MQTT documentation this configuration corresponds to a state-less trigger channel. It means that the state of the item associated to the channel is sent to the mqtt broker and then from the broker to the external object. As long as the external object is not operated independently the openhab item state is aligned to the external object state. But, if the latter is independently operated, the broker should receive a message on the status topic and the thing won’t process it and won’t update the openHab item, because of the lack of the stateTopic.
As Rick asked, inspection of the events.log file should reveal what’s going on. If a command is given there should be something like
2025-12-14 07:53:24.211 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Luce_Divano_switch_led' received command ON
2025-12-14 07:53:24.214 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Luce_Divano_switch_led' predicted to become ON
2025-12-14 07:53:24.215 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Luce_Divano_switch_led' changed from OFF to ON
On the other hand, when the external object is operated independently there should only be the item change (but only if the stateTopic is present)
Hope that this may help
PS A note on language.
What is the meaning of Items? openHAB items or devices (i.e. physical objects)?
This suggests that openHAB can read the status of the external devices but cannot change it. In this case the explanation I proposed does not apply.
That is what I did using Uptime Kuma. I’m tracking if messages appear on this channel, which should happen every minute. And if this does not happen, I raise a warning that “openHAB is broken”.
With items I mean openHAB item object.
Correct, openHAB can get information from external devices (configured as openHAB things), but a change in the openHAB item is not forwarded to the external device.
On the upper line a Shelly actor is linked as a openHAB thing - but this Dimmer does not react.
The lower example is the MQTT ping I use for alarming purposes.
Focusing on these MQTT ping messages, please the following extract of the event.log:
2025-12-14 14:00:00.766 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'OpenHAB_MQTT_Ping' received command 1765717200
2025-12-14 14:00:00.767 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'OpenHAB_MQTT_Ping' predicted to become 1765717200
2025-12-14 14:00:00.768 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenHAB_MQTT_Ping' changed from 1765717140 to 1765717200 (source: org.openhab.core.autoupdate.optimistic)
2025-12-14 14:01:00.766 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'OpenHAB_MQTT_Ping' received command 1765717260
2025-12-14 14:01:00.766 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'OpenHAB_MQTT_Ping' predicted to become 1765717260
2025-12-14 14:01:00.766 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenHAB_MQTT_Ping' changed from 1765717200 to 1765717260 (source: org.openhab.core.autoupdate.optimistic)
2025-12-14 14:02:00.766 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'OpenHAB_MQTT_Ping' received command 1765717320
2025-12-14 14:02:00.766 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'OpenHAB_MQTT_Ping' predicted to become 1765717320
2025-12-14 14:02:00.767 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenHAB_MQTT_Ping' changed from 1765717260 to 1765717320 (source: org.openhab.core.autoupdate.optimistic)
Although it looks normal in events.log for me, no message can be seen on the mqtt channel openhab/mqtt_thing_ping as it should be according to the configuration shown above.
After reseting the openHAB by restarting the container, the events.log looks like this:
2025-12-14 14:12:03.617 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'OpenHAB_MQTT_Ping' received command 1765717923
2025-12-14 14:12:03.621 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'OpenHAB_MQTT_Ping' predicted to become 1765717923
2025-12-14 14:12:03.621 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenHAB_MQTT_Ping' changed from 1765717872 to 1765717923 (source: org.openhab.core.autoupdate.optimistic)
2025-12-14 14:13:00.779 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'OpenHAB_MQTT_Ping' received command 1765717980
2025-12-14 14:13:00.780 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'OpenHAB_MQTT_Ping' predicted to become 1765717980
2025-12-14 14:13:00.781 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'OpenHAB_MQTT_Ping' changed from 1765717923 to 1765717980 (source: org.openhab.core.autoupdate.optimistic)
In my opinion it doesn’t make sense to concentrate to much on MQTT, because MQTT binding is only one of the affected. Propagation of information from openHAB items to different openhab things is on error in general (also for zWave, Shelly, HTTP and MQTT things).
Do these Items have autoupdate disabled? If not this might help identify where things are going wrong. With autoupdate enabled, you should always see at least a "predicted to become’ entry in events.log after the command. If the command caused the Item to change there should also be a “changed from” following the prediction.
If autoupdate is disabled, you will not see the predicted log statement.
If the predicted statements disappear when the commands stop making it to the devices that can point us to the general place in the chain where it goes wrong.
