Can't Edit Sensor Settings

Keywords: sensor, settings, edit, network stability, sensor availability, gateway lag,


Editing Sensor Settings. Sensor Availability, Gateway Lag and Network Stability.

Why Can't I Edit My Sensor Settings?

Sensor Availability 
Because Monnit sensors are battery-powered, it is critical customers leave their radio inactive between transmissions to conserve power. A CR2032 battery that can last for multiple of years transmits a signal every hour or two, conserving battery life and power. (Monnit's recommended heartbeat is not more than once every hour.)

If sensor transmissions are increased and left to listen continually for communication, the battery life is impacted harshly (maximum battery life could be as little as approx. 2 hours). This forces iMonnit to pass sensor updates to the sensor only after the sensor has turned on its radio and listens for an acknowledgment. During the acknowledgment, iMonnit can notify sensors that the database (DB) has a configuration update from which the network can send updates to the sensor. At this point, the sensor acknowledges configuration updates, and iMonnit marks the transaction complete. This also removes the 'pending transaction' flag.

Gateway Lag
Like the sensors, iMonnit can't instantly initiate communication to the gateway due to the many firewalls and security measures used to keep intruders from accessing customer networks. Out-of-the-box Monnit gateways are configured to communicate with iMonnit once every five minutes. (It uses the same communication protocol as your web browser does while communicating to your bank.)

Because of the five-minute gateway heartbeat there is a lag (delay time) between the time a user saves the configuration settings on Monnit's server, and the time the gateway checks-in to receive updates. Only after the gateway has acknowledged the updates will the sensor check in to receive them.

Network Stability
During pending transactions it is impossible for iMonnit to know which stage of the process the configuration is in. For example, if a user has set a configuration change to set the sensor's new heartbeat to 30 minutes, the gateway will have received the request when the sensor still hasn't.

There are certainly other network stability cases. For instance, if iMonnit modified the configuration to a 3-hour heartbeat to conserve battery life, the following network instability could occur.

A 3-hour change is observed in iMonnit. From there the gateway is ready to talk to the sensor and inform it the heartbeat should be now be 30 minutes. When the sensor checks-in and receives the configuration change, it will receive the 30-minute heartbeat rather than the 3-hour heartbeat. If the sensor were to communicate to the server that it has successfully updated its configuration, iMonnit must assume it has been updated to 3 hours, and marks the transaction as complete. This is the reason Monnit marks transactions that require communication with the sensor as "Pending."

To be able to update sensor configuration, users need to make sure sensor are communicating to iMonnit by waiting until pending configuration are complete.

Related Articles