OK, results are in! 
On Sunday, July 16 at 8:15pm, a GoControl Door/Window sensor on a slider (with extra pins locking it closed) caused SHM to alarm. I watched the interior motion sensors, as well as the remaining two doors – all of which reported “all is well!”
Seeing no other issues, I eventually removed the sensor from SHM, re-armed, and things continued as normal. Other than the bi-weekly visits from our homewatch company, nothing has alarmed since. They confirmed the door was closed.
Today’s Experiment: modified the stock DTH to make it always request open/closed sensor state, instead of only the first time after pairing with the hub. Also put in some additional logging & added tiles to display wake-up & last-contact times.
Eventually, the device woke up & said the door is “closed.”
Conclusions: some anomaly occurred (no kidding!) and the leading causes, so far, seem to be:
-
the GoControl open/closed sensor sent an “open” report and nothing since but battery updates. Seems possible, but unlikely, as no other contact sensor I have installed has ever done this in several years.
-
there is something wrong in the stock DTH. I’m going to do a code review & try to come up with some ideas – but that seems unlikely, since the sleepy device only woke to send battery reports. Still, there could be a bug in the way those ZWave messages are parsed.
-
something could have gone wrong in the ST cloud ecosystem. But, it has changed (probably) more than once since July 16th. It could be some race condition, which makes it nigh on impossible to track down – not to mention no public knowledge of the architecture or code. Perhaps ST folks on the inside might find this report useful in development or troubleshooting in the future…
In the meantime, this particular out-of-sync problem might be easily remedied by simply having “sleepy” devices occasionally update their status when they wake.
That’s what worked in my case. 