If it doesn’t show up as a file under /dev as a try file then the bindings can’t access it whether or not you are running in Docker.
Found it! its /dev/ttyACM0
How do I automatically add the z stick whilst creating the docker openhab container?
I already told you.
1 Like
Hi there,
I’m looking for on option to pre-install a certain set of bindings into my openhab2 docker container. Usually I have something like
- Binding: Astro, Exec, Expire, MQTT, NTP
- Misc: REST documentation
- Persistence: MapDB, RRD4j
- Transformation: Exec, Javascript JSONpath, Map
in a fresh install / container.
I do not like to use addons.cfg but rather prefer something like PaperUI or Karaf. Is there a script hook or something already prepared for OH2 in docker to pre-install such a list of bindings?
addons.cfg IS is the script hook or something to do this.
But now that the container properly manages upgrades, now as long as you maintain userdata outside the container all of your bindings will be there as you move from container to container, even if you change versions.
1 Like
I recommend posting this as a separate tutorial so it is seen by more people and easier to find.
These entries are creating an issue when run on a MAC .
docker: Error response from daemon: Mounts denied:
The paths /etc/timezone and /etc/localtime
are not shared from OS X and are not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
Any known solution for this.
/etc/localtime is a link on MAC
lrwxr-xr-x 1 root wheel 43 5 Apr 2018 /etc/localtime -> /var/db/timezone/zoneinfo/Europe/Bratislava
/etc/timezone is not existing at all.
What is the impact to ommit these 2 entries?
I don’t run on a mac. It seems likely that those files don’t exist on Mac or are put somewhere else. Those to lines set the timezone and local time inside the container to match the host.
Hi all,
I really like the docker install - it makes the install smooth.
I have a question: What about updates of openhab?
On the Raspberry PI, I logged in, made the openhab-config and performed the update. How can I do this with docker? I guess I just pull the new image - but is there a notification that a new docker file is available ?!?!
Again: Great job to all contributors!
Michael
Yes, just pull the new image and create a new container. There is no notification but the new releases are usually available within a couple of days off the initial release.
PR #213 just got merged which adds some new tags and makes use of multi-architecture manifests. It allows for Docker to download openHAB architecture specific images without having to specify the architecture in the tag.
See also the updated README:
For specific versions use:
openhab/openhab:<version>openhab/openhab:<version>-<distribution>openhab/openhab:<version>-<architecture>-<distribution>For the latest stable release use:
openhab/openhabopenhab/openhab:latestopenhab/openhab:latest-<distribution>For the latest release that has a milestone or stable maturity use:
openhab/openhab:milestoneopenhab/openhab:milestone-<distribution>For the latest snapshot release use:
openhab/openhab:snapshotopenhab/openhab:snapshot-<distribution>
2 Likes
What is the current state on the ping issue - we run container as root, or is there another option to have the network binding discover devices?
When trying the network binding, I have to first manually add a device, which will state “ONLINE” even if it is offline (in this case, an iphone).
Why is arp_state disabled? When exec’ing into the container with user openhab, the following command works perfectly reliably, showing the iphone as responding to packets when turned on, and not responding when turned off:
arping -I eth0 -c 2 192.168.1.1.60
ON => 60 bytes from 98:ca:33:bc:42:13 (192.168.1.60): index=0 time=56.558 msec
OFF => Timeout
So how do I make the binding actually use arping, as it is installed by default in the container and seems to work just fine when directly calling the command? Additional question: how can I troubleshoot myself? I’ve put the “org.openhab.binding.network” bundle into TRACE but it’s not showing me anything that looks wrong.
Update:
- running container as root fixes the DHCP permission as expected
- icmp_state still fails for pinging (I want to see these errors in the logs :() but at least we can already conclude that the Java ping is incorrectly saying it successfully pings a device which doesn’t exist…
Update 2:
Ok I’m going down this rabbit hole until I got it cleared out. So I installed ping in my container with
apt-get install iputils-ping
All good, ping now just seems to work:
First remark: what’s the issue here - why aren’t we installing ping in the Docker container?
Weirdly enough, the device is still showing as ONLINE. When I run the exact same ping command the binding uses in my container ad-hoc, I get:
ping -w 5 -c 1 192.168.1.60
PING 192.168.1.60 (192.168.1.60) 56(84) bytes of data.
From 192.168.1.27 icmp_seq=1 Destination Host Unreachable
Clearly, interpretable as offline. So I looked at the code of the binding:
if (line.contains("host unreachable") || line.contains("timed out")
|| line.contains("could not find host")) {
return false;
Is this what I think it is? Just a case sensitivity issue? I still haven’t managed to set up a way to debug this issue, could someone confirm?
So currently the open issues are:
- why is arp_state disabled for my binding inside my container?
- why is a device that is shut off showing as ONLINE when using either the Java ping or the unix native ping?
I really have nothing to offer in terms of answers or advice. I can confirm that arping was merged into the container in June. I don’t know why ping wasn’t added at that time as it was discussed but by default ping is almost never installed in a Docker container so that would explain why it is absent.
It does look like part of the problem could be a case problem, but at this point you know a whole lot more about the code than I do.
You should consider opening an issue and even better submit a PR to the openhab-docker project to include ping.
Yeah I’m a software engineer, but I’m having a very hard time just getting a good debugging setup going. If maybe someone could walk me through and set me up with a working debugging session through e.g. Skype, I’ll gladly investigate/fix/PR further. Then I could also help the guys out with the nikobus binding, which I also promised to take a look at. I know there’s a small part discussing debugging/contribution in the docs, but it assumes a bit too much Eclipse/Maven background. I’d love to do more contribution, but I’m missing a “let’s develop a plugin” video, where it is shown how to deal with local configuration etc. and how the runtime detects packages (right now it’s a magic setup and a git checkout with everything in it, but there’s no complete development inner-loop story)
For example: the network binding isn’t part of the short tutorial debugging setup, so how do I debug it?
I don’t do OH development. My contributions thus far are to the docs and making the Docker upgrade process a little cleaner. Beyond that I’m no help. But as you figure this out, a tutorial or video of your own I’m sure would be well received. 
As far as detecting packages and such I can say that the OSGI container (i.e. Karaf) does most of that.
Could you do me a favour and check one thing before I go mad - sifting through the code it looks to me like currently auto network-discovery can never work, and it also doesn’t at runtime. Does it work for you in the current 2.4?
I’m talking about the following functionality:
Looks like a small detailed question, but I’m figuring out how stable this binding is and whether it could make sense that I’m making several changes. I thought this was due to my Docker setup, but after changing a line of code here locally it starts working again.
I’m not certain that automatic discovery can ever work in a Docker container. The Container has it’s own IP address and IIRC the Network binding will search the subnet for the machine that OH is running on, meaning the Docker network, not the LAN. 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 (if that even makes sense), AND you are using --net=host it might work. But I’ve really never looked into it that closely.
The binding itself is very stable. It was one of the first OH 2 bindings. However, it is also one that has seen a lot of new attention over the years so perhaps someone inadvertently introduced a regression recently.
What I can say is that for Things that I define manually (service Things, not device Things) it works like a champ. I use the Java ping and don’t use arping. To detect my phones I run an external script that reports to OH over MQTT. At some point, not that arping is in the container, I may do away with that external script but it works as needed now so it’s not a high priority.
Well I can confirm that network discovery works perfectly from my Docker runtime right now 
Again, the fix I performed wasn’t even Docker related. I predict that currently on nobody’s 2.4.0 install the discovery works, as I’ve had to replace a “==” by a “!=” completely inverting the current logic. And yes, the docker network is always shared with the host, like the docs also recommend btw.
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.
1 Like