Problem with alarm reporting

[Dave-T]

I have a pretty serious issue with alarm reporting for things like Ph, or temp, that are sampled at a very high rate. Typically, when the reading goes into an alarm state it hovers around that value, at least for a while. So if I have a temp alarm at 80 degrees, for example, the sensor will read 79.9, then 80, then 79.9, etc - for quite a while. This means that I get an email/text dozens of times in a short period, while the sensor goes in and out of the alarm state before it ends up settling above or below the alarm reading.

How do other people deal with this? Is there a workaround that I'm not thinking of? The way that I think it should work, which isn't how it appears to be designed currently, is that the alarm wouldn't re-enable until it went further away from the alarm value. So if you have an alarm set to 80 degrees, and the sensor reads 80, then the alarm wouldn't re-enable until it went below 79.5.

 

[ingchr1]

This is something I've brought up in the past. The alarm setpoints need a deadband to them. The only "work around" would be to set your alarm higher.

An alarm acknowledged feature would be nice. Acknowledged the alarm and the audible is silenced for that specific alarm. When the alarm clears the audible for that specific alarm is re-enabled. That way if it comes back in you get the audible again, but when the alarm is persistent it's silenced. If a different alarm comes in the audible alarm goes off until its acknowledged.

Another nice feature to have with the alarm would be hysteresis on the setting.

For example the way it currently works, assume you have high temperature set at 80.0F. Alarm comes in at 80.0F, but if it drops to 79.9F it clears. This creates an issue that the alarm bounces in and out until the temperature is a hard 80.0F. This can go on for some time. With a hysteresis you could set it to not clear until it drops to 0.2F or so below setting.

An alarm log would be nice as well.

 

[Dave-T]

I agree on your other points as well. I've also thought that it should allow you to ack an alarm. Did you get a response about this?

 

[BeanAnimal]

In the alarm monitoring world, we call this “swinger bypass”. Once tripped a swinger bypass sensor can’t trip again until manually reset. It can be a one-shot or several shot threshold, but once met swinger bypass takes over and prevents further alarms.

 

[Lasse]

Once tripped a swinger bypass sensor can’t trip again until manually reset.

The level sensors have these possibilities. You can set a "dead" band on every sensor. A must on time and manual/automatic reset on each level function.

Sincerely Lasse

 

[BeanAnimal]

The level sensors have these possibilities. You can set a "dead" band on every sensor. A must on time and manual/automatic reset on each level function.

Sincerely Lasse

As part of the level programming or the alarm state?

I would think that any "alarm state" should have the option. Part of the reason (among others) that I don't use alarms. Something I need to look into in the near future though.

 

[Lasse]

Even I would love to be able to set a respond time on all of the other sensors too.

Sincerely Lasse

 

[Lasse]

Here is my setting for my ATO. If it take more than 4 minutes before the sensor indicate a normal level - the alarm goes on. And the alarm reset automatically if it fill up by time or I fill it up. If not Reset error automatically is active - you need to do a manual reset. I have my heater and temp controller in a compartment that can´t be emptied - if it was that way - i would use the manual reset and a heater shout down if the alarm was triggered.

My sensor must indicate for 3 seconds before anything happens

Sincerely Lasse

 

[BeanAnimal]

Thank you for the update Lasse

 

[ingchr1]

I agree on your other points as well. I've also thought that it should allow you to ack an alarm. Did you get a response about this?

I asked in another thread and did not.

That's what happened with my temperature alarm as well. The alarm was set at 80F but the temp was bouncing between 79.9F and 80.0F, hence the alarm was coming in and out, sending a new text each time. One for the alarm then one for the just clear. I ended up raising the alarm setpoint just to make it stop. My tank normally runs less than 79F.

@Vinny@GHLUSA Maybe something that can be looked at for a future firmware upgrade? Add some type of deadband to the alarm setpoints? e.g. for temp make it so it has to drop by 0.2F before the alarm clears.

Edit - I guess it would have to actually be 0.2C based upon resolution of the sensor being 0.1C.

 

[Dave-T]

The issue is with non level sensors, such as Ph, temp, salinity, ORP. @Gaël - does GHL have any plans to fix this?

 

[Gaël]

Honestly, I don't think in the near future, but it's on the list of things to consider.

Gaël

 

[Dave-T]

Ok thanks. I've received literally 125 emails over the last 24 hours, as my temperature fluctuated around the alarm setpoint. I don't see how they consider alarm reporting useful, with this issue as it is.