Open jimaek opened 2 weeks ago
We already have this in https://github.com/jsdelivr/globalping-probe/issues/240. For HW probes, I was actually thinking we let the firmware itself generate the UUID, store it, and expose it to the probe as a variable. The probe itself doesn't need to write anything.
@jimaek , if the issue is to have a reliable UUID, we can use the hardware's unique identifier. It will persist even across sdcard swaps....
How is it generated and how reliable is it?
I would rather preserve a way to change it if needed. It should survive restarts and container updates, but a full FW flash should get a new ID.
@jimaek Well, it uses the factory-set SN and other unique data on the chip. If the factory doesn't commit an error, it should be pretty unique.
I assume to expose it we would need to flash a new firmware? If we could enable it for everyone with a probe update it would be interesting. But if not then up to Martin
Yes, it requires a new firmware. Add it to the next version bucket list :)
I think it makes sense to create a new small volume with like 10MB of storage to save there something like adoption info, to avoid losing probes when the IP changes when the probe was offline.
@kernelgurumeditation is there a safe way to do it to avoid killing the SD card? Maybe enabling RAM caching of the files, or some other configuration?