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.
1 Like
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.
1 Like
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:
4 Likes
Ok cool I'll give this a shot.
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.
1 Like
I assume maybe you found and followed this info? I have some info on my results here: Reset zwave routes - #11 by jtp10181
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.
Example I just tested out:
1 Like
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.
1 Like
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:
- Kasa plugs
- Unifi Network Controller
- Broadlink RF
- Rachio
- Chromecast (beta)
- Google Home (built in)
- Google Home (community)
- Google SDM Nest Integration
- Gcal search
- Apple Homekit
This may have solved the problem.
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.
Still was having issues. I decided to try excluding the Multisensor 6 from Hubitat. I seems to have made improvement.
Disconnected Battery vs Excluded on a non-repeating sensor should logically not make any difference
Apparently it IS a routing device and I had it plugged in via USB for awhile....
Ah yes, I always forgot about that with some of these sensors. IF you included it while on USB power a lot of them will join as a repeater. If you then switch to battery it will stay as a repeater but work VERY badly because it will be going to sleep all the time.
So if this improves the situation you could try pairing it again while on battery power to ensure it joins as a non-repeater. The general recommendation is to do this even if you want to power it with USB, just because they are often not good repeaters anyway.
2 Likes
This problem is getting worse by the day. Every day, it seems like more Z-wave devices are acting funny, the Hub is starting to miss triggers and automations more often. If I hit a light switch, sometimes the light won't turn on for several seconds or even several minutes after I hit the switch. When the light does turn on or off, sometimes I get a blast of entries in the log that look like this:
There seems to be nothing wrong with any of my ethernet connected devices or apps in Hubitat, but I will start disabling some of my networked integrations to see if stability improves. But so far using the USB Zwave stick and PC-Controller hasn't shown me any reasons why my Zwave network is so messed up.
