Monnit Edge - 10 Monnit Alert

Monnit Alert with Delay

This article walks through a complete template Flow that uses Monnit - Alert with a 30-second Delay before email / HTTP. If the condition returns to normal (or you Disarm) while the message is still waiting in the Delay, the pending notification is cancelled and nothing is sent.

Package: node-red-contrib-monnit-alert   (palette label Monnit - Alert).

Related articles:

• Monnit Edge Flows — Monnit Alert (full node reference)
• How to Disarm and Rearm Rules
• Rules Snooze: Jointly vs Independently
• Rules — Acknowledgement Mode

What this example demonstrates

Important: Monnit - Alert alone stops new Alert messages after clear / Disarm. It does not cancel a message that has already entered a Delay. That is why Status must reset the Delay.

Flow diagram

[iMonnit-Edge] ──► [Monnit - Sensor Filter] ──► [Monnit - Alert]
                                                      │
                         ┌── Alert (port 1) ──────────┼──► [30s Delay] ──► [Alert Text] ──┬──► [e-mail]
                         │                            │                                  └──► [http request]
                         │                            │
                         └── Status (port 2) ──► [Resolve before delay] ──► [30s Delay]
                              (sets msg.reset = true)         ▲
                                                              │
[inject: disarm] ──► [Monnit - Alert] ──(Status: disarmed)────┘
[inject: rearm]  ──► [Monnit - Alert]   (rearm only — do not reset the Delay)

Wire disarm and rearm into the same Monnit - Alert input as the sensor stream. Node-RED merges multiple wires into one input.

How cancel-before-send works (step by step)

1. A reading meets the Alert condition → Alert output fires (state: "ALARM"  ).
2. That message enters 30s Delay and waits.
3. Within those 30 seconds, either:

- The reading returns to normal (Acknowledge = Auto), or

- You click disarm

1. Monnit - Alert emits on Status (cleared   or disarmed  ).
2. Resolve before delay sets msg.reset = true   and sends into the same Delay node.
3. The Delay flushes / cancels its queue → template / e-mail / http never run for that pending alert.

If the Delay finishes with no reset, the message continues to Alert Text → email / HTTP.

Rearm only resets the Alert rule for the next matching sample. Do not wire rearm into msg.reset   — that would only clear a pending Delay, which is not what Rearm means in iMonnit.

Nodes in the example (every configuration)

1. iMonnit-Edge

Use your site’s Edge connection settings as usual. This node is the live data source for the template.

2. Monnit - Sensor Filter

A filter is optional — Monnit - Alert can match sensor IDs itself. The template keeps a Filter so you can restrict traffic before the Alert node. This is used if your intention is to create an alert for a single sensor.

3. Monnit - Alert (example values used in the template)

These are the values from the example Flow. Empty Sensor ID / Value are intentional for a copy-and-fill template.

When you copy this Flow for production: set Sensors and Value (and adjust Compare / Snooze as needed). Leave the Delay / Status / Disarm / Rearm wiring as shown.

4. Delay — “30s Delay”

Do not use a second Delay for the reset path — reset must hit the Delay that holds the pending Alert message.

5. Change — “Resolve before delay”

Any Status event from Monnit - Alert (cleared  , disarmed  , rearmed  , stopped_24h  , …) will reset the Delay in this template. That is fine for a grace-window example. Optionally insert a switch on msg.payload.state   and only pass cleared   / disarmed   if you do not want rearmed   to flush the Delay.

6. Inject — “disarm”

Disarm stops further Alert notifications while the condition may still be true (same idea as iMonnit Disarm). Because Alert emits Status, the pending Delay is cleared without a second wire from the Inject to the Delay. You can test by clicking the button to the left of the node.

7. Inject — “rearm”

Rearm does not fire an alert by itself. It resets the rule so the next sensor message that still meets (or again meets) the condition can Alert again. You can test by clicking the button to the left of the node.

8. Template — “Alert Text”

Example template body:

Monnit Edge temperature alert

Sensor ID: {{topic}}
Reading: {{primary}}
Condition: {{payload.condition}}
UTC: {{payload.utc}}
State: {{payload.state}}

msg.topic   is the sensor ID. msg.primary   is the triggering value. Full detail is also on msg.alert   / msg.payload  .

9. e-mail

The e-mail node sends a real email when you enter your email server details (SMTP host, port, TLS, username/password or OAuth, and To / From). Until those are filled in, the node is only a placeholder in the template.

After Deploy, when an Alert survives the 30s Delay, the Alert Text body becomes the email message and is sent through that SMTP server.

Configure credentials only on a private Edge — do not leave production passwords in shared templates.

10. http request (Webhook POST)

The http request node can call a webhook with POST. Set the method to POST, put your webhook URL in URL, and the Alert Text payload is sent as the request body (typical for Slack/Teams proxies, Zapier/Make, custom APIs, and similar).

You can keep email only, webhook only, or both in parallel after the template. Leave the URL blank in the shared template until you paste a real webhook.

Monnit - Alert — every setting (complete reference)

Double-click Monnit - Alert. Fields appear or hide based on Trigger and Compare.

Identity and sensors

Trigger

Channel (Sensor Reading only)

Compare and thresholds (Reading / Battery / Signal)

Outside band — fires when value < Low or value > High.

Inside band — fires when Low ≤ value ≤ High (inclusive band behavior as implemented by the node).

Inactivity

Aware State — Aware rule (Trigger = Aware State)

Snooze

See Rules Snooze: Jointly vs Independently.

Acknowledge

See Acknowledgement Mode.

Auto-stop (hours)

Matches iMonnit’s “notifications stop after 24 hours” idea, but is configurable on Edge.

Time zone (optional)

Every event always includes utc  (ISO-8601 UTC), whether or not local time is enabled.

Outputs

Do not confuse port 2 with the grey core status node (that node watches canvas status text). You need Monnit - Alert’s second output.

Alert payload (example)

{
  "state": "ALARM",
  "sensorId": "123456",
  "metric": "reading",
  "condition": "≥ 20",
  "value": 21.5,
  "utc": "2026-09-24T19:00:00.000Z",
  "localTime": "09/24/2026, 13:00:00 MDT",
  "timeZone": "America/Denver"
}

Also available: msg.alert  (full detail), msg.primary  (triggering value), msg.topic  (sensor ID).

Disarm and Rearm (detailed)

Same ideas as iMonnit Rules (Disarm and Rearm):

Accepted command shapes

Aliases: ack   / acknowledge   behave like disarm; reset   behaves like rearm for the Alert node — do not confuse that with Delay’s msg.reset  .

Recommended Inject setup

1. Disarm: Payload type string, value disarm   → wire to Monnit - Alert.
2. Rearm: Payload type string, value rearm   → wire to Monnit - Alert only.
3. Deploy, then use the Inject buttons when testing.

Suggested production settings (after copying the template)

Test plan

1. Set Sensors and Value on Monnit - Alert (and Filter ID if used).
2. Deploy.
3. Force a reading that meets the condition → confirm Debug/Status shows ALARM and the Delay starts.
4. Within 30 seconds, return the reading to normal or click disarm → confirm email / HTTP do not send.
5. Click rearm, then send another matching reading → Alert should fire again after the Delay (if not cancelled again).
6. With Snooze on, leave the condition true past the snooze interval → confirm a second Alert (unless Disarmed or Auto-stop hours elapsed).

Troubleshooting

Support

Questions about Monnit Edge Flows or this example: support@monnit.com