https://bugs.kde.org/show_bug.cgi?id=526451
Bug ID: 526451
Summary: Ekos Scheduler skips the Focus step when a job starts
after waiting for its start condition
Classification: Applications
Product: kstars
Version First 3.8.3
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 196710
--> https://bugs.kde.org/attachment.cgi?id=196710&action=edit
ekos-2026-09-12T20-52-11.analyze
## Summary
Ekos Scheduler skips the Focus step when a job starts after waiting for its
start condition.
## Environment
- KStars: 3.8.3 Stable
- Platform: StellarMateOS
- Hardware: Raspberry Pi 5
- Architecture: aarch64
- Base OS: Debian GNU/Linux 12 (bookworm)
### Kernel
`Linux 6.6.31+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29)
aarch64 GNU/Linux`
### INDI
- INDI Library: 2.2.4
- Code: 2.2.4-tgz
- Protocol: 1.7
### StellarMate
Repository:
`stable/bookworm`
Relevant packages:
- `stellarmatenetworkmanager 2.1.2+20260601111352~stable~bookworm`
- `stellarmatenetworkmonitor 2.0.0+20260601111840~stable~bookworm`
- `stellarmateudevmanager 2.1.17+20260804005919~stable~bookworm`
- `stellarmatewebmanager 2.2.3+20260617102710~stable~bookworm`
## Description
When the Ekos Scheduler is started before the scheduled imaging session and
waits for the job start condition to become valid, the Focus step does not
appear to be executed when the job actually starts.
The Scheduler job has the following startup steps enabled:
- Tracking
- Focusing
- Alignment
- Guiding
However, when the Scheduler eventually starts the job, the `.analyze` file
shows Tracking, Alignment and Guiding, but no Focus event at all.
The expected startup sequence is:
`Track -> Focus -> Align -> Guide -> Capture`
The recorded startup sequence is instead:
`Track -> Align -> Guide -> Capture`
## Observed behavior
In the attached Analyze file:
`ekos-2026-09-12T20-52-11.analyze`
the Scheduler job starts at:
```text
SchedulerJobStart,4284.283,M 33
```
The mount then slews and starts tracking:
```text
MountState,4284.783,Pointage
...
MountState,4309.783,En cours de suivi
```
Alignment starts afterwards:
```text
AlignState,4406.345,En cours
...
AlignState,4427.631,Terminé
```
Guiding then starts:
```text
GuideState,4429.247,à l'arrêt
GuideState,4430.799,Sélection d'une étoile
GuideState,4431.035,Calibrage en cours
...
GuideState,4479.925,Guidage
```
There are no `FocusState`, `Autofocus`, or Focus events anywhere in the Analyze
file.
Therefore, from the recorded events, the Focus step appears to have been
skipped.
## Expected result
When Focusing is selected as a Scheduler startup step, the Scheduler should
trigger an autofocus operation when the job actually starts, even if the
Scheduler has been waiting for the job start condition beforehand.
## Actual result
The Scheduler proceeds from Tracking directly to Alignment and then Guiding,
without any recorded autofocus operation.
## Steps to reproduce
1. Create an Ekos Scheduler job.
2. Enable the following job steps:
- Tracking
- Focusing
- Alignment
- Guiding
3. Configure a start condition that causes the Scheduler to wait before
starting the job, for example:
- a scheduled start time, or
- the twilight constraint.
4. Start the Scheduler before the start condition is satisfied.
5. Let the Scheduler remain in the waiting state.
6. Wait until the job becomes eligible and starts automatically.
7. Check the Ekos logs or the generated `.analyze` file.
Expected:
The job startup sequence includes Autofocus before Alignment.
Observed:
The job starts with Tracking, then proceeds directly to Alignment and Guiding.
No Focus event is recorded.
## Additional information
The attached `.analyze` file demonstrates that the job started automatically
through the Scheduler and that Tracking, Alignment and Guiding were executed.
The `.analyze` file itself does not contain the Scheduler checkbox
configuration, so I can also attach a screenshot showing that the Focusing step
was enabled for the job.
## Suggestions for diagnostics and debugging
To make this kind of Scheduler issue easier to diagnose, I would suggest two
improvements:
1. Record the Scheduler waiting-for-start state in the Analyze timeline/log.
When the Scheduler is started before the job can actually begin, it would be
useful to have a clear state/event showing that the job is waiting for its
start condition to become valid, and another event when it leaves this waiting
state and really starts execution.
2. Write the important Scheduler configuration parameters to a dedicated log
when the Scheduler is started.
For example, the log could include:
- enabled job steps (Tracking, Focusing, Alignment, Guiding);
- start constraints and start time;
- twilight constraint;
- altitude and moon constraints;
- completion condition;
- startup/shutdown options;
- sequence file used by the job.
Having this configuration snapshot in the logs would make it much easier to
verify afterwards what was actually configured and to debug Scheduler behavior
without relying only on screenshots.
--
You are receiving this mail because:
You are watching all bug changes.
