Thanks for testing and posting your findings.
That is disappointing, and doesn’t seem entirely logical. It seems like it would be a somewhat straightforward thing to code and have the lights turn on if they aren’t already on when the camera turns on in the dark.
My guess/conjecture is that the cameras are pixel-based because it’s more sensitive during the day and allows for the setting of the more precise zones, which I really like. However, pixel-based may not work as well in the dark, so they made the lights PIR so that the lights would trigger on before (or at the same time) as the cameras and assist the camera’s motion dection to work better. Though as you’ve described, in implementation, the camera and the lights often trigger separately. Bugs seem to trigger the camera and not the lights. Whereas moving plant life often triggers the lights but not the camera…
When my floodlight cams seemed to be working appropriately, the lights did trigger noticeably in advance of the camera at a pretty good distance as a human (or animal) walks up), which I thought was effectve for security. However, the last few sets of floodlight cams that I’ve received have had all sorts of problems with the lights. Even with the lights at maximum sensitivity, I am now finding that the lights don’t trigger until I am practically under them waving my arms, while the camera captures my movements in the dark. Not sure if Ring has reduced the quality of the hardware, reduced the PIR range through firmware, or both…
Definitely agree that having a setting where the lights will always be on with the cameras at night would help prevent these issues. Plus, the motion zones on the PIR lights are pretty rough and mostly ineffective, so having them linked to the cameras would help that as well.
Sigh… I had expected the Ring products would stabilize and improve over time. But instead they are getting more and more buggy, while they were apparently giving our PII and data to Google, Facebook, etc. without our knowledge…