Hello
For various reason I deleted (using the APP) the data from my AIR and SKY, I have done that before and will most properly need to do it again. But this time my devices (SKY and AIR) can no longer be accessed using the API, I just receive a JSON with: status_code 404 status_message “NOT FOUND”
But, I can access latest station data using the API.
Anything else seems to be working as it should, HUB is broadcasting udp-packets.
Anyone tried this?
Regards
What is your station id?
4990
Thanks.
Regards
I just checked and it’s all working fine. I get data on your Air and Sky.
What URL are you using?
This is my SKY:
Hmm wait a minute, my device id’s changed
Before:
SKY:14324
AIR: 14323
Now:
SKY:15064
AIR:15063
Is that normal?
Regards
Yes, your device IDs changed.
That’s very strange. Instead of deleting the data, it creates new device IDs.
David, @dsj @WFmarketing @anon84912554
Is this really the intended action? This just seems wrong on every level. This needs to be explained as it seems it is not deleting the data but replacing it with a new ID.
Yes!
What is more strange is that the ID’s did not change previous when I deleted the data.
Regards
This is expected behavior. The system creates a new device ID when the “Delete Data” option is exercised. This new device ID replaces the old device ID associated with the station maintaining all metadata for the device.
Ok, thanks.
Stange, maybe its just me but I think that one time the old device id’s was continue working after I deleted the data.
Anyway, we found out what was going on.
This is actually unexpected behavior for me and has caused an issue for those with RTI devices. The driver depends on the Device ID entered when the installer sets up the RTI hardware for the customer.
A change in Device ID means a $$ service call for the customer to have the installer to come reprogram the RTI hardware.
This is very frustrating. A year into development and I just now discover this.
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.
Will you consider a warning?
Delete the device data will changes the Device ID.
However, now that I know I can handle this in the REST code that is used.
By-the-way, I get frustrated, I bug you, I get over it a minute later.
Sometimes I even go mow my yard in 90 degree heat.
In the end, I make it work.