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.

Eric,
it seems like your initial question is answered meanwhile. What about if we start with extracting all the observatory stuff to a new tab? This is a) not too big, b) more or less isolated inside of the Scheduler and c) might help us developing the target architecture of the overall.

The weekend is close, weather is rainy, best conditions to start hacking

Cheers
Wolfgang

If everyone here agrees that we would have a benefit in having that Observatory module, indeed, that seems a good idea to me! The new module can receive the relevant Scheduler functions without too much difficulty. The whole startup/shutdown state management can move (checkStartupState, checkShutdownState, checkParkWaitState, executeScript...). And we need tests too. Let's then work from there to enhance that new module further.


Agreed, the watchdog driver was helpful multiple times for me too.


As it is now, the watchdog listens to a heartbeat from the client. When that heartbeat fails, the watchdog driver itself connects to its registered indiserver as a client, requests parking to mount and dome, and execute the shutdown script. To achieve what you propose, you would need an INDI driver for your UPS (which is relatively straightforward), which would trigger the watchdog upon detection of power failure. However note that currently the watchdog doesn't publish a trigger for this purpose, it should be added.


Sorry, what specification are you referring to? There's no real "verb" defining how the dome should behave. However, the dome simulator, representing the generic behaviour, has been bluntly closing the shutter upon park for 4 years or so. But I think I understand your point and how you approach the subject.

-Eric

Hans, do you agree to make your Ekos Sentinel a parallel project to what is done in that Observatory module?
We would follow the same approach as the Ekos Internal Guider developed in parallel to Linguider and PHD2.
That means your project needs to formalize a notification interface, and that means Observatory needs to clearly separate its safety management to accept external services.
That would be a benefit for both I think.

Yes that was my intention. To follow any upcoming EKOS' observatory close down changes and keep it only as a failsafe system for the cases where EKOS does not close down while it should. (I consider this to be a different situation from an EKOS crash where the INDI watchdog driver can kick in.)

That sounds perfect. Where are the parts of the Linguider/PHD2 interfaces that EKOS uses described ?
Ekos Sentinel can now only command the scheduler to start or stop. It cannot ask what the scheduler is doing. The new observatory module should have an API where external programs can query these things, and it would be great if the observatory module could inform sentinel that it is going to do something, and that it expects to take X seconds at max. I propose I add a REST API interface to Sentinel for this.

-- Hans

Which dome driver is this?

What I'm referring to are the standard properties in the developer manual
indilib.org/develop/developer-manual/101...erties.html#h8-domes
It says this:No mention of closing the shutter, that's a separate switch.

And the INDI API here indilib.org/api/classINDI_1_1Dome.html#a...f74fd79dc763a1eb9bc1
It says:Once again all it says that Park does is move the dome to the park azimuth.

Those docuents seem to me to be as close to a standard as it comes.
I don't see how a client or user can cope if it doesn't know what a standard function does.

Sorry for the poor formatting of the quotes,
Chris

That is correct, parking and closing shutter are two separate properties. However, another switch can be added to a dome driver to automatically close the shutter on park. This is per-dome and does not apply to all domes (one 5.5m dome I worked it is impossible to close shutter automatically), and hence it needs to be implemented on case-by-case basis. This is I asked which dome driver to see if it can support "Close Shutter on Park" functionality or not.