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.
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).
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.
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.
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.
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.
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?
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.
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:
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
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
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?
