Some of us want to remove the dependency from the cloud so the desire to have cloud variables stored on the Hub is high.
Station
Station ID
Station Name
Latitude
Longitude
Timezone
Elevation
Device
Device ID
Serial number
AGL
Name
Environment
Having this data would pretty much remove the need to ever use the REST API and make applications much easier to keep data synchronized with the Hub when changes are made.
I give careful thought to requests I make in public because I know that resources are limited and one has to justify ROI. There are BIG differences in what I personally want and what is good for WeatherFlow. If one really needs more, then one can develop their own applications.
You should see the private messages I send to David and Corrine.
Well Gary . . . If your private messages are anything like your Canon flash lightning simulator (which I just noticed this morning) then you should probably collect them all into a book . . . I am sure it would sell.
But you are certainly correct about being careful not to ask for wild enhancements. This WF product is already remarkable, especially for its price point. Possibly a pro-sumer version down the road will be a product to load up with some of the wilder features.
Hi Gary. It’s very unlikely we’d store these “application level” settings on the Hub. The hub has minimal storage capacity and our approach is to treat it as a “generic device” with all application-level metadata stored elsewhere. That is, the Hub doesn’t know where or who it is.
But, but, but… If you stored that data it would know where and who and when it is.
It’s just a thought and would be a low priority IF you should ever consider it. I understand it would require a new method to retrieve that data and a lot of new code so I don’t expect you to put a lot of thought into it.