[SOLVED] Binding started but not reacting at all in DOCKER environment

Development
,
1

I’m developing the Nanoleaf Binding and I am encountering a strange situation on one of my installations (on others it does work quite will).

  • the binding is installed (as being said by Openhab logs)
  • Karaf tells me that the feature is started / activee and the bundle as well

However, It doesn’t seem to work nor do I see any logs of my binding even though I am sure I have set the bundle to debug or even trace

(I am pretty sure I am using the right expression “log:set TRACE org.openhab.binding.nanoleaf” as I am using that on other installions as well).

  • Even when I start the discovery it stops much faster with the discovery as usual (normally it tries about 30 secs where in this case it stops already after 2 secs) and even though I have debug logs in all AbstractDiscoveryService-Methods, there is no log output at all.
  • I have stopped and (re)started the feature as well as the bundle in the openhab console with no success
  • When starting the bundle there is no exception in the logs that would hint to an issue.
  • Usually the bundle is pretty chatty when I set it to TRACE or DEBUG but I see nothing.
  • Other bundles do work

So my question is

  • What could be the case that a binding is installed but doesn’t really run?
  • Any idea how I could further analyze the root cause?

Thanks in advance
Stefan

2

did you started the binding from the OH console? This could show if a dependency is missing.

I had the same problem with my Shelly binding, but can‘t remember the root cause.

Which dev environment are you using? 2.5.2?

3

I am on 2.5.1 on that system. Yes I did with karaf . I also thought there might be a missing dependency but then there must have been an exception but as I said I see nothing.

4

I mean the build environment, not the runtime, you should get a 2.5.2 SNAPSHOT. If not try a fresh IDE install

what does bundle:list shows?

did you tried a mvn clean install (sometimes I had the problem that a normal mvn install created broken jars)

is this a new bundle or does the problem occurs after changes

does the bundle come up in Eclipse?

Do you use gson? which version is installed (bundle:list)?

I my case ir was not an exception, but hack I can‘t remember

5

Oh yes, sorry, the bundle itself is 2.5.2.

To be exact: The runtime environment has been installed with 2.5.1 and I had issues with my binding on 2.5.1 (as well). So I built my latest bundle which has even more log statements and this one is as follows.
So the behaviour is not related to being new.

openhab> bundle:list | grep Nano
268 │ Active │ 80 │ 2.5.2.202001261455 │ openHAB Add-ons :: Bundles :: Nanoleaf Binding

Yes, I am using Gson

20 │ Active │ 80 │ 2.8.2.v20180104-1110 │ Gson: Google Json Library for Java

There is no difference in behaviour of using my 2.5.1 bundle or the 2.5.2 unfortunately (even though as you said 2.5.2 could have dependency issues with 2.5.1 and then I would be happy to see them :wink: ).

“does the bundle come up in Eclipse?”

Not sure what you mean with “eclipse” in that sense. I can see it liste in karaf as being installed and active.

I should mention that both run perfect on my own local home environment as well as on the one of my bundle development partner. So I don’t think it is a general problem with the bundle but it seems to be related to that environment on which it is currently running. I would rather find out the root cause of that as there might be others that would also have the same setup and then I would be even more blind to find out why there is an issue (currently I have full access myself to that box).

6

I’ve seen an issue in other topic with Gson file. Here is a updated working jar that may help:
https://repo1.maven.org/maven2/com/google/code/gson/gson/2.8.5/gson-2.8.5.jar

7

So just put that into the add-ons folder as well? Is it compatible to 2.5.1?

I am still wondering why I wouldn’t see any logs if there were exceptions and the like?

8

Correct, place in addons and I’m not 100% sure about the compatibility with 2.5.1 but it’s worth a try.

9

yep, I checked old messages and Gson seems to make the difference. I would expect 2.8.5 as part of OH 2.5. Maybe try the following

  • deinstall the binding and GSon 2.8.2 using OH console (use bundle:uninstall )
  • stop OH
  • place GSon 2.8.5 into the addons folder
  • copy the binding jar in the addons folder
  • start OH
10

I have just developed a binding but others have had the same issue that the binding doesn’t load. Developed in vscode 2.5.2snapshot. I’m new to all this so didn’t know if I had to add anything in anywhere such as Gson for it to be used. Or if it would be backwards compatible with say 2.4/2.3?
It works perfectly on my bare 2.5 system (albeit with a few other addons installed but not setup)

11

I would assume that it runs on fresh installs and problems are related to upgraded installations. Nevertheless you should check the GSon topic

12

So I tried this finally but even this had no effect. Neither the bundle tells me anything nor do I see any exception. btw, I even compared the log settings to what I have at home and they are equal (for transparency reasons I should mention I run openhabian at home).

In the meantime I also updated the basic linux system (hypriot) which had no effect.

Tomorrow I try to update openhab to 2.5.1-2. I’ll keep you all posted if that has an effect. Maybe someone could even point me to a documentation how I do that update on a linux environment (actually openhab runs in a docker container based on hypriot there).

13

you should get 2.5.1-2 when doing an apt-get update && apt-get upgrade

14

I am using the docker container from https://hub.docker.com/r/openhab/openhab

I pulled openhab/openhab-latest and it shows

Logging in as openhab

                          __  _____    ____
  ____  ____  ___  ____  / / / /   |  / __ )
 / __ \/ __ \/ _ \/ __ \/ /_/ / /| | / __  |
/ /_/ / /_/ /  __/ / / / __  / ___ |/ /_/ /
\____/ .___/\___/_/ /_/_/ /_/_/  |_/_____/
    /_/                        2.5.1
                               Release Build

and

cat /openhab/userdata/etc/version.properties
openHAB Distribution Version Information
----------------------------------------
build-no        : Release Build
online-repo     : https://openhab.jfrog.io/openhab/libs-release

Repository        Version
----------------------------------------
openhab-distro  : 2.5.1
openhab-core    : 2.5.0
openhab1-addons : 1.14.0
openhab2-addons : 2.5.1
karaf           : 4.2.7

but I wanted to have 2.5.1 -2

Can you advise which version I should pull to get “-2”?
(note that openhab/openhab:latest-2 doesn’t work)

15

So finally I found out what the reason was:

THE DOCKER NETWORK SETUP IS THE PROBLEM!

More and more I had the feeling that something was wrong with the discovery and the mdns and finally this proved to be true. Due to the normal setup of a docker container only configured ports will be open to the public which is a killer for mdns (or upnp).

The really simple solution that has cost me hours and days to find out is the following:

Add this one liner to your docker-compose file:

network_mode: host

similar like

services:
  openhab:
    image: "${REPO:-docker-openhab.mydomain.com}/openhab:${VERSION:-latest}"
    restart: unless-stopped
    network_mode: host
    build:
 ....

if you like to know the details to the topic, see https://forums.docker.com/t/option-network-mode-host-in-docker-compose-file-not-working-as-expected/51682

I hope that saves many others like me valuable time.

cheers
Stefan

16

You can also save valuable time by reading the documentation because this is the very first note :roll_eyes:

Important: To be able to use UPnP for discovery the container needs to be started with --net=host .

1 Like
17

Definitely thanks @wborn for pointing that out.

You see, this is the point with documentation. Usually the solution for your problem is somewhere documented if you how to ask the right question :wink:

In hindsight I can say that I did not setup the docker container myself and the one who did probably wasn’t aware of that documentation (no excuse). So it is good that you again directed to that point in the documentation.

At least I learned a lot (and maybe the docker syntax above is a bit of a value for someone).

Thanks again,
Stefan

1 Like
18

I bet you did learn a lot about Docker along the way!
When running into such issues you’ll learn the most. :slight_smile:

19

Yep, I learned at lot about debugging karaf and bindings and finding things that couldn’t be seen and digged very deeply into the network :nerd_face: