Thanks - glad to know I didn't miss any steps... ugh... hope this gets addressed soon.
I noticed the same thing on all my motion devices... Sometimes they are fast and 1% delay is 3 or 4 seconds.
I have tried the RM and local Webcore and I see no difference.
@bobbyD - I presume this isn't just limited to motion devices, right? I'm seeing overall slowness randomly on Z-wave.
For instance, sometimes I can ask Alexa to do something, she responds 'ok', but the action never happens on the Z-wave device... Also, my 'good night' routine in Alexa which flips a virtual switch to change Hubitat to Night Mode and then turn off all of the lights takes forever.
Yes same thing for me... noticed that last night when it took alexa almost 5 seconds to complete command.
Is there a dedicated thread to the overall Z-Wave slowness? I'm very surprised that an issue of this magnitude is getting - AFAIK - very little attention by the community. I'm the first to acknowledge that this is a hobby and I don't expect anything remotely close to perfection, but this is seriously affecting my WAF! It's common for me to see 2-3 minute delays from the time a Z-Wave command goes to when the device (e.g. switch) responds. They queue-up and eventually always fire.
1 Like
It's complex, I'm sure. I don't KNOW, but I'm imagining the ZWave radio, which is of course half duplex, getting inundated with receive data (every motion device sending LUX, temp, IR, humidity readings) every x mins. The transmit side gets to wait for a turn. I'm guessing (again) but I can see specific minutes where many devices have something to say.. and one controller vs N chatty devices yields a bottleneck. Now pile on ZWave antique devices using the series 300 chip (vs series 500 for Zwave+) and it seems like with 80 randomly purchased devices, bottleneck is approaching certain. 
I've read comments that say something along the lines of: "It only polls every N seconds, I don't see that being a problem." It doesn't matter what value N is, eventually N aligns with everything else using any other value (M) because N * M = collision.
I have my mental image of how difficult it is to cure and maybe I'm close in my guesses, maybe I'm far, but I didn't see anything in the spec that allows the Hub to manage the chattyness of 30/60/90 devices. But I'm hoping I'm completely wrong and Hubitat pulls the rabbit from the hat.
This very well may be the case, which is why for the Multisensor 6's, I've backed way off on the polling interval, but, more importantly, I've set all of mine on USB power to selective reporting based on thresholds for temp, lux, etc. - using the Advanced DH for that device.
I agree with you that just adjusting polling might not make a difference, but, if the polling intervals are made different for each motion sensor, and the configure commands sent at different times, thereby starting the clock from different points, theoretically, that should spread out the chattiness, right?
1 Like
Recently Bruce announced changes to RM because using the underlying cron tool just didn't work as expected. Unfortunately, once you do know how it works, we're losing a tool in the "de-chatify" war.
cron runs once a second to see if there's anything in the queue. But that also means it will never be a "every N seconds, minutes, hours" tool. It always runs on a specific second or specific minute. (it accepts lists of seconds, lists of minutes, but that it absurdly complex for a consumer device.)
To de-chatify, and also knowing cron, means you can assign specific seconds to run a poll. You can create a Rule that runs on second # 27 and poll 2 devices.. then another rule that runs on second #33 to poll yet another 2 devices and thus KNOW that there won't be a collision for those two.
Shifting to runin in RM has major advantages everywhere else BUT de-chatify. So it's perfect... except 
Disclamer: These are MY opinions. I continue to have no insight to Hubitat MORE than "you."
Interesting.... maybe I was misinterpreting the 'polling' interval here.
I'm thinking that 'polling' in this case represents the reporting interval that the Multisensor 6 stores to know when to report Group 1 values. If that is adjusted slightly on each device, theoretically, it should reduce some chattiness.
Now, if you are talking about RM or Motion Lighting doing some polling I'm not aware of, then yes, I agree. As someone who cut their teeth on Unix (I'm old. :)), I'm unfortunately all too aware of the limitations of cron in this case.
Let's hope that @bobbyD, @bravenel and the team have some sort of fix for this, or, at least a set of best practices for those of us running this many sensor devices.
"SmartThings threw a bus at it" -- Bruce Ravenel
Hubitat doesn't poll.
For older ZWave devices (non + ) polling might be necessary. SmartThings decided that EVERY device needed a poll EVERY 10 seconds. Hubitat is zero.
Thus it falls to us to manually set up a Rule to poll only those few devices that matter to us.
I had two rules, and because cron was still de rigueur, I didn't have any collision between those two rules.
BTW, the Every N Seconds for Periodic trigger in RM had a fatal flaw (Cron shortcoming) and has been deprecated. Instead you can use an action of Repeat These Actions every n seconds.
yes, wasn't "every" but was "on"
Once the "it's cron" sank in, I was happy. I'll mourn the loss of cron, but will probably make more use of the new.
Periodic of say 21 seconds would run 21 then 42, then 63, then 84 seconds after clicking OK once cron is deprecated.
However, periodic of 21 today, before cron is deprecated, it runs on 21, then 21, then 21, then 21.. On the 21st second of each minute. It's great if you KNOW that, because it can be put to some use.
But, like I already said... So it's perfect... except
Ok, so, then my interpretation is correct. It's the Multisensor 6's being chatty on their own... which, theoretically, based on use of the Advanced DH and selective threshold reporting, should be able to be minimized if you set the Group 1 reporting value to something other than the default 3600 seconds.
Or, maybe I'm just crazy, and this isn't what's causing the issue I'm seeing. I do see a lot of debugging/parameter setting messages for my Multisensor 6's, which would indicate more network traffic than I'm thinking is there.
I think we're both swirling around it.. The Multisensor IS 6 devices in one.. it SHOULD send 6x the traffic of an Ecolink Door Sensor 
Plus a door sensor only has one thing to say and only when the door opens and closes.. not fully latch the door on a breezy day and maybe the Door Sensor can output more than a Multisensor.. but let's not look for scary things
Perhaps simplify down to: some devices are chatty by the nature of what they are and we want them to be. A Multisensor that only gets around to telling me it got cold yesterday, isn't exactly what I want to spend money on
The manufacturers know about chattyness. They know to reduce it and mostly they do, based on the logs I see off an Aeon Z-Stick + OpenRemote. The entire message is just a few bytes, the multisensor is ZWave + and therefore spits out tiny messages at high baud rates. I see the messages going by at no more than 1 per second (measured without a stopwatch)
But for chatty.. this Dome takes the cake!!:
dev:552 2018-07-25 11:55:39.398:debug Motion Active
dev:552 2018-07-25 11:55:38.950:debug Motion Active
dev:552 2018-07-25 11:55:38.324:debug Motion Active
dev:552 2018-07-25 11:55:38.263:debug Motion Active
dev:552 2018-07-25 11:55:38.102:debug Motion Active
dev:552 2018-07-25 11:55:38.090:debug Motion Active
dev:552 2018-07-25 11:55:38.052:debug Motion Active
dev:552 2018-07-25 11:55:37.927:debug Motion Active
dev:552 2018-07-25 11:55:37.908:debug Motion Active
dev:552 2018-07-25 11:55:37.839:debug Motion Active
dev:552 2018-07-25 11:55:37.786:debug Motion Active
dev:552 2018-07-25 11:55:37.658:debug Motion Active
dev:552 2018-07-25 11:55:37.595:debug Motion Active
dev:552 2018-07-25 11:55:37.568:debug Motion Active
dev:552 2018-07-25 11:55:37.444:debug Motion Active
dev:552 2018-07-25 11:55:37.294:debug Motion Active
dev:552 2018-07-25 11:55:37.242:debug Motion Active
dev:552 2018-07-25 11:55:37.167:debug Motion Active
dev:552 2018-07-25 11:55:37.085:debug Motion Active
dev:552 2018-07-25 11:55:37.040:debug Motion Active
dev:552 2018-07-25 11:55:37.001:debug Motion Active
dev:552 2018-07-25 11:55:36.972:debug Motion Active
dev:552 2018-07-25 11:55:36.862:debug Motion Active
dev:552 2018-07-25 11:55:36.851:debug Motion Active
dev:552 2018-07-25 11:55:36.777:debug Motion Active
dev:552 2018-07-25 11:55:36.757:debug Motion Active
dev:552 2018-07-25 11:55:36.719:debug Motion Active
dev:552 2018-07-25 11:55:36.602:debug Motion Active
28 messages in 2.8 seconds 
My kids were chasing the dog right under that sensor.
OpenRemote logs look like this, just for reference:
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x25]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x27, 0x75]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x73]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x70]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x86]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x72]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0x77]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Serial_Port_RXTX : Data bytes read : [0xCD]
DEBUG 2018-07-25 10:22:00,839 (Z-Wave): RX_Frame_Layer : Data frame [0x01, 0x11, 0x00, 0x49, 0x84, 0x07, 0x0B, 0x04, 0x10, 0x01, 0x25, 0x27, 0x75, 0x73, 0x70, 0x86, 0x72, 0x77, 0xCD] has been received.
DEBUG 2018-07-25 10:22:00,840 (Z-Wave): RX_Session_Layer : 'Application Controller Update' frame [Status: UPDATE_STATE_NODE_INFO_RECEIVED, Node ID: 7, Device Classes: [Basic: BASIC_TYPE_ROUTING_SLAVE, Generic: GENERIC_TYPE_SWITCH_BINARY, Specific: SPECIFIC_TYPE_POWER_SWITCH_BINARY], Command Classes: [Supported: [COMMAND_CLASS_SWITCH_BINARY, COMMAND_CLASS_SWITCH_ALL, COMMAND_CLASS_PROTECTION, COMMAND_CLASS_POWERLEVEL, COMMAND_CLASS_CONFIGURATION, COMMAND_CLASS_VERSION, COMMAND_CLASS_MANUFACTURER_SPECIFIC, COMMAND_CLASS_NODE_NAMING], Controlled: [ -- ]]] has been received.
All of the ZWave bytes are displayed, and decoded.
1 Like
Ok.. well, then this means that with the selective threshold reporting turned on, and tuned down, it's probably likely that my (or 'our') problems are less about the multisensors and potentially something else. I don't have any Dome sensors - mine are all multisensor 6's... my switches are Zwave (not plus).
Something else is clearly going on here, and I'm at a bit of a loss to determine what... 
1 Like
Agree.
There's another factor.. Mystery X to me... I am not seeing messages at a rate that SHOULD jam up the ZWave Radio. I have 12 of the Multisensors and 2 of the Dome. So, Yes, I have chattyness, but I suspect it's not 10x everyone elses.
Referring back to my paste of 28 messages in 2.8 seconds.. that's 100ms between messages. That's slow, relative to the capability of the ZWave Radio.
I'm going out on a limb here and say that I don't think I'm seeing half the real delays. I've said it elsewhere, because I don't really watch the OFF events. Motion occurs and the light goes on. 4-15 mins after motion stops, the light goes off. I critically watch only the light on event. If the light OFF event occurs 5 seconds late, I'm not watching, (other than the minutes immediately after inventing the Rule.)
Yet clearly the ZWave radio is jammed up. All the messages behind the jam do come out, in the right order, once the jam clears.
Me.. I've moved into the "I've done my portion (de-chating) , Hubitat is working their portion" frame of mind.
1 Like
I replaced my batteries with rechargeables, and motion is almost always active. When Motion goes to inactive, it immediately goes back to active. I tried this with 2 different multisensors. Anyone ever seen this?
rechargeables are very iffy with the Aeon MulitSensor 6
I have 12 and only 2 will work with rechargables. I see pretty much constant motion when operating from rechargable. The logs show there's motion, it times out and says no motion and within a second, motion again... even when inside a drawer!
Sure enough, I'm glad I found this thread. I had one freaking out I was about to toss. It had some new rechargeables I just got in, I put in while re-purposing. I wonder what the science behind that is? I mean voltage is voltage, right?
True, but typically disposables have a higher voltage than the rechargeable version. I'm not sure about 123a. but for AA it's 1.5 vs 1.2 usually
1 Like
