Openhabian + RPi4 + Zwave Gen5 falls offline on restart

[awald (Asher Waldfogel)]

I will run some more tests, but I don’t know that I’m seeing 100% recovery from OH restart. I guess I’d have to detect a cold boot and then restart OH a second time. Sounds like a recipe for an infinite reboot loop if I get the cold boot flag wrong.

Do you know if

sudo systemctl restart openhab.service

also restarts the JVM? I’ve been down this track before and nothing good happens when Java is supposed to talk to a physical port.

[apella12 (Bob Eckhoff)]

@awald

Do you know if

sudo systemctl restart openhab.service

also restarts the JVM? I’ve been down this track before and nothing good happens when Java is supposed to talk to a physical port.

I tend to focus on zwave issues I see in the forum as I have a modicum of experience on it and have studied the binding code a bit. I’ll ping the forum guru for a comment @rlkoshak He knows everything

[awald (Asher Waldfogel)]

I’m looking at the java code for the binding and I have a new theory to test.

It looks like the error is happening before the binding tries to open the serial port

[awald (Asher Waldfogel)]

I think this log shows what’s going on. I hard reset with the serial port configured as “/dev/zwave”.

Zwave did not come back ONLINE. I reconfigured first to “/dev/zwav” just to force the updater to run. Log shows ZwaveSerialHandler tried to start, but failed in getConfigDescription twice.

Then I set back to “/dev/zwave”. Same thing. Next to “/dev/ttyAC” and then back to “/dev/zwave”. Finally I set it to “/dev/ttyACM0” and this try succeeded. Not on the log, but I subsequently set it back to “/dev/zwave” and that also succeeded.

There might be a problem with serial support, but it looks like this problem is happening in the configuration subsystem.

What’s the best way to show all this to the developers and get their assessment?

2023-05-19 07:26:48.111 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
2023-05-19 07:26:48.175 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-05-19 07:26:48.176 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:3070fe8bd9.
==> /var/log/openhab/events.log <==
2023-05-19 07:26:48.166 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:3070fe8bd9' changed from UNINITIALIZED (HANDLER_MISSING_ERROR): Handler factory not found to INITIALIZING
2023-05-19 07:26:48.182 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zwave:serial_zstick:3070fe8bd9' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
==> /var/log/openhab/openhab.log <==
2023-05-19 07:27:30.980 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:27:45.622 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:27:45.640 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update received
2023-05-19 07:27:45.658 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_softreset to false (Boolean)
2023-05-19 07:27:45.661 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_networkkey to F7 22 FE A4 A9 8A 80 7C 65 FD 17 D6 47 1D C1 47 (String)
2023-05-19 07:27:45.663 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_inclusionmode to 0 (BigDecimal)
2023-05-19 07:27:45.665 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sisnode to 1 (BigDecimal)
2023-05-19 07:27:45.667 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_maxawakeperiod to 10 (BigDecimal)
2023-05-19 07:27:45.669 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sync to false (Boolean)
2023-05-19 07:27:45.672 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_master to true (Boolean)
2023-05-19 07:27:45.674 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored inclusion_mode to 2 (BigDecimal)
2023-05-19 07:27:45.676 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update port to /dev/zwav
2023-05-19 07:27:45.678 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_wakeupperiod to 3600 (BigDecimal)
2023-05-19 07:27:45.680 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_exclude to false (Boolean)
2023-05-19 07:27:45.682 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored heal_time to 2 (BigDecimal)
2023-05-19 07:27:45.684 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_inclusiontimeout to 30 (BigDecimal)
2023-05-19 07:27:45.686 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_hardreset to false (Boolean)
2023-05-19 07:27:45.754 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2023-05-19 07:27:45.757 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2023-05-19 07:27:45.759 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2023-05-19 07:27:45.760 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2023-05-19 07:27:45.762 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2023-05-19 07:27:45.766 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-05-19 07:27:45.767 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:3070fe8bd9.
2023-05-19 07:27:45.989 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:28:01.022 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:28:01.041 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update received
2023-05-19 07:28:01.062 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_softreset to false (Boolean)
2023-05-19 07:28:01.065 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_networkkey to F7 22 FE A4 A9 8A 80 7C 65 FD 17 D6 47 1D C1 47 (String)
2023-05-19 07:28:01.067 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_inclusionmode to 0 (BigDecimal)
2023-05-19 07:28:01.070 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sisnode to 1 (BigDecimal)
2023-05-19 07:28:01.072 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_maxawakeperiod to 10 (BigDecimal)
2023-05-19 07:28:01.075 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sync to false (Boolean)
2023-05-19 07:28:01.077 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_master to true (Boolean)
2023-05-19 07:28:01.080 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored inclusion_mode to 2 (BigDecimal)
2023-05-19 07:28:01.082 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update port to /dev/zwave
2023-05-19 07:28:01.085 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_wakeupperiod to 3600 (BigDecimal)
2023-05-19 07:28:01.087 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_exclude to false (Boolean)
2023-05-19 07:28:01.090 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored heal_time to 2 (BigDecimal)
2023-05-19 07:28:01.092 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_inclusiontimeout to 30 (BigDecimal)
2023-05-19 07:28:01.095 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_hardreset to false (Boolean)
2023-05-19 07:28:01.151 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2023-05-19 07:28:01.153 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2023-05-19 07:28:01.156 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2023-05-19 07:28:01.157 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2023-05-19 07:28:01.159 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2023-05-19 07:28:01.160 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-05-19 07:28:01.162 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:3070fe8bd9.
2023-05-19 07:28:01.320 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:28:32.312 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:28:32.328 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update received
2023-05-19 07:28:32.345 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_softreset to false (Boolean)
2023-05-19 07:28:32.347 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_networkkey to F7 22 FE A4 A9 8A 80 7C 65 FD 17 D6 47 1D C1 47 (String)
2023-05-19 07:28:32.349 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_inclusionmode to 0 (BigDecimal)
2023-05-19 07:28:32.351 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sisnode to 1 (BigDecimal)
2023-05-19 07:28:32.352 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_maxawakeperiod to 10 (BigDecimal)
2023-05-19 07:28:32.354 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sync to false (Boolean)
2023-05-19 07:28:32.356 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_master to true (Boolean)
2023-05-19 07:28:32.358 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored inclusion_mode to 2 (BigDecimal)
2023-05-19 07:28:32.360 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update port to /dev/ttyAC
2023-05-19 07:28:32.362 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_wakeupperiod to 3600 (BigDecimal)
2023-05-19 07:28:32.363 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_exclude to false (Boolean)
2023-05-19 07:28:32.365 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored heal_time to 2 (BigDecimal)
2023-05-19 07:28:32.367 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_inclusiontimeout to 30 (BigDecimal)
2023-05-19 07:28:32.369 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_hardreset to false (Boolean)
2023-05-19 07:28:32.431 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2023-05-19 07:28:32.433 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2023-05-19 07:28:32.436 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2023-05-19 07:28:32.437 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2023-05-19 07:28:32.438 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2023-05-19 07:28:32.440 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-05-19 07:28:32.442 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:3070fe8bd9.
2023-05-19 07:28:32.564 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:28:44.336 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:28:44.360 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update received
2023-05-19 07:28:44.386 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_softreset to false (Boolean)
2023-05-19 07:28:44.389 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_networkkey to F7 22 FE A4 A9 8A 80 7C 65 FD 17 D6 47 1D C1 47 (String)
2023-05-19 07:28:44.391 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_inclusionmode to 0 (BigDecimal)
2023-05-19 07:28:44.393 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sisnode to 1 (BigDecimal)
2023-05-19 07:28:44.394 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_maxawakeperiod to 10 (BigDecimal)
2023-05-19 07:28:44.396 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sync to false (Boolean)
2023-05-19 07:28:44.398 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_master to true (Boolean)
2023-05-19 07:28:44.400 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored inclusion_mode to 2 (BigDecimal)
2023-05-19 07:28:44.402 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update port to /dev/zwave
2023-05-19 07:28:44.403 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_wakeupperiod to 3600 (BigDecimal)
2023-05-19 07:28:44.405 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_exclude to false (Boolean)
2023-05-19 07:28:44.407 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored heal_time to 2 (BigDecimal)
2023-05-19 07:28:44.409 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_inclusiontimeout to 30 (BigDecimal)
2023-05-19 07:28:44.411 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_hardreset to false (Boolean)
2023-05-19 07:28:44.473 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2023-05-19 07:28:44.475 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2023-05-19 07:28:44.476 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2023-05-19 07:28:44.478 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2023-05-19 07:28:44.480 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2023-05-19 07:28:44.482 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-05-19 07:28:44.484 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:3070fe8bd9.
2023-05-19 07:28:44.640 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:29:03.324 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:29:03.346 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update received
2023-05-19 07:29:03.369 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_softreset to false (Boolean)
2023-05-19 07:29:03.371 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_networkkey to F7 22 FE A4 A9 8A 80 7C 65 FD 17 D6 47 1D C1 47 (String)
2023-05-19 07:29:03.374 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored security_inclusionmode to 0 (BigDecimal)
2023-05-19 07:29:03.377 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sisnode to 1 (BigDecimal)
2023-05-19 07:29:03.379 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_maxawakeperiod to 10 (BigDecimal)
2023-05-19 07:29:03.382 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_sync to false (Boolean)
2023-05-19 07:29:03.384 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_master to true (Boolean)
2023-05-19 07:29:03.387 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored inclusion_mode to 2 (BigDecimal)
2023-05-19 07:29:03.389 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update port to /dev/ttyACM0
2023-05-19 07:29:03.390 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_wakeupperiod to 3600 (BigDecimal)
2023-05-19 07:29:03.391 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_exclude to false (Boolean)
2023-05-19 07:29:03.393 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored heal_time to 2 (BigDecimal)
2023-05-19 07:29:03.394 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_inclusiontimeout to 30 (BigDecimal)
2023-05-19 07:29:03.395 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Controller Configuration update ignored controller_hardreset to false (Boolean)
2023-05-19 07:29:03.450 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing receive thread
2023-05-19 07:29:03.451 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Receive thread dispose
2023-05-19 07:29:03.453 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Disposing serial connection
2023-05-19 07:29:03.454 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial connection disposed
2023-05-19 07:29:03.456 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2023-05-19 07:29:03.457 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2023-05-19 07:29:03.459 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:3070fe8bd9.
2023-05-19 07:29:03.580 [DEBUG] [g.zwave.internal.ZWaveConfigProvider] - No bridgeUID found in getConfigDescription thing:zwave:serial_zstick:3070fe8bd9
2023-05-19 07:29:08.475 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2023-05-19 07:29:08.506 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Starting receive thread
2023-05-19 07:29:08.515 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Starting ZWave thread: Receive
2023-05-19 07:29:08.517 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2023-05-19 07:29:08.520 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initialising ZWave controller
2023-05-19 07:29:08.566 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller

[rlkoshak (Rich Koshak)]

@awald

The ZWave connection appears solid once it comes up. The problem is cold booting after a non-graceful shutdown. Pure speculation but stale file system lock? Timing issue on boot sequence? I don’t even know where to start looking.

If it’s a standard openHABian that means zram is enabled which puts the $OH_USERDATA folder into RAM. It’s only written to disk on a graceful shutdown of the zram daemon (or a system reboot). So it might be possible you’ve set up all these configs, pull the power and all your changes are gone.

@awald

After the couple days I spent testing USBIP I’m hesitant to try another remote USB approach. My main instance of OH is running under Docker (currently under WSL2 on a NUC) so I have to create the remote device before I start Docker and inject a port into a container. Docker gets really unhappy if you try to map a device that doesn’t exist.

It might be possible to implement the USBIP client inside the container to avoid that problem. I’ve never tried it but it would solve this particular problem. But this feels like an XY Problem and chasing a solution to the wrong problem.

@awald

I’m testing a port to HyperV. The reason I want to run on the NUC with Windows is my BACNet PLCs have a config app that is native Windows, and I’d like everything with climate automation on one server if possible. Also OH with Docker is fabulous! I can bring up a test version in just a few seconds without affecting production at all.

The last time I saw this looked at, WSL didn’t support hardware passthrough and neither did Docker for Windows. Has this changed?

@awald

The Pi is hanging on a DIN rail and not close to any screens. I guess I could add a switch to the Pi to command a graceful shutdown for service

Yanking the power even without zram on these machines is a bad idea. If the device happens to be actively writing to flash memory at the time power is lost you lose not only that one file, but any file that shares that sector. With wear leveling, that can be anything, parts of the kernel, file system tables, config files unrelated to OH, etc. You can end up with a corrupted system as a result.

Even with SDDs and HDDs, yanking the power without a graceful shutdown is a bad idea. So indeed, something to gracefully shutdown the machine is a must.

@awald

At first I thought the problem was with the stick or maybe the SD card, but now my best guess is the binding can’t recover from stale state when it restarts.

From what I understand, perhaps it is related to ZRAM. If what ZRAM wrote to disk is somehow off or has been corrupted from the lose of power, you are basically restoring that corruption to the ZRAM disk when you restart and any changes you made are being lost because you are yanking the power instead of gracefully shutting down.

I suspect corruption over stale state because, to my knowledge, the binding doesn’t really store any ephemeral state on disk. It’s all on RAM. But there are files it loads at startup from disk and if those are corrupted, recreating the Things would fix the problem.

I don’t think your problem is specific to Zwave. It’s a file system problem. It’s just the luck of the draw that you are seeing the problem on Zwave.

tl;dr: you can’t just yank the power from the RPi. If that’s a requirement for you, you need to find some other platform to host OH on. Hard resets are simply not supported on a machine running on flash memory and especially not supported on a machine running zram as you’ll lose everything.

You can’t get there from here. You’ll either need to figure out how to get the machine to safely shutdown or you’ll have to use a different platform.

[awald (Asher Waldfogel)]

Rich,

Understand your perspective but it’s impossible to guarantee a machine never hard resets. Whether it’s a power glitch or software hang, these things happen. You can make it rare - and I’m taking those steps. But sooner or later it happens. I’m tech support and really hate the support calls when something stops working. My experience with RPi is they are pretty robust on recovery and even on the SD card file system I can’t remember any of my Pis bricking from a hard reset.

If you look at the last log files I posted it appears that something strange may be happening with configuration, but it hasn’t affected any of the general site or user configuration information.

WSL does not support hardware pass through, which is what put me on the USBIP track in the first place. My testing did not give me much confidence in USBIP for production. Seemed great for dev and test where a human will notice and intervene when a connection hangs. Microsoft does not recommend WSL as a production platform and I concur. It’s not meant as a server. One of my to-dos is to switch from WSL to something different for production. I’m rapidly ruling out the Pi. The NUC looks good. I still have to evaluate native Linux / Docker vs Windows Docker running Linux containers.

I’m not 100% following what you’re saying about zram. Would I be better off mounting a USB drive and shutting off zram?

Just to back up, all I’m trying to do with the Pi is put the Zwave stick close to the controlled devices so I don’t have a distance or line-of-sight dependency between the main OH server and the thermostats. I’m open to any robust solution that recovers from power resets reliably. I initially thought a Zwave hub might work. Does OH have a binding to support Honeywell ZWave thermostats over a hub?

[rlkoshak (Rich Koshak)]

@awald

Whether it’s a power glitch or software hang, these things happen. You can make it rare - and I’m taking those steps. But sooner or later it happens.

Agreed but the way flash storage works, you are playing the odds as to whether or not you end up with a corrupted file system every time you yank the power. It’s just how the technology works and you can’t get around that.

@awald

My experience with RPi is they are pretty robust on recovery and even on the SD card file system I can’t remember any of my Pis bricking from a hard reset.

I’ve had it happen multiple times. YMMV but it’s a well known and documented limitation of the technology.

@awald

I’m not 100% following what you’re saying about zram. Would I be better off mounting a USB drive and shutting off zram?

The way zram works on openHABian is:

1. at boot the files on the physical disk are loaded into the ram disk
2. during running all changes to the files occur only in the ram disk
3. at proper shutdown, the current state of the files are written back to the physical disk

If you skip 3 by yanking the plug, you lose everything that happened in step 2. If there is something wrong with the files stored in step 1, you’ll get that bad stuff reloaded in step 2 even if you “fixed” it last time you booted. You lost the fix.

Note, this ZRAM configuration is actually a mitigation against file corruptions caused by loss of power. Those corruptions only occur if the RPi happens to be actively writing to disk when power is lost. Because the vast majority of writes in the openHABian ZRAM configuration occur to RAM, the chances the machine is actively writing to SD card is lower than it would be otherwise. It also mitigates SD card wear out.

The main point though is if you are not rebooting normally and yanking the power, you lose everything you did to the OH config since the last boot. So yes, if yanking the power is going to be part of your standard operating procedure instead of something that happens very rarely you need to turn off zram and switch to running off of an HDD (not USB thumb drive, maybe SSD if it has power loss protections which most do).

@awald

I’m open to any robust solution that recovers from power resets reliably.

I’m using a USB RJ45 adapter to connect my 3D printer to my desktop. They work quite well. That could give you up to 150’ to work with if you can run a cable (theoretically).

@awald

Does OH have a binding to support Honeywell ZWave thermostats over a hub?

Once you are dealing with a hub, openHAB doesn’t know or care if it’s Zwave. If OH supports the hub, it supports anything that hub can connect to.

[awald (Asher Waldfogel)]

Thanks for the explanation. The part that still confuses me is I’m not changing anything in the OH config. But if I’m reading the logs correctly (and from a quick look at the binding java code) it looks like OH may not be finding the string name of the Zwave serial port on a hard reset. That seems to be the root cause here, not broader FS corruption.

I agree with everything you’re saying but in 100 hard resets on my testbed my Pi has come up every time while the ZWave binding recovers 60% of the time. If it was up to me I’d suggest a developer to at least take a look at what’s going on. I looked at the java code and concluded it will take me at least a few weeks to get up to speed and build an environment to do anything with it and the problem is manifesting somewhere in the binding initialization sequence.

I’m not advocating hard reset as a daily procedure, but if it’s the sort of thing that happens once a year then I have to document and/or reverse engineer a fix under some duress. If I was a commercial integrator (which I’m not) I’d treat this behavior as a show-stopper. I went down the Zwave track rather than WiFi so I could control everything locally and not have a remote connectivity dependency.

I guess the next step is to explore moving most of the FS off the SD card. Perhaps leaving the boot image behind on a read-only card. All this complexity - UPS, external FS - is slightly undermining the Pi value proposition.

You’ve probably figured out I’m trying to wrapper OH so “regular” users will get the behavior they expect or a diagnostic I can interpret that helps me get the system running again quickly.

[rpwong (Russ)]

@awald

I agree with everything you’re saying but in 100 hard resets on my testbed my Pi has come up every time while the ZWave binding recovers 60% of the time.

I would guess that you’re pulling the power when nothing is being written to the SD card, in which case you’re not simulating the actual worst-case scenario that you want to avoid. Try moving some files around and then pulling the cable while the writes are in progress.

[rlkoshak (Rich Koshak)]

@awald

If it was up to me I’d suggest a developer to at least take a look at what’s going on.

You can. You can file an issue on GitHub. That’s how you get the developer to take a look. How to file an Issue

But, given no one else is reporting these same issues there has to be something unique about your particular setup that is either causing the problem or causing the problem to surface. It’s pretty hard to fix something that cannot be reproduced and the first set of suspects is going to be something related to the OS or a defect in the USB controller. The fact that is only occurs after pulling the power points to the OS.

As for the rest, openHAB is not and does not present itself as a commercial product. A Raspberry Pi (or other Single Board Computer) is not the only way to deploy openHAB and openHABian is not either. Be careful not to project too many requirements upon a system that was never intended to meet them. openHAB running on a RPi using openHABian, like any engineering problem, is an exercise in compromise between capability/reliability and ease of deployment. If those compromises don’t meet your needs, you have the option to choose a different approach.

[apella12 (Bob Eckhoff)]

@awald

If it was up to me I’d suggest a developer to at least take a look at what’s going on.

I’d suggest opening an issue on the zwave github with your debug logs. There is only one developer for both zwave and zigbee.

@awald

WSL does not support hardware pass through, which is what put me on the USBIP track in the first place.

Perhaps I do not understand hardware pass through, but I use OH on WSL when I want to test zwave code. I attach a zstick with
>usbipd wsl attach --busid 1-1

where busid 1-1 is the zstick identified with (in command prompt)

C:\Users\Robert>usbipd wsl list
BUSID  VID:PID    DEVICE                                                        STATE
1-1    0658:0200  UZB (COM12)                                                   Not attached
1-2    093a:2510  USB Input Device                                              Not attached
1-3    1c4f:0016  USB Input Device                                              Not attached
1-11   0658:0200  UZB (COM3)                                                    Not attached

1-11 is my zniffer

[awald (Asher Waldfogel)]

Thanks will open the issue.

Your usbipd command is connecting the usb device over IP (hence USBIP). You are typing a command to the server end on Windows (usbipd) that forwards a command to linux to initiate a USBIP connection. I am running the NUC on Win10 and had to rebuild the kernel to support usbip, but apparently it’s native in the Win11 version.

I found it was great for development, but if I left it running for a couple days the connection would fail or lose sync. My second try was to remote the usbipd to a Pi, but had the same issue with the client side. That’s how I got on this whole track of using the OH remote binding to communicate to the zstick.

[awald (Asher Waldfogel)]

The other hairball with WSL is I am running Docker under WSL. To pass the serial port into Docker it needs to exist before the docker run command, which I was automating with a Dockerfile. On reboot I had to get the usbipd running on windows after WSL started and before Docker started. Doable, but I hate those kind of dependencies for production.

[rlkoshak (Rich Koshak)]

@awald

The other hairball with WSL is I am running Docker under WSL

Since you are going through layer after layer of abstraction already anyway, why no run in a VM? VirtualBox is free, runs on Windows, and supports USB device passthrough.

Or you can just run OH natively on Windows. openHAB does not require Linux and can run on almost any OS that supports Java 11 (Java 17 for OH 4).

That would actually be a good test. Does the binding have any problems with the controller on Windows?

[awald (Asher Waldfogel)]

I’m testing how to deploy the main server. One important requirement is it restores automatically on a restart.

I really like the configuration management simplicity of docker. I have to spend some time to learn how to set up an OH docker container on Windows and that’s on the list of candidates. I have a testbed NUC to test a few configurations including WIndows docker running Linux images, Windows docker running a windows image and a Linux VM with docker. I’m assuming once this is running I won’t touch it very often so I want a software stack that’s pretty vanilla.

That doesn’t solve the zwave issue because I am trying to avoid a line-of-sight dependency between the OH main server and the zwave devices. On the PI I will try a USB drive and shutting down zram to see if that behaves any differently.

[rlkoshak (Rich Koshak)]

@awald

I have to spend some time to learn how to set up an OH docker container on Windows

It doesn’t support USB passthrough.

[awald (Asher Waldfogel)]

Removes Windows docker from the list

[Andrew_Rowe]

@awald

On the PI I will try … shutting down zram

yeah if yanking out the cord is a requirement, I’d not run zram. Zram kinda depends on cord not being yanked out

[awald (Asher Waldfogel)]

Digging a little deeper, I found the zwave binding leaves behind a file

/var/lock/LCK…ttyACM0

with some numbers. If I delete the file I can restart the binding.

Is there a way to script deleting all the lock files on OH startup?

[Wolfgang_S]

Have a look to this thread Aeotec Z-Wave Gen5+ Stick stays offline after container restart / Raspi reboot
A script that is example is posted there in

Aeotec Z-Wave Gen5+ Stick stays offline after container restart / Raspi reboot

I’ve had problems with my Aeotec Stick (recent model) under a docker environment as well. The main problem was a stale lock file, preventing the stick from getting accessible. And the poor man’s solution was adding an init file under /etc/cont-init.d/10_remove_zwave_lock: #!/bin/bash -ex ZWAVE_LOCK="/var/run/lock/LCK..zwave" if [ -f "$ZWAVE_LOCK" ]; then echo "Removing stale ZWave lock file $ZWAVE_LOCK..." rm -f ${ZWAVE_LOCK} fi Problem solved for me, the lock file is getting removed at…