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.

 

[ingchr1]

@Gaël any updates on adding a deadband to the alarm points? Just received well over 100 push notifications as my temperature is fluctuating 0.1F around the alarm setpoint.

 

[Dave-T]

Yes, please add this feature! And while you're at it, it would sure be nice if the alarm notifications showed the parameter value. Notifications like "value x is too high or too low" aren't super useful, especially when you can't always connect to the Profilux to check what the value is at.

 

[n2585722]

Not sure if this is what you are after but on my controller it has a resend timer. I have mine set to 30 minutes. Once an alert has been sent it will not send another for the same issue for 30 minutes. Even then it has to be in a state that an alert is required. The 30 minute setting is the quickest.

 

[Dave-T]

Not sure if this is what you are after but on my controller it has a resend timer. I have mine set to 30 minutes. Once an alert has been sent it will not send another for the same issue for 30 minutes. Even then it has to be in a state that an alert is required. The 30 minute setting is the quickest.

We are talking about GHL, not Hydros.

 

[n2585722]

We are talking about GHL, not Hydros.

Ok, sorry about that but I assume they may have something similar that can be set. It would probably be a different way though.

 

[ingchr1]

Not sure if this is what you are after but on my controller it has a resend timer. I have mine set to 30 minutes. Once an alert has been sent it will not send another for the same issue for 30 minutes. Even then it has to be in a state that an alert is required. The 30 minute setting is the quickest.

Yes, GHL has something similar but that is not the issue. The issue is, as an example, that if your high temperature alarm is set for 82.0F the alarm will come in at 82.0F and clear at 81.9F. If your temperature happens to be fluctuating that 0.1F, which it will do until it becomes solid on one of those numbers, it will send an alarm in and alarm clear each time it fluctuates that 0.1F. The alarm needs a deadband. For example, if the high temperature alarm comes in at 82.0F it should not clear until at least 81.7F. This way you do not get that cycling of the alarm in and out. For temperature I say the deadband should be at least 0.3F since underneath GHL is operating in degrees Celsius, so it actually needs to be at least 0.2C of a deadband.

 

[n2585722]

@ingchr1 the Hydros does not send a alarm clear alert. It will just stop sending an alert every 30 minutes if it clears for that item. If it does not then it will keep sending them every 30 minutes until it is clear. Below is a recent list of push notifications from mine. One is because my reservoir for my KH buffer dosing is low. The other two is room temp but that is form 2 different days and then ATO run time exceeded. It will turn off the ATO if it hits the maximum runtime. That one will only clear by either the sump level going wet or I override the output to off and then back to auto if I do it remotely. I I am at the tank I can override to on and then back to auto but I don't want to take a chance on not getting it from on back to auto if I am not there. The second screenshot is during a power outage, I have 2 collective one is Aquarium Control and the other is Mix Station. The Aquarium Control has battery backup and Mix Station does not. So I did get a device not responding alert from the cloud server for that one during the outage. I have the cable modem and router on a UPS also so it will remain powered during an outage. The longest the power has been out is about 4 hours and both aquarium and UPS lasted that long. My return pump will not run without AC power so that is the reason for the sump overfull alert. Also the two leak detectors for the RODI and AC unit are not Hydros and default to leak when they loose power. I do have them connected to sense ports on the Hydros. These notifications are off of my iPad. My phone also receives them.