I have 143 devices on a single hub and a zwave stick coming in the mail in a day or so. I'll take a look and see if my traffic looks like yours. Just looking at the sends and receives it just looks like it's passing traffic from 1 to 5, then 5 to 10, then 10 to 15, then 15 to 22. Then in reverse for response traffic. Do you have any devices reporting power or temp? Those like to flood the network and bring things to a crawl.
1 Like
I only have one switch that does this, and it only does it sometimes. It’s a GE on/off Z-Wave Plus switch and it’s also the only switch that I have that reports the “switch was turned on [digital]” and then the “switch is on [physical]”. All of my other switches are Zooz. It’s device 816 in the image. It’s always done it but it doesn’t do it every time. It responds instantly for on and off and I have a C5 hub also. It's the swirch for the light over my trash cans and doesn't get used very often. This log for after turning on the switch from a dsahboard.
So is this somewhat repeatable? What do debug logs show if you turn them on (temporarily) and it is doing this?
What driver are you using, and what model number is this switch?
Okay, so I pulled off the switch plate and it says it’s a GE ZW4005. Online it says that this isn’t Z-Wave Plus. As you can see by the screen shot of the clusters, it is. This is my oldest switch by far. The log, with debug on, starts with turning the switch off, and then on. If I pull the switch out, which I didn’t I might get more info from the back. I’m using the Generic Z-Wave Smart Switch driver which I believe was the drive picked by Hubitat when I paired it.
The "ZW" number is used on many models, so it isn't the best # to use as a reference. Some "ZW4005" are non-plus (the 12xxx GE moodel #s), and some are plus (the 14xxx GE model numbers).
Both models say "ZW4005" though.
You have to look at the back side of the switch to see the 'real' model #. As it is zwave plus (based on the clusters) it is certainly a 14xxx model #.
I wrote custom user drivers for those models, You could try it and see if it does anything different than the in-box driver (it really shouldn't in this case).
1 Like
That was going to be my next suggestion, your drivers work excellent, and I have been extremely happy with them.
Give them a try @nibyak, and see if that makes a difference. It would be nice to narrow this down to an app, driver, or something.
It is a switch (not a dimmer) it would be this one:
2 Likes
So I took it out of the wall and it appears to be a 14291-3. The pic is little blurry because I didn’t bother to turn off the juice and I didn’t want to yank it too far out, but I think I got the numbers right. Then, I loaded up your driver and the attached screenshot reflects me turning it on and off repeatedly. No repeats and I turned on and off another 20 times. So it looks like it did make a difference.
Thanks
1 Like
Good to see it may be fixed. JasonJoel's drivers are excellent, I am not surprised in the least that they act better. Please keep us updated after a few days to see if things stay working good.
If this is the solution, then I would say to contact support, and let them know what was going on, and what the solution was, so they might investigate this (apparently malfunctioning) driver.
if you switch back to the inbuilt driver and the issue returns, then it's our driver, otherwise it isn't...
please try this and report back.
4 Likes
Well, as you can see in the 1st attached screenshot, it seems to be working correctly both ways. Jason’s driver says “is on” or “is off” then I changed the driver and the built-in driver says “is on [digital]” or “is off [digital]”. So now they both seem to be working without the data storm.
Then I turned it on with my outside group (5 switches) 2nd screenshot and it did post multiple “is on [physical] when using the built-in driver. I don’t understand the [physical] part when I’m using the dashboard or automations.
screenshots are reversed.
determining the commands origin (physical vs digital) is a crap shoot with some devices.
if its accurate you can use that distinction in automations, if not, then you can't.
I have seen this in a few of my devices..the Community has always said that it’s a mesh issue. But it seems like sometimes the hub can’t get the ack out in time when doing 2 or 3 actions in the same rule
2 Likes
Do you think this is a device/driver issue? I see this with GE, Leviton, HomeSeer switches/dimmers and other devices with both stock or custom drivers. I never see it if I directly turn on/off a device. This is just now after motion turned on a few outside lights:
Kitchen Door light here is running stock "HomeSeer WD-200 Dimmer" driver.
This is almost always a weak mesh issue, none of the device manufacturers you mentioned are known to produce spastic events all on their own.
60+ Z-Wave devices, all Z-Wave plus, in a 3000sq.ft house. I don't think it would be weak, and if so there will be many many paths? What do you mean with weak mesh actually?
the indication here is that the device for whatever reason isn't getting the frame ack from the hub, so the device is being "helpfull" and sending the frame again...
This could be due to low signal strength, network bandwidth congestion or interference from other emissions in the Z-Wave spectrum...
There could be bad routing going on too I suppose, I would try a z-wave repair if you haven't already done so...
Not really though as you see in Post#8 above:
There are multiple outstanding Basic Get to the SAME device, initatied by the Hub. Wouldn't you agree it would be better to not have the same Basic Get to the same device in the send queue?
Sure, but C5 and prior stack doesn't check any of that, C7 does.
The multiple gets are the same issue as the report, just the other direction...
I don't know what to tell you, something is very very wrong with your network...
