@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.