I set up the LED schedule feature on my SFT1200, but I've noticed that in all versions of the firmware since the feature was introduced, including the current version 4.3.19, it works at first but after a period, which varies between a few days or a few weeks, it suddenly stops working. Disabling and re-enabling the function doesn't make any difference once it is in this state. The only solution appears to be to reboot - annoying at 11pm when you want to go to sleep and find the LEDs are still on!
Thanks for the feedback, I will try to reproduce this situation here.
Is the router date/time correctly?
Yes, the router time & date is correct.
Please bind the router to the GoodCloud and share with us, PM me your router MAC and the GL GUI login password. When the router happens this situation, note me.
Has this been solved in the meantime?
Not as far as I am aware. @bruce made a temporary fix by adding a chron schedule - which fixes the problem - but since the software guys have had trouble reproducing the issue, no update - that I am aware of - to fix the bug permanently has been incorporated into the code.
Hello,
We did not reproduce this phenomenon.
Do you have encountered the same and similar issue?
Please confirm that the NTP service is normal, the router time and time zone are synchronized.
If you find the rules, please tell us how to reproduce it
The SFT1200 configuration is as follows:
Mode: Access Point (Actual LAN link speed from main router: 400Mbps)
Attached Devices
WiFi: 2.4GHz - Typically 10 - 15 devices
WiFi - 5GHz - Typically 2 - 3 devices
Time Zone: London/Europe
NTP Service: Normal / Time is correct
System Overview
CPU Average Load: 1.25 - 1.5
Memory Usage: 73% (Used: 65% / Cache: 8%)
LED Schedule: OFF 23:30 / ON 07:00
Fault: LED OFF schedule sometimes does not execute and LED remains ON. The next day, it can execute correctly, but some days later the fault will happen again.
Workaround: @bruce added a task to the chrontab and that works 100% reliably. You can see the LED flicker sometimes when both the crontab and normal scheduled tasks both execute one after the other around half a second or so apart.
My working assumption is that the normal schedule code executes in a loop by repeatedly checking the time against the schedule every minute, which - when the CPU is very busy - it sometimes fails to do within the minute and therefore just misses the change of state, whereas the crontab task is interrupt driven and always executes as a higher priority task.
The loop code only checks the schedule change and not whether the current LED state is different from the scheduled state. If it did, then even if the schedule change itself was missed, it would still correct itself 1 min later.
1 Like
Mine does that too.
1 Like
@D.D Yay! At least that proves that I'm not the only one then... 
I try to re-open this case, and let guys to reproduce this issue again. Thank you all.
@bruce - When trying to reproduce the problem, it's important to have the SFT1200 configured as it is actually used when the issue occurs and not just in default router mode with only one or two devices connected.
Additionally, if the scheduler event code was altered so that it always checks whether the actual LED state is the same as the schedule says it should be, then the problem would never happen for more than a minute as it would inherently correct itself. This is what is known as defensive programming as it is always dangerous to assume that something will always work because it will never not work.
Any improvement on 4.3.24?
@hecatae Not really. I currently have 4.3.24 installed. Today I observed that at 07:00 the LED switched ON as it should (I believe this is the Chrontab event, previously set on my device by @bruce). However, at 07:01, the LED went out for about 2 seconds and then re-illuminated (I believe this is the actual Schedule code).
If everything was working in the schedule code, then the two events (Chrontab and Schedule code) should effectively occur simultaneously. Clearly, they do not.
The fact that the LED goes out and then back on again - and a minute after it should turn on - is also indicative of something odd still going on in the Schedule code.
1 Like
My experience with this issue is slightly different to @SNAFU's:
It happens about 2-4 times a month and more often when there is activity and either very rarely or probably never when there are no active devices (which means no computer, only a couple unused mobile devices which might do some minimal background network activity). My "Scheduled Tasks" are set to turn off 2,4 GHz WiFi, the 2,4 GHz Guest WiFi and the LED at the same time in the evening and turning them back on in the morning. I don't use the 5GHz WiFi, so the Opal operates with 3 instead of 5 possible tasks. Also there almost never more than about 6 or 7 devices on WiFi, which is less than what @SNAFU reports.
Hope that helps with the analysis.
While I am at this topic: At least for my use case it would be more convenient to have one Schedule for several possible tasks. Because when I need to change the on/off times I have to repeat that on every task with the mouse.
All in all both issues are just minor annoyances, but they are annoying. Especially because of the relatively bright light: It's clearly visible in the dark. That works great as WiFi (and day/night time) indicator - if it works correctly.
Hello,
We have not reproduced this issue by side, the cause cannot be further check and analyze.
R&D provides a new special program to mark the issue log, when the exception is executed, the log will be created and printed to /etc/led.txt file. Please help us reproduce the issue.
In v4.3.24 firmware, replace/overwrite these two files
a. /etc/init.d/gl_led
b. /lib/functions/gl_util.sh
With WinSCP to import it into the corresponding path of the router and replace them.
For example,
- Unzip the files on PC
- With WinSCP (or scp) upload them to /root/
mv /root/gl_led /etc/init.d/gl_ledandmv /root/gl_util.sh /lib/functions/gl_util.shchmod +x /etc/init.d/gl_led /lib/functions/gl_util.sh- When the issue is reproduced, please export the
/etc/led.txtfile and send to us - Please record the time when the issue is reproduced and tell us the time point
THANKS!
1 Like
Hi @bruce
Thanks to the R&D folks for doing this. However, I have 3 questions...
-
I was not able to get to this until today, only to find that the WeTransfer link has apparently already expired and I cannot recover/download it unless I pay to join the Ultimate Plan @ 21GBP per month (that is not happening). Free transfers are supposed to be available for 7 days, but today is only 5 days after your post. So why is the WeTransfer website saying it's expired?
-
The SFT1200 software has since been upgraded to 4.3.25. Are the custom files in the download still valid for this later version?
-
Instead of a text file, why not write a LED-SCH-ERR event to the System Log, which is both time-stamped and also easy to check and export via the UI without requiring (Win)SCP? It also means I don't have to check it every morning and evening (which is not always possible).
In any case, the transfer needs to be sent again...
Thanks in advance
Sorry, the next time I share the firmware through wetransfer will choose the 7-day validity period.
All are valid on firmware versions that can reproduce this issue.
We rewrite the code to achieve the collection of relevant logs in the logread and share again.
We used to worry that logread had other system running logs and probably print too much, which might cause the led log to be overwritten, so export the led log separately.
But we rewrite it and collect the led log into the logread.
Thanks.
Update:
The led log will print in the logread (syslog), when the issue reproduced, please export the syslog, and share with us, also let us know the issue time point
In v4.3.25 firmware, replace/overwrite these two files:
a. /etc/init.d/gl_led
b. /lib/functions/gl_util.sh
With WinSCP to import it into the corresponding path of the router and replace them.
Example:
- Unzip the files on PC
- With WinSCP (or scp) upload them to /root/
mv /root/gl_led /etc/init.d/gl_ledandmv /root/gl_util.sh /lib/functions/gl_util.shchmod +x /etc/init.d/gl_led /lib/functions/gl_util.sh- When the issue is reproduced, please export the syslog "logread" file and send to us.
- Please record the time when the issue is reproduced and tell us the time point
I installed the first version with led.txt, but the issue has not happened yet.
Below you see yesterdays entries (correctly turned on in the morning, turned off in the evening), please check just in case those entries are not up to expectations (some entries look unnecessary to me but it's possible just how it works):
led_enable_on: Thu Mar 27 07:30:00 CET 2025
led_off: Thu Mar 27 07:30:00 CET 2025
gl_i2c_led_off: Thu Mar 27 07:30:00 CET 2025
led_on: Thu Mar 27 07:30:00 CET 2025
led_daemon: Thu Mar 27 07:30:00 CET 2025
service_stop: Thu Mar 27 20:00:00 CET 2025
gl_i2c_led_off: Thu Mar 27 20:00:00 CET 2025