iMonnit Accumulator Reset Ran Only Once? Verify the Rule Can Recur
A scheduled pulse-counter reset that works once and then stops is a configuration problem to investigate, not a reason to keep clearing production totals manually. In iMonnit, resetting the sensor accumulator and preparing the rule to run again are separate actions. Check the target device, trigger assignment, recurrence and history before relying on a repeating reporting cycle.
This guide concerns Monnit ALTA pulse counters managed through iMonnit. It explains the manufacturer's documented scheduled-reset workflow and an evidence-based acceptance check. It does not configure your account or establish that a reset happens at an exact metering boundary.

Original conceptual illustration; not a specific product, optical specification, live measurement or customer installation.
Key takeaways
Check both accumulator and rule targets.
Verify the trigger sensor and recurrence configuration.
Prove two scheduled occurrences before relying on the reset.
1. Decide whether a reset is actually needed
Start with the reporting requirement. A production supervisor may want a fresh shift display, while an analyst may need an unbroken consumption history. Those are different requirements. Ask the system owner whether a reporting-period calculation could meet the need without clearing the source accumulator. Preserve existing raw observations and conversion settings before making an authorised change.
Monnit's single-input counter supports interval counting or ongoing accumulation. Confirm the selected mode on the installed device; a report of pulses for one interval is not interchangeable with a lifetime total. The pictured industrial single-input product is one catalogue example. Confirm the exact model, firmware, compatible pulse source and gateway arrangement for the installation.

2. Check two different targets
The scheduled task must identify which accumulator to clear. Separately, a rule-reset action identifies which rule to rearm. Mixing these targets can leave the intended counter unchanged or leave the schedule unprepared for its next occurrence. Record both identities explicitly, using device IDs as well as readable names where available.
Monnit's dedicated instructions describe a Scheduled Time rule with a Reset Accumulator system action targeting the selected device. For recurrence, they add a Full Reset action targeting {Target Self}; that example specifies No Delay for this rule-reset action. Calendar restrictions can then define the required days. Follow the dedicated procedure for this application rather than copying delays from an unrelated relay-control example.
3. Do not overlook the trigger sensor
The same procedure requires returning to the Conditions tab after creating the rule and assigning a trigger sensor. A saved schedule alone is insufficient evidence that the configuration is complete. Check the assigned sensor in the current rule, save the change and record the intended schedule as displayed.
If the rule has been copied or edited, inspect all its tasks before testing. Remove unintended actions only through the site's authorised change process. Do not use a rule linked to operating equipment as a convenient test harness; arrange a separate permitted test with the responsible person.
4. Prove recurrence over two scheduled occurrences
Use a test counter or an agreed maintenance window. Before the first occurrence, retain the rule configuration, accumulator value, reporting mode and time reference. Agree how the team will distinguish the scheduled action from a manual reset. Avoid changing several settings while the test is running.
After the scheduled time, inspect Rule History and the available counter observations. Monnit documents history as the place to identify executed system actions. Keep the portal action record separate from evidence of the resulting counter value. An action entry alone does not prove that a receiving dashboard or external calculation handled the new baseline correctly.
Repeat the check at the next permitted occurrence without manually rearming the rule in between. If the first event succeeds but the second does not, investigate rule state, self-reset task and calendar settings. If neither succeeds, check the trigger assignment and target configuration as well as the schedule. These are diagnostic priorities, not a guarantee of one particular cause.
5. A hypothetical shift-reporting check
Suppose a team wants a counter display cleared at each shift change. The first test shows a reset action in history and a later observation near zero. The next shift shows no corresponding action. Do not interpret that as zero production, and do not adjust the pulse conversion factor to compensate. Preserve both shifts' observations, inspect recurrence and repeat the controlled test after correction.
Also avoid assuming that the last pre-reset observation is the exact closing shift total. Reporting intervals, the reset event and later observations need their own timing evidence. If the required boundary cannot be demonstrated, mark the affected interval for review rather than inventing consumption or billing quantities.

Original explanatory diagram. Numerical values are hypothetical where shown; follow the actual equipment documentation and approved application method.
6. Prepare a useful support record
Send the exact counter model, rule purpose, selected mode, intended recurrence and a sanitised history extract. Include both target identities and the two test outcomes. Exclude passwords, device security codes and account tokens. Keep production acceptance with the responsible integrator; this monitoring workflow does not establish a certified safety or revenue-metering function.
Need help with your application?
For instruments and product selection, visit ProSense Instruments, email sales@prosenseinstruments.com.au or call 1800 560 854.
For monitoring and automation projects, visit ProSense Solutions or email sales@prosense.com.au.
For software enquiries, visit ProSight Software or email info@prosightsoftware.com. Confirm integration requirements for the exact instruments and system.




Comments