×

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

Bi-monthly release with minor bug fixes and improvements

Full Automation and Weather handling in the Scheduler

  • Posts: 456
  • Thank you received: 76
Yes the shut down works really well. I start the scheduler and I trust it enough to go to bed. But what would be awesome is if it could do a 'suspend' on bad weather and resume on good weather. Suspend for me would mean park scope and dome, then wait for better conditions. Or shutdown if dawn comes.
Its not that straightforward to implement this though I think.
The following user(s) said Thank You: kamisan, Paul Muller
4 years 3 months ago #46845

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

Yes, this would be an awesome idea to have. Currently, it goes into total shutdown mode. Maybe with the right switch, it can also go into the current Park Wait mode. Park Wait is exactly this, it parks but doesn't shutdown, but this is used now when the next job is far away. Maybe it can be re-used for 'suspend' on bad weather if the option is set. However, looking at my own observatory, Park Wait would not suspend power or shutdown INDI , so you could end up in a situation where your equipment is wasting power. My shutdown script actually includes a Python script to turn off the power completely. Also, by the end of the shutdown, it would shutdown INDI server itself. At this stage, the scheduler has no idea what the weather is since the driver is down.

Perhaps one idea is to have the weather driver on in its own INDI server always running regardless. Or ... Ekos can be smart enough about this and requests shutdown of everything except the weather driver (INDI server is essentially running in protected mode) which it then listens to intently to monitor the weather conditions and upon favorable conditions, it runs the startup sequence again. Though at this time, instead of running a new INDI server, you will just request the startup of the drivers you previously shut down.
4 years 3 months ago #46851

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

  • Posts: 1185
  • Thank you received: 370
@knro: remember our discussion about the role of the scheduler? Who has control over the observatory - the observatory itself or is the scheduler the master of all?

If we think in that direction that we want an automated setup that is able to startup everything as soon as the weather is better again, I think we need something like an observatory agent that is running separately.
The following user(s) said Thank You: Jasem Mutlaq
4 years 3 months ago #46858

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

Yes I agree. We need to consider all the various scenarios as well to accommodate different requirements for each. So this would be a completely separate external process?
4 years 3 months ago #46863

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

  • Posts: 1185
  • Thank you received: 370
Yes, I think a completely separated process is best. What about building a separate web application on top of an INDI server that controls the observatory and communicates with the scheduler? INDI is already perfectly prepared with its distributed architecture. I would build two INDI servers, one for the observatory devices (dome, weather, maybe energy control for the mount) and one separate INDI server for mount, CCDs, focuser etc.

Ekos could use both INDI servers so that everything is at hand from one UI. And a separate web application sitting on top of the observatory server would control the observatory devices only and in addition communicate with the scheduler via DBUS for starting, stopping etc.
The following user(s) said Thank You: Paul Muller
4 years 3 months ago #46866

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

Ok I've been thinking that the additional INDI server only runs the weather driver (and perhaps any power controlling drivers), but not dome/mount..etc.

Now, it could be Ekos Scheduler module itself or a separate process that monitors weather and commands the scheduler to shutdown or startup. The current "Park Wait" implementation is fine for short periods, but inefficient for long periods of inactivity, and therefore a complete power-off shutdown would be the way to go (given you don't cut off power from weather station!). The dedicated process or Ekos can then start the scheduler when the weather improves. The scheduler has no idea and would start as it would have been started by a human operator. That intelligence just acts as the decision maker. It's not just weather, for could be used perhaps for the holy grail we've been seeking for a long time: multi-night scheduling.
The following user(s) said Thank You: Paul Muller
4 years 3 months ago #46869

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

  • Posts: 456
  • Thank you received: 76
My scheduler shutdown script also powers off everything (except weather station). It also starts a data-reduction-pipeline and when all done powers off the main PC.
A separate process may be the way to go alright. I've bee playing with a python script that uses dbus to start/stop the scheduler but haven't made much progress lately. I have a raspberry pi in the observatory which is switched on all the time and was hoping to run it there. It would do a wakeonlan to the main pc and then use dbus to load the schedule file and start the scheduler.
Derek
The following user(s) said Thank You: Craig, Paul Muller
4 years 3 months ago #46873

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

  • Posts: 1185
  • Thank you received: 370
What about extending the INDI webmanager? It already has a web interface and the python infrastructure for starting/stopping an INDI server.
The following user(s) said Thank You: Craig, Paul Muller
4 years 3 months ago #46874

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

Time to create page: 0.358 seconds