In my opinion a weather/safety tab need to be able to guarantee safety, and thus stop or pause the scheduler (and park stuff) when conditions are not safe. As such it is the top level controller.
Safety includes manual sessions where the scheduler is not even used. When someone just manually uses the other tabs to open the observatory, point the telescope, etc.

-- Hans

I fully agree, that a safety relevant events need to force the scheduler to execute a controlled shutdown. With "top level" I meant, that the Scheduler is the orchestrator of everything and as such being the center for automation inside of EKOS. All modules communicate with the other modules with signals, where some signals might have top priority - like safety events.

- Wolfgang

If I had a truly remote observatory I'd have a system to make the observatory safe that was totally independent of as much as possible. It would monitor safety things, such as heavy cloud, rain, wind, and, not least, power. When things were unsafe it would close the observatory. It should be possible to do this regardless of the position of the scope.

I would try to keep the imaging system informed of what is going on but if it continued to take images of the observatory ceiling, so be it.

I would not build it into the scheduler because one of the unsafe conditions is the scheduler or Ekos crashing.

This coud be a bit extreme for most applications where a system crash and the observatory being left open until it can be reset isn't a disaster but even with a portable scope on the patio I've had a few occasions where it got rained on.

From these posts, I understand that while Scheduler is the top-level controller orchestrating things, the observatory controller must be able to decide by itself when there is a security or safety issue.

To me that's a perfectly viable strategy: let's have the Scheduler request the Observatory (see now I use capitals for modules) to startup and open the roof, and the Observatory notify the Scheduler that it does not want to or is shutting abruptly down because of unsafe observing conditions. Orchestrator does not imply ruler. And if Observatory manages mount parking, it should be able to overcome situations were parking space is limited or requires a particular sequence.

I also consider the independence of safety controllers with Ekos to be a great point. But we have a watchdog INDI driver, we must use that.
Ekos crashes? Watchdog makes sure the fallback scenario secures the observatory. There's no point in continuing to observe if there is no more observer.
In this situation, Ekos can still be the one checking the weather to decide to terminate the observation, knowing that the crash scenario will terminate the observation anyway.

(side note: we should probably discuss the concept of redundant INDI servers some day)

That, obviously, does not prevent anyone from building an independent system to ensure the safety of the observatory.
Thus, the Observatory module should either be the controller, or delegate the control to the external system and translate its notifications to Scheduler.
We already sort of have the case with the various guiders supported, although those guiders all have a different interface.

-Eric

For protection of ekos and kstars crashes ,there is the existing watchdog driver. This works well, I have experience once for my remote observatory when kstars crashed. It parked the scope, roof and ran a script to send me an SMS. All worked perfect.
Derek

Where is the existing watchdog driver defined? I've looked and can't see any mention of it in any of the INDI standard definitions.

Chris

The code lives in the auxiliary folder.

-Eric

I just added the documentation: indilib.org/devices/auxiliary/watchdog.html

Can the watchdog driver also manage a UPS (Uninterruptible Power Supply) in case of blackouts? It would be nice to have a routine to detect the UPS kicking in and safely park, close and shutdown equipment.

Thanks for that Jasem.
One thing, the dome is parked but that doesn't close the shutter. Should the be a Close Shutter command as well as or instead of parking the dome?

I think that should be left to the dome driver. i.e. if it receives a parking command, should it close the shutter automatically as well?

I don't think so. The specificton of Park is to move the dome to a park position, that's it. The shutter is what opens and closes the shutter.