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

[Max_G]

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

And yes: it is not working!

[rossko57]

@Max_G

Restarted OH earlier → no change.

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.

[Max_G]

No, no, no…

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)

[rossko57]

@Max_G

{channel="mqtt:topic:mymosquitto:zevabms:mac"}

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.
Try
{channel="mqtt:topic:zevabms:mac"}

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.

[rlkoshak (Rich Koshak)]

@rossko57

If you’ve no traffic on those topics, no harm done.

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.

@Max_G

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

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

[Max_G]

@rossko57

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. Try {channel="mqtt:topic:zevabms:mac"}

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

Control MHI Aircon by MQTT

Hey there, i want to share how i saved some money on my new Mitsubishi Heavy Industries Aircondition by not buying an overexpensed WIFI adapter but building one with Wemos D1 Mini. So there is the following github repository providing the needed Hardware and sketch: https://github.com/absalom-muc/MHI-AC-Ctrl So i give you an example on the configuration i used to control one device. aircondition.things: Bridge mqtt:broker:mosquitto [ host="localhost", secure=false, port=1883, clientID="ope…

… 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.

@rossko57

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.

Yes, it does unlink/link on channel change…

In fact I had tried both methods.
MainGate did not have mymosquitto
{channel="mqtt:topic:maingate:mac"}
Zeva did have it.
{channel="mqtt:topic:mymosquitto:zevabms:mac"}
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.

@rlkoshak

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

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…

[rossko57]

@Max_G

In fact I had tried both methods.

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

@Max_G

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

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

@Max_G

            Type string : mac "MAC address" [
                stateTopic="ArgyleCourt/Shed/Tower/Zeva16/MAC"
            ]
            Type string : notification "Notification" [
                stateTopic = "ArgyleCourt/Shed/Tower/Zeva16/Notification"

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

[Max_G]

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.

[rossko57]

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,

[Max_G]

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.

[rossko57]

@Max_G

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

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

@Max_G

The PaperUI items I set up also did not receive updates;

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.

[Max_G]

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…

[Max_G]

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

JsonDB Storage

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

Configuration

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?

[Max_G]

@rlkoshak

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

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

[hafniumzinc (T)]

@Max_G

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.

[Max_G]

Thanks… good idea…

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.

[denominator (James Bowler)]

@Max_G

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?

You can do this.

Things

Lets say you have set it up in paperui or a thing file like your example with the exact same settings.

Bridge mqtt:broker:mymosquitto [ host="localhost", secure=false, port=1883, clientID="openhab25" ]

Then in another things file you would add it like.

Thing mqtt:topic:zevabms "Zeva BMS" (mqtt:broker:mymosquitto) @ "Shed" {
  Channels:
      Type string : mac "MAC address" [ stateTopic="ArgyleCourt/Shed/Tower/Zeva16/MAC" ]
  }

@rossko57

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

Mine works with spaces

Bridge blah blah {

    Thing topic fan1 "Dining FAN" [ availabilityTopic="IFANdining/tele/LWT", payloadAvailable="Online", payloadNotAvailable="Offline"] {
    Channels:
        Type switch : Power1   "Dining Light "  [ stateTopic = "IFANdining/stat/POWER", commandTopic = "IFANdining/cmnd/POWER", on="ON", off="OFF" ]
        Type dimmer : fanspeed "Fan Speed"      [ stateTopic = "IFANdining/stat/FANSPEED", transformationPattern = "JSONPATH:$.FanSpeed", commandTopic ="IFANdining/cmnd/FANSPEED", 0="OFF", 1="LOW", 2="MED", 3="HIGH", 2=100  ]
        Type switch : reachable "Reachable"     [ stateTopic = "IFANdining/tele/LWT",	on="Online",	off="Offline" ]
      }
}

I agree not everything is documented for the beginner. openHAB for me has been many hrs of learning.

[Max_G]

Thanks!
Referencing the broker in () was the missing link.

[hafniumzinc (T)]

There are a number of examples hidden away in the github pages for the MQTT binding - I have no idea why they are not part of the main docs, because they seem very useful. It even has a section on converting from MQTT v1…

openhab/openhab-addons/blob/main/bundles/org.openhab.binding.mqtt.generic/xtend_examples.md

[rossko57]

@Max_G

If textural config is the here to stay, it should be appropriately supported.

You’ve said that before. What exactly do you think is not appropriate at the moment?

@Max_G

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?

Okay, choosing the difficult path again.
If you must mix PaperUI and xxx.things files, it can be done.
You will find posts about how to relate topic Things to a non-nested broker Bridge, whether that is defined by PaperUI or in another xxx.things file.

Custom thing type

Yes you dont have to put the “Thing” inside the “Bridge {}”. You have to specify the bridge in brackets () Thing mqtt:topic:tasmota-plug-1 "Tasmota Plug-1 MQTT" (mqtt:broker:127_0_0_1_1883) { Channels: Type string : state "State" [ stateTopic="tele/tasmota-plug-1/STATE" ] Type switch : power "Power" [ stateTopic="stat/tasmota-plug-1/RESULT", transformationPattern="JSONPATH:$.POWER", commandTopic="cmnd/tasmota-plug-1/Power", on="ON", off="OFF" ] }

@Max_G

Do we know which ones,

What needs reinitializing when is hugely dependent on the binding and what you are editing.
Example, a polling binding may poll several Things periodically. Edit one of those things, it will probably require stopping the scheduled poll job and recreating it. Or maybe it requires nothing. Shall we disrupt for every edit, or none? Note that @hafniumzinc approach is generally effective but not in every case.

In the case of MQTT it might or might not need to unsubscribe/resubscribe, switch transformations, blah. There’s always compromises to be made in how far to go and it won’t please everyone.

There is no list. How often do you plan on editing?