Alarm/Event delays

[liltux]

@jgyates 2 questions.

1. Alarms and Events, are they handle in the same manner? If I am understanding from previous issues/discussions, there is a register that has a specific value if it is Alarm(Shutdown), Warning, or Event(state change). With regards to the software processing and messaging, are these handled in the same manner.
2. How difficult would it be to introduce a timer or delay into the message handling. Example, Low battery warning triggers, timer starts, times out 2 sec., if alarm is still present, message is handled and sent. Else if it is not present, no message. Or, with communications. There is a dropped packet, modbus exception - trigger timer and timer expires - no longer dropping packets or modbus exception is not present, no alarm? I am dealing with more so on the communications side.

I don't know if it makes sense, but I know on the industrial side with DIO and Analog inputs we can program slight to lengthy delays for error handling depending on how critical or not the event is. This helps eliminate error messages that are not being helpful or effective. I maybe the only one experiencing this type of issue on a generator, but we generator anywhere from 2-4 comms loss messages in a week to 60 in a day. But every time I check the GUI, it is accessible and functioning. Not sure if it is worth the effort or makes sense.

[jgyates]

Hi @liltux

In general alarms and events are handled in the same way. It varies a little from controller to controller, but in general the software looks for any changes in the switch state, engine state or generator state. If there are any changes in the previous states, then it checks if an alarm is active alarm (sends a notice if it is), if no alarm then it sends a notices on the current state. This method avoids the notification logic from having to know about specific alarm types or handle situations differently.

Are you interested in a delay for all notices, or just for specific ones. The latter would be difficult to implement with out a lot of trade offs.

Comms loss errors can be handled in a few different ways. If you are experiencing timeout errors then you can increase the modbus timeout on the the advanced settings page. If you use serial over TCP over wifi, you can increase your signal strength or switch to Ethernet or direct serial to get rid of comm loss due to wifi signal loss / reflection.

Is the issue you are trying to avoid only a comms loss notification? If not, then what controller and message is the issue?

[liltux]

Just comms loss at this point. Can see a benefit to other alarms, but mostly comms.

I am getting a response errors, like incomplete packets. It is on the industrial H-Panel on WiFi serial server, the Genmon is actually in the server room. I do not have a report of the serial server signal strength and I do not have budget to pull a separate ethernet cable to the unit. The blips or messages or within seconds, comms loss/error and then comms restored.

I suspect it is in the battery voltage and has to do with the dips during the weekly exercise or outages, but yet do not have any hard evidence.

I was just throwing out the idea per conversation to see if it makes sense to allow a delay, which in this case and the interval of the alarms may or may not help, or even if it would be to difficult to implement it would not make sense.

I have other things to look into as in better battery source, power supply circuit improvements (adding caps/diodes to help get through the voltage dips), or even try ModbusTCP vs Serial Ethernet on how the packets are clumped and processed. I will let you know how that goes.

[jgyates]

There is also a setting named "Additional Watchdog Timeout (sec)" on the advanced setting page that may be exactly what you are asking. At one point I was having issues with serial over wifi and added this setting and the modbus timeout as options. The modbus timeout can help with timeout errors as it waits longer for a response. The additional watch dog increases the time without a change the received packet count before sending an comms failure. the default comm watchdog timeout is 2 sec for serial and 8 sec for TCP. The additional watchdog setting will add to each of these, for example for TCP, if you have 5 additional seconds the total time out for comms failure is 13 seconds.

[liltux]

Thanks! I always wonder what that delay was for. I will give that a go and see what happens.

[jgyates]

ok. let me know if you have any issues.