Add user function to be executed when a PHT alarm is set off.

[a-schneider-fmi]

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.

[PaulZC]

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

[a-schneider-fmi]

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.

[PaulZC]

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

[a-schneider-fmi]

Thanks for merging.
Correct, I haven't seen #36; example 16 runs fine on my board, but I haven't tried example 7.