No updates from TTN MQTT server - how to debug in OH?

SoerenG · July 29, 2025, 10:24am

Hi,

I have a couple of LoRaWan sensors which I’d like to include in Openhab. They are all registered in TTN (“The Things Network”) and are fully working. TTN provides a MQTT server to subscribe to, and I thought that would be an easy thing.
Problem is now: I configured an MQTT bridged, the things and items for one sensor to test but I don’t see any updates incoming in OH. I use “MQTT explorer” in parallel to check that on the publishers side everything works as expected - and it does. Is there any chance I can get some additional info from the log file about mqtt events? I tried to increase the loglevel using karaf " log:set DEBUG org.openhab.binding.mqtt" but it does not provide too much information. So right now I’m a little lost where to look at.

Running OH 4.3.3 via openhabian at a Raspberry 4B.

Setup is as following, everything is provided as files. First the bridge

Bridge mqtt:broker:TTN_MQTT_Broker "MQTT Broker @ TTN" [ host="eu1.cloud.thethings.network", secure = false, username = "***",
    password = "***", enableDiscovery = false ]

I tried with secure = false and true, so far no change. The status of the bridge however is green/ONLINE and when I change e.g. the password I see it going offline. So at least I can confirm that the MQTT broker connection seems to be working correctly.

A shortened version of the things definition:

Thing mqtt:topic:ttn:water-sensor-deposit "LoRaWAN Water sensor deposit" (mqtt:broker:TTN_MQTT_Broker) @ "Deposito"  {
Channels:

    // Technical message details
    Type string   : full_message  "full json message"   [ stateTopic="v3/ccopenhab@ttn/devices/dd275-deposit/up" ]
[...]
    // Sensor data
    Type number : battery  "battery level device"       [ stateTopic="v3/ccopenhab@ttn/devices/dd275-deposit/up", transformationPattern="JSONPATH:$.uplink_message.decoded_payload.Bat" ]
[...]    
}

And finally the same for the items (also shortened):

Group WATER_SENSOR_DEPOSIT "Water Sensor Deposit" <water> (water_control_system) ["Equipment"]
Number	WATER_SENSOR_DEPOSIT_battery			(WATER_SENSOR_DEPOSIT) ["Point"] { channel="mqtt:topic:ttn:water-sensor-deposit:battery:number" }
String  WATER_SENSOR_DEPOSIT_full_message		(WATER_SENSOR_DEPOSIT) ["Point"] { channel="mqtt:topic:ttn:water-sensor-deposit:full_message:string" }
[...]

From the log it looks live the MQTT subscriptions are working, also the topics are looking OK

2025-07-29 12:15:24.255 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:full_message
2025-07-29 12:15:24.256 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:time
2025-07-29 12:15:24.257 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:rssi
2025-07-29 12:15:24.258 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:consumed_airtime
2025-07-29 12:15:24.258 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:battery
2025-07-29 12:15:24.259 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:interrupt_flag
2025-07-29 12:15:24.260 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:distance
2025-07-29 12:15:24.261 [DEBUG] [.MqttChannelStateDescriptionProvider] - Adding state description for channel mqtt:topic:ttn:water-sensor-deposit:temperature
2025-07-29 12:15:24.347 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:battery to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.347 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:consumed_airtime to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.348 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:temperature to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.349 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:interrupt_flag to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.349 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:rssi to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.350 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:distance to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.351 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:full_message to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up
2025-07-29 12:15:24.397 [DEBUG] [ab.binding.mqtt.generic.ChannelState] - Subscribed channel mqtt:topic:ttn:water-sensor-deposit:time to topic: v3/ccopenhab@ttn/devices/dd275-deposit/up

And finally a picture from the MQTT explorer, which shows that all updates from the sensor get propagated into the MQTT broker:

grafik

As said, I’m a little clueless now where to check further in OH why this does not work. Thanks for any help.

Sören

rlkoshak · July 29, 2025, 2:08pm

I don’t know much about TTN. I assume they provide the MQTT Broker based on your Bridge Thing.

If the Bridge shows as ONLINE then it is most likely configured correctly.

Based on the screen shot from MQTT Explorer, the message is not retained. That means OH has to be online and subscribed to that topic before the message is published by the sensor. If it was not then you have to wait for another message to be published before OH will get anything.

Based on the timestamp in MQTT Explorer the message was sent at 12:08 but your logs indicate OH didn’t subscribe until 12:15.

I don’t know if you have control over this but if you can, it might make sense to configure the messages to be published as retained. Though TTN may not give you that ability. If it doesn’t all you can do is wait until another message is published.

SoerenG · July 29, 2025, 3:25pm

Hi,

the timestamps are because I probably copied the logs from after a restart and the screenshot from a message before that time. Actually I made sure the subscriptions runs when sending some test messages.

I also just put in a wildcard subscription, but even that provided no result of any sensor message.

Type string : test "ALL" [ stateTopic="v3/ccopenhab@ttn/#" ]

rlkoshak · July 29, 2025, 3:56pm

Then one of the following is going on.

The way you logged into the broker using MQTT Explorer is different from the Broker Thing and therefore the Broker Thing cannot see the topics.
There is a typo somewhere in the topics you’ve subscribed to in the Channel configs.

I don’t see any typos but I’m pretty awful at find those.

You might need to ask for advice from TTN. Debug logging from the MQTT binding also might provide a hint.

HWL · July 29, 2025, 5:29pm

agree to Rich. 1 addtion: it could also be that your transformation isn’t correct (though that would not explain why you can’t see the complete topic content).

Did you set it up using textfiles? (I think so) Could you give it a try using the UI?

Could you please post the content of the topic (the part that MQTT explorer shows in the bottom right (starting with ‘{ ënd_device…” ‘).

SoerenG · July 29, 2025, 8:10pm

Finally fixed the problem, although I still have some questions open. After fiddeling around with mosquitto_sub to check there’s no notwork problem (no, there isn’t) and trying to subscribe to a number of different other topics and also with wildcards (yes, all worked perfect), I noticed that - DOH! - the item file had a problem.

I had

Number WATER_SENSOR_DEPOSIT_battery (WATER_SENSOR_DEPOSIT) ["Point"] { channel="mqtt:topic:ttn:water-sensor-deposit:battery:number" }

but it should be

Number WATER_SENSOR_DEPOSIT_battery (WATER_SENSOR_DEPOSIT) ["Point"] { channel="mqtt:topic:ttn:water-sensor-deposit:battery" }

Probably this was a copy & paste problem, but at the end totally my fault. So a link between thing/channel and item was missing, meaning that the message was not consumed or processed. A number of comments however why OH was not helpfull really to solve this issue

The item was not connected to any thing/channel, this is not pointed out in the UI of OH or somewhere
I still don’t see any DEBUG messages in openhab.log, even not after fixing it when everything is processed. Providing some meaningful log details of the binding would eventually have helped here.

But anyhow, it’s running now., learned something about OH and MQTT - and thanks for looking into this issue

rlkoshak · July 29, 2025, 8:55pm

It’s definitely not an error so the UI doesn’t raise a red flag go out of it’s way to point this out. There are lots of reasons to have Items without Links.

But the UI does tell you. Here’s an Item with a link:

Notice the section titled “Channel Links” at the bottom.

Here’s an Item without a link which lacks that section.

Did you put the binding into debug level logging? You can do so through the UI. Navigate to Settings → MQTT Binding (under Add-on Settings) and you can change the logging level of all the different parts of the MQTT binding. The levels are inherited so changing org.openhab.binding.mqtt will change the logging level for all the parts of the binding.

By default, bindings log almost nothing at the INFO level. This is by policy and by design.

But I’m confused. You posted debug level logging from openhab.log above in the original post.

Perhaps it’s that Channels without Links to Items are usually rendered inert by the binding. That means they do not generate any logging messages because they are not actually running. Only if there’s a reason for them to run (i.e. they are linked to an Item) will they do anything. Maybe that is the reason for no logs?

Another way you can potentially identify this sort of problem is from the Thing. In MainUI the Channels show what Items they are linked to.

The second and third Channel shown here are not linked to any Items. This is probably a better place to look to make sure your Channels are linked as expected.

From the karaf console and from the UI you can also get a list of orphaned links. These will be all the links where either the Channel or the Item do not exist. From a browser you can open http://<openhab address>argus:8080/rest/links/orphans or by running the command openhab:links orphan list in the Karaf console.

SoerenG · July 30, 2025, 8:00am

Hi Rich,

thanks for your extensive explanations , that will probably help me in the future to solve similar issues. The logs I posted were indeed after I set the mqtt bindings log level to DEBUG in the karaf console. I just tried to set it also through the UI, a little more convenient, thanks for that hint as well

However, the binding does not provide more information, even in TRACE, no info about processed messages. I just send a number of messages from the sensors, I did see updates in the items, but the log does not show anything from the binding, except the item updates in the even log. But I think, this is an issue of the binding, not the OH core itself.

So thanks again for your comprehensive help, I’m happy it runs now and OH is taking over a little piece more of our automatisation