Update External Notifications with a full redo of logic gates#10006
Conversation
|
Your patch looks perfect, also handling the Mute, thanks for considering it!. |
There was a problem hiding this comment.
Pull request overview
Refactors the External Notification module’s message-handling logic to evaluate alert conditions independently per output (generic GPIO, vibra GPIO, buzzer), aiming to fix issue #6368 where the buzzer could trigger on messages it shouldn’t.
Changes:
- Split alert evaluation into
genericShouldAlert,vibraShouldAlert, andbuzzerShouldAlert. - Only activate each output when its corresponding alert condition matches (bell vs non-muted message).
- Consolidate nag-cycle start logic to trigger when any output should alert.
|
Would this also work with GPIO buzzers like here: #6368 (comment) I am asking because in your table, you speak of "Alert GPIO Buzzer when receiving a bell" as Off and |
Yes it should work well overall. |
Ah yes, of course, it is all in the code. All good. In general: I think the main objective has been fulfilled, meaning alerting on bell only working, if and only if, a bell is in the message, alerting on message working also for all messages. https://meshtastic.org/docs/configuration/module/external-notification/#alert-types I was going over this with a firefighter, and was puzzled at times. Now, in BE terms, I am buzzing ;-) To summarize: thank you all very much, I learned a lot about that module. |
* Update External Notifications with a full redo of pathways * Correct comments. * Fix TWatch S3 and use HAS_DRV2605
…stic#10006) * Update External Notifications with a full redo of pathways * Correct comments. * Fix TWatch S3 and use HAS_DRV2605
…stic#10006) * Update External Notifications with a full redo of pathways * Correct comments. * Fix TWatch S3 and use HAS_DRV2605
I have taken the time to map out the various methods and redo the logic gates which I believe corrects #6368.
This was all tested on a Wio Tracker L1 Pro.