Sorry for the late response.
As for false events, I have not heard anything internally about a bug or a known issue that could lead to false events, however I do not want to say that is 100% and deflect the blame else where.
But one thing we can do is, enable extra logging on your hub and once it happens, I can take a look at the Radio to see if the device is the one originating the message.
And maybe… There is a ghost somewhere tripping the motion 
Thanks for the reply, @Kianoosh_Karami. Sadly, the false positive events I’ve observed have been far & few between: three times in as many years on two hubs. No false negatives have been observed, but statistically you know they are also there.
Please raise this internally, should any of the developers be looking at anything related. It’s simply a fragment of information, but in my experience sometimes these kinds of things trigger thoughts leading to problem diagnoses.
Thanks for your consideration. At least a ‘refresh’ tile in a DTH might help collectively reduce the load on support. Folks like me with hubs at wildly different locations cannot pull batteries or ‘replace’ a device to make it work again…
It seems like there is a generic SmartThings issue where door sensor status can be lost. I have this same problem with my Dome Door Sensor Pros where the door will report open when it is really closed. The problem becomes almost completely reproducible if I trigger an alarm to my 2 Dome Sirens. So if opening the door triggers an alarm and then the door is closed, the status of the door will remain open.
I’ve reported this to support in the past but since my door sensor and sirens are not officially supported there is nothing they will do about it. I also reported it to Dome, but they say it’s a SmartThings issue. It’s clearly not a device handler issue since using a siren should not affect how a door sensor device handler operates. It also doesn’t matter what application or device handler I use anyway, the problem still remains.
Unfortunately, it appears information like this is simply being dropped on the floor—rather than being reported to engineering for further analysis or additional data points.
Anecdotally, this points to a systematic problem. It happens with more than a single device type or manufacturer. It is intermittent (which makes it even more difficult to diagnose). And, sadly, it’s so random and infrequent it may possibly never come up on a list of issues needing resolution…
In my case, having the door sensor trigger 2 sirens simultaneously makes the issue happen almost 100% of the time. When I use just 1 siren the issue becomes much less frequent, but still happens. When I use no sirens the issue happens rarely.
The point is that the system seems to get distracted managing the sirens and drops status reports from the door sensors on the floor.
Any changes on your end, @capfan? Since this last false ‘motion’ report, I’ve had no more false positives. Yet.
I just wanted to thank Barkis for his solution as this worked perfectly for me for 3 open/close sensors using the default DHT modified to exclude the conditional use of zwave.sensorBinaryV2.sensorBinaryGet. OK, it now runs in the cloud instead of locally, but I’ve not noticed any issues so far.
Appreciate the feedback, @chirpy!
Just be aware this mod probably affects battery life on the device itself, as it makes the device transmit on extra message every time it wakes. I use this trick just to get the device back in sync, then switch back to the original DTH.
Understood. Though if it’s between reduced battery life and a effective sensor, it’s worth it for me.
Ironically, here we are in November 2022–and there have been NO false events of either motion or door open since the aforementioned. We’ll never know why it happened!
Sigh! It’s still happening here in early 2024: this time a Zooz ZSE40 4-in1 sensor. New driver environment, so it is unlikely the drivers as much as it is something along the lines of the SmartThings Z-Wave handlers occasionally dropping a message on the floor.
Or so it would seem…