I think a fixed ~24h polling interval is the best, because it can just happen that you get nearly no discrepancy at all, and then an algorithm would pick an excessively long time. Also because once a day is really rare in terms of resource consumption, adding an algorithm just adds unnecessary clutter and possibility of additional bugs.
Timeout is not really as you’ll just try again the next day or something
If the timestamp is a numeric string the exact length doesn’t really matter, and on a server the memory usage is not a big issue. Maybe this has to be revisited if millions of tags are collecting data into one server / cluster, but at this point there is no need to optimize last bytes of data.
Good point, I’ve not checked but I’d be surprised if there is no RSSI in data given by ESP32. The RSSI should be included.
Whitelisting would be a nice-to-have feature, not strictly necessary. But having it would definitely be a good thing. It would also let users to have only one firmware rather than recompiling and flashing if they want to include / exclude new tags
The algorithm needs to be smart enough not to pick a “next poll time” that is neither too soon nor too late. Consider more frequent polling reduces the complications when the local system clock is fast, and needs to be “stalled”. It’s not so simple.