After using 10 years Domoticz. It’s time for something different to try.
I did a lot of reading in and the race was between Home assistant or Openhab
I am going for Openhab because of the more stable system, blocky and Google home integration.
I came across a weblog from someone (Home assistant) who uses an awesome solution to cast a ipcamera to chromecast devices. But it uses a docker container to convert rtsp to HLS so it will accept on a chromecast device.
I am totally new to Docker but from what I have read its nice to run several containers at the same time.
Now my question is in the openhab Docker Information page I have read that it’s not supporting Exec bindings.
I couldn’t find or determine if it’s useful to have and what it means or does.
Can someone clarify this for me?
Are there more advantages or disadvantages to run Openhab Docker?
Well Docker is great if you don’t want to deal with all the needed software like java etc.
Just spin up the Container and you are ready to go.
Clean setup, easy to reset, easy to upgrade, easy to downgrade.
Nice structure either folders or docker volumes.
Forward ports etc.
Quote from the docs:
However, this flexibility comes at a cost. For example, because openHAB is running in its own container with only enough installed to run openHAB, the Exec binding is very likely to be useless to you because the container will not have access to the programs and files you need.
Solution? Build your own Docker Container or with docker compose add needed software like python3. stackoverflow
dammit now I got even more interested.
I am building a full openHAB setup from scratch with influxdb, grafana and openHAB with an easy Start/Stop/Remove scripts.
I will maybe also add Node-RED and more for a full user Setup
Thanks for the answer. I am not a programmer or a Linux expert and coding. All the things i have to accomplish and accomplished I have to do with tutorials and how to’s and when I see the coding to let containers to communicate it scares me a bit off.
The only thing i want to use docker is to cast my ipcams on Chromecast. So I think I will use a dust getting Pi1 to use as host for the docker image to convert rtsp to hsl.
I use Docker on an Ubuntu server I built for openHAB and several other services. I decided to run openHAB inside Docker along some other lightweight services like Mosquitto. I run node-RED and Shinobi CCTV software outside of Docker, however (node-RED for access to the command line and Shinobi for easier access to the GPU for hardware acceleration).
I’m by no means an expert. I did struggle at first with some of the docker stuff but it came to me eventually. I think it’s good to keep track of the docker run commands you use for easy editing later. I also recommend using Portainer or something similar to keep track of your containers.
Hard to answer because it depends on your preferences, knowledge and HW.
The main advantage is in being able to rollout fast, roll fore and roll back OH and other server instances and OH versions.
This will help minimizing SW dependencies if you want to colocate OH with other services on a shared server but comes at a price. Some system-near stuff such as Exec binding or GPU access won’t work, and it’s consuming quite some resources so I wouldn’t want to run it on a RPi2/3 which otherwise is fine as a (dedicated) OH server.
The standard recommendation is a RPi with openHABian. I, too, would separate OH and your RTSP-whatever converter and run them on dedicated HW.
It’s not so much that it doesn’t support the Exec bindings but that the Exec binding isn’t all that useful.
The whole purpose of a container is to provide everything that a single program needs to run in one package. In some ways, you can look at a container as a wholly separately running operating system.
But, the container also only includes just what the program running inside it needs to run. There are no extras available, like Python. Some containers don’t even have bash. So most of the things you will want to have access from the Exec binding won’t be there. And even if stuff like Python were there, it will be limited in what it can do outside of the container.
Personally, I run everything in containers. It makes installation, upgrade, and backup pretty simple. I don’t have to worry about incompatibilities with libraries or ports or the like.
Or outsource that stuff to some other app you can command more indirectly such as through MQTT.
With one exception (Calibre which doesn’t offer an official Docker container) I always use the “official” images from the software provider unchanged.
You might look into Ansible. I have all of this (minus NodeRed) running in containers installed and managed by Ansible playbooks.
If they have the option to install this software not in a container you will probably have better performance. Converting media streams tend to be RAM and CPU intensive and containers do increase the amount of RAM needed to run a set of software.
Absolutely. Especially because you can integrate your config files there as well and put everything into a git repository for versioning.
What I assume is that docker could get more complicated with USB related stuff. At least there was a time some years ago I tried that on my Synology (running docker and using USB for zwave) and I failed.
I don’t find it to be all that complicated. But perhaps my approach inadvertently avoided problems. I always make sure there is an equivalent user on the host as the user the program running inside my containers are running as (i.e. my host has an openhab user and it’s the same uid as the openhab user inside the container) and I added the host’s openhab user to the proper groups for read/write access to the devices. Then I just need to pass the device into the container with the right arguments. In Ansible that’s supplying valued for “devices”.
Have you tried this binding as it can provide the HLS stream and I have my cameras streaming to my Chromecast enabled Sony TV. Sorry if I have missed something special about your use case as I have not used docker before, as far as I know you can run Openhab in docker and then use this binding to do what you wish. The binding does need access to ffmpeg…
I am reading up the documents on Openhab docker as I would like to set it up when I get my hands on a RPi4. Just wondering if there is anyway to setup everything via docker compose and config files?
I read that you can have bindings installed by specifying in the config file, and I have all the items/sitemap/rules in text files as well.
However, I thing I am uncertain is Things. For my current setup (non Docker), I add Things using paper UI, then use the channel ID on the my items. Is there a way to automate on adding things? And then link it to an item?
Of course. Just mount a conf folder into the container over /openhab2/conf inside the container and the OH in the container will use those config files. You also need to mount a userdata folder over /openhab2/userdata to preserve anything you may do through PaperUI, embedded persistence (mapdb, rrd4j) and any binding specific persisted data.
This is why you want to mount a userdata into the container as well. All this gets stored in the JSONDB which is in files in the $OH_USERDATA/jsondb.
If you mount both conf and userdata than you can use openHAB however you want, be it using PaperUI or through text configs.
I run this way and have done so for years.
The automation for the adding of Things is automatic discovery which you do through the Inbox. You can define Things using .things files, but there will be no automatic discovery. You will have to research each binding and figure out how to define the Things properly in a .things file.
There is no way to automatically link them to an Item because how is OH going to know what Item to link it to? You can put the link on the Item in your .items file, is this what you are asking?
Anyway, the tl;dr is just mount volulms for both userdata and conf and use OH how ever you are used to it.
I’d refrain from doing so. There’s no general benefit in using Docker that would justify this.
And you’re using almost everything which is new (Docker is new to you) and untested (openHABian on RPi4/buster is not yet implemented). Seems like you are asking for trouble.
I’m currently working on getting openHABian to run inside Docker and there’s quite a number of issues.
Sure, Amanda is part of openHABian and recommended to use for all backup purposes.
Thank you for your answers. I thought it would be a good way to prepare my system for the future. Run OH2.4 in a Docker, Later OH3, have a Docker for Milestone Builds, …
I just started with informing me about Docker and the first few Info´s looked good for me.
After reading your post I think I have to decide whether I will do it or not. It looks to be a big workload, especially if there is no experience from my side.