Once again I would like to ask for your kind assistance (if, of course, you have some time to spend) for a problem I have for weeks with one of my zwave sensors.
For information, my OpenHab2 system is running on a Raspberry Pi3.
My zwave installation consists in an aeotec z-stick, 2 aeotec range extenders 6, 2 fibaro motion sensors (FGMS-001) and 2 aeotec ZW100 multisensors. Everything is working correctly, except one ZW100 which refuses to connect to my Zwave installation (node is not communicating with controller).
Here is a map of my zwave installation.
Knowing that from zwave stick (2nd floor) to repeater 1 (node 4, 2nd floor), there is a wall and 4 meters), repeater 2(node 6) is on the 1st floor (+/- 3 m) and the “non working” multisensor is on the ground floor (+/- 4 m).
I initially connected the multisensor with the stick next to it but after I plugged the stick into the raspberry and waited 1 night, the sensor appeard in red and it is not in red for 3 days. I tried a repair, a synchronize network but without any success.
I still do not understand why the sensor does not try to connect to the nearest repeater (node 6)
Would somebody happen to have a forum/internet site to suggest me for my zwave issues as despite all my efforts I cannot find any solution to the multisensor problem.
For me this looks like the device was not discovered correctly / fully.
I would delete this device in PaperUI, reset it and let it discover close to the controller.
If you are using the multisenser with batteries I would connect it to power, a little mobile phone charger is fine.
Then take it to the final position and let it on power over the night.
Battery powered Z-Wave devices can be a challenge to get fully discovered initially. Try excluding the device. Then reset the device. I have found that some devices associate more fully after being reset.
I used HABmin to discover the device and frontail to monitor the logs.
After telling OH to add the device I pressed the button on the device regularly to keep it awake. When fully discovered there should be an xml file for the node in The Userdata zwave directory.
I use the ZW-100s exclusively powered via 5v, for these kinds of issues.
What is your zw100 node 13’s situation? battery or external power supply?
If battery operated- see if by powering it from an external power supply or power bank, and letting it heal over a day the situation changes.
…sometimes a speceific devices can also be faulty… tho i don’t want to jinx you.
Thanks a lot (all of you) for your answers and advices.
Node 13 (Multisensor) is external powered (just like node 11 which is working without any problem).
I will try to reset/exclude the device and try to associate it again; I already tried to delete (rubbish bin in Habmin) and re-discover but without any real success. The story is always the same, it seems to work as long as the sensor is closed to the controller but as soon as I move the sensor to its new location and wait one night, it disconnects and does no longer communicate with controller.
Note that you MUST include the device using the power source that you will operate from. If you do not do this, it will not work properly as the controller will not handle the device properly.
For example, if you include the device using a battery (to allow you to move it close to the controller) and then change to using 5v input, the controller will still think the device is a battery device. It will not use it for routing, and more importantly, it will assume that it is not a listening device, so will not attempt to communicate with it unless it sends out an “Im awake” message.
Yes, that is what I did, the sensor was connected to an external usb power (iphone charger) for the inclusion (near the controller) and then moved to its new place where it is still plugged to the same charger.
good, ok checking to see if it did create an xml file is more of a step to make sure the device is being discovered. Bruce knows a little more about this but it still may not be fully intialized even thou an xml file was created. I think he may be able to tell if it is fully intialized be looking at it. Post it up if you can
Thanks for your patience, I really appreciate ! But do not loose to much time with me, this is not tragic, I am just wondering why the other sensors are working and not this one …
Here is the file. network_e7b6f669__node_13.xml (28.0 KB)
Chris, is this because when the XML is created it references the power source and once created, it is not recreated again? therefore not discovering a change in power source?
No - this is nothing to do with the XML or the binding. As I said above, the CONTROLLER is the issue here. The controller downloads a bunch of information from the device when it is included into the network, and this information is static.
This is why (for example) the Qubino switches that have temperature sensors must be excluded and re-included if the temperature sensor is enabled/disabled as this core information about a device is not allowed to change while a device is in the network.
The XML in fact is updated regularly, and is certainly recreated during the life of the device. If this was something the binding had the capability to work around I would probably have done it a long time ago, but it’s not something I have any control over - sorry.
Some update … I moved the sensor to the 2nd floor (not far away from the controller) and left it alone for some hours and then moved it to its usual location; here is (after 2 nights) the new map.
Problem still present; I removed the sensor from the zwave network, waited one day, include it again (all the operations done near the controller); it was perfectly working near the controller but from the moment I moved it to its new location, it stopped working “node is not communicating with controller”.
I also tried to swap with the other multisensor but the problem is exactly the same.
It seems the location (ground floor) is too far away from the controller (2n floor) even if there is a repeater on the 2nd and the 1st floor.
Thanks anyway for your assistance and your patience with me.
