[Solved] OH2: mqtt connects as home assistant to mosquitto?!

OH 2.5.9-1
System: Host: rpi3ohv2 Kernel: 5.4.51-v7+ armv7l bits: 32 Console: tty 1 Distro: Raspbian GNU/Linux 10 (buster)

I happily migrated a bunch of mqtt items from v1 to v2, only to discover my items are not getting any updates.
I stopped the mosquitto service and ran mosquitto -v to see, whether openhab does connect… and it does, but this is what I get:

1603357359: Received PUBLISH from Arduino_TheHub (d0, q0, r0, m0, 'ArgyleCourt/Property/Hub/IrrigationTank/Valve', ... (3 bytes))

1603357359: New client connected from as openhab25 (c1, k60).
1603357359: No will message specified.
1603357359: Sending CONNACK to openhab25 (0, 0)
1603357359: Received SUBSCRIBE from openhab25
1603357359: 	homeassistant/# (QoS 1)
1603357359: openhab25 1 homeassistant/#
1603357359: Sending SUBACK to openhab25
1603357359: Received SUBSCRIBE from openhab25
1603357359: 	+/+/$homie (QoS 1)
1603357359: openhab25 1 +/+/$homie
1603357359: Sending SUBACK to openhab25

1603357359: Received SUBSCRIBE from Arduino_TheHub
1603357359: 	ArgyleCourt/Property/BorePump/Status (QoS 0)
1603357359: Arduino_TheHub 0 ArgyleCourt/Property/BorePump/Status

… it does not connect to #, but rather homie and homeassistant… none of these topics contain anything on my system.

2020-10-22 18:24:42.874 [WARN ] [g.mqtt.handler.AbstractBrokerHandler] - Tried to unsubscribe org.openhab.binding.mqtt.homeassistant.internal.discovery.HomeAssistantDiscovery@17408ac from discovery topic +/+/$homie on broker mqtt:broker:mymosquitto but topic not registered at all. Check discovery logic!



Bridge mqtt:broker:mymosquitto [ host="localhost", secure=false, port=1883, clientID="openhab25" ]
    Thing topic zevabms "Zeva BMS" @ "Shed"
            Type string : mac "MAC address" [
            Type string : notification "Notification" [
                stateTopic = "ArgyleCourt/Shed/Tower/Zeva16/Notification"
            Type string : voltages "Voltages" [
                stateTopic = "ArgyleCourt/Shed/Tower/Zeva16/Voltages"
            Type string : current "Current" [
                stateTopic = "ArgyleCourt/Shed/Tower/Zeva16/Current"
            Type string : status "Status" [
                stateTopic = "ArgyleCourt/Shed/Tower/Zeva16/Status"

    Thing topic maingate "Main Gate Controller" @ "Property"
            Type string : mac "MAC address" [
                stateTopic = "ArgyleCourt/Property/MainGate/MAC"
            Type number : temperature "Temperature" [
                stateTopic = "ArgyleCourt/Property/MainGate/Temperature"
            Type string : notification "Notification" [
            Type string : doorbell "Door Bell" [



String ZevaUNO_MAC			"MAC address [%s]"						<network>		(gZevaStatus)		{channel="mqtt:topic:mymosquitto:zevabms:mac"}
String ZevaUNO_Message		"SysMsg: [%s]"							<settings>		(gZevaStatus)		{channel="mqtt:topic:mymosquitto:zevabms:notification", expire="12m,Zeva Controller broken"}
String ZevaCellSetRaw		"Cell sets raw [%s]"									(gZevaStatus)		{channel="mqtt:topic:mymosquitto:zevabms:voltages"}
String ZevaCurrentRaw		"Current raw [%s]"										(gZevaStatus)		{channel="mqtt:topic:mymosquitto:zevabms:current"}
String ZevaStatusRaw		"Status raw [%s]"										(gZevaStatus)		{channel="mqtt:topic:mymosquitto:zevabms:status"}

Should all work… all textural config. No v1 action or binding running

Good, it’s not supposed to,

Yes, devices conforming to those standards are ‘discoverable’ by MQTT binding. If you’ve no traffic on those topics, no harm done.

The good news is that you’ve got at least one broker Thing working at the openHAB end.

I cannot spot any obvious config error.

I do think you are wise to start with simple string payload captures, refining to more useful numbers etc. later … but bear in mind when it gets that far, bindings working from xxx.things files are not very ‘dynamic’ about edits, always restart the binding to be sure of picking up edits.

Basics - does your xxx.things file load? See your openhab.log
Basics - does your xxx.items file load? See your openhab.log
Even when not using PaperUI for editing, you can use it inspect your Thing structure. Are your topic Things showing up?

Thanks :slight_smile:

… for the homie explanation.

Well, I can see the mqtt connection in the events and openhab logs.
I can also see link and unlink messages in events.log

“reload the binding”?? I never had to do that… I do textural config for years, and cannot recall any problems with accepting the change.

Yes, .items and .things load.
and yes… I see in PaperUI in real-time things appearing and links being established.

But why is mqtt not receiving any mosquitto msgs?
Modules are active:

275 │ Active │  80 │ 2.5.9                   │ openHAB Add-ons :: Bundles :: MQTT Broker Binding
276 │ Active │  81 │ 2.5.9                   │ openHAB Add-ons :: Bundles :: MQTT Things and Channels
277 │ Active │  82 │ 2.5.9                   │ openHAB Add-ons :: Bundles :: MQTT HomeAssistant Convention
278 │ Active │  82 │ 2.5.9                   │ openHAB Add-ons :: Bundles :: MQTT Homie Convention
279 │ Active │  80 │ 2.5.0                   │ openHAB Core :: Bundles :: MQTT Transport

When I enable TRACE (log:set TRACE org.openhab.binding.mqtt) all I see is:

2020-10-22 21:08:16.723 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:08:16.755 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:08:16.761 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:09:16.671 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:09:16.701 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:09:16.706 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:10:16.748 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:10:16.805 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime
2020-10-22 21:10:16.817 [TRACE] [.MqttChannelStateDescriptionProvider] - Providing state description for channel systeminfo:computer:local:cpu#uptime

… yet mqtt msgs should pop in every second… like so:

10/22/20 21:16:29.039 ArgyleCourt/Shed/Master/Blanket1/Command HeatedBlanket_1_Level (Type=NumberItem, State=1, Label=Heated Blanket Helga Level, Category=null, Groups=[gShed_Room_South_West])
10/22/20 21:16:29.047 owntracks/owntracks/maxg-iphone {"cog":258,"batt":7,"lon":152.371057,"acc":5,"bs":2,"vel":29,"vac":3,"lat":-27.317832,"conn":"m","tst":1602800543,"alt":191,"_type":"location","tid":"MG"}
10/22/20 21:16:32.784 ArgyleCourt/Shed/GroundFloor/LivingRoom/AmbientLight/Lux 9.92
10/22/20 21:16:32.790 ArgyleCourt/Shed/GroundFloor/LivingRoom/AmbientLight/Visible 395
10/22/20 21:16:32.797 ArgyleCourt/Shed/GroundFloor/LivingRoom/AmbientLight/IR 68
10/22/20 21:16:39.928 ArgyleCourt/Property/AcuRite5in1 {"time" : "2020-10-22 21:16:39", "model" : "Acurite 5n1 sensor", "sensor_id" : 1699, "channel" : "A", "sequence_num" : 0, "battery" : "OK", "message_type" : 49, "wind_speed_kph" : 1.828, "wind_dir_deg" : 0.000, "rain_mm" : 251.460}
10/22/20 21:16:39.936 ArgyleCourt/Property/AcuRite5in1 {"time" : "2020-10-22 21:16:39", "model" : "Acurite 5n1 sensor", "sensor_id" : 1699, "channel" : "A", "sequence_num" : 1, "battery" : "OK", "message_type" : 49, "wind_speed_kph" : 1.828, "wind_dir_deg" : 0.000, "rain_mm" : 251.460}
10/22/20 21:16:39.945 ArgyleCourt/Property/AcuRite5in1 {"time" : "2020-10-22 21:16:39", "model" : "Acurite 5n1 sensor", "sensor_id" : 1699, "channel" : "A", "sequence_num" : 2, "battery" : "OK", "message_type" : 49, "wind_speed_kph" : 1.828, "wind_dir_deg" : 0.000, "rain_mm" : 251.460}
10/22/20 21:16:41.084 ArgyleCourt/Shed/Tower/Zeva16/Voltages 311,3311,3311,3314,3313
10/22/20 21:16:41.591 ArgyleCourt/Shed/Tower/Zeva16/Voltages 312,3313,3311,3312,3310
10/22/20 21:16:42.162 ArgyleCourt/Shed/Tower/Zeva16/Current 40,0
10/22/20 21:16:42.667 ArgyleCourt/Shed/Tower/Zeva16/Status 30,0,2,4000,529,27
10/22/20 21:16:42.787 ArgyleCourt/Shed/GroundFloor/LivingRoom/AmbientLight/Lux 9.95
10/22/20 21:16:42.796 ArgyleCourt/Shed/GroundFloor/LivingRoom/AmbientLight/Visible 396
10/22/20 21:16:42.805 ArgyleCourt/Shed/GroundFloor/LivingRoom/AmbientLight/IR 68
10/22/20 21:16:43.169 ArgyleCourt/Shed/Tower/Zeva16/Voltages 301,3309,3310,3310,3311
10/22/20 21:16:43.788 ArgyleCourt/Shed/Tower/Zeva16/Voltages 302,3311,3311,3311,3309
10/22/20 21:16:44.648 ArgyleCourt/Property/AcuRite5in1 {"time" : "2020-10-22 21:16:43", "model" : "Prologue sensor", "id" : 5, "rid" : 57, "channel" : 2, "battery" : "OK", "button" : 0, "temperature_C" : 25.900, "humidity" : 50}
10/22/20 21:16:48.552 ArgyleCourt/Shed/Tower/BMS/BatteryCapacity 16.6
10/22/20 21:16:48.609 ArgyleCourt/Shed/Tower/BMS/BatteryPower -635.0

But it’s not working.

I have uninstalled/installed the mqtt binding --> no change.
Restarted OH earlier -> no change.

And yes: it is not working!

We only know what you tell us.

How many bridge/broker Things have you got in PaperUI, as you previously used that to create one but are now creating another from file? I’m suspecting duplicate, with your file topics linked to the wrong one.

No, no, no… :slight_smile:

I may be slow in catching onto this THING thing… but I have progressed significantly over the last 48 hours… spending some 10 hours on modifying files.

There is only one broker thing… I deleted the broker and two generic things as stated.

I am dealing with one broker thing and two generic things as per above post.

And just tried, the three disappear when taking it out of the things file. (no dupes)

I’m not sure about that as a channel UID - it doesn’t need to know which broker, that is the topic Thing’s business.

I suspect if you peek at your topic Thing channels in PaperUI you will find that is the suggested ID

Editing this should provoke logging about changing links.

Mostly no harm done. There was an issue for some users connecting to some third party hosted MQTT brokers that would drop the connections from clients that try to subscribe to any but a predefined set of topics. I believe an option was added to turn that autosubscription off . It’s not really related to the problem here though but thought it worth mentioning.

This is a known problem for some bindings. Changes to .things files require reloading the binding to pick up the changes.

This tutorial helped me lot to see ‘things’ and their syntax clearer:

… and it does include the broker.
So does the image I attached in my previous port, they all show the broker name in the Thing.

Yes, it does unlink/link on channel change…

In fact I had tried both methods.
MainGate did not have mymosquitto
Zeva did have it.
The examples in the link above have the broker in the channel.
{ channel="mqtt:topic:mosquitto:Aircondition:fanspeed" }

Both my items do not get updated by mqtt.

TRACE logging the binding shows no activity in picking up any topics.

Well, if it is changes to .things files only, then my statement holds true, as the tings I use are astro, logger, ntp which never changed since late 2018 when I created that thing file.

I think another issue with mqtt being in a thing file, whenever a change is made it disconnects and reconnects to the broker… thus interrupting message flow for that short period.

I am at the end of my wits.
… and basically reverted all changes; as in back to mqtt v1. It simply works…

Yeh, I know both ways are supposed to work … but always less scope for error with less packing.

If I’ve read back correctly, tracing on your broker shows no evidence of attempts to subscribe to these topics? Even with typos in topic we should subscribe even if no updates arrive.

If so, …
We can trust the binding which works for hundreds of other people.
We know you have a usable broker Thing, because you see the discovery subscriptions.
It is allowed to have write-only channels, so a channel with no valid stateTopic will not necessarily complain (but obviously won’t subscribe to anything)
You can even validate that by creating a channel with a commandTopic and sending it a command, it should publish.

What can be wrong with stateTopic then?

We didn’t get a PaperUI screenshot of your topic Thing with channels - I’m not sure if that reveals stateTopic when it can’t be edited, as originating from file.

We’ve seen problems with weird characters like | pipe - none in use here.
Alphanumerics and / should be no problem, standard fare.

Unrecognized keywords will be ignored without complaint - so typos like statetopic= will fail silently. Your stateTopic looks fine. But we must beware of hidden unprintable characters introduced by editors. More than one person has spent hours struggling over something to find these - and it’s really easy to copy-paste them into everything. Just deleting and retyping provides a magical cure.

Looks like the correct type of quotemarks in use, plus errors here invariably log complaints.

The only other straw to grasp at is extra spaces around the = inconsistency

The parser might be rather simplistic … I don’t believe I’ve seen any working examples with spaces.

1 Like

I appreciate your effort with troubleshooting.

Some 60 minutes ago I removed the v2 bindings and things definitions… learning the lesson that this was the last time I modify my production environment with 'new stuff. be it bindings or version upgrades.

I will eventually have a look, whether OHv3 is officially released; find the prescribed way of installing it, and build a v3 system by migrating to it.

It may take while, until restarting OH is not required when the PaperUI db stuffs up, or when binding reloads are not required when thing files are changed.
In my books, changes to these should be picked like item and rules files.
I think both issues are not acceptable for a production system.

The PaperUI that is being complained about allowed you to set up MQTT Things and Items that worked. You did get advice to continue that way, for good reason. I believe this method also deals with the binding reinitialize factor.

You’ll notice Rich has not chipped into this thread … he does not when people use xxx.things files for MQTT because so much time is wasted,

:slight_smile: No hard feelings…

The PaperUI items I set up also did not receive updates; why I deleted them and created a .things file for it… to at least see any mistakes made and not having to deal with db issues.

If using .things file is not ‘supported’ it should be removed from the documentation.

I have no problem with any statement, but is should clearly be made.

Since running both mqtt versions (which I tried) is also not supported, which would have allowed a gradual migration, I opted to restore my previous system and set-up a new one.

This will have two benefits, I should not encounter migration problems, and start with a clean slate.

It’s supported. It’s up to the user to be meticulous when using it, you’re free to choose difficult paths.

Misinterpretation of “working” in old posts on my part then.

I’d love to see if those subscribed in the broker log, might be gone by now.

My OH system is busy ATM… and should end what it is doing after 16:00.

I will then restore the openhab-cli backup from Oct 20.
I will check, whether all is back to normal.
I then have until 02:00 when OH starts getting busy again to potentially give it another try.

This time less enthusiastic or stupid for that matter… :slight_smile:

Sometimes it would be good to know what is going on under the hood…

Why is better to do one way in favour of the other.

If textural config is the here to stay, it should be appropriately supported.
Otherwise, the theme should be: we are moving more and more components into a graphical interface tool with a db (or some sort of store) as back end.

I understood the mqtt item config to sit under a broker thing (nested) in the config. If I create the broker thing in the UI, how can I bundle/specify the generic mqtt things for that broker in the .things file, w/o repeating the broker in the thing file?

Do we know which ones, or is it generally all things in .things files?
What is the remedy other than reloading the binding?

What I do:

  1. Make the .things file invalid by removing an import piece of syntax, such as a bracket.
  2. Save the file. If you’re watching the logs, openHAB will complain and unload all the Things in that file.
  3. Undo the change which invalidated your .things file, and save again. If you’re watching the logs, openHAB will reload all the Things in that file.

I prefer this method, because I can do it all from the same interface that I’m using to develop other parts of openHAB - no switching back and forth between other user interfaces.

Thanks… good idea… :slight_smile:

In my case I watched logs (I always do and capture), no errors there…
However, I am reading up on the jsondb, and that seems straight forward too.
I can see in the json backups that I never created anything in the UI, except the last two days. since it keeps the last 5 backups, I can easily track what was going on… and what I need to do to start with a really clean slate.

Then I repeat my (now documented) approach for textural confgi and see how that goes.