Israel uses EU frequencies…
FALSE
According to the Z-Wave Alliance Israel uses 916 MHz. EU uses either 866.4 MHz or 869.85 MHz.
Using EU Z-Wave devices in Israel is likely illegal
Did you get everything set up the way you want?
I’m very pleased with Docker and my Ubuntu server. I’m running containers for:
openHAB
MotionEye
InfluxDB
Grafana
Shairport
Logitech Media Server
Portainer
Emby
Frontail
UniFi poller
I also use and installed directly:
NodeRED
Network UPS Tools
Mosquitto
I love docker but came to embrace a mixed philosophy: Docker when convenient but systemd if there were too many trade offs.
Can you point me to a guide to installing influxDB and Grafana as docker in OH?
Hi Omri, here is my docker-compose.yaml for most services you want to setup. They are all bound in one network (smarthome --> docker create network smarthome). You can start/stop the services with docker compose.
Start: docker-compose up -d
Stop: docker-compose down -v --remove-orphans
version: '3.8'
services:
mosquitto:
image: eclipse-mosquitto
container_name: mosquitto
restart: unless-stopped
environment:
- TZ=Europe/Berlin
- PUID=1000
- PGID=1000
volumes:
- /opt/docker/smarthome/mosquitto/config:/mosquitto/config
- /opt/docker/smarthome/mosquitto/data:/mosquitto/data
- /opt/docker/smarthome/mosquitto/log:/mosquitto/log
ports:
- "1883:1883"
- "9001:9001"
networks:
- smarthome
openhab:
image: openhab/openhab
container_name: openhab
restart: unless-stopped
ports:
- 8080:8080
- 8443:8443
- 5007:5007
volumes:
- /etc/localtime:/etc/localtime:ro
- /etc/timezone:/etc/timezone:ro
- /opt/docker/smarthome/openhab/openhab_addons:/openhab/addons
- /opt/docker/smarthome/openhab/openhab_conf:/openhab/conf
- /opt/docker/smarthome/openhab/openhab_userdata:/openhab/userdata
depends_on:
- mosquitto
- motioneye
- node-red
environment:
OPENHAB_HTTP_PORT: "8080"
OPENHAB_HTTPS_PORT: "8443"
EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
LC_ALL: "de_DE.UTF-8"
LANG: "de_DE.UTF-8"
LANGUAGE: "de_DE.UTF-8"
USER_ID: "1000"
GROUP_ID: "1000"
networks:
- smarthome
node-red:
image: nodered/node-red
container_name: node-red
environment:
- TZ=Europe/Berlin
volumes:
- /opt/docker/smarthome/node-red/data:/data
ports:
- 1880:1880
restart: unless-stopped
networks:
- smarthome
motioneye:
container_name: motioneye
image: ccrisan/motioneye:master-amd64
restart: unless-stopped
volumes:
- /etc/localtime:/etc/localtime:ro
- /opt/docker/smarthome/motioneye/etc/motioneye:/etc/motioneye
- /mnt/storage/docker/smarthome/motioneye:/var/lib/motioneye
ports:
- 8765:8765
- 8081:8081
networks:
- smarthome
networks:
smarthome:
external: true
1 Like
I haven’t tried Compose much - it’s on my list but at this point I start everything with docker run
and manage it with Portainer. I’ll offer my advice as a parallel to that provided by @MrksHfmn.
I did a short write-up with some Docker advice and your question motivated me to cross post it here:
For InfluxDB, my run command looks like this:
sudo docker run -p 8086:8086 \
-d \
--name influxdb \
-v /opt/influxdb:/var/lib/influxdb \
-v $PWD/influxdb.conf:/etc/influxdb/influxdb.conf:ro \
influxdb -config /etc/influxdb/influxdb.conf
For Grafana, I’d recommend creating a Grafana user with appropriate UID and GID (I used 9004). I discussed this in the link I posted.
sudo docker run \
-d \
-p 3000:3000 \
-p 8081:8081 \
--restart=always \
--name=grafana \
--user=9004 \
-e GF_SECURITY_ALLOW_EMBEDDING=true \
-e GF_AUTH_ANONYMOUS_ENABLED=true \
-e GF_RENDERING_SERVER_URL=http://192.168.1.80:8081/render \
-e GF_RENDERING_CALLBACK_URL=http://198.168.1.80:3000/ \
-e GF_LOG_FILTERS=rendering:debug \
-v /opt/grafana/data:/var/lib/grafana \
grafana/grafana
Note that both of these containers use persistent volumes in the opt directory. I’d recommend creating these directories before creating the containers, and in the case of Grafana, doing some permissions fixes. I talked about that in my write up too.
Hope that’s helpful!
1 Like
Thanks so much.
Could you also share your frontail docker setup?
Sure thing.
sudo docker run --name frontail-openhab -it -p 9001:9001 -d -v /opt/openhab/userdata/logs:/logs -v /opt/frontail/ui:/ui --restart=always mthenw/frontail --theme dark --ui-highlight --ui-highlight-preset /ui/frontail-preset.json /logs/openhab.log /logs/events.log
Sorry for putting it all on one line. Docker run spits out an “invalid reference format” error when I split it up neatly like I did for Grafana above. I don’t know why, but putting it all on one line fixes it.
I set this up to use openHAB’s highlights but with the dark theme. To use the highlights, you’ll need to create /opt/frontail/ui and in it place the following file: https://github.com/openhab/openhabian/blob/master/includes/frontail-preset.json
Note that this setup also relies on openHAB being run in a Docker container and keeping its files inside /opt/openhab. If this isn’t your OH directory you’ll need to adjust obviously.
1 Like
Thank you again Sir!
1 Like
This looks interesting Actually to fit in with the newest Linux filesystem standards /srv/openhab would be more appropriate for a mix of file types.
After seeing this post I decided to play around with Compose. Instead of running it from the command line, I started the stacks using Portainer’s editor.
I now have six stacks running and I love the simplicity and elegance. Even better, next time I start clean with my server it should be even more painless.
I still stand behind my original advice and suggest new Docker users learn the system with simple containers started with docker run but Compose really takes it to the next level!
2 Likes
Perhaps you should submit updates to the official documentation.
I’d be open to that.
Are you referring to the lack of a compose option on the Docker install page? I’d be happy to add a generic Compose file and explanation.
I also noticed that the page still references a Docker container run as a systemd service. From what I understand, that’s a bit obsolete and doesn’t really have any benefits.
I have found the documentation really lacking.
The Docker documentation is on Docker Hub in addition to the openHAB web site.
Can you explain what “working with stacks” mean and how it simplifies the setup?
I understand the new version of portainer is kubernates enabled. Is it anything like that?
that very depends … it’s not black&white … I use compose only for containers which have to coexist together … like influx+chronograf and stuff like that
having multiple containers at one wrapper is pain in the ass when you need to update one of them.
Before doing stacks one need to think it thru a bit, but yes it’s convenient in some ways
having openhab + mosquitto + nodered in one stack is… silly
1 Like
A single capability will often involve a number of different applications. For example, a typical openHAB “stack” might include:
- openHAB
- FronTail
- Mosquitto
- InfluxDB
Each of those applications would be running in it’s own Docker container. By using Docker compose (or similar tools) you have one file that defines all four of those containers and will bring them up in the proper order and with the proper run parameters.
I wouldn’t go that far. It depends on the intent and how the individual user wants to manage their own system. There is no multi-developer DevOps situation going on here. It’s one person trying to deploy one set of systems in a way that makes the most sense for them. It may not be a best practice but I wouldn’t call it silly. For many people, working out of one file is convenient and makes more sense for them.
Pardon my newbie limited knowledge about dockers.
It sure does make it easier to deploy initially all the docker containers that are related as a start.
So if I need to stop the openhab docker, back up , remove the tmp and cache folders before I update to the newer version, how would I do so with docker compose? do I also need to stop all the other docker containers in the compose file and reload in total? Can I just remove a single docker container and get a new image and start up that particular new container?
I am comfortable using portainer 1.24 for managing my docker containers for all home automation related containers.
Backup is no different than with regular docker. Either enter the container and run the backup script, or backup the volume where the conf and userdata is preserved outside the container. Clearing the cache during an update is already handled by the container itself so there’s nothing you need to do. If you want to do it manually, you’d do it just like you do with any other docker deployment.
No. Docker Compose is really just a way to control the startup of a number of services and control the order they start up in. It’s not really any more than that. It doesn’t change where and how the data is stored or what the container does once it’s already started.
Probably, though typically when you are using compose, you treat the group of containers as a single unit. You wouldn’t typically mess with just one and leave the others running. That’s sort of the point. It lets you treat two or more containers as a single “thing”.
1 Like
maybe it’s too strong to call that silly, let’s call it bad practise then 
this is exactly the point where you think about stack in a wrong way because you figured out that for OH update you need to remove whole stack and run it again - as it should be, but for mismatched application it is not convenient. It can be indeed done separately, but then you are loosing what stack is doing.
So use stack for things which needs one or another to live, like grafana+grafana-image-renderer or influxdb+chronograf etc. basically everywhere you have dependancy.
But what kind of dependancy has got mqtt server with openhab? zero, because mqtt is needed even when openhab is restarting as devices are communicating to it, so another systems like nodered can still be operational. Having OH,nodered,mqtt and basically any other automation software in one stack is … bad practise.
what’s dependency between medusa,lms or sickrage? none, only thing “common” is they handle different mediafiles, these should not be stacked, no reason for that, and so on, so on