Hi Gary. Sorry for the frustration. I thought the RTI driver used the local UDP data, not the API. The device_id is not stored on the hardware and has no natural connection to the physical device. It’s a “surrogate key” in the database sense. You also get a new device id when you “delete” a device through the app (even if you add the same one back). Deleting the data or the entire device has the same result. Likewise, deleting a station will result in a new “station_id” if/when the same devices are re-added to an account.
That said, the device_id is relatively permanent, so your RTI driver users should be pretty safe. Deleting all data from a station should be a relatively infrequent event for RTI users - as would deleting or replacing a device (or station) itself, hopefully. All of those events should be pretty rare.
Of course, keeping track of a user’s device and how it maps to other things in other systems is an application-level issue - and not a trivial one. There is no getting around the fact that things change over time. The most meaningful information in the Smart Weather ecosystem is the user’s account - all meta data (including station_id’s and device_id’s) flow from that: Account->Station->Device. The other potentially meaningful information in a Smart Weather Station is the serial number, which is physically stored on each device (and does not change). Of course, accounts can change too, and if the user replaces a physical device they’ll get a new serial number as well - so there’s no perfect solution here.
One approach you might consider is to have the technician link the RTI system to the user’s Smart Weather account via Oauth2. That’s the way our Amazon Echo, Google Home and IFTTT integrations work, and it’s kind of the defacto standard for linking two cloud-connected systems together. The user (or technician on the user’s behalf) would authenticate the Smart Weather account through he RTI driver, storing the access token instead of the device_id. The driver could then use that to access all other data. The RTI driver could still store the device_id for convenience, but it would be able to go in “from the top” if/when necessary to discover the device_id when needed.
One more thing to consider is the “station observation” construct that’s available via the API. This is a “federated” data object that solves the problem of having more than one device producing the same parameters at a single station. This is what we use for Amazon Echo, Google Home as well as the Weather Underground data feed. It’s one fixed set of data for any sort of station configuration.