Instead of a 5USD time switch, you can configure Webconverger to shutdown at a set time.

Use case: Museum closes at 6pm Tuesday to Sunday (closed Mondays). Kiosks are powered on manually by staff at opening time in order to be ready and waiting for the public. Though for the convenience of staff, kiosks automatically turn off at 6pm sharp, closing time.

Note on booting automatically in the morning: This can be done Wake-on-LAN but it's fairly complex to setup locally and unfortunately there is nothing Webconverger can do remotely.

Update: Sleep is the future. Cron won't be used to turn off machines, once the new sleep after a period of inactivity feature is realised.

Step 1, figure out your timezone else use UTC

By default Webconverger boots into synced UTC time. Chances are you live in a different timezone, whereby you need to study ftp://ftp.iana.org/tz/data/zone.tab for the right string to describe it.

Lets pretend the museum is in Durban, South Africa. Even though Johannesburg isn't the capital, I know it keeps the same time as Durban. Africa/Johannesburg is hence the appropriate string from zone.tab for describing my local time zone.

Now I need to append that to a Webconverger boot like so:

timezone=Africa/Johannesburg

Step 2, set the schedule (cron job)

The cron utility is the time-based job scheduler which unfortunately has a awkward API syntax which we make even uglier by replacing spaces with %20.

To realise the above use case a crontab entry would look like:

00 18 * * * root poweroff

At 6PM, as the "super user" root user, the machine will power off.

To pass this as a configuration to Webconverger, it needs to be encodeURI on boot like so:

cron=00%2018%20*%20*%20*%20root%20poweroff

Hint for developers: The script live-config writes out the cronjob.

My machine is not shutting down at the specified time / my time is wrong

In your logs, which can retrieved using the support API and http://support.webconverger.com/ service, you will probably see:

ntpdate[9748]: no server suitable for synchronization found

Which as documented upon http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-trouble.htm#AEN4972, meaning your network is most likely filtering NTP time synchronization packets.

The ideal way to fix this is to let your network/firewall administrator know.

Else as a workaround, ensure correct BIOS time.