@greg, I have an update here.
First, my Aeon sensors seem to be reporting battery every 12 hours, and indeed, they are reporting 100% battery. I guess itās possibly that thereās a physical problem with both of them, but Iām inclined to just say that they are measuring Y mAH on the cell and they consider X mAH to be 100%, but Y > X at present because new battery, higher capacity battery than spec, etc., so itās gonna report 100% until Y falls below X and onto the scale that Aeon has calibrated for the device.
Now, the monoprice motion sensorā¦ Iām just climbing out of the rabbit hole here. First, it looks like Florianz code should be checking battery daily. It also is logging an event when it issues the command and when it handles the report. I saw neither event in my historical event logs for the device for days (yes, I checked all events).
From this, I knew that something was wrong, but I canāt say what. So, I did what any software engineer would do, and rewrote the device handler until it worked. 
But holy crapā¦ So, this was the first sleepy device Iāve gotten personal with. I understand the different paradigm, but itās a whole lot heavier on the responses from parse, and the documentation and examples around thisā¦ well, many are plain wrong, with wrong defined as ādoesnāt workā. I think there are things that did work that now donāt or things that are supposed to work but donāt yet.
I have more testing to do to find out the current state of issuing commands and events in response to a device event out of parse. Right now, my rough guidance is:
- Returning a single response-wrapped-command from parse works.
- Returning a list of individually wrapped commands and wrapped delays works.
- Returning a list of individually wrapped commands and un-wrapped delays fails silently
- Returning a list of commands and delays that has been wrapped as a unit fails (this is the example in documentation)
hardly exhaustive, but my goal so far was finding what worked for the case at hand. Iāll try to perform more tests and write up results.
On the WakeUpNoMoreInformation command - Iām not sure of itās exact effect yet, or if thereās a race condition to be concerned about. Certainly, if the NMI arrives at the device before my last command to it, then my last command is SOL. But what if all my commands have hit the device, but all reports havenāt yet been sent when the NMI command arrives at the device? Does it preempt pending reports?
I still need to investigate identical fingerprints (the device pairs as an Aeon Multisensor at inclusion. But this precludes me from doing anything clever at that time, so the end user experience is still to switch the handler on the device - less than ideal.
Anyway, at least I have something at the moment that is working. Iām hoping to button it up enough today to get into the wild.