[SOLVED] Z-Wave unreliable in 2.5.0.M4

[mhilbush (Mark)]

@sihui

I quickly checked all my nodes: all associations are set correctly in HABmin, maybe the display bug was fixed.

I recall a PR for the binding that worked around the display issue in HABmin.

Edit: Here it is.

update handling of association

[Celaeno1 (Alex)]

@Celaeno1

If there is something other (e.g. lifeline) missing, I’ll let you know immediately.

.

I’ve checked all XML files again. It seems to be mixture of old and new binding.

I have 5 identical “Smoke Sensors” (same firmware/type) (=node3, 4, 5, 6, 7) and 3 identical “Motion Sensors” (same firmware/type) (=node 8, 9, 10).

But there are a lot of differences between the XML files. While node3, 4, 5, 7 have almost the same entries, in node6 the following is missing:

  <associationGroups class="concurrent-hash-map">
    <entry>
      <int>1</int>
      <associationGroup>
        <index>1</index>
        <maxNodes>0</maxNodes>
 !!       <name>Lifeline</name>
 !!       <profile1>0x0</profile1>
 !!       <profile2>0x1</profile2>
 !!       <commands>
 !!         <commandClass>COMMAND_CLASS_DEVICE_RESET_LOCALLY</commandClass>
 !!         <commandClass>COMMAND_CLASS_BATTERY</commandClass>
 !!         <commandClass>COMMAND_CLASS_ALARM</commandClass>
 !!         <commandClass>COMMAND_CLASS_SWITCH_BINARY</commandClass>
 !!         <commandClass>COMMAND_CLASS_SENSOR_BINARY</commandClass>
 !!       </commands>
 $       <associations>
 $         <associationMember>
 $           <node>1</node>
 $         </associationMember>
        </associations>
      </associationGroup>
    </entry>
    <entry>
      <int>2</int>
      <associationGroup>
        <index>2</index>
        <maxNodes>0</maxNodes>
 !!       <name>Smoke alarm action</name>
 !!       <profile1>0x71</profile1>
 !!       <profile2>0x1</profile2>
 !!       <commands>
 !!         <commandClass>COMMAND_CLASS_ALARM</commandClass>
 !!       </commands>
        <associations/>
      </associationGroup>
    </entry>
    <entry>
      <int>3</int>
      <associationGroup>
        <index>3</index>
        <maxNodes>0</maxNodes>
!!        <name>Smoke basic action</name>
!!        <profile1>0x71</profile1>
!!        <profile2>0x1</profile2>
!!        <commands>
!!          <commandClass>COMMAND_CLASS_BASIC</commandClass>
!!        </commands>
        <associations/>
      </associationGroup>
    </entry>
  </associationGroups>


<entry>
    <commandClass>COMMAND_CLASS_ASSOCIATION_GRP_INFO</commandClass>
    <COMMAND__CLASS__ASSOCIATION__GRP__INFO>
         <version>1</version>
         <instances>1</instances>
         <control>false</control>
         <versionSupported>1</versionSupported>
 !!        <autoSubscribeGroups>
 !!            <int>1</int>
 !!            <int>2</int>
         </autoSubscribeGroups>
     </COMMAND__CLASS__ASSOCIATION__GRP__INFO>
</entry>

   <entry>
    </entry>
 §    <commandClass>COMMAND_CLASS_SECURITY</commandClass>
 §    <COMMAND__CLASS__SECURITY>
 §       <version>1</version>
 §       <instances>1</instances>
 §       <control>false</control>
 §       <versionSupported>1</versionSupported>
 §    </COMMAND__CLASS__SECURITY>
 §   </entry>
 § <entry>

.
You can see the missing entries (node6) by the two exclamation marks → !!

And it was missing the “lifeline node” in node4 and 5: see → $

And in node3 was missing “COMMAND_CLASS_SECURITY”: see → §
.
.
Following is missing in node8 and node10:

<entry>
  <multilevelSensorType>DEW_POINT</multilevelSensorType>
  <multilevelSensor>
     <sensorType>DEW_POINT</sensorType>
     <initialised>false</initialised>
  </multilevelSensor>
</entry>

node9 contains above entry . DEW_POINT ?? How comes??
.
.

I then have done a “Reinitialise Device”. Now the entries are all the same for each “device group”.

Wonder why the entries were different. Have deleted the things many times with PaperUI or have reinitialised the nodes (many times).

Next step will be: testing “daily heal” again with “zwave binding 1731”, but now with correct initialised nodes…

To be continued.

[Celaeno1 (Alex)]

After reinitialising all devices again, network heal is still not running for node8, 9, 10. They are again marked as offline. See above. Or here.

It’s not urgent, but hopefully it will be solved in near future. Issues reported on github are still open:

#1178
#1195

[Celaeno1 (Alex)]

@chris

Apologies I’ve not had the chance to look at this as I’m completely overloaded with other work for the next couple of days and am then away from home until mid November so just don’t have time until then.

Hello @chris, I want to inquire politely, when there will be any progress? Thanks a lot.

[chris (Chris Jackson)]

Sorry - I’ve not had time to look at this due to other commitments with ZigBee. This should start to drop over over the next few weeks and I will try and look at this issue then.

[Svolli (Sven Mey)]

Hi,
I tried to upgrade to 2.5 und ran into the exact same problems.
What du you mean bei “removing the nodes”?
Removing and rediscovering them in PaperUI or exclude and re-include them on the stick?

If the second way is the solution? I have one or two included devices that no longer exist. How du I exlude those on my Aeon Stick?

Thanks in advance
Sven

[rrgeorge (Robert George)]

I had a node that was completely unresponsive. I had to reset the device and add it as a new node. Then, I removed the bad node through openHAB.

At this point, I have the daily heal disabled and it’s been running pretty stable for a while now.

[ottoson (frank v)]

For the communication to battery driven devices, I do have two genral questions, maybe somebody can help me with this!

I do also use the AEON Z Wave Stick Gen 5. The stick is working fine with all my “wired” devices but I always had problems with battery driven devices.

This means the Heimann Smoke detector (3x HS1SA-Z) and Neo Coolcam Door window sensor (2x NEOEDS01Z)

In case of Alarm (Test button) OH is receiving the alarm from all of my sensors but the battery information is most of the time missing!

1. It looks like I do have three differnet options to include the devices,

• Offline via the battery powered Z Wave Stick pressing the button on the stick

• Online with the software “Z-Wave PC controller 5”

• Online with the “Search for new devices” in PaperUI or HABMIN

=> Should OH work with all of this three solutions or do I have to use only OPENHAB?

I am asking this because in the Z-Wave PC Software, the node information looks differnet for all three methods and I am wondering, whether OPENHAB should be able to identfy the device in all three cases. (even on similar devices, I do get sometimes more or less parameters and so on…) In case I do the inclusion via the z wave software, OPENHAB is not able to identfy the device afterwards via “search for new devices”. In case I do use Openhab for inclusion, I have very limited information in “Z-Wave PC controller 5”

2. In Case I try to update from OH 2.4 => 2.5 my “idenditied” battery driven devices, are unknown in OH 2.5 again.

=> is this in general the case or is it a problem, that my battery driven devices may have never been inlcuded properly so far?

I hope anybody of you can help me with my questions!

[mstormi (Markus Storm)]

@ottoson

=> Should OH work with all of this three solutions or do I have to use only OPENHAB?

Inclusion will work all three ways, but you still have to create the proper zwave things config
so PaperUI or habmin are recommended as they take care of that for you.

@ottoson

In Case I try to update from OH 2.4 => 2.5 my “idenditied” battery driven devices, are unknown in OH 2.5 again.

Huh ? Upgrading shouldn’t modify the OH things and the device database in a newer OH is a superset of that in older OH versions so they should remain “identified” unless you choose to delete those things.

[ottoson (frank v)]

Dear Markus,

I am using paper UI for the things configuration, but if I have added the nodes before via Z-wave
software or via push button on the stick, then the z-Wave binding search is only delivering “unknown device” instead of the correct Heimann sensor.

The update I tried to do via complete new installation in a different folder, not to loose my old data, and then just adding z wave binding and search for the nodes, but also in this case the already identified sensors in OH 2.4 were found as unknown devices In OH 2.5 meaning somehow the same like above if I do not include the devices in OH directly but use external inclusion, in this case OH 2.4

[mstormi (Markus Storm)]

@ottoson

then the z-Wave binding search is only delivering “unknown device” instead of the correct Heimann sensor.

While running latest OH (2.5) ?
Then it will not have worked to do that with 2.4 and get the sensor properly identified.
Check if the sensor is in the zwave database and if not add it.

@ottoson

The update I tried to do via complete new installation in a different folder,

Not a good idea.
Use openhab-cli backup/restore to save/restore your config.

[Chrishab (Christian)]

The Heimann smoke sensors are tricky! Once you start the inclusion you constantly have to press the button on the device like every second to keep the sensor awake.

If that fails exclude again and start over. I already had my own “fun” with these devices…

[ilektron (Stephen Farnsworth)]

How did you identify the faulty node? How was it faulty? I’m running into this issue every night, and my network hasn’t completely healed in several days.

[mstormi (Markus Storm)]

@Chrishab

The Heimann smoke sensors are tricky!

Well just as with any battery sensors, you eventually have to wake them up a couple of times to complete initialization, but my Heiman now is recognized just fine.

[ilektron (Stephen Farnsworth)]

I’ve updated to the 2.5.1 snapshot linked in another thread and heal is still destroying my network causing me to have to restart my openHABIAN pi to bring all the nodes back online. You can see that my network needs to update the neighbors because the last 20 or so devices I’ve added haven’t correctly mapped their network. Heal doesn’t seem to be working on individual nodes, either.

[rockit4 (D)]

May I ask how? I have the same problem.

Solved: Got it removed after several attempts and this:

Remove a ghost Z-Wave Node from HABmin

Set as failed Wait 20-30 s. Remove from the controller Restart the Openhab server Find your device on the things list (it would have some kind of remark like “…Z-wave network…” < don’t remember exactly. Delete the thing. You made it

[robmac (R Macdonald)]

Firstly that map does not necessarily reflect your network’s routing. It is a list of neighbours reported during a neighbour update. I ignore it as it looks nice but is not massively useful. Zwave routing is a bit more complex.

If your network is bad you can try this…

If you have a windows machine or run openHab on a windows machine. Download PC programme from silicon labs.

Take the usb stick and put it in your windows machine with the machine in exactly the same place as you normally have your openhab machine.

Open settings

select the port and save

you can now manage your network outside of openHab

First backup NVM

Now go to

Now if you select Rediscovery your network will do a heal. When it is finished run a network health check. If good close down the program or look around and see what else you can do. If not this tool is good for sorting it out. Ping back if you have issues.

Take the usb out when you have finished and put it back in openHab machine and restart openHab. That little map thing will still be as useful as a chocolate teapot but if your nodes are all in range of each other and everything is working don’t worry. You can always look at the topology in PC programme.

Which is loaded from the nvm.

Enjoy

Robert

[higgers (Steve Higton)]

I’ve used this software before but I can’t find where I downloaded it to and I can’t seem to download it from Silicon Labs. Can anyone suggest where I can download it? Google isn’t helping at moment…

[higgers (Steve Higton)]

Problem solved! I had to agree to the SIlicon Labs terms and conditions first by downloading their SDK, this then gave my account the necessary privileges to download the PC Controller software.

Obvious… /s

[robmac (R Macdonald)]

Pleased you fixed it.

Remember that unless you have issues with heal in openHab it is a lot of hassle so I am not saying not to use heal in openHab. This is suggested as a workaround if it is not working.

It stopped working for me at around 120 physical devices but many things on a zwave network become interesting at that number of nodes.

I speculate it was at that point that the underlying traffic on the network from reports from devices clashed with the rate of the discover neighbours sent by openHab.

OR

Possibly also time it takes to rediscover neighbours goes up as the count of nodes goes up and it started to exceed the time openHab is set to consider too long.

Certainly started to see timeouts.

Anyway hope it works for you.