×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Partitioning the Scheduler code

  • Posts: 456
  • Thank you received: 76
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
4 years 10 months ago #38914

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
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
4 years 10 months ago #38920

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
The code lives in the auxiliary folder.

-Eric
The following user(s) said Thank You: Chris Rowland
4 years 10 months ago #38927

Please Log in or Create an account to join the conversation.

The following user(s) said Thank You: Chris Rowland
4 years 10 months ago #38937

Please Log in or Create an account to join the conversation.

  • Posts: 97
  • Thank you received: 20

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.
The following user(s) said Thank You: Eric
4 years 10 months ago #38947

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
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?
4 years 10 months ago #38959

Please Log in or Create an account to join the conversation.

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?
4 years 10 months ago #38961

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138
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.
4 years 10 months ago #38962

Please Log in or Create an account to join the conversation.

  • Posts: 1185
  • Thank you received: 370
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
4 years 10 months ago #38963

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
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
Last edit: 4 years 10 months ago by Eric.
4 years 10 months ago #38971

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301
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.
4 years 10 months ago #38976

Please Log in or Create an account to join the conversation.

  • Posts: 85
  • Thank you received: 40
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
The following user(s) said Thank You: Eric
4 years 10 months ago #38978

Please Log in or Create an account to join the conversation.

Time to create page: 1.017 seconds