Reference · built on requestConnectorSensors, meters & gateways

Monnit iMonnit

Readings, gateway status, and alert states from Monnit wireless sensors in iMonnit, over REST or the Data Webhook.

About

iMonnit is the portal for Monnit wireless sensors and gateways: temperature, humidity, water detection, dry contact, light, pulse counters, vibration, current, voltage, pressure, and air velocity. Each sensor reports on a heartbeat in a Standard State, and faster in an Aware State once a threshold is crossed. REST calls return XML or JSON. The Data Webhook posts every message to one endpoint per account.

Through Fibric, an operator reads each sensor message as it lands, compares it with the limits you keep, and proposes a threshold, heartbeat, or alert change on the sensor. You approve. The change is applied once and the receipt shows the old and new values.

This is a reference listing. It documents what Fibric would read from Monnit iMonnit and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Sensor messages with sensorID, applicationID, dataMessageGUID, state, messageDate, rawData, dataType, dataValue, plotValues, plotLabels, batteryLevel, signalStrength, and voltage
  • Gateway messages with gatewayID, networkID, messageType, power, batteryLevel, date, count, and signalStrength
  • Location messages with latitude, longitude, altitude, speed, and course for tracked devices
  • Sensor inventory and properties through SensorList, SensorGet, SensorGetExtended, and SensorGetCalibration
  • Aware State transitions, signalled by the state field on each message
  • The Data Webhook stream itself, one HTTP POST per gateway check-in with its sensorMessages array

Proposed actions

  • Target capability: propose new limits through SensorSetThreshold with minimumThreshold, maximumThreshold, hysteresis, and measurementsPerTransmission
  • Target capability: propose a heartbeat change through SensorSetHeartbeat with reportInterval and activeStateInterval, never below ten minutes
  • Target capability: propose enabling or silencing a sensor's alerts through SensorSetAlerts
  • Target capability: propose a relay change on a control sensor through SensorSendControlCommand
  • Target capability: propose a calibration through SensorSetCalibration, or a rename through SensorSetName

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Log freezer temperatures for the health inspector

    TemperatureData messages from each freezer sensor arrive by webhook. The operator keeps the log, flags any messageDate gap, and proposes the corrective-action entry when a reading leaves the range.

    With Food Safety Log

  • Act on an Aware State before product spoils

    When a sensor's state changes to Aware, the operator checks the dataValue against the SensorSetThreshold limits and proposes the escalation, naming the sensor, network, and time.

    With Cold Chain Excursion

  • Find water before it finds the drywall

    A water detection sensor reports a wet state. The operator proposes a dispatch and, once dry, proposes returning the heartbeat to its Standard State interval.

    With Leak Response

  • Retire the sensor with the dying battery

    batteryLevel and signalStrength ride on every message. The operator proposes a replacement or a gateway move for sensors trending down, and a SensorSetHeartbeat change to stretch what is left.

    With Sensor Health

Requirements

  • An iMonnit Premiere or Enterprise license, which Monnit requires for both REST and Webhook access
  • Gateways and sensors already registered to a network in your iMonnit account
  • For the Data Webhook, an endpoint that accepts an HTTP POST with a JSON body; only one data push is allowed per account
  • The applicationID of each sensor profile, available from the GetApplicationID lookup
Authentication
An iMonnit authorization token from GetAuthToken, created with your iMonnit username and password and valid until that password changes, placed in the URL as https://www.imonnit.com/{xml|json}/{Method}/{token}?parameters.

Limits

  • One data push per account, across Webhook, Watson, Amazon AWS, and Azure IoT Hub destinations; switching types means stopping the existing push first
  • Up to 4 delivery attempts per message at 2, 15, and 60 minute gaps; 100 consecutive failures suspend the webhook until reset by hand
  • Heartbeats cannot be set below ten minutes
  • The full REST endpoint reference, the API Keys page, and the Rule Webhook page sit behind an iMonnit login

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Monnit iMonnit ↗

Questions and answers

Do I need a paid plan to use the API?
Yes. Monnit states that a license of iMonnit Premiere or Enterprise is required for REST and Webhook access. The endpoint reference at imonnit.com/API/RestAPI is only visible after logging in.
How does the Data Webhook retry a failed delivery?
Each message is attempted up to 4 times: immediately, then after 2, 15, and 60 minutes. After 20 consecutive failures every message gets a single attempt, and after 100 consecutive failures the webhook is suspended until manually reset. A message that fails 10 total attempts needs Monnit support to release it.
What is the Aware State?
A sensor runs in a Standard State on its normal heartbeat to save battery. When a reading crosses the thresholds set with SensorSetThreshold, it enters the Aware State and reports on the shorter activeStateInterval. measurementsPerTransmission sets how often thresholds are checked between heartbeats.
Ask about Monnit iMonnit

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.