ZWave Controller Offline After Reboot

Setup, Configuration and Use Beginners
,
#9

Thanks @Burzin_Sumariwalla for sharing your solution, I’m sure others will find this helpful.
Click the square box on your post to mark as solved.

Thanks again

#10

Hi, where and how did find these both services: zbw_connect and z-way-server?

#11

I think I found reference to them in the Z Wave.ME documentation (which is awful). As for finding the service on Linux, try

ps -ef | grep -i zbw_connect
ps -ef | grep -i z-way-server

Regards,
Burzin

#12

Thanks, I cannot find either of them, so in my case it must be something else. I’ve already spent hours on this issue and cannot get it done… I installed Z-Wave binding 2.4.0 via OH2/PaperUI, I configured UDEV and symlinks and this part works fine, i cannot figure out why after reboot Z-wave controller cannot connect and it is required to press soft-restart to get it back online.

Does anyone have any other hints perhaps? Where to look for.
I installed the OH2 on Linux Ubuntu 18.4 LTS via the automatic setup. I tried to clear the tmp and cache folders and it did the trick but only for the first restart, subsequent restarts gave negative outcome.

#13

I have the same issue. Did you discover anything?
My problem started after moving to the 2.4.0 SNAPSHOT build.

#14

Unsure if I solved the issue permanently, however after reinstalling OH2 via OpenHABIAN last two reboots were successful, meaning Zwave controller got attached properly.

#15

Yikes. Hoping to avoid having to do a full re-install. Are you on the snapshot, or the stable release?

#16

stable release

#17

I am experiencing this issue as well with 2.5.0 as of 20190709

openhab> bundle:list | grep -i wave
187 │ Active   │  80 │ 2.5.0.201907090433     │ openHAB Add-ons :: Bundles :: ZWave Binding

I have to

bundle:stop 187
bundle:start 187

to get it working. As far as I remember this is a known ESH issue: The serial code is loading too late.

I could workaround this by doing something like

mv /usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar /usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar.tmp
sleep 5
mv /usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar.tmp /usr/share/openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar

Pretty much brute force - does anybody has a more elegant solution?

#18

I found a more elegant solution now. Create a script called restartZwave.sh:

#!/bin/sh

OPENHABBIN=/usr/share/openhab2/runtime/bin/client

bid=`echo "bundle:list --no-format" | $OPENHABBIN | grep ZWave | cut -f 1`
echo "bundle:stop $bid \nbundle:start $bid " | $OPENHABBIN

This script will find the zwave bundle id and restart zwave.
Create the following rule:

rule "rgconf_1"
when Item viTimeEvent_System_Starting changed to OFF 
then
    // uncomment to reload jsr 223 scripts
    //executeCommandLine("/bin/sh@@-c@@/usr/bin/touch /etc/openhab2/automation/jsr223/*", 1000)
    //Thread.sleep(1000);
    executeCommandLine("/home/openhabian/restartZwave.sh")
end

viTimeEvent_System_Starting is a switch item which is set to ON at system start and 5 minutes later is switched to OFF. I use this to inhibit certain actions while the system is starting up.

#19

This issue was solved for me with the Milestone build (starting at snapshot #1656)

#20

I am a bit lost now. I can only locate a zwave binding build “#730” as of today. Is there somewhere a mapping between snapshot number and build number?

And what is your output of “bundle:list | grep -i wave”

#21

That is just a sequentiel build number. I am talking about the snapshot version number.

#22

https://ci.openhab.org/job/openHAB-Distribution/

#23

Ok, thanks a lot.
For that I would have to update my complete installation to 2.5. There are jsr223 changes from 2.4 -> 2.5 and currently I just don’t have the time for such an upgrade.
Basically it means that on 2.4 stable with a 2.5 zwave binding the workaround as shown above is still needed.

#24

Yes, when I remember correctly that change was made to the core.

#25

Which changes are you referring to? The helper libraries are backwards compatible with 2.4, except for a couple function name changes.

#26

There has been a major rewrite of the javascript/python helper libraries. I am sitting on a couple of thousand lines of javascript code. Basically a much extended Hue binding implementation in javascript supporting RGBW colormixing (i.e. combining RGB and White led strips) to interface hue with the zwave light switch actors.
I have to upgrade the helper libraries from 2.4 to 2.5, change a ton of includes and by try-and-error have to derive the changes and adapt the code. With a family, a handicapped family-member and a demanding job I need to find some quality time for such an exercise. I expect roughly 16 hours for that exercise. Add to that that there might be other changes to other bindings from 2.4 to 2.5 which add to the resource usage.
I really like OpenHab. But it is currently a system for nerds with no other hobbies or worries - if you like to follow the development. This is due to the topic - home automation outside the knx universe has years to go before a standard will evolve. Understood. But there are times when I just want a working homeautomation and some rest without drama because dad’s working on the home-automation and the lights aren’t working.

#27

Yes… I am very aware of it :wink:! I’ve done everything I could to maintain backwards compatibility, which is why I was interested in hearing what your hesitation was in upgrading.

Since being added, the functionality of the JS libraries is still being brought up to the level of the Jython libraries, but they should still be backwards compatible… so just new features added. Maybe you are referring to the changes that were made to the JS library names and directory structure when they were brought into the helper library repo.

As for breaking changes in automation between 2.4 and 2.5, nothing comes to mind other than the package name changes made in OH core for the ESH reintegration. There will be more of these in the OH3 release. You may need to account for these in your scripts, but the libraries are written in a way to work with either the old or new package names. The Jython libraries only had some name changes to a couple functions that occurred since 2.4.

That is harsh, quite offensive, and very inaccurate… so good luck to you!

2 Likes
#28

Please accept my excuses for how the feedback resonated with you. I wanted to give an open and undisturbed feedback. Homeautomation is a nerd hobby if you aren’t rich and can afford to spend €30k to €50k for a typical installation - that is what companies in my area quote. And this is only for newly build homes and appartments. Consequently OpenHab is a nerd hobby as well. Same applies to Fibaro, Vera and the others if you get into scripting. Not to talk about hardware integration. I for myself took an educated decision to use OpenHab. And I really like it. But upgrading has been an issue in the past and installation is another topic. Security is non-existent in the whole home-automation universe. Even Philips doesn’t get it right - Here’s my post on how to secure the Hue hub using nginx.
Would I recommend home automation currently to my family, friends or colleagues?. I am working in the insurance industry as an actuary in non IT environment. The answer is no since nobody would be willing to invest into the necessary learning curve.