And thank you all so far… It is very generous to help and I have learned a lot. I will come back to this after the Re interrogation and a healing has finished.
If you have any obvious suggestions I would take them with gratitude…
/O
Your screenshot shows that the device was found in the database, and the device ID you listed also matches (look for 0x0200:0x0107 in the screenshot), well the bottom 221 at least. So you don’t need to edit any files.
Likely at least one of your problems is related to this:
How many devices did you include in this manner, just that one or more? This technique is highly discouraged. What has happened is that your controller has invalid routes to the device and it can no longer talk to it. If you check the driver debug logs, you’ll probably see a lot of communication errors.
Also, check the general troubleshooting docs. Number one tip is to make sure you have a USB extension cord installed.
1 Like
So I will have to a extensive Heal. My system is installed in a NUC so it is possible to move the NUC close to the devices and then include them the normal way. My house is to big for a USB extension cord.
So what do you suggest to do? To use the global heal function…?
Can you point me in the direction of the driver debug logs?
The point of the extension cord is to reduce interference from your other electronics, especially USB ports. You only need a short one. It should be installed permanently.
So what do you suggest to do? To use the global heal function…?
All I can say is try what the issue says.
Can you point me in the direction of the driver debug logs?
I posted the link. See above.
I have a extension cord installed already
Under DEBUG in the zwave UI I get a lot of these : Error: connect ECONNREFUSED 192.168.111.77:1883
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16)
2022-05-23 23:36:31.205 INFO MQTT: MQTT client closed
2022-05-23 23:36:32.206 INFO MQTT: MQTT client reconnecting
2022-05-23 23:36:32.209 ERROR MQTT: Mqtt client error connect ECONNREFUSED 192.168.111.77:1883
Thanx I found the logs and longing was turned on but just for info so i turned it to silly…
I have to play with this its a lot to take in…
Again THANK YOU VERY MUCH for your patience
Turn off your MQTT client, it shouldn’t be on if you aren’t using it. Then, you want to focus on ZWAVE, not APP or MQTT.
1 Like
My two cents is to avoid the global heal. For me it makes a mess of everything, and was discussed here that it just doesn’t work well - 70 Zwave device network stuck healing for over 24hrs - #20 by HeyImAlex
Instead I heal individual devices that are slow or have routing problems/log issues, and possibly the ones physically around them. That seems to work well. Also, make sure any battery device you heal is awake.
Most of my nodes has been restored and the MQTT issue was the main reason for the problems it seems. As soon as I turned it off things started to improve fast… Thx Petro
I still have some nodes with problems but I have not had the time to look into it but will… Starting with looking into the log…
Hi I did look into these references… What I do not understand is how I will be able to include new devices that are located far from the controller. Do they communicate through the established zwave network?
I did test with a sensor located at the far side of the house, was not able to include it…
Zwave is a “mesh” network, which means another device can relay messages from a device further away, the key being it must be a mains powered device. For power conserving reasons, battery powered devices cannot act as a repeater (although they can use a mains powered repeater nearby). To build a strong mesh, you should include mains powered devices closest to the hub/zstick first, and then work your way out.
Here is an in depth explanation of how it all works
Hi Tim
I am familiar with the network topology as I have worked with field-bus, can bus etc and they are similar. What that Vestnet article does not discuss is the protocols employed for communication in and between the network layers… So how is a request for inclusion handled from the main controller until it finds the object for inclusion…
Does this communication also adopt the Mesh routing principles such that it will use the forwarding capability of the mesh…for the actual inclusion process???
Have you yourself experience in adding zwave nodes that is outside direct reach om the main controller?
Well I guess its just to try out and I will use another device this time…
I know you have participated in discussion on the healing process in HASS and in those threads I did understand that the NetWork graph is of little value… Do you know if it is possible to see the zwave routing table in HASS?
The feature you are asking about is called “Network Wide Inclusion” (NWI). This is a Z-Wave Plus technology addition which means not every device or controller supports it, 500 series chipset at least. You need to have both for it to work. If your equipment can’t support NWI, then you must include your node near the controller and move the device to the final location with a network heal. If the final location is particularly far from the controller, you may have to move/heal incrementally in steps.
This is just the nature of Z-Wave.
1 Like
Yes I have- my devices in my detached garage are no where near the computer with the zstick and route through other devices on their way. As pointed out by mterry, they are 500 series “zwave+” chips though.
Older devices, particularly older S0 locks that use “whisper pairing”, require direct placement next to the zstick/hub to initially exchange security keys.
Not that I’m aware of. Zwavejs2mqtt has a network neighbor graph but it is not the same thing as a routing table. The routing table is stored in the zstick though, and if you really want to see it you can temporarily remove the zstick from the Home Assistant machine and use the silicon labs pc controller software. The program is advanced and not user friendly but if you want to check it out:
Directions:
Here’s another article on it - I personally try avoiding messing around with the PC controller software. It can really mess things up if not used properly.
Yes I have devices that are many years old and I will replace them as trouble increase, but is to bad to through away devices that most of the time is working ok, but this kind of trouble I would like to avoid.
I will have a look at it … It would be helpful to know which nodes are used for repeating so that these nodes are Zwave Plus with the necessary chip so they support MWI … I see now that my network is back to normal except two both older and both Fibaro nodes: Dimmer and Switch
This SW requires Windows, IOS or Ubuntu as it has to be installed through Simplicity Studio. My installation is on a X64 based machine running as a VM under Proxmox Virtual Machine Server. This choice was mad in order to get USB passthough from the VM. I could of course have installed HASS on “bare metal” but then loosing out of the snapshot possibilities etc.
I guess i could install another VM running Ubuntu and then install on that but the how will it interact on the HASS VM… This would probably be a uphill struggle…
You do not have to change anything with your current installation. Just install the si labs software on another machine, unplug the usb stick from the home assistant machine temporarily, put it in the machine running the pc controller software temporarily, then put the stick back in the home assistant machine when you are done
The zwave network and routing are stored on the usb
Just because in reading this it doesn’t seem to have been explicit…
you can pair your device right next to the controller and then move it to it’s final destination and things should still work fine as long as there is a route back to the controller thru other mesh devices. I do it all the time with no issues.
Worst case is that you might have to heal the network after relocation. But I don’t remember ever really needing to do so. It generally just works.
thx… this is exactly the topic… The discussion gives the impression that to use this method for inclusion is risky and can lead to significant problems… I think that just in very rare cases there will be NO route back… On the other hand as have been informed it should be possible to include devices with the Z-Wave Plus protocol employing the correct chip…
I think for expanding my network i will attempt to include it in its final place and when this is unsuccessful do it close to the controller and perform an update when its in its final location
Other updates were instaled during the last few days (and a new core is avialble today) and I have again lost a larhge partt of my network… I think I will start a new thread with a more appropriate topic…