I have a C-5 running platform version 2.2.2.125 (not that it matters other than to point out it's neither a C-7 nor 2.2.3.x) and it runs pretty well though it does slow down sometimes for unknown reasons which a reboot remedies. No lockups, mesh problems or anything like that, at least not that I'm aware of.
I have only 39 devices of which a few are virtual and the rest about 50/50 Zigbee/Z-wave. Most of my motion detectors are Iris v2 (love 'em!) which work great. The curiosity is why do these sometimes detect much faster than other times? I'm not talking about automation response, although that correlates, but rather the amount of time before the detector flashes green indicating that it "sees" me. For example, I have one of these on a wall in the garage and sometimes it detects before I've even got the door from the kitchen fully open and other times not until I'm on the landing and closing the door behind me, a difference of about 1.5-2 seconds I'm guessing but clearly evident. The longer times correlate to HE slowness but what does that have to do with the local LED indicator? These flash even when the detector isn't paired with HE so I can't see any possible reason.
For completeness I'll add that this automation is in Node-RED but it still gets the event through HE via NR nodes for HE so I don't see how that matters.
And the kicker? This detector isn't listed as being part of the Zigbee mesh as reported by http://hubIP/hub/zigbee/getChildAndRouteInfo! WTH??? This must be a problem with the report because when I go to the specific device from the Devices list and select Events I see them as expected.
Maybe I should just chalk it up to another one of life's oddities that seem to cluster around me. Or maybe Murphy has new tools??
So this isn't a problem really, other than for deepening the furrows in my brow, but if you can shed some light on this I may sleep a little better.
The sensors are all PIR (Passive InfraRed) and thus the amount of ambient IR can alter the detection profile. Same as shining a flashlight in your eyes.. at the beach, in the sun, you won't even see the flashlight... in the dark, the flashlight might be too bright.
Same with the PIR.. if it's facing a heat source (IR) that fluctuates, then your 'shadow' might be all it sees of you.
Thanks but I understand that and it doesn't account for my experience. You'd have to know many more details which you don't want to read nor do I want to write so you'll have you take my word for it
This has been happening for weeks and I've looked at many possibilities, not that I'm certain there aren't others.
I have 9 of the Iris Motion Sensors. Four of the v2's and five of the v3's.
Only 3 of them are in situations in which I would care about significant variation in their response. And of course I do see variation, just not seconds of difference.
Like I said, it's not a problem, just a mystery, which I enjoy...once it's explained. And this topic is mostly for like-minded puzzlers so no need to apologize.
Not sure about the variations in response time (assuming the path you're taking to activate the sensor doesn't vary, as these things by nature respond better to motion moving in a direction that is across the lens rather than directly toward it). But there is no mystery as to why it doesn't appear in the getChildandRouteInfo page.
That page will only 'always' show the sensor if it is a child device of the hub. If it's working normally, then it is a child device of one of the mains-powered Zigbee routers elsewhere in your network (they also maintain their own child tables but aren't visible through the HE UI).
There's a chance that it may pop up from time to time in one of the Route Table entries (in which case you will see a 'via' indicating which Zigbee router is in the path from that sensor to the hub) but those are the result of route record requests by the hub and are transient.
Thanks, @Tony, that's interesting. It seems odd to me that all of my Zigbee devices show in one table or another on that page except for this one but strange things exist so
Are they definitely not already triggered and in their pause state? I recall Iris motion sensors take 30 seconds pause before re-arming after a trigger. My Xiaomi's take 60 seconds. This is as designed in order to preserve battery life. So during that period they won't retrigger and therefore may appear to be slow. Just an idea, anyway.
Think everyone has covered the 2 main things on the PIR side, which it is to do with, like you said the indicator is connected to the trigger of the pir. So that happens with or without HE and so any slowness on the HE side isn't connected.
PIRs are dependent on heat as @csteele example perfectly explains. We have people phone up each year with our detectors that say they have "lost their sensitivity program" and it's because there is a heat wave here, external temp cools down and it's all good again. Come round to winter and suddenly they are TO sensitive!
So is there ANY variation in heat between the faster and slower times? Or Aircon units pointing across them?
If nothing site specific then other options is firmware? Maybe they fixed a issue in a later release?
No. The detector is in the garage which opened maybe once/week with this virus thing going on. I'm retired and just don't have a need to go anywhere most of the time anyway but now that this area is a mandatory mask zone due to the exponential rise in cases lately I'm more of a homebody than usual. Even with our current, and unusual, hear wave I'm seeing only an 8F variance over 24 hours. And there is virtually no air movement in the garage.
This is an Iris v2 sensor so even if it has the capability of firmware upgrade there is none available.
Come to think of it I don't recall seeing talk of any Zigbee device having upgradable firmware. I never thought to question it before but I'm guessing it's just not part of the spec.
I’ve upgraded firmware on my Zigbee SmartThings MultiPurpose Sensor. Of course, I had to fire up my SmartThings hub to do that, then put the SmartThings hub back in the box when the update was done.
Ah, yes, I do recall seeing that about ST devices. Thanks for the correction.
While I do have some ST devices, and I'm very happy with them, I don't have their hub and I'm not about to get one. Although it just occurred to me that I may find one for peanuts (the edible kind, not the HA devices) on Ebay and it would be worth it for a few bucks because I don't know of anyone in my area that has one if a firmware update becomes desirable.
I'm finding a lot of ST hubs on Ebay so I have to ask if it matters which version if I'm only using it for firmware updates. And am I correct in assuming that the ST hub is also the only way to know what version of firmware my devices currently have? At the bottom of the HE device page I see a "softwareBuild:" field but no info after it.
Wish I could be more help, but I’m not a SmartThings expert. We moved into this house just over a year ago and the hub was a Wink 2, but the builder/owner had never been able to get any of the automation to work. Earlier this year, when Wink implosion got severe, I moved to SmartThings, and then, a couple weeks later, the SmartThings upheaval started, so I moved to Hubitat. Been happy since.
You need to log into the SmartThings IDE, from there the firmware level will be shown when viewing the relevant device page. ST provides OTA updates for OSRAM Lightify Zigbee bulbs and the IRIS V2 battery sensors (contact and motion) as well as SmartThings branded sensors.
The IRIS hub was also capable of updating IRIS devices, but that service is defunct. Not sure if there are any other options.
That's a lot of movin'! I'm glad you landed here. Even with the current platform QC issues I feel it's by far the best place to be. Having said that I'll add that I'm running Node-RED as an adjunct for motion lighting because it's faster and for things HE doesn't support, like Internet speed testing. Yeah, someone will add that (if not already) but I like "seeing" some processes. And I think the QC will improve
Yes, the IDE is going away sometime next year; no specific date has been given. I assume that even with the general 'dumbing down' of the platform that OTA updates will still be provided, but how much of that feature will be exposed to end users is TBD. Not sure about the original V1 hub, but I had a V2 so I assume at the minimum V2 and V3 will support OTA udpates.
Or maybe Murphy has new tools?? 
I'm glad you landed here. Even with the current platform QC issues I feel it's by far the best place to be. Having said that I'll add that I'm running Node-RED as an adjunct for motion lighting because it's faster and for things HE doesn't support, like Internet speed testing. Yeah, someone will add that (if not already) but I like "seeing" some processes. And I think the QC will improve 
