Why I went back has many reasons. There will soon be a new topic that is likely to cause a huge stir.
Here are the results of my testing:
Today I’ve tested: Snapshot #1731, with a downgraded z-wave binding #1486:
279 │ Active │ 80 │ 2.5.0.201901020757 │ ZWave Binding
Heal was running completly for: node9, node10, but it took 2 wakeup intervals!
node9:
node10:
.
node8: It was a failure while “assigning return route”, but heal was done.
.
.
I’ve triggered a further heal, this will be complete in about 15 min. I’ll report it…
node9 and node10 were healed again!
node8: same result, failure while “assigning return route”, but heal was done.
.
What does this mean?
1 Like
Alex, this is a brand new snapshot OpenHAB version with an old zwave binding from Jan 19 correct?
Yes, of course. See 3-4 posts above. Scott requested this testing! And you also found this a good idea.
1 Like
Next testing:
“zwave binding 1731” with snapshot 1486:
Unfortunately binding is not installing due to dependency errors:
11:16:41.874 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/C:/Openhab2/addons/org.openhab.binding.zwave-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [378]
Unresolved requirement: Import-Package: com.thoughtworks.xstream; version="[1.4.0,2.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
OK.I stopped my testing.
Now I’m running Snapshot 1731 with “zwave binding 1486” again. I will observe if this is running stable and reliable.
2 Likes
Hello folks,
today I’ve tested the other way around: Snapshot 1486 with “Z-Wave Binding 1731” only.
Here are the results: automatic network heal does NOT work.
node8:
node9:
node10:
.
.
SUMMARY:
Network heal with Snapshot 1731 and z-wave binding (1731) is NOT RUNNING.
Network heal with Snapshot 1731 and downgraded z-wave binding (1486) is RUNNING.
Network heal with Snapshot 1486 and upgraded z-wave binding (1731) is NOT RUNNING.
Conclusion:
There seems to be a problem in the z-wave binding or database.
My 3 devices are all: Fibaro FGMS001, Firmware 2.7, Type: 0800:1001
Maybe that’s the problem?
1 Like
I upgraded to Snapshot #1738 today (core and binding), deleted all things and re-added them (to pick up the full database export some time ago): all good, everything is working.
Same here, but just one with firmware version 2.6
This is what I did also, see here (but with 1731):
Also automatic nightly heal?
I can tell you tomorrow 
I am reading those threads with interest because I never had problems with nightly heals (coming now from #1665).
1 Like
No issues after the nightly heal.
1 Like
OK. Thanks for reporting. 
I’ve compared 1738 to 1731, only a few database changes…
Why is it running on your PC and not on mine?
You have Linux, me Windows, which JAVA version do you use?
There are a bunch of people having problems with nightly heal. Maybe I have a lucky mix of devices. I started with Zwave 5 years ago, so my devices mostly are already old.
I don’t think it has something to do with Java, but:
java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (Zulu 8.40.0.25-CA-linux64) (build 1.8.0_222-b10)
OpenJDK 64-Bit Server VM (Zulu 8.40.0.25-CA-linux64) (build 25.222-b10, mixed mode)
1 Like
I’ll try a new Java version.
Other question. Did you set any special settings with your FGMS001? e.g. Association or something else? Which controller are you using?
IIRC you have a zwave.me ZME_UZB1? In spring
of 2019 I’ve switched to “Aeon Z-Stick gen5”= ZW090-C (because it’s portable and has a backup tool for Windows).
I could see a difference:
You have set:
.
And I have, by default: (I didn’t change anything!)
.
Was this recommended somewhere?
.
And what did you set here?
For every zwave device you need to set the Controller update association group to your controller stick to get updates for your values in openHAB.
For the Lifeline group this is done by the binding automatically. But not for older devices.
After you have changed the setting a pending mark appears in HABmin, you need to wake the device (fast triple click the button right next to the battery until the LED glows blue) until the pending mark disappears. You probably need to wake the device several times.
Associations are also used to send state updates to the controller when the state of a device changes. For example, if you turn a light on, the device will let the controller know so that the state of the light is shown correctly within the user interface.
Same as yours.
.
I never had to set this, but I always got values in Openhab! That’s still the case.
Is this also needed for a network heal?
I have a red X in all devices…
.
This I also never had to set.