Hello,
This question is directed to anyone with a stationary observatory.
I have the scope dome roll off roof with a scope dome rain and cloud sensor + a hygrometer.
I also use the SQM which talks to Scope dome. The other weather sensors I have is a separate weather system I use in close proximity to the observatory. This generates and API key which Scopedome speaks to.
My question here is; what will the settings be in SGpro with regards to the sensors etc?
I have a similar setup but with a 3m dome, this is my configuration, give it a look and let me know more specifically what you need.
Hello and thank you for the reply.
as I wrote previously, I am a bit confused as what to put in these settings.
The sensors I have is showing up on the internal sensor tab is shown in the attachment. However, when I try to configure them I get a connection error.
Basically they are all working in ScopeDome, but they dont seem to be talking with SGpro. Im sure its just something I am missing.
I see that you have open weathermap instead of your local ScopeDomoe sensors. Why is that ?
Here are some screenshots of my settings.
I tried your configuration and have the same error, I think this is not the right way to configure the internal weather sensors maybe we have to ask to Jacek Pala owner of Scopedome.
The other possibility is to find if there is a possibility to trigger a safety event. I have an AAG cloudwatcher and if it goes overcast or detects rain, it sets an ASCOM safety event. In the case of the AAG, it writes a Boltwood compatible text file and the ASCOM safety driver reads that.
A further possibility is to use a utility written by a fellow SGP user. Do a search for ASCOM observing conditions safety driver or similar. It monitors the ObservingConditions hub driver and sets a safety event based on your criteria
I have the same condition, this is wath I’m using very cheap and 100% functionality
With a simple webcam you can setup a cloud rain sensor, unfortunately I’m unable to set it up in to Observing Condition Hub since the Ascom driver is only for a safety events, but, as workaround and for safe conditions I set it up only as a Safe condition switch.
@Geremia_Forino I bought that a few years ago but never got it working reliably. I think it may have been the camera choice. If you can PM me some details, I will take another look.
I found something interesting regarding the connection between my Explore Scientific weather station (Weather Underground API) just in case anyone else is using this.
This may work for the main weather station that I have. I will get up to the observatory this weekend and try it out.
As for the settings for the ScopeDome internal sensors I have no clue yet. Trying to get some help from them. Lets see how it goes.
The observatory came with a very nice cloud/rain sensor which works perfectly well in ScopeDome, its just a matter of getting it to speak to SGPro which I didn’t think should be such a mystery. I figured since ScopeDome is showing as an option in SGpro, that would be the natural choice for me.
Here is another question; OBSCON. Does this speak to ASCOM observing and safety conditions ? Do I need to set this up separately if I want to use OBSCOM ?
Thanks guys 
No problem buzz, I give you a shot on Friday to define how we can be proced, it can be more easy if you have a remote connection on the PC with Tektite Sky, explaining is a little bit complicated.
Unfortunately not. ASCOM is made of several distinct devices. A Dome device does not have weather information, only an Observing Conditions device has. For instance, my Pegasus powerbox has three separate associated ASCOM drivers - one for switches (dew/power), one for observing conditions (temp/humid) and a third for focuser. In your case, there would have to be a specific ScopeDome ASCOM driver for weather conditions.
Hello Buzz,
Thank you for clarifying this a bit. So what you are saying is that I will need a separate ASCOM driver for the Cloud and Rain sensor for ScopeDome? I do not believe such a driver exist yet. In ASCOM standard site it only states that this driver passed the test and then it refers me to a site which is unavailable.
Anyway, I think I managed to connect the Wether Underground API with ASCOM now, but not sure if its working. How can I check in SGpro?
I see that my SQM is showing data, but not the weather station. It just dont show any connection errors.
Following up with some screenshots
Hello,
Just to clarify; ScopeDome has its own cloud sensors but (see screenshots) there is just no way to communicate them through ASCOM ? These are purely there for ScopeDome to initiate commands if it detects bad weather ?
If this is the case, do I even need Asscom Observing condition Hub or readings in SGpro? If the observatory (ScopeDome) does this all on its own?
I just hope the ScopeDome overrides any commands given by SGpro in that case.
Seems like they need to release a driver for all that useful information. It is not difficult to do. I see that it is an Arduino-based and, for info, I made my own Arduino weather monitor and managed to do an ASCOM driver with comparative ease.
I guess the overriding question is, could SGP cause collisions if the roof and SGP are working independently? For instance, if the roof’s sensors cause the mount to park and roof to close, could SGP accidentally slew into the dome/roof? I tested my own ROR driver with a substitution box to check all the sensor combinations but also sat out in the shed, with a watering can and validated how things worked and tried to fool SGP into slewing into a closed roof. I suggest to look at the slave settings carefully and validate with a hand on the power switch before you trust it out of sight.
Hello Buzz,
Seems like it.I saw someone post something about and ASCOM driver that was called Arduino Observing Conditions, but I am not able to find this anywhere.
Yes this is my concern, I hate to see my telescope ruined because of this. Unfortunately I do not possess such programming skills so I guess I will have to wait until something comes along.
If the Arduino sends a simple string (which is normally the case), it would not be too difficult to decipher it. That is all my unit does and would just require a different parsing of the signal within the ASCOM driver. Is there any documentation on communications? It is worth a quick look to see if it is doable.
Hello Buzz,
Thank you for taking time to do this.
There are allot of scrips here and I am unsure which one to share.
Here is a screenshot of what scripts I can find. Let me know which one you would like to have a look at?
I think it is more likely to be in the documentation. There may be something that says how to interface to it. Like this one:
under protocol.
If I had known about this protocol for this device, I would have made my Arduino unit mimic it, removing the need for writing my own ASCOM driver
Hello Buzz,
The only manual I can find is this one. But I an not able to find anything like you sent me.
Juding from the profile picture id like to say I miss your Youtube tutorials
