Not to quibble, but neither of these are HTTP. Both are TCP/IP but the protocol for MariaDB is JDBC and the protocol for MQTT is, well, MQTT.
I just want to head off the chance that someone comes along and reads this and thinks they can use the HTTP binding for these.
Your point is still valid though.
@binderth, I suspect we’ll need some trace level logs from the MQTT binding when this behavior occurs. I’ve never experienced this nor have I see reports of similar behavior reported.
Elsewhere as in Node-Red, my Wallbox and my evcc could use the incoming MQTT-topics/payloads meanwhile.
hmm… got some, but they just show no incoming messages at all - until the binding restart
But what I just saw, there’s some double and triple entries for “Providing state description for channel…” - which aren’t even linked to an MQTT-item?
like here:
2022-12-13 09:25:49.444 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel modbus:data:kostalInverterInfo:kostalBatteryChargeDischarge:number
2022-12-13 09:25:49.447 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel modbus:data:kostalInverterInfo:kostalBatteryChargeDischarge:number
2022-12-13 09:25:49.451 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel modbus:data:kostalInverterInfo:kostalBatteryChargeDischarge:number
So, let’s see:
modbus:data:kostalInverterInfo:kostalBatteryChargeDischarge’s “Value as Number”-channel is linked toKOS_BatteryChargeDischarge onlyKOS_BatteryChargeDischarge is also only linked to that channel - no MQTT involved at all?and also
modbus:data:kostalInverterInfo:kostalBatteryChargeDischarge is modbus:poller:kostal:kostalInverterInfo:UID: modbus:poller:kostal:kostalInverterInfo
label: Kostal Modbus Poller 531-585 Inverter
thingTypeUID: modbus:poller
configuration:
length: 54
start: 531
refresh: 5000
maxTries: 3
cacheMillis: 50
type: holding
bridgeUID: modbus:tcp:kostal
modbus:poller:kostal:kostalInverterInfo is modbus:tcp:kostal:UID: modbus:tcp:kostal
label: Kostal Modbus TCP Slave
thingTypeUID: modbus:tcp
configuration:
rtuEncoded: false
connectMaxTries: 1
reconnectAfterMillis: 0
timeBetweenTransactionsMillis: 60
port: 1502
timeBetweenReconnectMillis: 0
connectTimeoutMillis: 10000
host: 192.168.78.50
afterConnectionDelayMillis: 0
id: 71
enableDiscovery: false
here’s the two logs - at around 9:26:43 I restarted the MQTT-binding:
openhab.log (994.3 KB)
events.log (56.6 KB)
How exactly did you put the binding into trace level logging? I think the “provided state description” stuff is a distraction. Since that appears to be the only thing logged at the trace level, I’d bump the level up to debug. I can’t imagine anything to deal with state description would prevent the binding from receiving and processing messages.
Beyond that indeed I don’t see anything in the logs, but there’s a lot of noise so something may have been missed. But I also don’t see any logs from the receipt of a message.
log:set TRACE org.openhab.binding.mqtt it was.
And yes, very noisy indeed.
But strangely enough, some MQTT-items (BB_EltakoImpulse e.g.) did get updated… Which I didn’t get at first. Sheeesh.
Off-topic - for the State Description sideshow, try purging dead links initially.
Also possibly off-topic but performance related; non-trivial Modbus configurations with default settings can provide a throughput challenge for persistence services, because of the Item update rate.
I think I may experience the same thing as you, but it’s only with two MQTT devices and it doesn’t happen suddenly. I have:
My Tasmota power bars always work, but I’ve noticed sometimes that OH stops getting updates from octoPi and SleepAsAndroid, even though messages are still received by the broker running on my OH server (confirmed with MQTT Explorer). My quick fix is to remove and then re-add the things (by commenting them out in my things file, saving, and uncommenting).
Anecdotally, I think this only happens after I’ve restarted OH (which is infrequent enough that I haven’t worried about it). The only significant difference between the Tasmota and octoPi/SleepAsAndroid things is that I don’t have any command channels in the latter group. I just receive state updates for them.
I initially thought that this might be due to not using Last Will and Testament, but all of the devices can still send messages to the broker–it’s only openHAB that stops updating…and only for some devices. Saying that, I don’t have a good grasp of LWT (which kind of makes my head spin).
I usually stick to snapshots, have hundreds of mqtt items, and they are usually very chatty (e.g. motion sensors). I haven’t noticed something like this on my system, but since I tinker a lot, my openhab gets restarted at least once a week, and often many times a day.
Did this issue happen after a prolonged uptime? Can you reproduce it?
Sorry, didn’t quite get this. What do you mean with “default settings”?
Didn’t know that dead links tipp, but only a bunch of orphaned amazonechocontrols found - but purged now, thanks.
My openhab is running for 5 days straight now. Had to reboot for some OS update. But… my mqtt-Things that stopped had only receiving channels. So this could be an indicator. The LWT stuff is active, though
I’ve never had this issue before. My Pi usually stays on like forever and only gets rebooted if needed. Openhab gets restarted of there’s some error, but last week I didn’t change a thing, and Pi/openHAB were up since 5 days now. Today I only restarted the MQTT-binding.
If you want to follow up on performance tuning Modbus (which can impact other sub-systems, it’s very capable of generating buckets of Item updates) see
For the MQTT stuff, you’ve got something of a job to pin it down further.
There’s no suggestion that the link between openHAB and your broker is in trouble, the clues say it remains alive.
(Where is your broker living? Which one is it?)
It looks like either
Broker has ‘forgotten’ OH subscriptions, or lost pathway to push them.
or
openHAB is forgetting to process them, maybe because it has forgotten channels with matching topics.
Neither are known problems.
I think you might need to be debug logging io.mqtt.transport or something to see incoming topic messages .
My bet is, OH had some issues with the subscribed topics and didn’t mean to share that in the logs somehow. As I said, the topics were sending, the broker “Mosquitto 2.0.15” dockerized in my Synology.
No issues in the logs at that time - all topics (including the ones missing in OH3) were sent as expected.
ok - I’ll remember that for next time - hopefully it was a one-timer! 
Thanks for your help!
It’s not really complicated. When an MQTT client registers on the Broker, it can provide a LWT topic and message. When this happens, the broker will set up a heart beat between itself and the client. If the client fails to respond to the heartbeat, the broker will publish the LWT message to the LWT topic, thereby alerting other clients that this client has gone offline.
Put in less technical terms, the client tells the broker “if you don’t hear from me, publish this so everyone knows I’m gone.”
The LWT is almost certainly not related to this behavior.
The thing is, we haven’t seen that yet. The broker could have pushed some messages to elswhere, but forgotten where openHAB lives or that OH was subscribed for the same topics.
(Consider something like your DNS messing up could give this effect, and still allow OH to publish to MQTT)
Hence the interest on whether the missing messages truly turn up at openHAB, to guide which service to even look into.
“My mail hasn’t come, the neighbours did” - maybe the dog ate it, maybe the postman lost your mail. If you can find out if the letterbox opened, you’ll get a better idea who to blame.
Okeydoke, truly external on a different box then.
If it happens again restart your MQTT server see if that helps. Then you know at least where the error is happening. For me restarting mqtt server helped which made me realize that I misconfigured mosquito.
Did some more testing. And as it turns out:
=> some weird stuff happening inside openHAB-AppServer I guess. But sometimes rebooting helps.
Any update on this issue? I have a similar behavior with my openhab 3.4.4 (MQTT thing stops working) and I found out that it happens if the MQTT broker sends invalid messages, e.g., a “null” message, for whatever reason. Since other MQTT clients, such as MQTT-Explorer or mosquitto_sub continue to work, I assume it is aproblem of the openhab mqtt plugin and I opened a bug report, see [mqtt] MQTT thing stops working after receiving "null" message · Issue #15282 · openhab/openhab-addons · GitHub
no. had it a few times. I let openHAB send me a message, if there’s no update for defined intervals on the items and then I restarted accordingly.
I don’t think it was because the broker sent NULL, but I could try to find this one out the next time it happens.
personally I’m waiting for me to finish migrating to OH4, perhaps it’s solved there.
The result of the bug report was, that there is a bug in the transformation which made the thing hang when a null was received. To my understanding, this has been fixed in OH4. On github, I mentioned a workaround (using JS instead of JSONPATH) for those who are currently not (yet) migrating to OH4. This workaround at least works for me.
had it again yesterday evening. and yes, there was a NULL payload on one JSONPATH-topic.
The workaround using JS instead of JSONPATH works for me now several days (before it stopped every night because of a null triggered by another component). However, I had to replace all JSONPATH transformations that may receive a null to JS, even if the channel was not used by an item. Otherwise, my openhab log was filled with “QoS 0 publish message dropped.” messages.
i have like a bazillion of channels/items working with MQTT and JSONPATH… so I’ll wait until after my holidays and I’ll upgrade to OH4. but thanks for the hint!
