The ability to use the OpenWeather API to provide observing conditions in Voyager is really helpful. We have some reporting stations nearby and I find the reported conditions match my site weather very well.
Separately, I’ve written a Python script which makes its own call to the OpenWeather API and filters/reformats the JSON file into a Boltwood-compatible file containing the cloud/wind/rain conditions (I also add light conditions through the Python Starfield module, based on sun altitude, moon position and phase, but this is not so important.)
I’ve set Voyager to read the text file in the Weather section, and I’m successfully using it to trigger safe/unsafe states etc (with a hardware rain sensor as backup!) I’ve had to register another address for a second API, because the combination of Voyager’s calls, plus mine, eventually exceeds the number/rate of calls available from Openweather’s free API.
In a future version of Voyager, would it be possible to extend the built-in OpenWeather functionality so that e.g. there’s a third radio button in the Weather section, after AAG Cloudwatcher and Boltwood / Clarity II options, that offers OpenWeather as a method of triggering OK/Suspend/Exit states?
Thanks for your reply on an Easter Sunday holiday!
So, at present Voyager can use the OpenWeather API to report the observing conditions, which appear in the widget, as shown here:
But (and maybe I’m wrong here?) there isn’t a way for Voyager to use OpenWeather values to determine the Conditions in the Weather settings tab, shown below. Currently I believe these can only be provided by an AAG Cloudwatcher or Boltwood-compatible weather station:
So my question is whether it might be possible for Voyager to also use the OpenWeather data like a kind of “virtual cloud sensor”, so that if OpenWeather indicates e.g. a certain level of cloud or wind, it triggers a suspend or exit condition?
All my Python script does is generate a single line file that follows the Boltwood format - it passes the Voyager Test Read check, and Voyager treats that file just like it would a file generated by a real Boltwood-type weather station. Except that it’s all coming from OpenWeather.
My script does work, so you may wonder why I’m suggesting this as a possible feature. First running a python script in the background is not a very elegant solution. But second, and more importantly, it generates additional calls to the OpenWeather API, along side the calls made by Voyager. Since weather condition data needs to be updated frequently, I eventually exceed the number of calls, or call rate, allowed for the free API. What I’m proposing is that this might be done inside Voyager, with each call sending its data in 2 directions - Observing Conditions, and Weather.
Obviously it would have to be at the user’s risk since the Openweather data isn’t guaranteed to be identical to the weather at the site. But certainly in my case, it’s in really good agreement and would work well for this purpose.
Nice work Nigel! I wrote a similar script to write a one-line Boltwood file based on OpenWeather data as well. I think you need to be careful though that the OpenWeather data is not real time, and can have up to a 2 hour delay unless you pay for a much higher tier of data.
There is a 1 minute resolved 1 hour forecast for precip that you can also use to sense impending rain. I’ve thought about adding that data and some triggers to have a message sent to me via Telegram if there’s expected rain in the near future. I think the other forecast data are all hourly.
Thanks! OK, that’s interesting; I’d not appreciated the risk of that level of delay in the OW data - so far it’s tracked pretty well what goes on at the site here, but I’ll watch that really carefully from now on. I’m still in the process of commissioning the robotic operation and quite cautious about the weather conditions - I’ve also got a Hydreon RG11 running as a hardware “last resort” sensor to shut the dome if any moisture is detected. The forecast data option is interesting - I’d not considered that, will look into it further.
By the way, does OpenWeather API work for you. For the life of me I cannot get it to work. I have a new API key, I find in Ascom my site (having entered the key) but then obtain new update data. It is bizarre.
Yes, it works fine for me, both in Voyager, and via the separate Python approach. I obtained the API key through OpenWeather first, then entered it into Voyager and used the City Name field to set my location - that seemed to work OK, and Voyager now reports the correct parameters (i.e. they match the parameters I get for that location directly from the OpenWeather website). Screenshot attached showing my settings (probably not very useful). What is not working for you?
Do you see an “Observing Conditions” widget in Voyager, but with no numerical data?
Have you tested your API key outside of Voyager? You can do this through a web browser. Just enter this address (replacing the [API_KEY] with your key):
If the API Key works you’ll see a screen full of returned data - I’ve just tried mine, and copied a screenshot showing what the web interface returns, below.
We should probably continue this in another thread outside of the Feature Requests section.
Thanks, got it working. The only bizarre thing is once connected, it alternates every second between 0 and data for the first 4 items. Is that because it is waiting for more time to calculate an average or trend ?
If there’s interest, I can share the code I’ve written for the OpenWeatherAPI and Boltwood conversion. It also writes a safety file as well that can be read by Voyager.
We will not integrate Openweather into security systems, it just doesn’t seem the case. If you want you can create your own system to translate the data on a SafetyMonitor driver but at your own risk.
