[SOLVED] Mqtt - 2.4.0 binding issue

I recently update my openhab and I get the new mqtt - 2.4.0 binding.
I configure it with PaperUI by these steps:
Create an MQTT broker
and only to check the correct topic subscription create a channel
that when receive the mqttt messagge trigger an event in the events.log
Create a genreic mqtt thing with a bind to the broker
create a channel with the same topic created for the broker
The status of the Tiings go offline and only the event generated by the broker is reported in the events.log

May be I’m wrong in something, but I’m not able to understand what.

Remove the test channel from the broker thing

I removed the broker channel as you suggest, but nothing change.
I still have the Generic MQTT Thing Offline and no event related to the topic subscription in the log…

That sounds like known error (solved in the snapshot version), changes on the broker config causes this one. You need to either stop and restart the MQTT bundle (at least I think that is sufficient) or the complete OH.

1 Like

I restart OH and the Things status is now online, thanks for this.
When the OH restart, the log reports some apparent problem:
2019-01-09 13:05:09.341 [WARN ] [.MqttBrokerConnectionServiceInstance] - MqttBroker connection configuration faulty: host : You need to provide a hostname/IP!
2019-01-09 13:05:12.730 [INFO ] [panel.internal.HABPanelDashboardTile] - Started HABPanel at /habpanel

but some seconds later things seems to work fine
2019-01-09 13:05:52.145 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to ‘eu.thethings.network’ with clientid paho271972760547902 and file store ‘/var/lib/openhab2/mqtt/eu.thethings.network’
2019-01-09 13:05:52.175 [hingStatusInfoChangedEvent] - ‘mqtt:topic:b47a140c’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
2019-01-09 13:05:52.464 [hingStatusInfoChangedEvent] - ‘mqtt:broker:8a390460’ changed from OFFLINE to ONLINE
2019-01-09 13:05:52.505 [me.event.ThingUpdatedEvent] - Thing ‘mqtt:broker:8a390460’ has been updated.
2019-01-09 13:05:52.536 [hingStatusInfoChangedEvent] - ‘mqtt:topic:b47a140c’ changed from OFFLINE (BRIDGE_OFFLINE) to ONLINE

Anyway the problem related to the subscription topic still remain …
I see the data in TTN
but any event in OH events.log
When I subscribed the same topic in the broker channel I received it.

Because you have used “Services -> MQTT System Brokers”. (or so I can’t recall the exact name). As soon as you hit save in that category a hidden broker is configured, with totally wrong configuration parameters.
You can only get rid of it by deleting the correct .config file in the openhab config folder.

Thanks David,
I’ve done this steps:
-stopped OH
-deleted cache and tmp
-deleted \OPENHABIANPI\openHAB-conf\services\mqtt.cfg
also deleted an old mqtt in \OPENHABIANPI\openHAB-userdata\mqtt
-restarted OH
The log is:
mylog.log (17.8 KB)
there is no more the initial mqtt error but the problem remains.

Could you try these:

  • A topic without wildcards.
  • A wildcard topic without dashes.

We need to narrow down the problem.

With this topic “rse-test/devices/rse-test-device/up” it works !
I get:
2019-01-09 14:59:42.783 [WARN ] [eneric.internal.generic.ChannelState] - Incoming payload ‘{“app_id”:“rse-test”,“dev_id”:“rse-test-device”,“hardware_serial”:“0004A30B001BF893”,“port”:3,“counter”:14710,“payload_raw”:“DZgAEgc6”,“payload_fields”:{“battery”:3480,“event”:“motion”,“light”:18,“temperature”:18.5},“metadata”:{“time”:“2019-01-09T13:59:42.546792596Z”,“frequency”:867.3,“modulation”:“LORA”,“data_rate”:“SF7BW125”,“airtime”:51456000,“coding_rate”:“4/5”,“gateways”:[{“gtw_id”:“eui-1dee0eb900028599”,“timestamp”:2351800027,“time”:"",“channel”:4,“rssi”:-73,“snr”:10.5,“rf_chain”:0,“latitude”:45.81123,“longitude”:9.20063,“altitude”:420}]}}’ not supported by type ‘NumberValue’

In order to overcome to the “not supported by type ‘NumberValue’” I’ve added another channel of Text type and the same topic.
The log give only the Number type topic.
I’ve also tryed this topic on both channel “rse-test/devices/rse-test-device/up/+”
that give only one event " Incoming payload ‘“motion”’ not supported by type ‘NumberValue’
Any suggestion to the topic to test ?

I’ve also tested again the broker channel with the original topic “rse-test/devices/rse-test-device/+/battery” cited at the beginning of the post, that continues to work correctly (mqtt:broker:8a390460:test triggered 3466 in the log).
I’m wondering why using the same topic in the MQTT Things it doesn’t work.

Because a Number channel MUST receive a Number as a payload anything else will fail

But what I get (mqtt:broker:8a390460:test triggered 3466 ) with the topic “rse-test/devices/rse-test-device/+/battery” in the broker channel isn’t a number (3466) ?

This the broker trigger.
This in the broker thing, it’s not in your MQTT Generic Thing
Remove the channel in the broker thing, you don’t need it

In your Generic Thing
Your have two channels a Number that can accept ONLY numbers
and a String one that can accept pretty much anything

I used the broker channel only to check if the topic is correct and it seems to be correct and it get the number 3466.
The question is “why if I use the same topic in a MQTT Generic Thing (both of number type or Text Type) it doesn’t work ?”

It should
Post the screen shot of your channel

Both channel “test” (number type) and “test2” (text type) contain the same topic " “rse-test/devices/rse-test-device/+/battery” that works with broker channel

With this configuration nothing happen in the log

Instead if I change the topic in the “test” (the number type) channel with “rse-test/devices/rse-test-device/up” I get

whit a correct warning related to the number conversion, while if I did the same in the test2 channel (the text type) nothing happens.

Quite strange for me

Your channels don’t have items linked.
If a correct payload arrives nothing will be logged
Link some items and monitor the log

1 Like

You’re right !
I thought the log at Trace level will be put anyway something in the log. …
Many thanks for your support.

:joy: Never assume that the log will contain anything useful. Especially in my bindings I NEVER log anything if it is going to be presented to the user anyway ^^.