Deadlines are time targets set by a tasks running on a realtime OS, for completion of prioritized tasks. The idea is that the OS gives priority to the most essential (highest priority) tasks accomplishing their objectives within a deadline. There are probably 20-30 realtime tasks going on within the Sense monitor all at the same time, all with different degrees of urgency and timing deadlines. In a realtime environment like this, you don’t just add some code to poll and broadcast every second. You add a task with a deadline of broadcasting every 1 sec, plus an associated priority. The realtime OS scheduler then dynamically works out how fit the code in (or not if higher priority tasks are taking up the CPU).
My supposition is that I am already seeing cases where lower priority tasks are getting dropped. Adding yet more tasks to the mix, is a formula for even more dropped data sampling from the smartplugs. One other possibility that might explain my dropped data could be broadcast collisions between requests being sent to the smartplugs and the return replies, but that again would speak to likely issues in adding yet another UDP broadcast on the Sense subnet.
@den_by, I think you are also missing another key point here - those 6-8 integers come from calculations that may not be entirely done on the Sense monitor. Remember that the numbers you see are aggregated 1/2 second power numbers that come from microsecond level data. There’s a whole hierarchy of data managed by the Sense probe out to the Sense servers and back again - looks kind of like this…
- Raw data generated at the probe/monitor (1 microsecond resolution for some of the measurements)
- Specially processed data that is sent back to the mothership that is stored and used for identification and training (who knows how they compress and extract machine learning features - resolution somewhere between 1 microsecond and 1/2 second). But this includes separate power data for each house leg, plus realtime phase information.
- Realtime data that is sent to our apps from the mothership when we see the moving waveforms and bubbles - 1/2 sec resolution aggregated from rawish data, some computed realtime (Always On, Other bubbles, some identification bubbles), though some people are also reporting data delays in receiving this data.
- Historic display data that is sent to our apps from the mothership when we either:
- are displaying realtime data, but need some additional history to fill out time window
- go back in time and/or change resolution.
- Identification and summary data - rolled up from the historic display data AFAIK. Used for device displays, trends, usage and export.
I think you keep assuming that what you see in the UI is all queued up and ready in the monitor, and just needs to be broadcast, but most likely not. And broadcasting instantaneous readings every second or so isn’t useful in seeing the real picture of power usage.