Running openHAB 2 in Docker

[baka (Bart)]

I started a thread in Adventures implementing reliable network detection using arping as my network binding findings go beyond a Docker setup. Good news is that if I can get past my current hurdle, Docker won’t be an issue at all.

[smar]

@rlkoshak

Unless you modify the settings somewhere (I don’t know where, perhaps in userdata/etc somewhere) to bind to your LAN IP address instead of the Docker container IP address

You can do this from paperUI: configuration, system, network settings. This is exactly how I have mine (including running the docker container with --net=host) and haven’t had difficulty with OH discovering IP based things (note though that I am not using the network binding).

[waspie (scott dee)]

network discovery not working in 2.4

[Confirmed not fully functional]Network binding 2.4 does not work

Network discovery is not working in OH 2.4. It might come back in a later OH 2.5 snapshot though.

[Nico_Lembrechts]

I am wondering if someone encounters my issue and/or might have a solution.
My containerized openhab process doesn’t detect config file changes. From what i can see openhab is using the inotify kernel subsystem to detect the config file changes. In my setup i have a kubernetes cluster and i use the official docker image for the pod and the volumes are mounted (bind) via nfs directly into the container.
My vscode editor then uses the nfs server filesystem as the working dir. The problem is that nfs server doesnt “inform” the nfs clients kernel subsystem that the file has changed. (SMB also doesn’t do this) For example when i exec into the container and edit the mounted files from there then openhab does detects the change. So far my problem.
Some ideas:

• somehow make vscode to work directly into the pod.
• Find a way to manually trigger openhab to reload the config files
• implement a inotify helper
• use git do push changes first and the pull into the container.

So, i am wondering how this works for other docker openhab users.

Regards,
Nico

[rlkoshak (Rich Koshak)]

@Nico_Lembrechts

somehow make vscode to work directly into the pod.

I’ve seen some traffic here on the forum that VSCode has added an SSH option that will let you edit files on a machine you can SSH to. While it’s considered “not good practice” to put ssh in your containers, it could be a work around.

I use a Chromebook and you cannot (yet) mount a SMB or NFS file system into the Linux environment so I use you fourth option and use git to push/pull the changes.

I don’t see this problem because I mount a local volume into the container and share that volume (SMB for now for cross platform support) to edit it with VSCode and it works fine.

[wborn (Wouter Born)]

The container update process got further improved with PR #239.

It now has all the features of the update script used with manual and .deb package based openHAB installations:

• show update notes and warnings during the update (based on update.lst)
• execute the update pre/post commands (based on update.lst)
• replace userdata system files with newer versions (based on userdata_sysfiles.lst)
• update KAR files in addons dir by downloading newer versions
• log the update output in update.log

[psyciknz]

I’m trying in do an upgrade from 2.3 2.5m2 In a dev instance for verifying all my changes.

I see way up in this post, that I should remove cache and tmp folders, leaving etc, jsondb, zwave, persistence.

This contradicts https://www.openhab.org/docs/installation/docker.html#updating-the-image

While that’s fine, I’m getting very little joy in starting the upgraded instance. I do see it performing the upgrade (as the post above says it should), but it seems to hang. I can every so often see it throw out a rule invalid

11:39:46.310 [OH-ruleEngine-3] ERROR org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl - Rule 'Temperature min/max updates': The name 'triggeringItem' cannot be resolved to an item or type; line 148, column 82, length 14

Which is why i’m testing it. And complaining about a change to my influxdb.cfg for a db that doesn’t exist (I don’t what two systems updating my primary influx db)

Any guidance? I might hose it, and start again if someone can confirm what I do actually have to remove before starting the upgraded version.

[rlkoshak (Rich Koshak)]

@psyciknz

This contradicts

If you look at the OP you will see an update that for the past year and a half the container does all update steps for you.

That’s follow official docs instead of years old postings.

2.3 to 2.5 is a really big jump. You might try to upgrade to 2.4 first, fix problems, then upgrade to 2.5.

@psyciknz

. I can every so often see it throw out a rule invalid

That’s a symptom of the rules triggering before OH had fully loaded the rules engine. If it’s got stuck during the upgrade I’m not surprised by errors like these.

Often, one needs to let OH perform the upgrade, want for it to quiet down, and then restart it. Occasionally clearing the cache and tmp folders is needed as well.

What steps specifically did you take? Any other errors?

[psyciknz]

Ok, I’ll retry it. Just trying to get a dev system running with 2.3…then I’ll attempt and upgrade.

I’ve got a separate post about getting a dev system working (rather than upgrade my main prod system) and dealing with persistence and mqtt clients etc.

[ricadelic (Rick Jongbloed)]

• implement a inotify helper

I found an inotify message forwarder (GitHub - mhallin/notify-forwarder: Simple tool that can forward file system events to other machine, such as virtual machines with shared folders) which can forward inotify events from a NAS to the openhab container and it works!

I created an Openhab cont-init.d script. That script and a arm32 bit and a arm64 bit binary that i compiled can be downloaded here: Microsoft OneDrive . This is the script:

#!/bin/bash
arch=$(uname -m)
if [[ $arch == 'aarch64' ]]; then
echo running aarch64 version of inotify-forwarder...
    /etc/cont-init.d/notify-forwarder_aarch64 receive &
elif [[ $arch == 'armv7l' ]]; then
    echo running armhf version of inotify-forwarder...
    /etc/cont-init.d/notify-forwarder_armhf receive &
fi
disown

When using the following commandline on the NAS and i change a file via VS Code:

./notify-forwarder_armhf watch -c  10.43.125.124:29324 /k3s_storage/openhab/conf /openhab/conf /k3s_storage/openhab/addons /openhab/addons

I receive attrib events on the Openhab container. I can confirm that Openhab listens to attrib events

root@openhab-6fbf4d4dcf-qzkfj:/openhab# inotifywait -m -e attrib -r /openhab/conf
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/openhab/conf/.git/ ATTRIB FETCH_HEAD
/openhab/conf/.git/ ATTRIB FETCH_HEAD
/openhab/conf/automation/jsr223/python/personal/ ATTRIB 000_init_rules_on_startup.py

I will complete this post with an systemd script for the NAS later.
-edit-

A very quick and dirty unit file:

[Unit]
Description=Inotify Forwarder for OpenHAB
After=network.target
StartLimitIntervalSec=0
StartLimitBurst=3000

[Service]
Restart=always
RestartSec=3
Type=simple
ExecStart=/k3s_storage/openhab/contrib-init/notify-forwarder_armhf watch -c 10.43.93.81:29324 /k3s_storage/openhab/conf /openhab/conf /k3s_storage/openhab/addons /openhab/addons /k3s_storage/openhab/userdata/etc /openhab/userdata/etc

[Install]
WantedBy=multi-user.target

[ricadelic (Rick Jongbloed)]

Have you tried setting the yeelight binding log level to trace and see what is (not) going on?

Also you could inspect the network traffic to see if there is specific network traffic blocked.

And I’m not really sure, but when you’re not using host mode, you might need some kind of traffic forwarder/router for the upnp traffic?

[ohb1138 (Justus Reich)]

I found an issue when trying to call the karaf client in a rule using the `executeCommanLine" command:

rule "Do what I want"

  when
    Item restart_zwave changed to 2

  then

    val String results = executeCommandLine("/openhab/runtime/bin/client 'bundle:restart org.openhab.binding.zwave' ", 8000)

    logInfo("FILE", "***** RESTARTING: >" + results + "< *****")

end

The logs shows:

19:46:07.304 [DEBUG] [clipse.smarthome.io.net.exec.ExecUtil] - executed commandLine '/openhab/runtime/bin/client 'bundle:restart org.openhab.binding.zwave' '
19:46:09.160 [DEBUG] [clipse.smarthome.io.net.exec.ExecUtil] - exit code '1', result 'Closed'
19:46:09.161 [INFO ] [g.eclipse.smarthome.model.script.FILE] - ***** RECYCLING: >Closed< *****

It seems that there are some environment variables missing when calling it via rule because when I rund this command from the command line (or putting it into a small script and running the script from the command line inside the container the client bundle:restart works:

root@openhab-2:/openhab/conf/scripts# /openhab/runtime/bin/client bundle:restart 232
Logging in as openhab
root@openhab-2:/openhab/conf/scripts# 

And here the log output:

19:47:38.152 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from ONLINE: Node initialising: REQUEST_NIF to UNINITIALIZED
19:47:38.168 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
19:47:38.169 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node5' changed from ONLINE: Node initialising: REQUEST_NIF to UNINITIALIZED
19:47:38.185 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node5' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
19:47:38.185 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node4' changed from ONLINE: Node initialising: REQUEST_NIF to UNINITIALIZED
19:47:38.232 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node4' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
19:47:38.233 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:564c8ec1' changed from ONLINE to UNINITIALIZED
19:47:41.450 [INFO ] [ding.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
19:47:41.479 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:564c8ec1' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
19:47:47.496 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
19:47:47.499 [INFO ] [.zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
19:47:47.609 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:564c8ec1' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
19:47:47.615 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:564c8ec1' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
19:47:47.623 [INFO ] [ding.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
19:47:47.631 [INFO ] [ding.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
19:47:47.635 [INFO ] [ave.internal.protocol.ZWaveController] - Starting ZWave controller
19:47:47.635 [INFO ] [ave.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
19:47:47.647 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node5' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
19:47:47.649 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
19:47:47.652 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node4' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
19:47:47.666 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
19:47:47.668 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node4' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
19:47:47.669 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node5' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
19:47:50.840 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:564c8ec1' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
19:47:50.845 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node5' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
19:47:50.846 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node4' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
19:47:50.849 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
19:47:50.849 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zwave:serial_zstick:564c8ec1' has been updated.
19:47:50.857 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node2' changed from ONLINE to ONLINE: Node initialising: REQUEST_NIF
19:47:50.863 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:564c8ec1:node4' changed from ONLINE to ONLINE: Node initialising: REQUEST_NIF

Any idea what is different between normal OpenHAB installation and docker?

[ei_Gelb_Geek (Kevin)]

@rlkoshak

Limitations and Gotchas

• The Exec binding is likely not going to be very useful. The container has very little installed (e.g. no Python, ping, hping3, etc.) and almost no access to the host’s file system which eliminates most of the benefit from this binding. To get around this run an external service on the host that can receive commands from OH via REST or MQTT.
• The openHAB 2.0 Network binding has limited use. The Docker Image does not have “ping” installed so the “use system ping” option cannot be set to true, and I could not find a way to give the Docker Container permission to bind to low numbered ports so the dhcp option doesn’t work.

This Limitation can be fixed by building a custom Image

Example to install netcat ping jq bc awk

Dockerfile

FROM openhab/openhab:latest

RUN apt-get update && apt-get install -y netcat inetutils-ping jq bc gawk &&\
  rm -rf /var/lib/apt/lists/*

Command to build the Image

docker build --force-rm --no-cache -t private/openhab:latest

[jeshab (Jeremy)]

@ei_Gelb_Geek

This Limitation can be fixed by building a custom Image

You don’t need to build a custom image anymore with the container init scripts support.

Running Exec binding scripts in Docker using custom image

With the container init scripts support, a custom image is no longer needed for this use case. Here is the updated setup I am now using: cont-init.d/50-exec-scripts #!/usr/bin/with-contenv bash # Include openhab scripts folder in path export PATH=${OPENHAB_CONF}/scripts:${PATH} # Install additional packages apt-get -qq update && \ DEBIAN_FRONTEND=noninteractive apt-get -qq install --no-install-recommends -y \ curl \ jq \ python \ python-pip \ python-setuptools \ python-wheel #…

[ei_Gelb_Geek (Kevin)]

Nice … Thx for the hint

[liveislife (Leif)]

Hello guys,

I´ve followed the tutorial and got openhab 2.4 up and running in docker. Everything seems to run fine except those warnings/errors on each startup:

2019-10-03 11:26:18.135 [WARN ] [org.apache.felix.fileinstall        ] - /usr/share/openhab2/addons does not exist, please create it.
2019-10-03 11:26:18.163 [ERROR] [org.apache.felix.fileinstall        ] - Cannot create folder /var/lib/openhab2/tmp/bundles. Is the folder write-protected?
2019-10-03 11:26:18.164 [ERROR] [org.apache.felix.configadmin        ] - [org.osgi.service.cm.ManagedServiceFactory, id=38, bundle=10/mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.4]: Unexpected problem updating configuration org.apache.felix.fileinstall.1813a014-eea4-4ad5-aa1f-e70c2be8093f

Permissions should be okay, I did:

sudo find /opt/openhab/ \( -type d -exec chmod 777 {} + \) -o \( -type f -exec chmod 777 {} + \)

to be sure. Any ideas where to start?

Thanks a lot!

[marcel_erkel]

Which tutorial did you follow because based on the path names I reckon you’re not using the official openHAB docker image:

openhab/openhab-docker

Also note that the log is complaining about /var/lib/openhab2/tmp/bundles (this directory does not exist in the official openHAB docker image) while you set the permissions for /opt/openhab/.

[liveislife (Leif)]

I´ve followed the tutorial from this thread and I´m using the offical openHAB docker image.

But now I see: I copied my / userdata and my / conf folder from my Openhabian installation (without Docker). There are probably references there that I still need to change.

Thanks!

[icompas (Immo)]

Actually, I have the same issue. Did you find the culprit?
This is actually the only item which causes some issue. Not sure though what the impact is.

When I map the folders according best practice, but still using my old conf directory mapped, the system crashes immediately.

ExecStart=/usr/bin/docker run --name=%n --net=host \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v /home/zotac/openhab2:/openhab/conf \
  -v /opt/openhab/userdata:/openhab/userdata \
  -v /opt/openhab/addons:/openhab/addons \
  -v /opt/openhab/.java:/openhab/.java \

result:

2019-11-12 20:04:19.537 [ERROR] [org.apache.felix.scr                ] - bundle org.apache.felix.scr:2.1.2 (39)Circular reference detected trying to get service {org.eclipse.smarthome.core.audio.AudioSink}={service.id=118, service.bundleid=116, service.scope=bundle, component.name=org.eclipse.smarthome.io.javasound.internal.JavaSoundAudioSink, component.id=6}
 stack of references: ServiceReference: {org.eclipse.smarthome.core.audio.AudioSink}={service.id=118, service.bundleid=116, service.scope=bundle, component.name=org.eclipse.smarthome.io.javasound.internal.JavaSoundAudioSink, component.id=6}
ServiceReference: {org.eclipse.smarthome.core.audio.AudioManager, org.eclipse.smarthome.config.core.ConfigOptionProvider}={service.id=120, service.bundleid=103, service.scope=bundle, defaultSink=enhancedjavasound, service.config.label=Audio, component.name=org.eclipse.smarthome.core.audio.internal.AudioManagerImpl, component.id=7, service.config.category=system, felix.fileinstall.filename=file:/openhab/userdata/etc/org.eclipse.smarthome.audio.cfg, service.pid=org.eclipse.smarthome.audio, service.config.description.uri=system:audio}

Having my mapping as follows, and using the old userdata location,

ExecStart=/usr/bin/docker run --name=%n --net=host \
  -v /etc/localtime:/etc/localtime:ro \
  -v /etc/timezone:/etc/timezone:ro \
  -v /home/zotac/openhab2:/openhab/conf \
  -v /var/lib/openhab2:/openhab/userdata \
  -v /opt/openhab/addons:/openhab/addons \
  -v /opt/openhab/.java:/openhab/.java \    

gets the system up and running, and as far as I can see it behaves normal. Only entries in the log files are:

2019-11-12 16:04:24.657 [ERROR] [org.apache.felix.fileinstall        ] - Cannot create folder /var/lib/openhab2/tmp/bundles. Is the folder write-protected?
2019-11-12 16:04:24.666 [ERROR] [org.apache.felix.configadmin        ] - [org.osgi.service.cm.ManagedServiceFactory, id=38, bundle=10/mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.4]: Unexpected problem updating configuration org.apache.felix.fileinstall.098b1b9c-eaed-41c3-8fac-c8c88d5624c5
java.lang.RuntimeException: Cannot create folder: /var/lib/openhab2/tmp/bundles

Anyone, any idea?

[wborn (Wouter Born)]

Maybe search and replace works. It’s a known issue anyhow:

openHAB directory is not relocatable