Locking out repeated API alarm notifications from UNO

I had a series of alarms occur yesterday where my API notification service received
repeated sensor alarms from two temperature inputs. I have written the code to lockout
any further reports after the first instance and can only be reset by physically pushing a
switch input at the UNO.
Yet I received a group of alarms from these two inputs over the space of about 1 minute
and 20 seconds, with about a 9 second gap between reports.
I am trying to figure out how the processor is ignoring the lockout flag. It can't be a processor reset as the alarms are reporting too fast for that to happen; I have a built in 5 minute startup delay in the void setup() to allow routers and things to reinitialize after a power outage.
So what else could allow the flag to be ignored?
Is it an instability with UNO WiFi Rev2 possibly? Voltage flucuation? Anthing like that you would think would either freeze up the processor or cause it to reboot.
Or is there a way to add code that would check this type of thing and prevent the lockout flag from being ignored?

system_reset_switch_state = digitalRead(system_reset_switch);
  if (system_reset_switch_state == HIGH) {
    temp_alarm_state_1 = false;
    temp_alarm_state_2 = false;
    temp_alarm_state_3 = false;
    temp_alarm_state_4 = false;
    temp_alarm_state_5 = false;
}

if (boiler_rm_temp >= Boiler_Rm_Tmp_Alm_Setpt  &&  summer_mode_lockout == false)  
  {
    temp_alarm_1 = true;
  }

if (temp_alarm_1 == true && temp_alarm_state_1 == false) {
    temp_alarm_state_1 = true;
    strcpy(blr_rm_temp_state, "ALARM");
    strcpy(report_system_alarm, "ALARM - Boiler Rm Temp!");
    sendToPushingBox(DEVID1);
  }

Alarm History Report from API:

27 November 2023 at 20:55:36 Boiler_Rm_Temp_Alarm
27 November 2023 at 20:55:26 Tank_Room_Temp_Alarm
27 November 2023 at 20:55:17 Boiler_Rm_Temp_Alarm
27 November 2023 at 20:55:09 Boiler_Rm_Temp_Alarm
27 November 2023 at 20:54:59 Boiler_Rm_Temp_Alarm
27 November 2023 at 20:54:50 Tank_Room_Temp_Alarm
27 November 2023 at 20:54:41 Tank_Room_Temp_Alarm
27 November 2023 at 20:54:32 Tank_Room_Temp_Alarm
27 November 2023 at 20:54:22 Boiler_Rm_Temp_Alarm
27 November 2023 at 20:54:2 Tank_Room_Temp_Alarm
27 November 2023 at 20:54:13 Boiler_Rm_Temp_Alarm


system_reset_switch_state = digitalRead(system_reset_switch);

  if (system_reset_switch_state == HIGH) {
    temp_alarm_state_1 = false;
    temp_alarm_state_2 = false;
    temp_alarm_state_3 = false;
    temp_alarm_state_4 = false;
    temp_alarm_state_5 = false;

  • How is the system_reset_switch wired ?

Larry,

I used a normally closed pushbutton switch for the reset input as it was something I had on hand at the time I installed the project.
Attached is a quick jand sketch of the wiring. I have a LibreCad drawing but wasn't sure if I could transfer that here and you be able to look at it.

Ed

Suggest you add a pull-up resistor (start with 1k) to both Arduino input pins 5 and 6 to Arduino Vcc.

I am fond of simple but effective suggestions. Does it matter if I source either the 5 volt or 3.3 volt?
edit:
I just realized after looking at the sketch code INPUT_PULLUP is being used on
the pinMode definition.
Is it better to go with an external resistor and redefine the input?
This is a UNO WiFi Rev2.

  • External pull-ups should go to the same voltage as the controller is powered from.
    i.e. UNO Rev3 is 5V, ESP32 is 3.3V

  • Was not sure if you used INPUT_PULLUP. :thinking:

  • As a test, you can still try adding the external 1K pull-ups to see if there is any change.

I am thinking to try an external resistor anyway and maybe go this route on all my digital inputs. A couple days ago I had an alarm on my system that indicated a low storage tank water level. And I know for a fact the float switch could not have been able to change state as the tank was completely full and the float was pinned at the top of its vertical travel.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.