Below you will find a list of all non-critical vehicle alerts and notifications that you can receive (note the IoT model you use may not support all of these notifications):

If the vehicle battery level increases by at least 10% (custom function, disabled by default):

Alert! Vehicle {NUMBER} battery increased from {VALUE}% to {VALUE}%!

For firmware/hardware issues, implemented for specific IoT devices by the manufacturer:

Alert! Vehicle {NUMBER} battery voltage not detected! Currently used by user with ID: {CUSTOMER NUMBER}

While the vehicle is not being used by any customer, when the Discharged status is assigned by the system automatically:

Alert! Vehicle {NUMBER} battery voltage not detected! Status "DISCHARGED" set automatically.
​
If the vehicle battery/fuel level reaches a low level (when system moves the vehicle to discharged status automatically):

Alert! Vehicle {NUMBER} has low battery/fuel level (x%)

The notification is triggered if the vehicle is in one of these statuses at that moment:

Available, Discharged, Needs investigation.

The notification is triggered once the vehicle moves to Discharged state due to vehicle battery level. We send the alert once, every time the vehicle enters this state. In case after 24h pass the battery still keeps dropping, ATOM system will send a repeated alert.

If the battery goes back to medium or high level and after that experiences another battery level drop to low level, system will send the alert again. We also reset the counter in case Available status is set manually.

In case of an active ride and also if per client's settings Discharged stated is never triggered (battery needs to be below 0%), the system will skip sending this alert.

The following alert is sent unless the vehicle is in any of these statuses: 'CHARGING', 'NOT_READY', 'NEED_SERVICE', 'TRANSPORTATION'. If the IoT supports this, it can be triggered by IoT events (Segway API case, for example), but on ATOM side there's also a function that if the vehicle battery is above 1% and it becomes 0%, and this happens for the 5th time in a 1h timespan and additionally ATOM does not receive the vehicle serial number, then the IoT disconnection alert is triggered (specific for Teltonika IoT case - when their IoT is disconnected, no vehicle serial number is sent; to avoid unstable connection between IoT and vehicle, we trigger this only after the 5th time it's received):

Alert! Vehicle {NUMBER} disconnected from IoT with ID: {IoT NUMBER}!

Mostly used in Segway API webhooks for cases when the IoT is reconnected:

Alert! Vehicle {NUMBER} reconnected to IoT with ID: {IoT NUMBER}!

Triggered in case IoT has stopped sending a signal and hasn't sent it for X amount of time (per individual settings for each client according to their dashboard):

Alert! Vehicle {NUMBER} has no IoT connection for X min

The notification is triggered if the vehicle is in one of these statuses at that moment:

Available, Discharged, Needs investigation.

We send the alert once, as soon as the IoT reaches the time limit during which it needs to send a signal to stay visible in the mobile app to end-customers. In case after 24h pass the IoT still hasn't sent any signal, ATOM system will send a repeated alert.

In case of an active ride and also if per client's settings IoT in marked as Not Integrated in the Manage IoT section, the system will skip sending this alert.

Triggered by the IoT or custom internal IoT rules. Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION:

Alert! Vehicle {NUMBER} recovered from overturn!

Triggered by the IoT or custom internal IoT rules. Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION:

Alert! Vehicle {NUMBER} overturned!

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status:

Alert! Vehicle {NUMBER} crash detected!

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status:

Alert! Vehicle {NUMBER} wheel up detected!

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status:

Alert! Vehicle {NUMBER} hit detected!

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. Additionally no active ride has to be detected:

Alert! Vehicle {NUMBER} illegal moving!

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. Additionally no active ride has to be detected:

Alert! Vehicle {NUMBER} towing detected!

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. Additionally no active ride has to be detected:

Alert! Vehicle {NUMBER} seat {} detected! Helmet: {}!

(SEAT STATE CAN BE OPENED AND CLOSED, HELMET STATE CAN BE YES OR NO (PRESENT OR MISSING))

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. Additionally no active ride has to be detected:

Alert! Vehicle {NUMBER} alarm detected!

This is sent on the 1st alert, afterwards upon 11th alert within 5min timespan are counted, then we repeatedly send the alarm, and then reset and wait for the next 5min. This rule is implemented to avoid spamming the merchant with too many alerts.

Triggered by the system settings for the specific service (No rides for more than X hours). Sent for vehicles in AVAILABLE status:

Alert! Vehicle {NUMBER} may need rebalancing

We send the alert once, as soon as the vehicle enters the Rebalancing state. In case after 24h pass the vehicle still hasn't had a ride, ATOM system will send a repeated alert.

In case of an active ride the system will skip sending this alert.

Not sent during an active ride, but only in vehicle statuses AVAILABLE, DISCHARGED, NEED_INVESTIGATION. Checked once in 1min. If ATOM receives less than 1 GPS signal in 1min then this is skipped. If the vehicle status is changed in the past 2min, the alert is not sent. ATOM checks the total ride distance in the last 2min, customer left the defined radius, overall max movement distance between first and last point within the previous 10-20 min (from +10 to +20 from current time):

{} Nr. {} moving! {}'.format(company_name, vehicle.nr, public_history_link)

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. If not used by anyone + GPS coordinates not older than 2min are received. We check every 5min where the vehicle is, if it's in the no-go zone, then the alert is triggered and afterwards we recheck in 1h after 1st successful alert:

Alert! Vehicle {NUMBER} located in no-go zone!'.format(vehicle.nr)

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. :

Alert! Vehicle {NUMBER} located in no-go zone! Currently used by user with ID: {CUSTOMER NUMBER}'.format(vehicle.nr, vehicle.use_by_user_id)

Sent in AVAILABLE, DISCHARGED, STOLEN, NEED_INVESTIGATION vehicle statuses. Not triggered the first 2min after the vehicle is set in Available status. We check every 10min, then 1h:

Alert! Vehicle {NUMBER} located in no parking zone!'.format(vehicle.nr)

NB! For all internal ATOM-managed alerts - none of these are triggered the first 2min after the customer has ended a ride in the mobile app.