After spending 35 years in the aviation industry where we are totally driven by weather forecasts, my only response to that is, forecast is irrelavent. They are wrong far more often than they are correct.

If I had it to do all over again, as a teen, I would have gone into weather forecasting. It's the only job I know of where you can be wrong 80% of the time, not get fired for it, and end up with a fat government pension at the end.

ok, if a forecast is irrelevant then how do you propose we monitor the weather for the Ekos scheduler?
It's all well and good for someone to go outside and check what the night looks like, but that's not what I can do (I'm sure others are or will be in my situation).

Are we going to rely purely on local sensors giving you information on the spot?
Surely a forecast is to be considered/introduced in the Weather class at least, maybe not as a top priority to decide if it's safe or unsafe.

In our case, all decisions from weather stuff will be based on 'here and now'.

One of my projects for this winter, is to analyze all sky data for things like cloud cover etc. This is what the all sky data looks like for us now



One of my projects this winter, analyze that data frame by frame as it comes in, and generate numbers for cloud cover etc. Right now, I have an indi server on the computer capturing data, then it just stores fits files, I mangle them later to produce the movies. My goal, and it's a bit of a high reach, is to have the program that is analyzing that data, produce real time numbers for cloud cover and sky darkness, things that will be very useful for making the 'here and now' decisions.

I'm not saying forecasts cant be used, I'm just saying they shouldn't be some form of 'must have' or otherwise necessary thing. For a first start, the important thing is homing in on one property which clients in general can use. How it gets set, is for now, observatory specific etc, so my suggested implementation is to have one driver that does nothing other than get/set the property regarding 'safe / unsafe'. All imaging clients should monitor that property, and if it goes to unsafe, park the mount. We can then write dedicated clients that connect to things like weather data etc, and do the logic to make safe / unsafe decisions, and they will likely be unique to each early on. As we gain more experience, then we can start working toward what amounts to a 'de-facto standard' client to do that same thing.

Would I like to see something I can just download, build, and run to make safe / unsafe decisions ? Yes I would, but, it doesn't exist (yet). But if we home in now on one property that is that decision, after it's been made, and clients honor it, then we have the means to start working on various implementations for setting it. I think eventually a lot of good thoughts will come from experience, and, eventually a fairly robust 'does most installations' implementation will come out of it. But the real issue now is, we dont have any implmentations, and only a very limited set of installations to work with on the 'learning experience' of it all.

The forecast wouldn't matter to decision making for "now". It helps in planning your observations, but that's pretty much it. If Ekos schedules a job at 8 because the forecast says it's "clear" and then 8 comes and it's raining, what will it do? It will not perform any observation (or open dome..etc) because the "now" weather sensors says it's raining. So regardless of forecast, we have to rely on the weather sensors/services to decide "now" conditions.

So I added a "Meta Weather" driver that can watch up to 4 weather drivers and reflects the "worst" case of the drivers. In this instance, you can have multiple sources and if one of them goes alert, the overall state is alert and the observatory goes into shutdown. This should be sufficient to decouple the client from any weather analysis details, it is all done on the driver side.

I'm back here, been busy with stuff and more boring stuff...
Anyway, what is this "Meta Weather" you are talking about please? Is there more information on how to use it please?

I've tested it, it's quite a nice driver.
What I've done now is separated my rain sensor (driver to be realeased soon) module from the custom compiled WunderWeather driver.
Planning to add an anemometer to the observatory too.

Found a spelling mistake in the WunderGround driver, under the tab 'Main Control' it's written as:
Percip (mm) instead of Precip (mm)

edit:
same applies in the 'Parameters' tab.