Sleep Timers
Sleep timers are a functionality built into the AutoPi who's purpose is to protect the battery of your vehicle by limiting the amount of power required by the device when it's plugged into a vehicle. On this page, we will explore how you can work with the sleep timers using a command and look over some of the configuration options that are available to manipulate how sleep timers are added and cleared from the device.
power.sleep_timer
Command#
The Let us start by going through the command that you can use to view, set and clear sleep timers. The command is
power.sleep_timer
. If you execute the command on its own, it will return
the currently set sleep timers on the device:
user@my_device $ power.sleep_timer _sleep_timer/inactivity_fallback: function: power.sleep _stamp: '2023-05-08T09:26:57.353790' name: _sleep_timer/inactivity_fallback seconds: 10800 enabled: true job_args: [] return_job: false jid_include: true maxrunning: 1 job_kwargs: delay: 60 reason: inactivity_fallback interval: 21600 confirm: true metadata: transient: true revision: 2 expires: '2023-05-08T12:25:13.961144' created: '2023-05-08T09:25:13.961144'
In the code snippet above, we can see that there is a sleep timer currently set for my_device
- the
_sleep_timer/inactivity_fallback
sleep timer. That sleep timer will expire at 2023-05-08T12:25:13.961144
- note
that this timestamp is in UTC, as are all timestamps generated by an AutoPi device. The expires
key shows the moment
in time when the device will initiate its "Going to sleep" sequence.
To clear all sleep timers, we can use the command together with the clear
keyword argument, like so:
user@my_device $ power.sleep_timer clear=*{}
We are also able to clear sleep timers based on their name. For example, we have the _sleep_timer/inactivity_fallback
sleep timer above. Note that the actual name of the sleep timer in this example is inactivity_fallback
, omitting the
_sleep_timer/
part. Now, we can execute the command like below, to clear that specific sleep timer:
user@my_device $ power.sleep_timer clear=inactivity_fallback{}
If we run the power.sleep_timer
command on it's own and it returns an empty response like below, that means there
are no sleep timers currently set on the device:
user@my_device $ power.sleep_timer{}
If you don't see any sleep timers set, that means the device won't go down to sleep. Or at least, until a new sleep timer is set. A new sleep timer can be set in different situations, based on the configuration of the device, but it's important to remember that there could be new sleep timers set, even if you clear all current timers. Usually, this happens only when the device detects that a trip with a vehicle has ended, using the Event Driven sleep timer (we will explore that a little later).
#
Configuration OptionsNow, it's time for us to look through how we can configure the automatic sleep timers of the AutoPi. We will explore first how to automate setting of sleep timers (i.e. when the device should go to sleep and for how long). Then, we will also look into how we can automate the clearing of sleep timers.
note
You can see all available power configuration options here.
#
Power > Sleep TimerThe sleep timer section of the Advanced Power settings allows you to
configure how the device behaves in terms of setting and clearing sleep timers automatically. The Event Driven
,
Inactivity After Sleep
and Inactivity Fallback
settings configure how the device goes to sleep, while the Suppress
section configures the device on how to stay awake.
#
Setting Sleep TimersFirstly, let's take a look at the settings that set sleep timers. The common settings amongst all of them are the following:
- Period - The period defines how long the device will stay awake for before going to sleep due to this sleep timer.
- Interval - The interval defines the amount of time the device will sleep for, due to this sleep timer.
- Delay - The delay is the amount of time to wait before going to sleep. The delay is applied after the period has expired, but before the device actually powers off.
Now, let's discuss the functionalities each one brings to the table:
Event Driven - The
Even Driven
sleep timer get's set when the event defined in itsEvent Regex
option is triggered by the device. This event can either be one of the default ones (like Engine events such asvehicle/engine/stopped
or Communication events such asvehicle/communication/disconnected
). The purpose of this sleep timer is to put the device to sleep when we have detected that the vehicle is no longer being used (hence the engine/stopped instead of engine/running, which we will see in the suppress settings further down).Inactivity After Sleep - The
Inactivity After Sleep
sleep timer get's set when the device wakes up and does not see the event defined in the Suppress > Event Regex configuration (explained in next section). This sleep timer is usually set when the device wakes up from its sleep due to an expiredInterval
, but the vehicle the device is plugged into isn't on or running.Inactivity Fallback - The
Inactivity Fallback
sleep timer get's set when the device has been freshly plugged into a power source, the event defined in theEvent Driven
regex isn't seen and the suppress event hasn't been triggered in this power cycle. In essence it works exactly the same as theInactivity After Sleep
sleep timer, however is only triggered upon first plugging in the device into power.
#
Suppressing Sleep TimersNow, let's explore the Suppress
section of the Advanced Power settings. This section defines how the device will
clear and suppress further sleep timers from putting the device to sleep. There's two options available in this
section - Event Regex
and Schedule
.
Event Regex
#
Let's start with the Event Regex
. This option allows you to set a regex pattern that will be matched against every
event that get's triggered inside the device. What this allows us to do is to set a specific event, that when triggered,
will clear all sleep timers that have been setup on the device. It also prevents new sleep timers from being set until
another event is seen (specifically, the Event Regex
from the Event Driven
sleep timer).
Common examples here are using the opposite events from the Event Driven
sleep timer:
Engine events like vehicle/engine/started
or
Communication events like vehicle/communication/established
. Note that
here, we are looking for an event that shows the vehicle is now being driven, so we want to clear the sleep timers as
we don't want the device to go to sleep, but instead record all of our data.
Schedule
#
Next, we have the Schedule
option. That option allows us to setup a schedule for the device for when it should be
awake and how long it should be awake for. This option is useful for situations where you need the device to be awake
at specific times of the day and stay awake for the necessary duration. The way this setting is defined is by writing
a cron expression, then the pipe sign (|
), followed by the amount of time the device should be awake for in seconds.
Let's go through an example:
0 9 9 5 * | 3600
If we grab just the 0 9 9 5 *
part, which is the cron expression and paste it into a crontab resolver, we will find
that this expression will be executed on 9th May at 9:00 AM in UTC time. Remember that the devices are all working in
UTC, so this (suppress) expression will also be resolved in UTC. Next, the 3600
portion says that the device will
stay awake starting at that time for 1 hour in the future.
This means that the device will be woken up at the appropriate time and then any sleep timers that are added to the
device will be adjusted to ensure the device will be awake for the desired duration. For example, suppose we have set
the suppress schedule to keep the device up for the next hour. Now, if the device automatically adds a sleep timer, or
if we add it manually using the power.sleep_timer
command, the new sleep timer set will be adjusted so that it only
puts the device to sleep after the hour from the suppress schedule passes.
#
Troubleshooting#
My Device is Constantly Shutting Down, Even Though My Vehicle is On and DrivingIt's important to remember that the AutoPi device will automatically setup sleep timers in an attempt to protect your vehicle's battery. This will happen even if there are no custom configurations setup or without any interference by the user. This usually causes confusion as to why the device isn't on, even though it should be on and recording data.
The cause for this is usually because the device hasn't been setup to listen to the correct data and/or events, in order to suppress (aka clear) sleep timers when the vehicle is being driven. If the device is plugged into an electric vehicle that can be a bit more difficult to accomplish.
note
In case you have any questions, don't hesitate to contact us at support@autopi.io.