@psherman Strange, when I tried the script again it worked as expected, that is to turn both blue and green lights off. Will reboot the pi and test if it works again.
Edit:
It seems the script needs to be run twice! First time turns off the blue light, second time turns off the green light.
It seems particularly strange that you need to run the script twice as you describe.
In your (now deleted) post, you seemed to indicate that setting the green to 0 turns it on and setting it to 1 turns it off... is this your finding? If so, that would indicate inverted logic.
Can you go back to the status of the green LED -- use the commands I provided earlier and just toggle it manually on the command line. Does it toggle as expected (1 = on, 0 = off, each command has the desired effect immediately)?
I have just rerun the commands you posted above and yes they both work as expected, 1 = on and 0 = off.
Here s the log after I run those commands but I will need to rerun after reboot to see if anything changes.
Tue Dec 20 19:42:56 2022 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.1.124 3c:4a:92:56:2e:56
Tue Dec 20 19:42:56 2022 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.1.124 3c:4a:92:56:2e:56
Tue Dec 20 19:42:56 2022 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.1.124 3c:4a:92:56:2e:56 aaron-HP-ProBook-4420s
Tue Dec 20 19:44:16 2022 authpriv.info dropbear[4385]: Child connection from 192.168.1.124:34000
Tue Dec 20 19:44:16 2022 authpriv.notice dropbear[4385]: Auth succeeded with blank password for 'root' from 192.168.1.124:34000
Tue Dec 20 19:46:57 2022 daemon.notice wpa_supplicant[1850]: wlan0: CTRL-EVENT-BEACON-LOSS
Tue Dec 20 19:47:24 2022 user.notice root: setting blue to 1
Tue Dec 20 19:47:24 2022 user.notice root: sleeping for 10 seconds
Tue Dec 20 19:47:34 2022 user.notice root: setting green to 0
Tue Dec 20 19:47:34 2022 user.notice root: done, exiting
After reboot the script does exactly what I want , (turning both blue and green lights off) only being run once. Not sure why it was acting strange before?
Edit:
Having in rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sh /scripts/lights.sh
exit 0
Only causes the blue light to be turned off when the script is initially run.
I'm really not sue why you are having issues here, except that it is possible that maybe there is another process that is actually configuring the LEDs that is completing around the same time or after your script runs.
Unlike originally intended, the rc.local is not run last any more.
It is run by the "done" init script that has priority 95 (S95done symlink).
LEDs have 96 as S96leds, and are configured after rc.local.
config system
option hostname 'OpenWrt'
option timezone 'UTC'
option ttylogin '0'
option log_size '64'
option urandom_seed '0'
config timeserver 'ntp'
option enabled '1'
option enable_server '0'
list server '0.openwrt.pool.ntp.org'
list server '1.openwrt.pool.ntp.org'
list server '2.openwrt.pool.ntp.org'
list server '3.openwrt.pool.ntp.org'
should I put either code for the lights or the code to run the script in there?
Starting to think I should come back to this later as I have run out of ideas and just continue with setting up the pi. That is unless anyone has any other ideas for how to solve this?
If I followed along correctly and you can run the second command successfully manually after the router is up a while, try adding a longer time to the sleep statement in your startup script.
Try sleep 200 .
This idea was inspired by psherman's reply:
Make rc.local spin off your script into the background:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sh /scripts/lights.sh &
exit 0