If only there was a simple way to exponentially limit your retries and back off a bit when the other side is constantly failing.
But it's quite easy to set timers to attempt things at regular intervals, rather than in an infinite loop until they succeed.
One attempt every 5 seconds (assuming a 5-second timeout for the request) is 17,280 attempts a day. One attempt every 5 minutes is 288 attempts a day. One attempt every 15 minutes is 96 attempts a day.
A simple repeating timer is a fantastic solution.
Does the car need to always send telemetry immediately? Can there be a 15-minute latency? If so, just put that on a timer and enjoy 99.4% power savings for offline cars, with basically the same quality of telemetry when they're online.
But what if a car needs to send telemetry at a given moment? Just move up the next timer function call.
But what if I want to get telemetry when the 3G signal is intermittent and briefly available? Just call the function once the 3G signal is available. Do this with a separate cool-down for this behavior.
But what if I need telemetry every second? Just dump all telemetry events into a buffer between successful sends, slap a timestamp on those events, and you can now send data for the past X hours all at once. Even from the black spots.
There are so many options (even less fancy than exp back-off), but this was probably built by a junior programmer without any support network. This feels like a very common lack-of-experience mistake that would be caught in code review if the reviewer cared.
It's literally just a left bit-shift? It's as easy as a linear back-off. The only thing less fancy is no back-off at all.
I guess you could always cap off the exponential interval increases at some max interval, making it basically a repeating timer.
Though there's still the question of why would you need this for telemetry. It doesn't feel like this type of "marketing" telemetry needs to be quite real time.
No you MUST have a max interval cap. Exponentials and all, you'll soon be waiting days or months for a retry.
Please cap your numbers for both user experience reasons, and safety reasons.
Yes, have dealt with this before. Nothing like doing a fault analysis and telling someone that it'll fix itself in a few months.
A capped fibonacci sequence is a very common back off timer.
*Rule One of IoT network design: NEVER assume that you even have a network * If at all possible, and to the maximum degree possible, an IoT device must work whether there's a network available or not.
* at least across module sleep/wake
It's fancy.
At least the penalty is you just repeatedly cause every car of the model in the entire country to fail instead of crashing into a wall, but this kind of thing is why the T in IoT is for "shit".
And it just supports my point, which is that it's not "literally just a left bit-shift".
It's quite a lot of work to do, actually. Which -- of course -- should be done. But there are commenters here acting like it's a single line of code.
But I think we all know what actually happened here was a rush to release and then a failure to follow up with "the update that actually does it right". The Jira ticket is probably still "open - should do, version: next" somewhere. And there's a "told you so" email chain linked in there somewhere.
So there is some justification for trying to keep a cell signal established or checking in more frequently than every 15 minutes or so. Someone attempting to remote start their car not having it actually respond for 15 minutes is likely to already be outside trying to leave and pissed off that they’re walking out to a cold car with iced up windows and thinking that the “remote start didn’t work”.
One example: This is exactly why randomness is required by Ethernet's ARP protocol: to avoid ARP storms when the power comes back on and all nodes try to get back on the network at the same time. (And ARP is still powering most IP connections (v4) today, since IPv6 is painfully fiddly by design, so no one uses v6 unless they have to...)