To clarify, your description is what is seen if, telescope blocks dome is used, and just indi participating. The dome is blocked by the telescope. Wolfgang's request to do a test was to involve the client by using the scheduler's weather alert detection to initiate both telescope and roof parking. Your description did not mention the scheduler.

In my case it is a rolloff roof, so you have the additional complexity of the dome to deal with. Not clear about how the shutter relates to the roof open/close and the dome park/unpark.

Without Scheduler, almost certainly NO. Using the Scheduler, almost certainly YES. You need to check the weather constraint (see my posting above) and select a shutdown procedure with mount and dome checked.

Regarding the synchronization of shutter and dome movement, I would not rely on the Simulator. I'm quite sure that this is manufacturer dependent.

I also tried using the RoRSimulator. This doesn't have a shutter, just a roof park property. In that case it is the same as in the first case, with the shutter not set to close. In fact there is no close shutter option in the Ekos Observatory module. The dome/roof park function is inhibited by the telescope dome policy and so the roof can't park and because of this the telescope does not park so the roof can't.

That's how the simulator behaves. A real roof could be made to work by implementing it as a dome. The 'shutter' property would just simulate a shutter but not move anything but its 'movement' would trigger the telescope to park. And when the telescope was parked the dome would close the roof. This only seems to work with Ekos, the observatory seems to see the weather change and closes the shutter, this triggers the telescope park and that triggers the dome park.

I ran a quick test with the scheduler, having dome and telescope set to ignore each other. I changed the weather in the simulator to an alarm state and the following happened:
As you could see, the dome started to park as soon as the mount parking is finished. This was a test completely without the Observatory settings.

I'm actually thinking that this whole discussion highlights that this management of what shutdown first should be completely left out of the drivers. The INDI drivers should be minimal and do their job. Right now, we have communication between drivers that are trying to perform some complex interlocking shutdown procedure. This should be definitely left out to clients to handle in my opinion. Maybe the whole thing should be removed from INDI drivers.

Nevertheless, there is ONE specific drivers that's whole purpose is to protect these drivers, it's the Watchdog driver. Currently, the watchdog driver performs a complete shutdown if it loses connection with the client. I suppose this driver can be extended to snoop weather data as well. This way, you don't really have to use Ekos (if you want to) to perform shutdown and just let the watchdog driver handles it for it. It would remove all the complex interlocking scenarios we have to account for. Such options could be left out the clients, whether that client in INDI Watchdog driver, or Ekos or CCDCiel ...etc.

I see your point but isn't the whole Indi snoop system designed to allow drivers to interact at the driver level? This seems to be useful for interactions such as telescope/dome synchronising.

Responding to weather also seems to be in this category because it is the sort of thing that should be running all the time, regardless of what applications are running.

What we have at present seems to be partially implemented in indi, and partially implemented in the Ekos Observatory and Scheduler modules. This is where I think it has difficulties. It is difficult to know where and how to set it up. It also seems only to be fully active when a sheduler task is running.

What we have in the drivers at the moment seems close. but what I'd do is make each driver only responsible for actions to it's own hardware, something like this:
The Dome driver snoops on weather and telescope and has a dome policy property which specifies when the dome/roof can be parked. This manages the dome parking depending on the snooped states of the weather and telescope.
The Telescope driver snoops on the weather and dome. The only property is needs is a boolean to say if it must park when the weather is bad. It doesn't need to wait for anything. When the weather reports bad it parks.
The Weather driver handles generating the warnings and alerts. If delays to prevent false alerts because of transient events are reuired these are implemented here because this driver is aware of the weather properties it is monitoring. For example it may want to delay because of a cloud event but definitely not if it starts raining.
That's it.
When a weather alert is raised the telescope sees this and parks. The dome/roof also sees this. It can close immediately if its policy allows or it will wait until the telescope is parked as well before parking.

Ekos need not be involved at all although there's noting to stop it handling things for itself, in particular the routine close down at the end of a session.

The main change seems to be to add weather snooping to the telescope and the associated telescope park if the weather is unsafe. The dome driver may not need changing at all.

Not sure how Jasem's watchdog driver should be involved, it seems to be a combination of a driver and a client. When it's trigggered it sends park commands to the drivers. It could have weather snooping added, becoming a fourth way to manage shut down.

I am working now on the updated Watchdog driver, which is indeed driver/client combination. I believe with this driver, it removes the whole orchestration complexity required for this shutdown procedure due to weather. I will share the driver once done.

I think the complexity here comes that there is not THE dome and THE telescope, but many variants. And on top of it, quite complex decisions to be taken how to act. Do we need a threshold before reacting on alerts, how do we react on warnings and that in combination with all the variants whether a dome and its shutter should wait for the scope being parked.

My conclusion is, we need to separate orchestration of devices from lower level device control. Being it the watchdog, the observatory module, the scheduler or something entirely separate - everything has its ups and downs.

Going ahead and increasing the dependencies between the single drivers is the wrong way. Drivers need to be 100% robust, therefore we should leave the "stupid" and accept, that they cannot resolve every possible situation and leave the more sophisticated controls to the layer above.

Wolfgang

Fully agreed! If we find here a common understanding, how it should be, I will go ahead and implement it. But currently, I do not see an agreement how it should be.

I personally tend to a logic where the observatory has a "Start" and a "Stop" button which both have a flexible way to graphically configure the start and stop procedures. If this is in place, I would replace the startup and shutdown procedures from the Scheduler by a simple option to call "Start" and "Stop" in the Observatory.

So please give me feedback if this is the right direction - or share your own ideas - so that we can move forward.

Cheers
Wolfgang

Ok I pushed the updated driver. This also requires updated Ekos since the client watchdog now uses seconds instead of minutes to be consistent to weather watchdog. So to test, both INDI+KStars must be updated to latest GIT.

Now the watchdog driver has a Client and Weather watchdogs that can toggled. Previously, it was only client watchdog which would trigger shutdown after communication loss with client. Now I added weather watchdog as well.



Regarding mount locking, it's added in Options



So the watchdog driver should be now sufficient without any external clients (Ekos..etc). The watchdog is a driver/client hybrid so it can orchestrate this without requiring any complex inter-driver communication. Please test this and report back any issues. If all goes well, I believe we ought to remove the weather handling in dome class completely. I even think the mount/dome locking policies can be removed and moved to the watchdog driver. The watchdog driver can monitor both drivers and enforce the policy if it detects a violation. But this is another issue, let's tackle it one at a time.

Looks really nice! What about if we give the Watchdog a UI representation in EKOS but leaving the entire controlling logic inside the watchdog driver? And we should then be so consequent and remove all dome and weather related stuff from the scheduler as well.

Is Indi only expected to run with Ekos? I thought that Indi was a generic astro hardware control standard, much as ASCOM is.

The Watchdog looks good, am pulling and rebuilding. Keeping this away from people who don't need it is a good idea.

I'd keep the Watchdog entirely separate from Ekos so it becomes available to other applications.

I'd be in favour of removing the snooping from the dome and telescope base drivers although the dome may need to continue to snoop on the telescope to implement dome sync. One thing, are there other clients that are depending on the current dome and telescope park interactions?

How complex are the scope/dome interactions in reality? In some cases the scope must be parked before the dome/roof is parked and the dome/roof unparked before unparking and moving the telescope but that's it isn't it? One boolean - park dome/roof first or not.

Managing alerts and warnings with appropriate delays seems to me to belong in the driver that generates the alerts and warnings. With ASCOM we had safety monitors with one property - Safe. We could have multiple monitors for example a SafeToOpen monitor to manage opening and closing the observatory and a SafeToObserve monitor to manage the observing process. SafeToObserve could go false on thin cloud or twilight, SafeToOpen may need heavy cloud or strong winds. With the warn and alert system I'd use warn to manage observing and alert to manage the observatory.

As for agreement full agreement is probably not possible. Somebody is sure to have a system that this can't cope with. Something that works for the majority of people is probably the best that can be done. There is always the option of turning the WDT off.