I'll post all that info later. I haven't really noticed any errors in the logs though I do see debug entries for the iris v2 keypad sometimes. But the delays happen regardless of what's going on with the keypad.
Occasional debug message isn't going to cause slow downs. I'm talking massive amounts of errors (not warnings) every few seconds. If you don't have that, then something else is the culprit. Look for a "chatty" sensor in the logs that might be slowing down the Zigbee network too.
I had no time to send the keypad to Mike but I can try to do it before sending it, never tried to pair it.
But if he is really not seeing delays when observing on/off from the device page for both his sensor and the light, but just when the two are involved in an automation, the finger is pointing to something running in the hub that is causing the latency. Chatty devices in the network would cause delays that would be observed even without automation in the mix, as would mesh issues.
OK, so then a simple test would be to focus on the devices involved to either confirm they are related or eliminate them. @toyanucci, If the motion sensors were removed and the automations were to use virtual motion sensors, is there still a delay when motion is triggered on the virtual motion sensor? If the answer is no, then the issue is related to the physical motion sensors you're using.
If there is still a delay, then add the motion sensors back to HE. Remove the lights affected by the delay and add a virtual switch in their place. Watch the virtual switch as you trigger the physical motion sensors. If the delay is gone, then the lights are related to the issue. If it remains, then the issue is neither the motion sensors or the lights. Start looking for what else might be causing delays on the Zigbee network. You might look first at the Iris v2 Keypad before trying other things.
this device isn't going to clog up zigbee, no matter if its working correctly or not...
ridiculous amounts of low threshold power reporting, from copious devices?, yeah, that can do it...
I tried to pair my Ring keypad to HE after removing it from the Ring system, no luck.
Seems like I read the ring system is zwave. If that's the case maybe try a zwave exclude with HE and then try pairing it.
No luck here with Ring keypad, I included it to Ring, excluded, hard reset, I did everything posible and did not paired with HE or ST. It uses a QR code for inclusion.
QR codes are a S2 security feature, to fetch cert it must accept and fall back to S0, which is what we currently support.
So either it's not certified, or it is but not compliant, or we're doing something and or not doing something that it doesn't like.
Only way to sort this is to sniff the packets while attempting to join it to HE.
If that doesn't point to anything, then the entire join process to the ring hub needs to be captured...
I told you guys this would be fun....
Ok, I will ship it to you, good luck and have fun.
as mentioned, I'll get to this when I can, don't ship it to me if you are expecting it back in anything less than a month, probably 2...
And if you're not using the ring hub, send that as well...
If not, then we'll just start with the keypad.
I use the hub, I have it connected to HE (ring has one contact, HE has one relay to trigger that contact) to call the police if an intrusion alarm happens, but I still have active my alarm. com system, I can use that and ship to you the ring hub if you promise you will ship it back max 3 months. At that time my contract with alarm. com will be ended.
sure, i can do that
Not to beat a dead horse here, but early in this discussion I explained why I left Smartthings because of the outages and some said they were on Smarthings and only had an outage lie 3 times and that the system was stable like 95% of the time but I say it’s way less then that but anywho I explained even though I switched over and now use HE I still receive the outage emails, and just like clock work received another one just now advising all Smarthings users to revert to using the classic smartthings app because they can’t figure out why the system won’t let you change the location correctly of your hubs. So like I said Smartthings is not so smart that’s why local processing is so important.
So again, everything was fast today, acceptably fast this evening and slow tonight. I did some more tests and I think I have figured it out. My modes change automatically based on time and at first I thought the mode was the issue, but in actuality its the light levels.
In the days the bathroom lights are 75%, 30% in the evening and 7% at night. I tried the different levels with each mode and the results were the same. I'm not sure why (It's easy to say it's perception but I'm not convinced that's all it is), but the higher the light level the faster the ramp up time is. So from off to 100% is much faster than off to 6% which is weird. This all ties in with my findings this morning as well. When I started testing it was slow and then it was fast but based on the time I was testing the mode changed from night to day during that time.
Tested with the on and off on the device page of the bulb and it's the same. When the level is higher it seems almost instant, but when the level is low (1%) there's a seeming delay for the ramp up.
Both bulbs being triggered by the same motion sensor. Bulb on the left is set to 100% while bulb on the right is set to 1%
In this video both bulbs are set to 100% trigger by the same motion sensor.
The results in the videos are consistent and repeatable.
So these are Sengled Element Classic bulbs? I don't have those. I have two Sengled Element Plus bulbs. They are my "Drunk Uncle" bulbs. Mostly, they're harmless and do what you expect, but every so often...
My wife HATES them.
After thinking it out logically, I came up with a solution of sorts that works for what I need...mostly.
I have a rule that sets the light levels based on what mode the hub is in (6% in night mode) and another rule that turns the lights off after 'X' minutes based on mode (1 minute in night mode) . What I decided to do was to create an action and add it to the rule that turns the lights off.
The action is delayed by 58 seconds, restricted to night mode and sets the lights to 25%. The rule which turns the lights off by mode does so at 1 minute without motion when in night mode. I then have that rule trigger this action with a 1 second delay as that's the only way to get access to the toggle to option to cancel the action on truth.
Soooo, to cut a long story short, the lights are now set to 25%, 1 second before they turn off without motion. Which means when they are triggered by motion they come on at 25% which is almost instant and without delay and then dims to 6% quickly.
I know, it's highly convoluted and unnecessary but I get the best of both worlds, fast response times and dim enough lights at night.
Since you’re using Sengled Zigbee bulbs, I recommend you use Hubitat’s Groups and Scenes App to create a group for these smart bulbs. When setting up a group of all Zigbee bulbs, you can also enable Zigbee Group Messaging which eliminates any popcorn effect. I use it on multiple groups of Sengled Element Color Plus bulbs. It also makes your rules simpler, and allows you to expose just the ‘group devices’ to Amazon Alexa or Google Home.
Are your Iris keypads and sensors Gen 2? If the keypads are your primary interaction with your system then you could have HE up and going pretty quickly. Just connect your Iris keypads to HE and link them using the Hubitat Safety Monitor (HSM). Then add some devices and configure the HSM to use them and your alarm system functions will be up and running. After that you can add some simple rules to turn lights on and off in the Rule Machine (RM).
I think reading the community posts make HE seem harder than it really is. There are some serious home automation power users in here. Using the Iris system really held me back since their rule creation was so cumbersome in comparison to HE. I've been extremely happy switching from Iris to HE.