Closed ggggh closed 3 years ago
Hmm.. I suppose in the case that your device stops reporting in new values (#18), the logic will always place the next-read at "now" (+ jitter).
Is your device asleep?
I've added some code, soon in the dev
images, that will exponentially backoff consecutive runs of "1 minute" delays up to 3 hours.
No, it isn't asleep, and would have had different values at the time for sure - I think it just missed a sigfox upload for some reason.
Good for the back off - but could we use the BlueRiiot__UpdateInterval instead of the 3 hours, as the max (or set a new parameter for max)?
It's an exponential back off, so it will gradually hit the three hours over a run of, iirc, 14 missed updates (see below).. The max should be relatively low, as to not be completely unreachable in case the device comes back online... is three hours too much?
Iteration, n | n^2 | Delay |
---|---|---|
1 | 1 | 00:01:00 |
2 | 4 | 00:04:00 |
3 | 9 | 00:09:00 |
4 | 16 | 00:16:00 |
5 | 25 | 00:25:00 |
6 | 36 | 00:36:00 |
7 | 49 | 00:49:00 |
8 | 64 | 01:04:00 |
9 | 81 | 01:21:00 |
10 | 100 | 01:40:00 |
11 | 121 | 02:01:00 |
12 | 144 | 02:24:00 |
13 | 169 | 02:49:00 |
14 | 196 | 03:16:00 <-- cutoff, this is capped at 3h. |
15 | 225 | 03:45:00 |
3h would be too much for me, especially during daytime with a strong sun, as the whole pump, chlorine, ph management runs based on this data and it changes very quickly. Pool could have gone way off target 3h later. Nighttime...wouldn't mind 3h delay.
Ah, but this is only for missed reportings... If your blue device (plus) keeps reporting in on its scheduled interval (1h 12m), it will never hit this exponential backoff... Also, the first time it hits a successful report, it goes back to not being backed off.
Right - I meant if it goes offline for whatever reason for a few hours and doesn´t upload new data (which would be problematic for me, but unavoidable if their service or sigfox coverage goes down), we might be adding yet 3 hours more due to that backoff. I wouldn't back off more than 1h12m more, as it shouldn't go more than that time without a reading.
Cool - as long as we're on the same page.
I'll make it configurable :)
A new config has been added, dev
should be updated soon.
Seemed to be working fine so far, but suddenly the automatic polling has done something weird.
At some point after a normal reading, the "new data ready date" turned out to be in the past (although "interval" was positive), so it kept polling every 30 seconds until it got a new reading with a new data ready date in the future.
Two points: 1- maybe build some back-off algorithm so it gradually increases the re-polling time to avoid doing it every 30 seconds? (does the jitter setting do this?) 2- review that "next read time" in the past issue and how it might happen