Status changes & notifications in the Remote Management Server

Status changes based on missed heartbeats and heartbeat monitoring are self-resolving. For example, when a device that has previously changed status due to a missed heartbeat starts sending heartbeats again, the status will update automatically, which makes the project easier to manage.

Status changes based on event logs are not self-resolving and have to be manually cleared in the RMS portal so, as a general rule, we recommend using these only as required.

As a best practice, we generally recommend setting up the RMS to change the status of the kiosk based on heartbeats and then trigger notifications based on those status changes.

In the RMS portal at the individual kiosk level, under Utilities, there is an item called 'Failure Alert Setup' utility, which allows you to define how and when the device's status changes.

There's a comparable utility at the project and site levels, but please be aware that using this utility at higher levels just does a one-time push to change the settings for each individual device in that project or site - if you add kiosks to a project or site later, you'd need to push this again to apply to the new devices.

Missed Heartbeats

The most obvious way to change status is based on a specific number of missed heartbeats.

Once the device connects to the server, the server builds out predictions of when the next heartbeat will occur based on the Heartbeat Interval configured in Kiosk Pro's settings. FYI, there is a small amount of latency built into calculating when a missed heartbeat has occurred (due to a grace period based on a % of the heartbeat interval and a server loop interval to check all devices for a missed heartbeat) so if you are testing this it may take longer than might be otherwise expected.

Heartbeat Notifications

There are a number of peripherals that can report their status as a part of a heartbeat. For most projects, the most important of these is the tablet's battery.

In Kiosk Pro's settings, there is a section called Heartbeat Notifications, which allows you to configure certain parameters for reporting the battery state to change the device status in the RMS.

This then gets linked to a specific kiosk status change in the RMS interface by setting up a status change based on heartbeat events.

Again, handling battery events in this way means that these status changes are self-resolving and when the battery no longer meets the parameters set above, the status will return to normal automatically.

Event Notifications

Event logging does allow you to see a wider range of events that occur at the kiosk, but as mentioned, status changes based on these events are not self-resolving.

The level of event log for a specific event is configured within the app settings.

The event level associated with a specific event can be used to trigger a notification directly (see below) or can be used to trigger a status change (which would need to be manually resolved).

All other items in the 'Failure Alert Utility' interface are specific to KioWare's Windows client and can/should be ignored for our purposes here.

Notifications

Notifications can be configured at the individual device, project or site level.

As a general starting point, we recommend setting up the missed heartbeats and battery heartbeat status to change the device status and then setting up a notification on status change. This will give you a list in the RMS of devices currently having issues and notifications of changes to those devices.