"20m AFTER SUNSET" schedule is not working

[brunetton]

Device

No response

Version

1.18.0-gita518080a+github240830

Question

Hi

Sorry to bother again :s but I'm trying to make a schedule with 20m AFTER SUNSET but this didn't done anything (I waited hours after sunset)

• I compiled 1.18.0-gita518080a+github240830 with SCHEDULER_SUN_SUPPORT
• set my long / lat for correct sunrise / sunset calculations
• flashed my device
• tested that the device is responding correctly when using switch buttons in the "Status" page
• checked again that long/lat coords are okay in UI (same float format)
• added two schedules:
  • "1h AFTER SUNRISE" / "relay 0 on" / "Relative" / Restore on boot: no
  • "20m AFTER SUNSET" / "relay 1 on" / "Relative" / Restore on boot: no

But nothing moved today. Nor the relative sunrise or sunset seems to work in my case :(

Some keys command values that I think might be useful:

> schAction0 => "relay 0 on"
> schAction1 => "relay 1 on"
> schEnabled0 => "1"
> schEnabled1 => "1"
> schHour0 => "9"
> schHour1 => "9"
> schMinute0 => "15"
> schMinute1 => "16"
> schRstrDays => "0"
> schSwitch0 => "0"
> schSwitch1 => "0"
> schTime0 => "1h AFTER SUNRISE"
> schTime1 => "20m AFTER SUNSET"
> schType0 => "3"
> schType1 => "3"
> schUTC0 => "0"
> schUTC1 => "0"
> schWDs0 => "1,2,3,4,5,6,7"
> schWDs1 => "1,2,3,4,5,6,7"

I'll test with bare SUNRISE and SUNSET to see.
Any tip is more than welcome !

Thank you

[brunetton]

I'll test with bare SUNRISE and SUNSET to see.

Unfortunately, it didn't worked neither with SUNRISE only. Did I missed something during compilation time maybe ? I thought it would be suffisent to enable SCHEDULER_SUN_SUPPORT but I maybe missed something 🤔

[mcspr]

Have you checked 'dev' branch instead?
Whats terminal output of get cfg?
Whats the output of schedule 0 & schedule 1?
Whats the output of event?

[mcspr]

...although...
version above has a bug related to .last & .next swap. AFTER uses .last, but it would update only after max(sunrise, sunset) timestamp happens to pass
'dev' has incorrect assumption about when the update should happen as well, but it is sometimes bound to midnight of the next day (which is also obviously bad)

let me have a look at how to correctly order those 3 together, then. debug info I asked about is probably not relevant

[mcspr]

...I think dev should work right now? Restore loop runs as usual, but now there is an additional calculation for 'before current timestamp'. edit: extra check for equality also added, so .last does not get updated with the .next in case update happens earlier than the next sun event.

btw event (in terminal) also displays current and previous timestamps.

[brunetton]

...I think dev should work right now? Restore loop runs as usual, but now there is an additional calculation for 'before current timestamp'. event (in terminal) also displays current and previous timestamps.

Thank you, I'll try dev branch

[mcspr]

btw, it is also strange that these keys were not deleted when set up

(quoted from above)
...
> schEnabled0 => "1"
> schEnabled1 => "1"
...
> schHour0 => "9"
> schHour1 => "9"
...
> schMinute0 => "15"
> schMinute1 => "16"
...
> schSwitch0 => "0"
> schSwitch1 => "0"
...
> schUTC0 => "0"
> schUTC1 => "0"
...
> schWDs0 => "1,2,3,4,5,6,7"
> schWDs1 => "1,2,3,4,5,6,7"

get cfg (in terminal) should show 17, no?
set cfg 14 & reset (aka reboot) should clear those out. config migration code compares cfg < 15, which it was at the time of e4b6929. unless those somehow got in via upload / manually