MQTT (2.4) works in Paper/Classic but not Basic UI

Tags: #<Tag:0x00007faee36ad0d0> #<Tag:0x00007faee36ace50>
  • Setup:
    • Synology DiskStation, DSM 6.2.2-24922
    • openHAB version: openhab-syno-spk 2.4.0.002

From within Basic UI all bindings work/respond except for MQTT.
If I i.e. trigger a MQTT switch nothing happens and the events.log says:

[ome.event.ItemCommandEvent] - Item 'XY_Switch' received command ON
[nt.ItemStatePredictedEvent] - XY_Switch predicted to become NULL

Whereas triggered from Paper/Classic UI it works:

[nt.ItemStatePredictedEvent] - mqtt_topic_mosquitto_xy_power predicted to become ON
[vent.ItemStateChangedEvent] - mqtt_topic_mosquitto_xy_power changed from NULL to ON

The whole setup used to work fine before I updated to 2.4.0.002, no changes were made to items/things. Sadly switching back to the previously working build (2.4.0.001) does not resolve the issue.

Also messages in the openhab.log that I can’t make sense of and that might (not) be related:

[WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "BridgeImpl" with key "mqtt:broker:mosquitto". It exists already from provider "GenericThingProvider"! Failed to add a second with the same UID from provider "GenericThingProvider"!
**[ERROR]** [e.internal.WriterInterceptorExecutor] - MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent.

Ideas/help/input is much appreciated :slight_smile:

The two Items in the log snippets are not the same Item of course. Maybe show us a bit more about these Item definitions.

They are the same item (events.log). The first time triggered from Basic UI, the second time from Paper UI.

Same result for every item such as:

Switch XY_Switch { channel="mqtt:topic:mosquitto:xy:power" }

It just strikes me as odd that everything works fine in Paper UI and Basic UI doesn’t seem to participate in any MQTT pub/sub…

We need to see your sitemap definition as well.

1 Like

??

This Item is called XY_Switch
[nt.ItemStatePredictedEvent] - XY_Switch predicted to become NULL

This Item is called mqtt_topic_mosquitto_xy_power
[nt.ItemStatePredictedEvent] - mqtt_topic_mosquitto_xy_power predicted to become ON

That one looks like an auto-generated Item, with a name derived from the found channel.

The “predictions” come from openHAB’s autoupdate feature, by the by. That can be influenced by any bindings.

Okay, so…

mqtt_topic_mosquitto_xy_power

must have been created by Item linking, Simple mode in Paper UI. Meanwhile my config files are beeing addressed by Basic UI which are predicted to become NULL.

I switched Simple mode Item linking off and created a generic MQTT thing, selected the MQTT bridge (that successfully triggers my config-file-items from Paper/Classic UI) and set MQTT state/command topic. Screenshot shows the result…

And there I thought I had finally figured out all the pitfalls of MQTT 2.4 :smiley:
What am I missing…?

OK, so your Item XY_Switch with channel=“mqtt:topic:mosquitto:xy:power” doesn’t work.
A new Item with channel=“mqtt:topic:mosquitto:Test:Test” doesn’t work.
There is a warning in the log
Cannot add "BridgeImpl" with key "mqtt:broker:mosquitto". It exists already from provider "GenericThingProvider"! Failed to add a second with the same UID from provider "GenericThingProvider"!

It looks like you have unexpected near-duplicate Items, I’ll guess one from an xxx.items file and an auto-generated one.
I’ll guess further that you have near-duplicate MQTT broker things,one that works and one that doesn’t.

As your Item mqtt_topic_mosquitto_xy_power appears to be working, perhaps you should look at what it’s channel is.

The channel seems to be auto-generated as well. Once I manually choose the one from my items-file (mqtt:topic:mosquitto:xy:power) Basic UI starts showing ON/OFF instead of “-” but flipping the switch still doesn’t turn the lights on…

Well gosh, I wonder what the working auto generated channel that was working used to be. I’m not that surprised that changing it to something else stopped it working.

The auto-generated channel never worked in Basic UI (only Paper and Classic UI).

Slow down, observe and understand your system.

Channels never ever work in Basic UI. Basic UI operates on Items, and you specify which Items in your sitemap.

If you see a functional difference between using BasicUI and ClassicUI, you are probably looking at different sitemaps. default.sitemap is not the same file as _default.sitemap, for example.

As you seem to have had simple mode on at some time, you probably have an auto generated sitemap kicking about, populated with auto generated Items.

Okay, so channels link Items to devices via bindings, MQTT in your case.
It matters not whether they work via this UI or that UI, if the channel works it works.
So, you have some that work (sometimes) and some that don’t work (at all).
But the “sometimes” just means you’ve got some sitemap issue to sort out as well.

The interesting thing then, is going to be the difference between the channels that work and the channels that don’t. I will bet you the brokers are different.

Okay, so manually assigning channels from my items-file (to items via bindings of course) works and I can once more pub/sub MQTT messages (also form Basic UI).
Manually assigning is highly impractical but Item linking Simple mode doesn’t seem to get the job right (meaning auto-generated channels instead of the once I propose in my items file). Is there a way to prepare things- and items-files so Item linking Simple mode works? Thanks for your patience!

Don’t think so. “PaperUI editing” and “file based editing” are pretty much mutually exclusive. No change made in PaperUI will ever get copied back to items or things files. So far as I know, you’re actually blocked from editing files-originating data in PaperUI anyway (though you can view it).

You can maintain a mix of Items and Things using both methods, but you will need to remember which is which, to keep your sanity.

As using the text based files configuration is an “advanced” technique, you almost certainly do not want to be in simple mode. That’s what got you into this mess in the first place.