Closed a-schneider-fmi closed 3 years ago
Thank you Andreas (@a-schneider-fmi ) - this looks useful! ;-)
It looks like ALARM_FUNC is called whenever a limit has been exceeded, regardless of whether the relevant alarm has actually been enabled. Can I just check that that is what you intended? From my side, I think it is OK. Users will just need to be careful to set the thresholds carefully, setting them to artificially high/low values to prevent the alarmType from being set. But maybe we should also pass alarmState
to ALARM_FUNC too so users can decide what to do?
void ALARM_FUNC(uint8_t alarmType, bool alarmState)
{
debugPrintln(F("Executing ALARM_FUNC ..."));
// Add your own code to be executed when an alarm is set off.
}
Very best wishes, Paul
Yes, it is intentionally that ALARM_FUNC
is always called regardless whether the alarm is enabled. As mentioned in my first comment, this gives the user more flexibility to choose what is needed. In ALARM_FUNC
the setting can easily be checked with the global myTrackerSettings
variable, if desired. In my use case, I have for example in ALARM_FUNC
if ( ((alarmType & ALARM_LOPRESS) == ALARM_LOPRESS) && ((myTrackerSettings.FLAGS1 & FLAGS1_LOPRESS) == FLAGS1_LOPRESS) ) { // If it's a LOPRESS alarm and it is enabled
(i.e. the setting is checked). Further down I have
if ((alarmType & ALARM_LOTEMP) == ALARM_LOTEMP) { // If LOTEMP limit has been exceeded
(i.e. without checking the setting). Adding alarmState
to the parameters of ALARM_FUNC
doesn't hurt but is kind of redundant.
Sure, OK, let's go for it! Merging... I'm working on issue #36 at the moment. I'll build your changes into the binary for Example16 once I've got #36 resolved. (I take it you haven't seen the same issue?) Thanks again, Paul
Thanks for merging. Correct, I haven't seen #36; example 16 runs fine on my board, but I haven't tried example 7.
I have added a user function that is executed when a PHT alarm is set off. This user function is intentionally executed always when the thresholds are exceeded, not only when the alarm is active, because this gives the user more flexibility, as the condition whether the alarm is activated can be checked in the user function or not. This feature is useful, e.g., to trigger hardware connected to the ATG upon alarms.