MQTT on OH 2.5 tries to autodiscover homie/homeassistant topics

mbuchberger1967 · April 13, 2020, 10:40am

hi,
I got 2 problems with the MQTT binding on OH 2.5.3.

I want to connect my farmbot with OH2 via MQTT. The binding tries to subscribe to topics “homie”/“homeassist” probably for auto-discovery. My farmbot message broker denies the first try to subscribe and terminates the connection.
If I stop the bundles for the “Homi” and “Homeassistant” MQTT stuff, it works and the connection is established. but with the next restart or bundle setting changes, they start again.
What can I do to stop this auto-discovery?
My first try with MQTT was to setup everything via PaperUI. I removed the MQTT Broker later and configured everything in the config files.
Now the system always detects the old Message Broker item in the Inbox. I removed the item several times, cleaned the cache, un- and re-installed the binding and restarted OH2 and the raspberry, but somewhere the information is still existing and the system tries to re-cover it. How can I get rid of this?

Thank you and Happy Eastern
Markus

H102 · April 13, 2020, 3:52pm

Not sure about the Homi stuff as I haven’t tried it yet but maybe add autodiscovery = false??

For the old items/links that wont go away:

Look in /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.link.ItemChannelLink.json and make sure there isn’t a Link hanging around.

For items check: /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.items.Item.json

If you find items/link here you can remove them but make sure to stop OH first.

rlkoshak · April 13, 2020, 5:56pm

You can see if removing the bundles in the karaf console works, though they will come back next time you upgrade. You best bet for a solution that doesn’t require redoing these changes periodically would be to bridge the farmbot broker with a broker you control (e.g. Mosquitto) and have OH subscribe to that. Alternatively you can look at the settings on the farmbot broker and figure out why it cares that OH is trying to subscribe to those non-existant topics. I suspect it has ACLs set up. If so you could modify those ACLs so it doesn’t terminate the connection when OH tries to subscribe to those topics.
The Broker Thing or were you using the embedded Broker? The MQTT binding doesn’t automatically discover brokers unless you are using the embedded broker.

mbuchberger1967 · April 13, 2020, 7:43pm

Where exactly could i do this setting for the mqtt binding? or is it a global config parameter?

I checked the files and only in DiscoveryResult.json I found an entry which is related to the MQTT.
Can I delete this?
{}pi@raspberrypi:/var/lib/openhab2/jsondb $ cat org.eclipse.smarthome.config.discovery.DiscoveryResult.json
{
“mqtt:systemBroker:fb3”: {
“class”: “org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl”,
“value”: {
“thingUID”: {
“segments”: [
“mqtt”,
“systemBroker”,
“fb3”
]
},
“thingTypeUID”: {
“segments”: [
“mqtt”,
“systemBroker”
]
},
“properties”: {
“host”: “clever-octopus.rmq.cloudamqp.com”,
“brokerid”: “fb3”,
“port”: 1883
},
“representationProperty”: “brokerid”,
“flag”: “NEW”,
“label”: “MQTT Broker”,
“timestamp”: 1586746025867,
“timeToLive”: -1
}
}

mbuchberger1967 · April 13, 2020, 7:47pm

@rlkoshak.
I am using the embedded broker, I thougt this is easier

The farmbot broker is run by the community, and I dont have access to its settings.
So i can only change it on the FB side. If there is no chance to disable this automatic subscribing I have to switch to another broker… thanks for the hint.
Still I dont understand, why there is this automatism but no way to disable that, couldn’t it be a problem for other brokers as well?

mbuchberger1967 · April 13, 2020, 7:56pm

And by chance, can you also help me with another problem I have regarding the transformation of the values:

I can connect to the broker, and I verified with mqtt-spy that my topics return a json as I expect.

Here is my configuration in OH:

Bridge mqtt:broker:fb2 “Farmbot MQTT Broker” @ “MQTT” [ host=“clever-octopus.rmq.cloudamqp.com”, secure=false, username=“device_5629”, password="…"]
{
Thing topic fb “Farmbot” @ “MQTT” {
Channels:
Type string : logs “FB Logs” [
stateTopic=“bot/device_5629/logs”,
transformationPattern=“JSONPATH:$.message”
]

  Type string : informational_settings "Information" [ 
    stateTopic="bot/device_5629/status",
    transformationPattern="JSONPATH:$.informational_settings"
  ]
  
  Type string : fw_version "Firmware version" [ 
    stateTopic="bot/device_5629/status",
    transformationPattern="JSONPATH:$.informational_settings.firmware_version"
  ]

  Type string : pos_x "Position X" [ 
    stateTopic="bot/device_5629/status",
    transformationPattern="JSONPATH:$.location_data.position.x"
  ]
  
  Type string : pos_y "Position Y" [ 
    stateTopic="bot/device_5629/status",
    transformationPattern="JSONPATH:$.location_data.position.y"
  ]

The items are configured here:

String mqtt_logs "Log [%s]"  (gFarmbot)     {channel="mqtt:topic:fb:logs"}
String mqtt_fb_info "Information [%s]"  (gFarmbot)     {channel="mqtt:topic:fb:informational_settings"}
String mqtt_fw_version "FW version [%s]"  (gFarmbot)     {channel="mqtt:topic:fb:fw_version"}
String mqtt_posx    "Pos X [%s]"    (gFarmbot)     {channel="mqtt:topic:fb:pos_x"}
String mqtt_posy    "Pos Y [%s]"    (gFarmbot)     {channel="mqtt:topic:fb:pos_y"}

But if I try to display this, alle items have a null value, except for pos_x, which contains the complete json response, but has no label; this proves there is a connection, but why does pos_x behave different than pos_y, and are the oter items all empty?
If I comment out pos_x, the others are still empty.
Is there a max length for the json response?

Thanks for any help, I dont know what i do wrong.

rlkoshak · April 13, 2020, 8:17pm

99.9999% of the time people are connecting either to an MQTT broker that they are running (e.g. Mosquitto, the embedded browser, etc.) or to a generic MQTT service (e.g. CloudMQTT). In all the years I’ve been supporting openHAB on this forum this is the first time I’ve see a system that provides their own MQTT broker that you have to connect to.

When you are running your own MQTT broker, it’s actually a lot of work and you have to really try to configure it to do the same thing that the Farmbot MQTT Broker is doing. No one actually goes through all that effort. It makes sense that FarmBot has their MQTT broker configured that way, but the number of systems that come with MQTT by default is exceptionally rare, those that come with their own MQTT broker is vanishingly small.

So I’m not surprised there is no way to turn off the auto-discovery. It’s never been a problem before.

I used to spend hours and hours every week helping people with syntax errors in their MQTT .things files. I refuse to do so any longer. When you create your Things through PaperUI or the REST API there are no syntax errors and it is obvious what options are available and how to use them.

Errors in the log? The NULL Items are never being updated at all and the transformation for posX is failing for some reason (probably explained in the logs).

rossko57 · April 13, 2020, 8:36pm

The screenshot doesn’t show any of the JSON keys you are looking for, so not much to say there.

JSONPATH is an optional installable service.

mbuchberger1967 · April 13, 2020, 10:11pm

@H102, @rlkoshak

I deleted the file, it was re-created and the systemBroker:fb3 is in it again. It must be stored somewhere else. any idea?

rlkoshak · April 14, 2020, 3:08pm

Yes, you have the Embedded Broker add-on installed. As long as you have the add-on installed and you do not have the corresponding Thing accepted out of the Inbox it will forever keep showing up.

mbuchberger1967 · April 23, 2020, 7:00pm

Hi @rlkoshak
you were right. my items were wrong, I had a wrong channel id. The broker and channels I created in PaperUI used only a 4-part channel id: mqtt:topic:status:wifi_level, while the broker / channels I configured in the things file use a 5-part id: mqtt:topic:farmbot:status:wifi_level
I have overseen that, thank you.
Now my subscribe_topic work well.

mbuchberger1967 · April 23, 2020, 7:04pm

This problem remains:
I once configured a systembroker thing in the PaperUI, named fb3
How can I get rid of it?
Somewhere all the information including the access token must be saved, as it always re-appears in my inbox.
I tried to:

deinstall the mqtt binding
stopped the server
cleaned cache
started the server
re-installed the mqtt binding
restarted the server with cache-cleanup

and the mqtt:systembroker:fb3 thing again showed up in my inbox.

Any ideas where this information might be stored?

rlkoshak · April 23, 2020, 7:06pm

Like I said, uninstall the MQTT Broker add-on.

mbuchberger1967 · April 23, 2020, 7:07pm

Hi
I did!
Uninstalled it, restarted the server with cache cleanup two times in a sequence.
After re-installing the MQTT broker addon, the thing shows up again

BR

rlkoshak · April 23, 2020, 7:11pm

You said you unisntalled the MQTT binding and thenre-installed the MQTT binding.

The MQTT Broker binding is a completely separate binding. When the Broker add-on is not installed, it should not be rediscovered in the Inbox since it’s not there to be discovered.

mbuchberger1967 · April 23, 2020, 7:14pm

Sorry,
I was not precise, you are right.

I de-installed and re-installed the MQTT binding:

The MQTT broker I think I dont have installed, at least it looks like this:

rlkoshak · April 23, 2020, 7:48pm

If the broker binding is not installed but it’s still finding it in the inbox I’m not sure why that would be the case.

You can go to /var/lib/openhab2/jsondb and search through the files there for it and manually delete it (stop OH before editing those files). Though it’s much safer to just ignore the Item. There is an eye looking icon in the inbox I think that you can click and tell OH to ignore that Thing. It won’t show up again.

mbuchberger1967 · April 24, 2020, 10:21pm

Hi,
I did both already.
I searched through the files in the jsondb after stopping the server, but couldnt find anything there associated with the thing from the inbox.

I also clicked the eye icon to ignore it, but on next re-start of the server, it appears again in the inbox.

No further idea where the data for this thing could be stored?
thanks

rlkoshak · April 27, 2020, 5:32pm

You can try clearing the cache but all things Things related get’s stored in the JSONDB.

mbuchberger1967 · April 30, 2020, 9:11pm

I already cleared the cache multiple times, too.

If I have all things, items, etc. in my config files, can I completely delete the JSONDB files (while the server is down)? Will it be restored automatically when the system restarts?