[SOLVED] ZWave binding not working since openhab2-2.4.0-snapshot

I have switched to openhab2-snapshot (fresh install). Since then the zwave binding cannot initialize my Aeon ZwaveStick GEN5. On openhab2-2.3.0 i have no problem.

OH2 Version: 2.4.0-snapshot-amd64-debian (docker)
Binding Version:

Inside container:
crw-rw-rw-. 1 root 249 166, 0 Nov 17 15:19 /dev/ttyACM0

Are you seeing any errors in the logs? Can you post a debug log of the binding startup?

Did you follow the upgrade information -:

Ok, so I took a look at the log you posted in the zwave repo…

2018-11-17 14:30:17.864 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Initializing ZWave serial controller.
2018-11-17 14:30:17.866 [DEBUG] [zwave.handler.ZWaveControllerHandler] - Initializing ZWave Controller zwave:serial_zstick:512.
2018-11-17 14:30:17.867 [DEBUG] [zwave.handler.ZWaveControllerHandler] - No network key set by user - using secure random value.
2018-11-17 14:30:22.861 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'zwave:serial_zstick:512' takes more than 5000ms.

This is a little strange. The controller handler decides to generate a network key. Five seconds later, the framework complains about the handler initialization taking more than 5 seconds. :confused:

This is a bit of a stretch, but I’m curious what kind of hardware you’re running. SecureRandom.getInstanceStrong() can be very slow on some platforms. It’s not out of the question that it could take more than 5 seconds.

@chris I don’t see anything else in ZWaveControllerHandler.initialize that could cause it to take more than 5 seconds to complete. WDYT?

I’m not sure - I’ve never benchmarked this - I would be a little surprised if it was taking 5 seconds, although if there are a lot of other threads also happening at the same time during startup, then maybe it’s possible.

If it was that though, then starting the binding after system init might help.

What hardware is this running on?

It’s more an issue of /dev/random blocking until there’s sufficient entropy is built up to generate the secure key.

@hardoverflow You could easily prove or disprove this by checking for the existence of the zwave network key.

In HABmin, go to the Z-Wave Serial Controller thing. Select Tools->Show Advanced Settings, then select the Network Settings panel.

What do you see in the Network Security Key field? Is it blank? If it’s not blank, please DO NOT post the actual value here.

See https://stackoverflow.com/questions/4819359/dev-random-extremely-slow

I’m pretty sure SecureRandom.getInstanceStrong() uses /dev/random.

Then again, I could be completely off base on this. Occam’s Razor says the cause is probably something much simpler. LOL

That is the DEBUG log of the zwave binding.

log:set DEBUG org.openhab.binding.zwave

My hardware: APU1D4
Linux xyz 4.14.78-coreos #1 SMP Mon Nov 5 17:42:07 UTC 2018 x86_64 AMD G-T40E Processor AuthenticAMD GNU/Linux

openhab2 running on docker:

What about this?

I resolved this issue. Yes, the “Network Security Key” was empty. I don’t know why!

Thanks @all

Quoting Vincent :slight_smile:

@hardoverflow How did you resolve it?

@chris The fact that the key was empty suggests pretty strongly that the call to SecureRandom.getInstanceStrong() did take longer than 5 seconds. Otherwise, had the call returned, it would’ve been saved in the config. Right?

I don’t think there’s anything to do about this now, as this is the only report there’s been on the handler initialization taking too long.

Yes - I agree with this and also that it’s just something to keep in mind for now…

I’ve seen more references to this problem so opening an issue -:

@mhilbush thanks for testing and researching this issue, I suspect you are 100% correct in blaming SecureRandom.getInstanceStrong().

I suspect the 5+ second time will only occur on systems which 1) do not have a built in hardware RNG (IIRC the ras pi even has this now) OR 2) those which are virtualized in such a manner that that the underlying hardware RNG cannot be accessed properly for whatever reason (not implemented by the container, bug, etc).

@hardoverflow I have implemented a possible fix but I am unable to reproduce this behavior on my machines here. Would be able to test out this build to see if it resolves the issue?

Thanks everyone for tracking this down and the details provided.

1 Like

I will test it in the next few days @dbadia.


i installed your build. It actually didn’t fix my issue but installing haveged and starting it fixed the problem. But now everything is reacting very slow like 1 to 2 seconds.
I’am running a Intel NUC on Debian 9 with Openhab 2.4.0 M6.

sudo apt install haveged -y
sudo systemctl enable haveged
sudo systemctl start haveged

Kind regards,

I have the same problem. The z-wave stick will not initialize since upgrading to 2.4.

Is there a solution for this? Otherwise, how do I downgrade? It seems that selecting Openhab Stable from openhabian-config does not work…

You could try entering a security key into HABmin manually if it is blank in the serial controller thing config.