Weather Underground Observing Conditions ASCOM driver

General
1

Messing around on the internet trying to figure out how big a project it will be to get my cloud sensor sky temp data into SGP, I found a way to get my Acurite 5N1 weather station data in there:

Here is a package that will load the data from ANY weather underground site (so I used mine, which is the 5N1 weather station):

https://github.com/EorEquis/ASCOM-WUAPI-ObsCon

just download a zipped copy of that github, unzip and go into the ASCOM-WUAPI-ObsCon-master\WU_ObsCon folder and run the setup exe (on your telescope computer).

In SGP, pull down the “Extra equip”:

and Select Wunderground… for Environment. Before you connect, click on the wrench to enter your closest WU site ID

Look at the bottom of this page to see a list of stations in San Jose, or use the location search at the very top:

The site id is listed on any station page you click into (after the name) or you can see it in the URL. e.g.:

https://www.wunderground.com/personal-weather-station/dashboard?ID=KCASANTA2491

for station ID KCSANTA2491

That’s it!

For more info open the SGP help file and take a look at the “Environment Devices” topic.

You can use the ambient temp from weather undergound to control focus events (vs. a temp sensor on your focuser itself) and if you are using SGP notifications it will alert you if the temperature is within 4 degrees of freezing or dew is about to start forming.

Note that there is no link to “safety” features like closing a roof or alerting on precipitation etc.

Your fits files will include the weather data in the header.

So maybe not everything one would want, but a big step forward in weather data.

I will be hacking the code to also read the sky temp from my Phidgets IR sensor. I’m about 50% of the way there so far.

Cheers

2

Hi! Author of that poorly written confusing ball of junk here! :slight_smile:

I’d love to see what you come up with as you hack it apart, and am eager to hear of any improvements you make! Also happy to answer any questions…if I can remember what the hell I was thinking when I wrote that!

3

Ha Ha, you sound just like me when describing code I’ve written.

I don’t claim to be a “programmer” (at least not since the 80’s) but I can usually sling syntax (in whatever language) at something to bend it to my will :wink:

So I have two goals in mind, mostly around my Phidgets IR temp sensor:

which makes a quick and excellent cloud sensor for astro imaging.

  1. Get the sky temp (the ir temp from the module) into fits headers to assist in sub grading

  2. To use a sky temp > 0 degrees c as an “unsafe to image” value for SGP

Looks like #1 requires ascom observing conditions and #2 ascom safety monitor.

So your code is helping with #1, but needs to be modified to read the Phdiget. Fortunately, there is working VB.net example code:

https://www.phidgets.com/downloads/phidget22/examples/dotnet/vbnet/TemperatureSensor/Phidget22_TemperatureSensor_VBNET_Windows_Ex.zip

That I hope to get around to adding to your code.

I had started with a different approach, but realized half way through that I was building something that depended on client side javascript, so a browser, which I wouldn’t have from inside your program :slightly_frowning_face:

I had previously used a client side javascript example to add a realtime plot:

image
image1922Ă—1112 860 KB

Anyway. That’s where I’m at. Any chance you would be motivated to update your code with the phidget support and/or write a ascom safetey monitor?

4

I don’t claim to be a “programmer” (at least not since the 80’s) but I can usually sling syntax (in whatever language) at something to bend it to my will

I love that description, and am using it from now on!

quick and excellent cloud sensor for astro imaging.

Yep, that’s a pretty common method for cloud detection. The question I’ve NEVER seen appropriate answered though is this : What happens when that temp sensor gets covered with dew?

I’ve pondered the idea of maybe covering it with a little bit of plastic or something on a servo, and swinging the cover out of the way with a servo…but that project has yet to progress beyond the “Hrm, i wonder if…” stage.

Any chance you would be motivated to update your code with the phidget support

Absolutely!

If you get something working w/ the Phidget, let me know. Or, just issue a pull request in the dev branch of the code, and we’ll figure it out. I’d be chuffed to add a cloud sensor to it…that’s the one really nice thing to have that hitting a “weather report” doesn’t really cover.

and/or write a ascom safetey monitor?

I actually played with…gah, I wanna say it’s @Chris’s work??.. the boltwood driver here which includes all the code. It’s ridiculously simple. The thing really only does one thing : Set an IsSafe property to TRUE or FALSE. Everything else can be handled completely external to it…in other words, how you determine “is it safe?” is entirely up to you. You can write whatever you want, however you want, to monitor anything you want. Read your cloud sensor, poll the google news API to see if aliens have landed, whatever.

Then, all you have to do is, say, set a text file somewhere, and tell that ASCOM driver “Read the text file every ____ seconds”, and flip that property based on the contents. Or hell, you don’t even need to read the file…just see if it’s there. If it is, it’s safe, if not, not safe, or however you want to do it.

If you want to hack up my OBSCON stuff to read the Phidget, then I’ll toss something in to manage a simple text file or something, and we can bash something together in the SafetyMonitor interface with a quickness.

5

hmm,

I haven’t had any dew since I deployed the sensor, or if I did it didn’t make itself noticeable. Since it has a 10 degree fov, I just have it in the plastic anti static bag it came in (with a hole for the lens to stick through) and gaffer taped to the front of my mount. That was supposed to be just for testing, but I never went back and made a housing. Now I want to move it onto my OTA, so it’s actually pointing at my target vs. just at the RA coordinate. Hmm, Maybe I’ll spray it with a mister and see what happens to the temp reading.

Since that unit comes with a USB interface and windoze software, it seem easier and less costly than the hole Adrino or Raspberry Pie kind of approach. Integrated 10 degree IR lens as well.

More on the coding stuff later.

6

“Haven’t had any dew”…here in Middle TN, we wouldn’t know it was a summer morning if we weren’t splashing our way to the car. :rofl:

Yeah, I’d be curious what happens to the sucker when it gets covered with moisture, as anything I deploy here is certain to do so.

Taking a quick glance at the Phidget code stuff, doesn’t look like it’ll be too terribly difficult, and I agree…not much sense in going the Arduino/RasPi route, unless mounting location makes running a USB cable impractical.

Seems pretty straightforward. Give it an ambient:sky temp difference…if above that difference, it’s clear, write a 0 byte text file somewhere named “safe.txt”. If the difference is below the threshold, delete the file.

Tell the ASCOM safety monitor to look for that file. If it finds it, IsSafe=True. otherwise IsSafe=False.

Bam. Done.

7

Interesting, I asked a similar type of question last week - wondering if anyone had written an ASCOM driver to get information from DarkSky. The iOS app gives updates on approaching rainclouds which is usually very accurate. There is a GitHub page for the API in various languages and wondered about slinging some syntax around myself to do a safety monitor.

8

wondering if anyone had written an ASCOM driver to get information from DarkSky.

Dropped that idea the moment I found out they charge for API calls beyond the first 1000/day.

(Not saying I’m opposed to them charging for their service, just didn’t want to go the route of each user needing their own API key)

9

But you could check every 30 seconds, in an 8 hr night, and not exceed 1000 API calls.

I think for any weather service you would expect to have an API key.

10

But you could check every 30 seconds, in an 8 hr night, and not exceed 1000 API calls.

Right. Any given individual could. But then the next individual would push you over that, unless he/she had their own API key. I did not want to write something that required each user have their own API key.

I think for any weather service you would expect to have an API key.

The one that is the subject of this post does not. :slight_smile:

11

IR sensors see dew as warm water, i.e. low cloud. It may be possible to warm the sensor slightly to keep dew at bay, rather like a tiny dew heater. Rain sensors do this.

12

I was assuming that each individual would have their own key and it would be part of the ASCOM setup dialog. At the end of the day, the risk to my equipment is worth something. Meteorology is notoriously unreliable but I when I check my various iOS apps in the evening, DarkSky is the most reliable so far. I still need to check out weather underground. If it is better, then sign me up for beta testing!

13

Looking at their information the intent is that a developer/supplier has one key and all their users use that. The supplier is expected to pay for the user’s access and recoup this cost in some way.

They dissaprove of this being circumvented by each user having their own key.

1 Like
14

thanks Chris. That is a shame. Might just have to try to do my own one then…

15

So it would appear this project no longer exists?

or is there another home for the ASCOM driver?

thx

Brian

16

Correct, the Wunderground API was EOL on 12/31. No, there’s no other source.

17

Hello there,

Maybe someone can guide me in the right direction here.

I have installed the ASCOM WUAPI driver and it shows up in ASCOM Observing Conditions Hub.

I have typed in my station ID but it dont seem to work at all. HELP! !

Following up with some screenshots

18

Screen Shot 2021-05-28 at 12.13.38
Screen Shot 2021-05-28 at 12.13.381652Ă—1382 153 KB

Screen Shot 2021-05-28 at 12.13.49
Screen Shot 2021-05-28 at 12.13.491576Ă—1388 111 KB

Screen Shot 2021-05-28 at 12.49.34
Screen Shot 2021-05-28 at 12.49.341474Ă—1318 291 KB

Screen Shot 2021-05-28 at 14.05.42
Screen Shot 2021-05-28 at 14.05.422850Ă—1698 277 KB

19

Note: I do see that someone has written that its EOL, but since ScopeDome can read everything from WU, isn’t there a way to connect it to ASCOM Observing Conditions through ScopeDome ?

20

Potentially, but that would be something to work out with the ScopeDome driver developer. Maybe they have an Observing Conditions driver that exposes it? Guessing they’re reading Weather Underground data differently than the ASCOM Observing Conditions driver was.

Jared