We have a new knowledgebase at kb.egauge.net!

This article can be found HERE.

The eGauge can be configured to send alerts based on a variety of trigger conditions. Alerts must be configured through the eGauge interface, and the eGauge needs to be powered on and connected to the internet in order to send alerts. Alert destinations can either be email addresses or SMS-capable phone numbers (or a mixture of the two).  

Depending on the nature of the network used by the eGauge, it may be necessary to provide the eGauge with an email gateway (essentially, the eGauge is provided with an email address). eGauge support cannot provide email gateway credentials, but using a free Gmail account is generally adequate (it will be necessary to enable less secure apps on this account, so personal or work email credentials should not be used).

The following document covers basic alert configuration and provides some sample alerts. Additional information is available on an eGauge-specific basis by navigating to http://DEVNAME.egaug.es/fundoc.html?alert where DEVNAME is the device name of your specific eGauge. To take advantage of all alert features, the eGauge should be on the latest firmware.


Update for Firmware v4.0

Firmware v4.0 adds the ability to have a JSON-formatted POST of alerts to a specified destination.

The HTTP POST uses chunked encoding, and the body of the POST is the JSON data.

Setup and options

In Settings -> Alerts, the "Alert Provider" can be chosen as "SMTP Gateway" (the only available method before v4.0) or "custom":

Alert Provider: May be "SMTP Gateway" to deliver emails or SMS (via email-SMS gateway) or "custom" to enter a custom URI for the JSON-formatted alert POST. In the future, there may be other options.

URI: The URI to send the JSON POST to. Should be unique to the device, such as with a GET token to uniquely identify.

Options: A comma separated list of options available below:

  • deflate: Use "deflate" content-encoding when posting alerts.
  • gzip: Use "gzip" content-encoding when posting alerts.
  • secure: For HTTPS connections, fail if the alert provider server's certificate cannot be verified as being valid.

Note: do not use multiple compressions, i.e., do not use gzip AND deflate on the same device.

Minimum priority to report: All alerts with a priority level equal to or greater than this will be POSTed to the URI when triggered. To prevent some or all system alerts from being reported, this may be set to "1" or greater. When alerts below the minimum priority level are triggered, they are only logged on the device locally and do not create a POST.

How alerts are triggered and sent

Any time an alert over the minimum priority level is triggered, any alerts that are newly created or triggered will be POSTed with the newly triggered alert regardless of priority level. On limited bandwidth connections, it is recommended to use compression and decide what system alerts should be above the minimum priority level. For example, if the connection is unstable, proxy-connection alerts may not be desirable to be above the minimum priority or bandwidth will be used to report when they trigger.

Only newly triggered or updated alerts will be sent with the POST data. Previously reported alerts that have not been triggered again will NOT be sent.

Data POSTs are limited to once a minute.

Example and description of POST data

  "now": "1568419537.35",
  "alerts": [
      "id": 1804290019,
      "priority": 7,
      "occurrences": 12,
      "first_occurence": 4462.5,
      "last_occurence": 389.31,
      "name": "Device-configuration changed",
      "detail": "By owner."
      "id": 1804290035,
      "priority": 0,
      "occurrences": 1,
      "first_occurence": 0,
      "last_occurence": 0,
      "name": "Device rebooted by firmware",
      "detail": "Howdy do?"
  • "now" is a 64-bit UNIX timestamp, possibly with a fractional (sub-second) part, formatted as a decimal integer string.
  • "alerts" is a list of reported alerts:
    • "id" is a number that uniquely identifies an alert. It is used, for example, to acknowledge or clear an alert.
    • "priority" is the user-assigned priority level of the alert (0 being the lowest priority and 7 the highest priority).
    • "occurrences" gives a count of how many times the alert has occurred since it was last cleared.
    • "first_occurence" and "last_occurence" specify how many seconds ago the alert occurred for the first time and the last time, respectively, relative to "now". That is, the specified number should be subtracted from "now" to get the absolute UNIX timestamp of when the alert occurred first and last, respectively.
    • "name" is the name of the alert that occurred.
    • "detail" provides additional detail on the alert that occurred.