Sorry, I, tried to use both, not in the tutorial.
I mean this broker channel
OK, so I wasn’t quite right - Bridge/Broker Things can have a Channel, but you likely don’t need it.
For each physical device that you have, setup a Generic MQTT Thing. Within that Thing, create Channels for each property that your device exposes: a switch, a temperature, a humidity etc.
Can you imagine when the channel of the broker can be useful?
I do not see anywhere where to distinguish between subscribe and publish action, how can I manage it?
No for my use cases. If you click the link in my post it describes what it can be used for.
It’s right there in the Channel configuration. Example:
MQTT State Topic and MQTT Command Topic
Ok thanks, precious suggestions. Now I will try to put them on the field.
I suggest you have a look at this tutorial in the documentation, or the one I linked in my first post in this thread to understand how to use MQTT in openHAB with your device - they both go over some openHAB fundamentals.
Thanks for all your support. I read them both, and now I am able to have “things” for subscribing and publishing what I need. However my OH2 system is quite complex; I used it as a framework with major software code based actuators (python, ruby, bash, etc.), in order to remain as much as possible free from a specific point of view, constraints and implementation (the ones of the platform developers), using a lot of Exec things.
With OH3, my approach seems almost impossible (or however non-sense), and on the other side I realize that the backward compatibility is not a main objective of OH software developers (it is understandable, for a free open source platform), so I have to decide whether to look for another platform or embrace OH3 with the risk of throwing away all my work with a future OH4.
One final observation: when teaching artificial intelligence at university, many times I kindly reminded my students to consider Occam’s razor 
Throwing away your work is a choice that you make. You could still be running OH2, you chose not to. I guess I’m not really following what horrors you are suffering with external scripts because the way to configure MQTT communications in openHAB has changed.
I am considering leaving OH2 mainly because I am unable to use Zoneminder (which works well in OH3).
The problem, however, is not “suffering” to redo the scripts and external code, but, forcing and “deforming” an approach that is increasingly distant from my original one, it makes no sense; in my opinion better to adopt completely the OH3 approach or leave the platform.
Items are Items. What about the changed way that MQTT is configured is forcing you to do what?
Sorry, I didn’t explain well, what I don’t want to force is the OH approach, not myself.
Just to be clear, I don’t mean there is a flaw in the platform, it probably just doesn’t fit my needs.
thanks.
should I use two generic mqtt for two devices?
or I can add multiple channels of two devices in one generic…?
You can do what you like - both options work.
I personally create one generic MQTT Thing per physical device, so that the Thing’s Channels are properties of the physical device only - leaves me less confused!
But it’s up to you!
2 Likes
I have a mqtt thing connected to my Mosquitto broker running on the same RPi as OH3 and it works fine.
I have tried to add a second bridge to connect to a broker hosted by Glowmarkt to retrieve my smart meter data. As far as I can see, I have configured it in the same way as the working one but I get the following error message:
2021-03-23 20:27:50.233 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'glowmqtt.energyhive.com' with clientid 35194180-52f1-47ee-9718-e685cce9b595
2021-03-23 20:27:51.052 [WARN ] [.transport.mqtt.MqttBrokerConnection] - Failed subscribing to topic homeassistant/#
com.hivemq.client.mqtt.mqtt3.exceptions.Mqtt3SubAckException: SUBACK contains only Error Codes
2021-03-23 20:27:51.056 [WARN ] [.transport.mqtt.MqttBrokerConnection] - Failed subscribing to topic +/+/$homie
com.hivemq.client.mqtt.mqtt3.exceptions.Mqtt3SubAckException: SUBACK contains only Error Codes
2021-03-23 20:27:50.169 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:broker:glowmarkt' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2021-03-23 20:27:50.217 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:broker:glowmarkt' changed from INITIALIZING to OFFLINE
2021-03-23 20:27:50.288 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:SmartMeters' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
2021-03-23 20:27:50.328 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'mqtt:topic:SmartMeters' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE)
I don’t understand what the errors mean because neither the bridge, nor the associated things make any mention of homeassistant or homie. I don’t know if these calls are part of the discovery service and attempting to discover topics on the broker.
I am sure I am connecting to the broker and successfully authenticating because if I change the login credentials, I get a “Not authorised error”. The thing that contains the details of the topic I do want to subscribe to never starts because the bridge is always offline.
The broker itself is working fine because I can subscribe to it with Node Red.
I don’t know what to try next.
That’s exactly it.
If you don’t want it for this broker, disable it on your Bridge thing.
Thanks, that was the last piece of the jigsaw.
I have setup OH3 on a completly new raspberry pi.
On OH2 I used a mqtt.things file for all my devices.
How can I convert it so it can be used in OH3 ?
I have only found “Add Items from Textual Definition” in the developer tools in oh3 ui
Is there a similar feature for things aswell?
No there’s not.
But you can continue to use your Things files in OH3. You don’t have to use the UI. Despite this tutorial my configuration is purely text based.
1 Like
