When using the Scheduler, a Weather ALERT leads to the sequence park mount --> park dome (if both are selected). Weather WARNING is ignored by the Scheduler.

For the weather alerts it obviously needs to work without the scheduler, so having the Observatory first park the mount and then the Dome seems clean.

It looks like the scheduler is already aware of the alert but I don't know how it responds to that.
If logic is to be placed in the Observatory to wait until the mount is parked before parking the Dome, perhaps the scheduler can respond knowing that. It does not seem much different than how it must presently resolve the parking of the Dome knowing that the Observatory is probably already doing that because a weather alert has happened.

Does anyone know what added value the Dome property Auto Park provides over the other Dome/Mount policy combinations. Is it just a if you want to do anything useful do it at your own risk kind of a setting.

You mean that if I schedule a photo shoot and there is a weather alert it will end the session and suddenly it will be like a normal end of session with the setting on the park of the frame and then close the roof?

I wouldn't involve Ekos at all. what I'd do is:
The Weather driver sets some sort of unsafe property.
The telescope and Dome snoop on this and when it's set:
The Telescope parks. It ignores whatever any application is telling it to do, it parks. No options, no choice.
The Dome continues to snoop on the telescope and when it's parked and the weather status remanis unsafe it makes the observatory safe.
Ekos is no more than a spectator in this. It could do something sensible but it doesn't matter if it doesn't, no one is paying any attention to it.

Actually I would try not to involve Indi either. I'd have an observatory that could close regardless of what the telescope was up to and I'd have a hardware signal that triggered the make everything safe process. It's the only way to be sure.

Makes a lot of sense to me.

Would it also make sense to make it an orderly 'shutdown' procedure that could also be used when the scheduler or the user has finished its tasks for the night? Not wanting to overly complicate things though.

Thanks.

Folks, could you please do me the favour and test the behavior of the scheduler? My impression is that most of the behaviour you describe is already present in the Scheduler.

The only thing that you need to do is using the Scheduler for your nighttime capture session and define scheduler jobs that

1. has the weather job constraint selected
2. has a shutdown procedure defined with at least scope and dome parking selected

Testing this should be quite easy using simulators for scope, CCD, weather and dome. Start the schedule job and see what happens if you change the weather condition in the INDI tab for the weather such that it changes to ALERT state. As soon as this happens, the job should abort, the mount should get parked and finally the dome should get parked as well.

Wolfgang

I can test with my mount/scope and obsy side by side so no collision can occur but, unfortunately I have never used the scheduler (tried quickly without success 30 minutes ago) and must figure out how to use it. Furthermore, I won't be able to test for a few days. I would have loved to but I will be away from my setup.

This works, but for some setups, I'd like the roof/dome close ASAP and not wait for the telescope to park first. Every seconds matter. I have a rolloff roof and there is no collision issue, so on WEATHER_ALERT, I want both actions to take place at the same time.

Another related topic is that this needs to be done when the ALERT is confirmed. What if Wind goes over the max limit for a couple seconds before going down to normal? Should such ALERT cause a total observatory shutdown or there should be some threshold management. Right now, the INDI::Weather immediately sets the ALERT once a threshold is exceeded. So maybe this issue also needs to be considered.

Looking at the Telescope, Dome or RoR and Weather interface it seems pretty easy to get much of what you want. At present the dome snoops on the weather and the telescope snoops on the dome. The dome sees an alert and closes/parks. The telescope sees the dome parking and also parks.
I think this needs the dome policy in the telescope driver to be set to Both and the telescope polity in the dome driver to be set to ignore telescope.
Auto Park is enabled.
When the alert is seen the dome starts to close/park. The telescope sees this and parks. There's a race between the two.

What seems to be more difficult is to set things so that the telescope parks first, then the dome parks. You can set things - the dome policy I think - so the dome will not park with the scope unparked and the scope seems to see something and will park. But the dome/roof doesn't then see that the mount has parked and continue to park it may be nice to close the roof as soon and possible but not when doing so will crush the scope.

It looks as if setting the dome policy in the telescope driver to both will require that the telescope is parked before the dome/RoR closes and parks and also that the Dome/RoR is unparked and open before the telescope is unparked.
Then setting the telescope policy in the RoR driver to telescope locks will stop the RoR closing until the telescope is parked, but now the dome is waiting for the scope to park and because the dome isn't parking the telescope won't park. A deadlock.

It looks as if there isn't an option to park the telescope before parking or closing the dome, the best is to do both at the same time.

Managing the response time for an alert seems to belong with the weather driver, this is more likely to know what is reasonable for the different properties. They could each have their own.

If changes were to be made to the indi Dome code, having a third telescope option would be useful: ignore wait or block.
Park both dome and mount at the same time or wait on the telescope might depend on what is mounted. With a small refractor I have no collision issue, with an SCT it needs protecting.

Wolfgang,

I ran a 2 tests using the scheduler and simulators. Both test were run twice once with the Observatory set to park dome on alert and once with that unchecked. I did not see a difference whether or not the Observatory was involved.

Test 1 the telescope used the "Dome Parks" policy and the dome used the "Ignore Telescope" property. With this combination when the alert was triggered both telescope and roof parked together. So that was the same result as
when the scheduler was not involved.

Test 2 the dome was changed to telescope blocks. With this combination the when the scheduler sensed the alert the telescope started parking and the roof output a warning that it could not park. Same as the none scheduler case, but when the telescope had parked the roof driver output a message indicating a changed of telescope status had been sensed. I then proceeded to park the roof as hoped for.

So using the scheduler along with policy combination worked well to provide whichever behavior was wanted.
Not extensive testing but promising.

You appear to have said "I then proceeded to park the roof as hoped for.". Do you mean that you were watching things and that you clicked on the park dome button to park the dome? Or was there a tiny typo and you intended to say "It then..." meaning that the system parked the roof once the scope was parked with no intervention on your part?

I wouldn't normally nit pick about typos but in this case it could be significant.