I upgraded to 1.0.8. I switched one of my Dome's to the Internal driver. I'll let you know if it makes a difference...
1 Like
Wow ... thank you!
In regards to FW upgrade - still need to remove it from the hub and attach it to another stick?
Looks that way, although haven't tried it myself yet. Just looking over the support page.
Yup ... here's a thread on this forum:
Yea, that's me, and yes, I've updated device OTA firmware while the device remains on the existing.
I have a "spare" Aeon Z-Stick and I've joined it to the Network established by Hubitat. It's rather a lot like having to Include a Minimote. You end up with another controller on the ZWave network. I do that on a Virtual Machine because that's easiest for me. I'm an ALL MAC house and the only way I'm letting a Windows machine in here is virtually 
I follow the Aeon instructions but start with something like Step 3 (after the device is found on the network).
I've successfully updated several Aeon MultiSensor6's and an Aeon Minimote. I tried to update an Aeon LED Bulb (RGBWW) and although it "started" - after 3 hours no progress showed. By that time it was getting dark and I needed the LED Bulb back in it's room. I have not yet retried, but given the reluctance I've already experienced with this OTA process, I'm hopeful the 2nd or 3rd or 4th attempt works. I moved the LED bulb closer to the Z-Stick, just 1) because it's a bulb, easy to move! and 2) just in case distance matters. I have no reason to think it's due to being on the same network. It is after all a parallel buildout. The ZStick is dedicated to the Update, and the Bulb (or other devices) have not been 'busy' with their 'real' tasks. Once the upgrade progress bar started going, it has been just a minute or two to complete.
5 Likes
I'm looking for that windows app on their website but I can seem to find it. Have you a link to it ?
You deleted getting the FW version !
it's 3-5 posts back by DeveloperDavidB
1 Like
DUH -- reading to fast and skipped that
Im going to try the Hoomseer Zwave flash update kit
So, I have 16 of these right now (all USB powered, because when you tear your house apart in a remodel, you can do that. 
).
I'm experiencing overall Z-wave slowness (I think), and, I used the advanced DH to set selective reporting, attempting to not overload the Z-wave network.
Is anyone else seeing strange behavior where the sensor clearly fires for motion, but the delay in turning on lights (doesn't matter for Motion Lighting or RM) is almost as bad as a full cloud roundtrip in ST?
This is beyond frustrating to debug, and I've tried to setup the Z-wave network per the excellent article from @bobbyD, but it's just painful at the moment.. 
yes.
I have 12 of the Multisensor6's and two of the Dome. 90% of the time everything is wonderful and then there's the remainder. 6-30 second delays.
Hubitat is working it, I'm certain, but it must be very complex.
1 Like
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."
