Monnit Pending Settings: Confirm a Configuration Has Reached the Sensor
Changing a sensor setting in iMonnit does not prove that the device is already using it. A maintenance team can save a new reporting interval, leave site and later discover that the sensor continued with its previous configuration. The useful acceptance question is whether the change reached the intended device, not simply whether somebody pressed Save.
This guide addresses pending configuration transactions in a Monnit gateway-based installation. It separates the manufacturer's documented delivery behaviour from a practical change record that your team can use. Check the exact sensor, gateway and firmware before applying a recovery procedure; a Wi-Fi device or another gateway generation may need different instructions.
Understand the delivery path
Monnit explains that iMonnit queues a sensor configuration through its gateway. Delivery is associated with a later sensor check-in and can require several communications. A pending-fields message therefore means the transaction remains incomplete; it is not an invitation to keep submitting the same edit. Read Monnit's pending-configuration troubleshooting instructions before attempting recovery.
The pictured Ethernet gateway is a catalogue example of the link between ALTA wireless sensors and iMonnit. Its presence on the network is one part of the path. A current gateway connection and current sensor communication are separate observations, so record both.
Record the starting condition
Before making an authorised change, record the asset name, sensor ID, gateway ID, current firmware versions where available, current setting, requested replacement value and reason for changing it. Add the responsible person and the observation window. Keep passwords and device security codes out of shared work orders and ordinary support emails.
Capture the last sensor communication time and the last gateway communication time separately. An old reading displayed neatly on a dashboard is still an old reading. If communication is already missing, preserve that fact rather than describing the configuration change as the original fault. Save a screenshot or export permitted by your site's information policy.
Submit once, then check the transaction
In iMonnit Online, select the intended sensor and its Settings tab. Confirm the device identity against the maintenance record, make the approved edit and save it. Monnit notes that available fields vary by sensor type. Do not use another model's screen as proof that a field or option exists on your device.
Allow the device to communicate using the configuration it already has while the edit is pending. Watch whether the pending message clears, then revisit the settings and inspect subsequent communication. Treat these as complementary checks: a cleared transaction supports delivery, while the following observations help establish whether operation matches the requested change.
A hypothetical interval change
Suppose an approved monitoring plan changes a sensor from a 120-minute normal reporting interval to 60 minutes, and the exact account and sensor permit that setting. The technician saves the request at 10:10. That does not establish a new report at 11:10: the sensor may still be awaiting communication under its earlier settings.
The work order should distinguish request time, observed transaction completion and later report times. Record the actual observations rather than pre-filling an expected success. This example illustrates the evidence to retain; it does not prescribe a reporting interval, guarantee delivery timing or establish compliance for cold storage or any other application.
Escalate with evidence before disruptive recovery
If the request remains pending, compare your observations with Monnit's troubleshooting sequence. The manufacturer identifies Holding Network configuration, communication problems, gateway firmware and sensor uploads of previously logged messages as possible factors. An upload backlog can delay configuration acceptance. Collect the evidence first so that support can distinguish these causes.
Avoid unplanned resets, battery removal or firmware changes during an active monitoring duty. Monnit documents firmware-dependent differences in whether logged sensor readings survive loss of power. Ask the responsible site person to assess the recording gap and recovery method before interrupting a device. Do not open an industrial sensor enclosure simply to try a battery reset.
A gateway network Reform also deserves a change plan. Monnit's sensor-list documentation describes circumstances in which rebuilding that list changes slot arrangements, which matters for local Modbus TCP or SNMP integration. Have the integration owner compare the mapping before and after any such work rather than assuming that familiar dashboard names guarantee the same local association.
Close the job with a usable handover
Record the final observed value, communication evidence, transaction state and any remaining exception. If the outcome is uncertain, leave the work order open and state which check is missing. Include the exact model, IDs, firmware information, screenshots, requested change and timestamps in a support request, without sharing credentials.
Common mistakes are accepting Save as completion, repeating edits without checking the queue, changing several variables at once and clearing useful evidence during a reset. A short, well-kept change record makes the next investigation easier. Where monitoring protects a critical process, use the site's approved contingency arrangements while configuration or communication remains unresolved.
Manufacturer references and pictured equipment
Need help with your application?
For instrument enquiries, explore ProSense Instruments, email sales@prosenseinstruments.com.au or call 1800 560 854. Include the exact model, intended measurement and site conditions.
For broader project requirements, visit ProSense Solutions or email sales@prosense.com.au.
For software enquiries, visit ProSight Software or email info@prosightsoftware.com. Confirm device and protocol integration for the specific application before selecting a solution.
Comments