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

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.

You can do this.

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" {
      Type string : mac "MAC address" [ stateTopic="ArgyleCourt/Shed/Tower/Zeva16/MAC" ]

Mine works with spaces

Bridge blah blah {

    Thing topic fan1 "Dining FAN" [ availabilityTopic="IFANdining/tele/LWT", payloadAvailable="Online", payloadNotAvailable="Offline"] {
        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.


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

1 Like

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…

1 Like

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

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.

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?

Again, thank you for your post…

I am getting smarter with this stuff by the hour… :slight_smile:

I have restored my previous version and all is well.

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

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

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.

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

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.

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

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.

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

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

1 Like

As always, I appreciate your useful comments… :+1:

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! :slight_smile:

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. :slight_smile:
Sometimes I seached for answers, just find a post where I asked the same question years ago. :slight_smile:

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.

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

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.

1 Like

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.