Alarms
Sentinel evaluates alarms itself, so the buzzer and LCD on site keep working when the WAN is down. The limits are set from the server or the web; every status change is sent as an event, and the current status accompanies the telemetry.
What can trigger an alarm: temperature (each slot), power (PZEM-004T), and digital inputs with dN_alarm = true. Other inputs (e.g. a door without dN_alarm) are only reported and displayed. For other metrics (Modbus meters, humidity) use rules.
Parameters
Section titled “Parameters”All take effect immediately without a reboot. A limit of 0 = that alarm is disabled.
| Key | Default | Range | Meaning |
|---|---|---|---|
temp_warn_c |
30 |
0 … 125 | default warning for all temperature slots. Must be lower than temp_alarm_c |
temp_alarm_c |
35 |
0 … 125 | default alarm for all temperature slots |
temp_alarm_hyst_c |
1 |
0 … 10 | a temperature alarm ends after the temperature drops this far below the limit |
alarm_delay_s |
30 |
0 … 3600 | the condition must persist this long before the alarm becomes active (all alarms) |
volt_min_v, volt_max_v |
0 |
0 … 300 | low and high voltage limits |
current_max_a |
0 |
0 … 100 | overcurrent |
power_max_w |
0 |
0 … 25000 | overpower |
alarm_buzzer |
true |
buzzer sounds on alarm (not on warning) | |
maintenance_until |
0 |
epoch seconds | maintenance mode until this time |
Per-slot limits (tN_warn_c, tN_alarm_c) and per-input delays (dN_alarm_delay_s) override these defaults. The effective warning must be lower than the effective alarm for each slot.
How it works
Section titled “How it works”- Delay. An alarm becomes active after the condition persists for
alarm_delay_s(digital input:dN_alarm_delay_s, oralarm_delay_sif-1). Shorter spikes are ignored. - Hysteresis. An alarm ends once the value returns past the limit by the hysteresis:
temp_alarm_hyst_cfor temperature, 2% of the limit for power. Ending does not use a delay. - An unreadable sensor does not change alarm status: an active alarm stays active until the sensor is readable again.
- Two temperature levels. Warning (
alarm_<name>_warn) and alarm (alarm_<name>_high) are two separate alarms; a temperature rising past both produces two events. - Combined level
alarm_level: 0 = normal, 1 = a warning exists, 2 = an alarm exists. - Changing a limit while an alarm is active re-evaluates it; if the condition ended, an end event is sent. Disabling an alarm (
0) while active also sends an end event once.
Alarm list
Section titled “Alarm list”Names follow alarm_<name>_<condition>, where <name> = the slot metric name (tN_name, dN_name; slot ID if empty).
| Alarm | Status metric | Trigger value | Level |
|---|---|---|---|
| Temperature warm | alarm_<name>_warn |
…_warn_value (Cel) |
warning |
| Temperature high | alarm_<name>_high |
…_high_value (Cel) |
alarm |
| Input active | alarm_<name>_active |
none | alarm |
| Input inactive | alarm_<name>_inactive |
none | alarm |
| Voltage low / high | alarm_voltage_low, alarm_voltage_high |
…_value (V) |
alarm |
| Overcurrent | alarm_current_high |
…_value (A) |
alarm |
| Overpower | alarm_power_draw_high |
…_value (W) |
alarm |
On site: LCD and buzzer
Section titled “On site: LCD and buzzer”- An alarm makes the LCD bottom line blink and the buzzer sound a pattern of four short beeps (80 ms on, 80 ms off) then 440 ms of silence, repeating every second. A warning only appears as text.
- BACK silences the alarms active at that moment (sound stops, no event is emitted). A new alarm, or an alarm that ended and became active again, makes the buzzer sound again and the screen jumps to the Summary.
alarm_buzzer=falseor maintenance mode silences the buzzer; events and status are still sent.
Maintenance mode
Section titled “Maintenance mode”maintenance_until (epoch seconds) silences the buzzer until that time, and telemetry carries maintenance: true. Alarm events are still sent, so the server can flag data during maintenance. It needs the node clock to be synchronized (NTP). A maintenance event is emitted at start and end.
Behavior in special situations
Section titled “Behavior in special situations”| Situation | Behavior |
|---|---|
| Node reboots while an alarm is active | no end event. After boot and the delay, a start event is sent again; treat it as an update, not a new incident |
| MQTT down when status changes | the event is held and sent once connected; the last status is sent, not every change in between |
| Node clock not synchronized | events are sent without their own time; the server uses receive time. Maintenance mode is inactive |
| Slot name changed while an alarm is active | the node first sends an end event for the old alarm name |