How we automated startup and shutdown for Always Coming, Always Going
Automating startup and shutdown
Our first major work, Always Coming, Always Going (or simply Always), automatically started every evening at 6pm and shut down without fail at 11pm, saving us many trips to the site over the three weeks that Vivid 2017 ran.
Here we share exactly how we automated our artwork (and even got it to email us to say it was “OK”), so you can do the same.
The Vivid organisers require that all installations on the Vivid Light Walk are on between the hours of 6pm and 11pm each evening. This is both to restrict viewing hours and minimise the environmental impact of the event.
We wanted Always to run with minimal or no manual intervention. To achieve this, we scheduled the startup and shutdown of the installation in software.
Always is driven by a single low-powered PC running Ubuntu that draws under 20 watts at idle. With such a low power draw we decided to leave the PC on at all times. This allowed us to run custom scripts to automatically start up and shut down the installation each evening. And with the PC running all the time we could remotely log in to perform any updates or make any tweaks as required.
To start the installation and shut it down we wrote two separate shell scripts, “startup.sh” and “shutdown.sh”, that were scheduled to run at 6pm and 11pm, respectively, using cron. More on cron later.
First, here is the startup.sh script:
echo"Startup: $(date)" >> $app_path/bin/run.log
$app_path/bin/$app_name&> $app_path/bin/app.log &echo"Waiting 30 seconds before sending email..."
sleep 30# wait 30 seconds so there's something in the log file to send and kinects have had a chance to connect
head -n 100$app_path/bin/app.log | mail -s "Automated message: Always startup" deu...firstname.lastname@example.org
Then a time-stamped startup message is appended to a log file called run.log. The app is then run, ensuring all of its log output (i.e. standard out and standard error: “&>”) are sent to a separate log file called app.log.
The second last line, “head -n 100 $app_path/bin/app.log | mail -s "Automated message: Always startup" deu...email@example.com”, sends the top 100 lines of the app log file to us via email. This gave us confidence that the installation had successfully started each night.
Sending emails was made possible by the PC being permanently connected to the Internet. To achieve this we used a 4G USB device. This device proved doubly useful as it gave the PC its own Wi-Fi hotspot that we could connect to when we were at the site.
During daylight hours the site housing the work is used as the arrivals hall for major cruise ships arriving in Sydney. We wanted to be absolutely certain that at 11pm each evening, the app was completely shut down and the display was cleared.
Here is the shutdown.sh script:
killall -SIGQUIT $app_name
sleep 3# wait for any issues closing app and send kill signal
killall -SIGKILL $app_nameecho"Clearing display" >> $app_path/bin/run.log
echo"Shutdown: $(date)" >> $app_path/bin/run.log
tail -n 100$app_path/bin/app.log | mail -s "Automated message: Always shutdown" deu...firstname.lastname@example.org
The shutdown script sends a quit signal to the app then waits three seconds. A kill signal is then sent to ensure that the app has definitely closed. After trialling a few different approaches we were confident that this was the best way for us to ensure the app had definitely closed.
The quit and kill signals are sent to a named app. If in your case the name of the app is not unique or there are multiple instances of it running, the wrong app might be terminated. To get around this, a signal can be sent to a specific process ID using “/bin/kill -SIGKILL $(cat $app_path/bin/app.pid)”. But for this to work the process ID has to have been stored when the app was started. To do this, run “echo $! > $app_path/bin/app.pid” directly after running the app.
After the quit and kill signals are sent, a custom Processing app called ClearDisplay is run to turn off all LEDs in the display. The vast majority of power consumed by the installation is by the nearly 20,000 LEDs. By turning these off we reduced our power draw to a minimal amount.
The startup and shutdown scripts were started automatically at 6pm and 11pm each evening using cron. Cron is the go-to solution for job scheduling on Unix-based computers. Using the crontab command-line program we added the following lines to “/var/spool/cron/crontabs/<username>”.
The first five values on each line refer to the desired minute (0-59), hour (0-23, 0 = midnight), day (1-31), month (1-12) and weekday (0-6, 0 = Sunday) for when the script should be run. The above lines tell cron to run startup.sh at 6:00pm and shutdown.sh at 11:00pm every day.
Recovering from a power cycle
Assuming the PC is always running then using cron to trigger a startup and shutdown script will work fine. But what would happen if there was an unplanned power outage/cycle, particularly if it were to occur between the hours of 6pm and 11pm? The cron jobs will not trigger, so the installation will not start. We need a script to run every time the computer starts to check the current time, and if the time is between 6pm and 11pm, start the installation.
Here is the restart.sh script that runs every time the PC reboots:
#!/bin/bashecho"Sleeping for 30 seconds to make sure everything is powered and up..."
sleep 30H=$(date +%H)if((18 <=10#$H && 10#$H < 23 )); thenecho"Time is inside hours. Starting app..."
elseecho"Out of hours. Making sure display is clear."
After waiting 30 seconds (to allow time for various hardware to start - e.g. Kinects, serial communication devices and custom Arduinos) the script checks to see if the current time is between 6pm and 11pm, and if it is, it runs the startup script. If the current time is outside these hours, the shutdown script is run. The shutdown script is run to ensure the LEDs are turned off by running ClearDisplay.
For Vivid 2017 we created robust scripts that would reliably start up and shut down our installation without any intervention. Receiving emails at 6pm and 11pm each evening let us know that all was well. We also catered for the edge case of a power outage/cycle during the activation hours (proving handy on two occasions during the three weeks that Vivid ran).
We hope this is helpful to you in automating your next light activation. If you have any questions, feel free to contact us.