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

[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?

[Max_G]

Again, thank you for your post…

I am getting smarter with this stuff by the hour…

I have restored my previous version and all is well.

@rossko57

What exactly do you think is not appropriate at the moment?

Sorted… I read the docs… and it is supported.

@rossko57

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.

It is not about the difficult path; this was a mere question. Which was answered in [Solved] OH2: mqtt connects as home assistant to mosquitto?! - #21 by denominator

I am also no longer worried about what needs reloading.

My approach is installing a test environment with the lasted stable OH2.
… and then go through different config scenarios.

By subscribing to my PROD mosquitto, I can start tackling the channels with transformations and then the rules… to eventually implement it all into PROD.
This will include migrating off v11 bindings were possible.
Case closed.

[rlkoshak (Rich Koshak)]

@rossko57

I believe this method also deals with the binding reinitialize factor.

It does not. You can edit Things all day long through PaperUI without needing to reload the binding.

@Max_G

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.

This is also a problem specific to .things files. When OH loads a .things file it removes the existing Things from that file and then recreates them. Thus your Broker Thing has to reconnect. That’s how it works with .items and .rules files too.

@Max_G

The PaperUI items I set up also did not receive updates

Then there is something wrong with the configuration, a typo in the topic or a misunderstanding of what one of the fields mean.

@Max_G

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

In OH 2 (and OH 3 it appears though I’ve not looked deeply into it yet) there are two sources of truth: JSONDB and text configs. The JSONDB gets loaded first and loaded in such a way that there is never a problem with something being loaded before something else is needed (e.g. rules being loaded before the Items it uses are loaded). Then the text files are loaded into memory and if they duplicate something from the JSONDB it overwrites it.

The JSONDB gets automatically backed up.

There is next to no parsing involved when loading from the JSONDB meaning boot times and load times are dramatically improved. I cut 20 minutes off of the boot time of an OH configuration on an RPi 0W simply by moving everything to the JSONDB.

When manually creating Things, Items, and Rules through the UIs it almost impossible to generate a syntax error.

JSONDB is also text based so it is suitable for storage in source control, copying backups from one instance to another, etc.

In general, OH runs so much better when working out of JSONDB compared to text configs that now that the UI is catching up with the MainUI in OH 3 I will recommend it for all OH configs going forward.

Textual config is here to stay but unless and until some developer or maintainer decides to take a crack at vastly improving how it works, it is always going to work like what it is, a kludgy system that is carried along for backwards compatibility. As such it’s never going to work as nicely as stuff does in the JSONDB. That’s just my opinion.

@Max_G

Do we know which ones, or is it generally all things in .things files?

MQTT for sure, I think maybe KNX and Exec too but I don’t use either of those so am going mostly from memory.

The remedy is:

• don’t use .things files
• don’t change .things files when you can’t take the hit from reloading the binding
• don’t use the binding

@hafniumzinc

I have no idea why they are not part of the main docs

I think they never figured out how to have subpages properly built from multiple .md files as part of the docs build.

[Max_G]

As always, I appreciate your useful comments…

I have installed docker (for the first time) and OH2.5.9 in to it, to play around with it all.
I also saw a post where you created the things offline and merged them into the jsondb. What I thought of doing this too. I have some 15 controllers (talking MQTT), some will need 20 channels (a number I initially underestimated), and I haven’t even started with home automation!

Whichever way I am going (jsonddb, fudging it or not, I appreciate the stance (and reasoning) on preferring the jsondb over text file config. As I said elsewhere (and yes it is open source anarchy, yadda yadda), but I felt it was never beneficial for OH to have such multitude of UIs, and reading about the troubles with it, I vowed to “never” adopt any of them. Yes, I with docker now, it should be easy to have a peek at OHv3 and see what the mainUI is doing.

Also, seeing how dynamically and quickly textural items associate with jsondb channels, I felt this to be a viable option too… why I asked earlier, whether the broker can be ‘separated’ for the associated things.

My issue is that I dive into OH once a year, and have to relearn how things need to be or work… during the rest of the year OH just does what it is supposed to do.
Sometimes I seached for answers, just find a post where I asked the same question years ago.

Anyway; thanks for the ‘guidance’.

[edit] I will have to check v3 out, but what also deterred me was the list of 1,000 items; in case the new UI can group them (e.g. per thing) I might be inclined to use it.

[rlkoshak (Rich Koshak)]

@Max_G

I also saw a post where you created the things offline and merged them into the jsondb

Post the link! Even though I wrote it I can never find it when I want to link back to it.

@Max_G

I will have to check v3 out, but what also deterred me was the list of 1,000 items; in case the new UI can group them (e.g. per thing) I might be inclined to use it.

I had similar concerns, and even now there are times where it feels like having some way to group Items would be useful. But so far I’ve moved just short of 200 of my Items over to a test OH 3 as I’m experimenting and learning the ins and outs of OH 3 and I find I don’t need such grouping so far. Maybe I’m just lucky and chose a reasonable naming scheme but so far search on the Items page of the MainUI has been more than adequate. And if I want to get a better look at the structure of my automation I use the Model view instead of Items.

I intend on pushing the importance of building the model in the beginner’s tutorial as a result.

Note I’ve really only got some Network binding monitoring Items moved over right now. And I’ve only built a location based model, not a functional model yet. But it should be reasonable and possible to build a functional model as well. And once you build the model both search from the Items page becomes more useful and HABot becomes almost magical. And building Pages becomes almost automatic, at least for a first cut at the Page.

[Max_G]

@rlkoshak

Post the link!

Well, I read through so much stuff, I can’t remember either…
And it is also not to ‘hold you to account’… as I fully understand with exposure and experience comes change in how things are done… which certainly applies to the jsondb.

---

I reckon it is a double whammy for me now, not having used PaperUI (unaware of its future place, yet aware of its flaws), and now hearing this is the new thing here to stay in OHv3.