I’m jumping into the deep end. I’m trying Docker for the very first time and openHAB is my test bed. I’m also going to set up mqtt2 for the first time.
I’ve been using openHAB for about 18 months. My production environment is openHABian on a Raspberry Pi. I’m using mqtt1. I specified my devices using .items files exclusively.
I followed the openHAB Docker installation guide. I set up /opt/openhab for conf & usedata.
I’m using mosquitto as my broker (it’s what I’ve become familiar with) so I can set up TLS down the road.
I used PaperUI to specify my broker Thing, added a MQTT Generic Thing with a switch channel, and linked an Item to the channel.
For a Docker openHAB deployment, what’s the recommended practice - PaperUI or configuration files (.things/.items)? Or is it just personal preference? My preference has been to use configuration files. I’ve just found it easier to make updates through VSC, particularly bulk updates. In either case, I’m assuming since both conf and usedata are external mount points, that they survive container updates. Yes?
With mqtt1 I set up my Items definitions so that I could publish to them by using sendCommand. Is this still an option with mqtt2 or do I need to use mqttActions?
It’s just the same as any other openHAB installation method. It’s all the good of openHAB but running in a container. If you like file based configuration just use that.
Yes if you mount the directories from the host into the container these files survive updates and complete removal of the container instance.
I haven’t used mqtt2 myself yet, so I can’t answer that question.
I don’t understand the question. Do you mean you do something like MyItem.sendCommand("blah blah blah") and “blah blah blah” gets published? Than yes, of course MQTT 2 can do that. If you create your Thing through PaperUI (it’s the recommended approach, despite the clunkiness), you can define both an incoming and an outgoing topic. Any command to the Item linked to that Channel will get sent on to the outgoing topic.
As with MQTT 1, you only need the Action in cases where you need to dynamically determine the destination topic on the fly in a Rule.
For all the Docker stuff, what Wouter said. It’s no different from any other deployment. Use what ever approach you are comfortable with.
Yes, Rich, you inferred what I was attempting to ask in my sendCommand my question
Mike
P.S. PaperUI Is it recommended because the mqtt2 syntax is complex or because the syntax changes as additional features are added… but the documentation is not as “dynamic” ? Like when I first started using openHAB, I’ll use PaperUI to get an understanding of setting up mqtt2… but hopefully I can graduate to doing it with files (maybe I’ll “inspect” the jsondb to infer the proper syntax ) Sorry, I just try to avoid it. WAY too many clicks (yes, clunky).
It’s recommended because the developer of the binding doesn’t believe in using .things files and therefor did not test or thoroughly document creating Things in .things files. And if you use PaperUI you are guaranteed to get syntactically correct Things.
I’m not sure how useful that will be. The formats are pretty significantly different. But what I did was created one Generic MQTT Thing. Stopped openHAB, then copy/paste/edited the JSONDB to create the other similar Generic MQTT Things. Then I started OH again and I had all my MQTT Things working. I only had to create a couple of Things by clicking around in PaperUI.
Probably a better approach which I would do next time is:
create one Generic Thing in PaperUI
query for that Thing using the REST API Docs
copy/paste/edit the result and create the new Things using the REST API Docs.
I used a unique and meaningful UID. For example, the Thing for the temp/humidity sensor in my master bedroom has a UID of mqtt:topic:mbr-sensors and my garage door controller has a UID of mqtt:topic:garagedoor1. It must be unique.
I thought that it perhaps had to be some specific alphanumeric code. Meaningful name makes it much better administratively… and probably easier to ensure uniqueness, honestly.
It’s no different from any other deployment. Use what ever approach you are comfortable with.
Is it recommended because the mqtt2 syntax is complex or because the syntax changes as additional features are added… but the documentation is not as “dynamic” 
) Sorry, I just try to avoid it. WAY too many clicks (yes, clunky).