My understanding of how the motion sensor works is as follows:
When it detects motion, it sends a signal to the bridge. Every minute or so, it checks if motion is still there, and if not it sends another signal to the bridge saying that it’s clear.
However, this is problematic because if the signal isn’t good, it could be stuck saying motion detected because it missed the clear signal. (This seems to happen to me sometimes).
I understand that Wyze wants to maximize battery by not sending signals that often. It seems more practical to send signals every minute, and if the bridge doesn’t receive one in a minute, it will assume motion has ended. However, in high-traffic areas, this will use up battery quicker because it will continue transmitting.
So here’s my solution:
Ask the user when setting up, and have an option to change later, what kind of use it will have so that it can be optimized to maximize battery life.
For example, if it’s going to be in a high traffic area, leave it the way it is now (send signal when motion starts and then when it ends), as that’s better for battery. But if it’s going to be in a place where there is bad signal, or motion events last for less than a minute, it could send updates every minute, and if the bridge doesn’t receive a signal on schedule, it will assume motion has ended. This will actually save battery for motion events under one minute long, as only one update needs to be transmitted.
You could also customize how often it updates.
Here’s another idea that might work better, to prevent the problem of a stuck status:
The bridge could send a confirmation when it receives a signal. So if the sensor doesn’t receive the confirmation, it would resend. I can see this using up battery in low signal areas though.
I don’t really know how they actually work, these are just my assumptions and observations based on how it seems to work for me.
Also, all these ideas would probably require hardware changes to the motion sensors, since I don’t think the motion sensors have any kind of firmware.