Found another odd behaviour of the scheduler:
"all tests are done with the simulator!!!"
M31 in the target, simple sequence.
1# Just select 'weather'
2# Now
3# none
4# Sequence completion
Startup procedure: Unpark Mount
Shutdown procedure: Park Mount
with the above set, hit : Start scheduler and then set the time close to what the scheduler said it was going to start.
let the job completes (that's all fine).
Once completed, hit 'Start Scheduler' again one more time and you will get:
Just thought about something for the scheduler, something that will take it to another level.
I would like to be able to save the scheduled work, send this over to the remote indi server and let the server act as a stand alone system.
Do you think this could be implemented one day?
It would be a very useful feature for a remote observatory to becoming a true robotic observatory.
It is indeed possible because the scheduler communicates with Ekos using 100% DBUS calls. I planned it this way for this very purpose, so that the scheduler can be moved to Web/Console...etc. But for now, I need to test the scheduler for quite a while (months) before another scheduler frontend is developed.
I've done today a part simulated scheduled task (part as I am using the indi_simulator drivers and the live box driver).
Ran through the all sequence fine, job was fine.
However, something I find inconvenient is that the FITs window stay in focus for ever, I would suggest to send it behind kstars a few seconds after the capture and to auto close it once the scheduled job has finished.
The Indi control panel is the same, it stays in focus and that one should definitely be in the background and auto closed at the end too.
This looks brilliant and while I can't make use of all its capabilities, it will still be very useful.
Is there a way to tap into some of the events to send external alerts? For example, if it's determined the weather goes into a warning state, could I get the notification either via event/notify or perhaps a script to be run like the start up and shut down? Or is there a better way to do this?
Is it also possible to get the same sort of thing if an abort occurs? In this case because the shutdown script will be called, it's more to know there why the shutdown is being done - because of an abort or was it planned? While I've got a dome, the shutter is still manual at this time. So when a shutdown occurs I'd have to close the shutters. I could send an alert if it's an abort to spring into action quicker for closing up.
Yes, this is why KDE is such a powerful platform as all KStars events are considered KDE events and they can be customized to execute a script/play sound....etc
Great, well you've just given me more incentive to switch my astro machine to KDE. I've just started using it on my desktop and I like it a lot. Much better than what I remember - which admittedly was many years ago now.