I have a Leviton DZ6HD dimmer that decided it wanted to crash and leave my Z-Wave mesh unexpectedly. Since I was unable to exclude the device, I force-removed it from Hubitat. As one might expect, things broke after that. The device no longer showed up in Hubitat's Zwave list, so I got a UZB stick and installed PC-Controller to see if I could find anytihng. The software shows exactly the same devices as currently installed. I don't see any extra devices besides what is actually installed on my network, yet almost all Z-Wave devices within the vicinity of the dead Leviton dimmer are struggling regularly - not responding, not updating status, responding very slowly, etc. What is my next step in troubleshooting?
Not sure what options you have on the C5? If you have a way to run a repair on a single device you could do it on the problematic devices. You could also try a full repair.
Other than that you just may need to wait a bit. How long has it been since you removed the zwave node?
The C-5 seems to have very limited z-wave tools. I can only repair the whole network, not individual devices. I have tried doing a repair a couple of times but no help so far. I have also tried using the "Update Neighbors" option for effected devices individually from within the PC Controller UI using a USB Z-wave controller, but that hasn't seemed to help much.
I want to say it's been about 3 weeks. I have since added a new device (another Aeotec Tri-sensor) in that area and it seems like the problem is starting to spread to more devices rather than slowly rectify itself...
Do you have any power metering devices or high traffic sensors that were in that area and possibly routing through the removed plug module? Try turning off or adjusting the reporting so it is less frequent. Can also just pull the battery, removing a battery device should not hurt anything since nothing will route through them.
I have 2 battery powered sensors in the area, and over time since the Leviton dimmer crashed both are starting to function less reliably than they had in the past. Once is an Aeotec Trisensor, the other is an Aeotec Multisensor 6. Both of them I have attempted to repair individually from the PC Controller software by hitting "Update Neighbors" and then hitting the wake up button on the two sensors.
I can try removing the batteries from them for a night and see if anything improves, but since nothing else routes through them I guess I don't see how that might help.. ?
It will reduce overall traffic greatly. I have seen other people having issues with some of the Aeotech sensors going bonkers and spamming zwave traffic, which will bring the mesh to a halt. This could be what is going on so disconnecting them for a day would be an easy way to test it.
Seems a drastic solution as several automations rely on data from these sensors, but I could probably take em out for 48 hours or so if that's absolutely necessary, but it seems like there should be less invasive solutions..
You should see improvement relatively quickly if they are the problem. Should not need 48 hours.
Only other way to try and find that sort of a problem would be to setup a zniffer.
You could maybe watch the zwave logs (does C5 even have that?) and find something. I think its only outbound messages so inbound duplicate and ignored messages may not be visible.
You could also try turning on debug logging for the suspected devices. They may or may not log every incoming message so seeing nothing does not always mean there is nothing.
I am one of these folks. I had two MS6s and one of them went insane and caused all sort of issues. I have since replaced them with a NYCE zigbee sensor.
I determined the MS6's were the issue because I have a Zniffer Zwave stick and was monitoring my network and saw constant spamming from these devices. Useful tool if you have the means:
In the meantime, if what I think I did is what I actually did, I think I manually pushed new primary routes to the wonky devices with the ZWave stick and PC Controller so that their first path of communication is to a nearby stable device. I will see if there is any improvement.
Usually the automatic routing is pretty good though even if you take a device out of the picture. I am still suspecting a spammy devices is what is causing the issues especially since it has persisted for 3 weeks.
No, but I'm reading it now. I was just blindly poking around SiLabs PC Controller where I found the "Set route" menu, which seems to allow you to manually input routes and primary routes.
For what it's worth, my poking around with routes has not fixed anything.
Yeah the trouble does roughly correlate to around the time the Aeotec Multisensor 6 was installed on my patio.. that's a huge bummer though as this sensor provides good info
The hub also seems to be missing triggers occasionally in RM, and I've heard general slowdowns are also possible when there's a spammy devices being naughty.
If you change the driver on that device temporarily to the generic "Device" driver it will log every single incoming message. Could be another way to check.
So far I have pulled the batteries on the Multisensor 6 and the results are promising but not yet conclusive.
A question remains if the sensor IS the cause of the problems.... would it be possible to pair the multisensor 6 to a zwave usb stick, and then share the device with Hubitat by joining the stick to Hubitat? I'm going to be kinda bummed if the sensor just cannot be used reliably, I think its a pretty subtle package for all the different sensors it contains.
If it has options to fine tune the reporting, you may be able to just adjust the settings on it. I would have to look up the specs on it to see what it has for settings.
Well, I turned off the Multisensor 6 (installed around a month ago) and so far the issues have not resolved. For fun, last night I also disabled my Aeotec Trisensor in my carport. No help. Still having problems.
I'm starting to think now that this may not be Z-Wave related, as I've started to notice a lot of other "triggers" being missed in Rule Machine. For example, the rules that have been working flawlessly for over 2 years that control presence detection are suddenly not working reliably. The presence is being detected, but the rules that use that presence as a trigger are only being triggered about 50% of the time all of the sudden...
There are other examples. Another rule that is supposed to be triggered by the door being manually locked at night is also not reliably being triggered.
What I thought was Z-Wave network slowdown and instability might actually be more broad slowdown and instability... but I have no idea what would have caused this to start happening...
Any suggestions? Logs all seem normal, I don't seem to have anything with excessive CPU time or load. No warnings of high load or low memory...
Have you tried downloading a backup and then restoring it right away? This will clean out any possible corruption in the database. This is the same result as doing a soft reset and restoring a backup.
Have you change the power source on the hub at all?
Wifi/LAN Integrations at all? Make sure they are all connecting and that device IPs have not changed at all causing repeated connection attempts.
No not yet, I will give that a shot now just to be sure.
Negative. The hub has not lost power for any reason. It's on a UPS backup so even if power fails I should get notified and have at least several hours to perform a safe shutdown.
I do have several LAN integrations, but haven't noticed any problems with those. I'll start looking into that, but there are several:
Just before I did this, I noticed in logs that some devices were showing up with "old" names... I recently renamed a bunch of rules and devices to give everything a bit more consistency. After doing a backup and restore, it appears everything now has been updated to the current name in logs.
Stability seems... Improved? I dunno, hard to say, might just be placebo. Will update tomorrow afternoon..
That's actually normal, the logs use the first name for a given app.device it finds, which is often old. Not sure why it does not use the newest instead, that would be logical. If you do a reset/restore and use the "clear logs" option it fixes it.
