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
“Beware of timeout” was meant as a reminder that the code should not hang waiting for response as the sample I referenced does.
Time server should be configurable since I am sure that some users will not be able to access pool.ntp.org (firewall) and will need to reference a local timeserver.
Can that (and other configuration items come from DHCP server?
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.
Will there be Slack channel for Dongle? I assume it can be used also for other (sensor) beacons
Wow, this is what I’ve been waiting for!
How about PoE input for the dongle, we would get LAN connectivity and power at the same time.
I created a channel #ruuvidongle on slack, please join in 
This is something we’ve been considering.
It would be a great option for some users and not useful for others. We’ll look into it for sure.
Have you cosidered the Fanstel open source Wifi to BLE gateway which is low cost as seen here - BWG832F ;
https://www.fanstel.com/open-sources-gateway/
Yes, we’ve seen this model. It’s $40.48 + shipping (VAT 0%).
We’re aiming to use external 2.4GHz dipole antennas which have better signal reception than tiny PCB antennas.
When I can test this? Is there anything in Github yet (assuming it is ESP32 compatible code)?
Sorry for the extremely late reply. We’ll announce it once we have something ready to test
BTW, are you aware of the redbear duo? That’s what I’d use!
Thanks for pointing it out, I love redbear products in general
The duo seems to be having less RAM than ESP32 and we’re already a bit short on the RAM, but if you’re aware of a project which would be a good starting point for us I’d be happy to take a look
We have an Android platform (xPlayer) with BLE support that is extensible via Android or Linux apps. Of course any Android supported languages are also available (PHP, etc). It can function as a BLE gateway.
Unit cost is 150 Euro in 1000+ volume (unit only).
It includes a miniPCI express slot that can support Wi-Fi and cell data connections, however we have used Wi-Fi for connectivity in the past for gateway functions and strongly recommend against it. Access Points connectivity can change when the environment changes (e.g. furniture or nearby equipment is repositioned), SSIDs change or passwords change. The platform also includes 10/100 Ethernet (complements the miniPCIe slot). This (or cell data) is much preferred.
Our enclosure is extruded aluminum (you can drive a small car over it).
Operational temp range is -40 to 85 deg C.
i.MX6 based with 8 GM ROM and 2 GB RAM.
HDMI (1080p) output
It can be rebranded by any purchaser.
I hope that I am not posting too commercially and apologize if I have crossed a line.
May I chip in?
Seems me the elephant in the room is cellular IoT, without which any tags, no matter how they are configured or connectable via BT, are seriously restricted in terms of use cases where wifi and mains power are not available, but cellular coverage is.
Not sure I understand. Is the concern that no mains power will be available?
For this project we assume that Mains + WiFi is available, we have something else coming up for the cellular use case
Thanks for introducing you product, it’s relevant to the discussion so I’m happy to hear about it. The price point is a lot higher than what we’re aiming for, ideally we’d be at ESP32 dev kit range.