Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pushover notifications for "restore" events #504

Open
lpaolini opened this issue Sep 27, 2024 · 9 comments
Open

Pushover notifications for "restore" events #504

lpaolini opened this issue Sep 27, 2024 · 9 comments
Labels
question Further information is requested

Comments

@lpaolini
Copy link
Contributor

Alarm system

EVO192 v.7.70.1

Environment

RPi/docker

Git branch

master

Questions

  1. Why do I receive Pushover notifications for "trouble restore" events, with the following configuration?
  2. Is there a way for lowering the priority (e.g. 0 instead of 2) for "restore" notifications?
PUSHOVER_EVENT_FILTERS = [
    'live,alarm,-restore',
    'trouble,-clock,-restore',
    'live,tamper,-restore',
    'live,arm',
    'live,disarm'
]
@lpaolini lpaolini added the question Further information is requested label Sep 27, 2024
@yozik04
Copy link
Collaborator

yozik04 commented Sep 27, 2024

  1. Strange, should be filtered out.
  2. Not possible with the current implementation.

@yozik04
Copy link
Collaborator

yozik04 commented Sep 27, 2024

Give me an example of an event that comes through.

@yozik04
Copy link
Collaborator

yozik04 commented Sep 27, 2024

Or check yourself.
If you have EVO then this is correct file:

tags=["trouble", "restore"],

Maybe tags are missing for your event.

@yozik04
Copy link
Collaborator

yozik04 commented Sep 27, 2024

Also if you want to study the subject in depth here are tests that describe possibilities pretty well:
https://github.com/ParadoxAlarmInterface/pai/blob/dev/tests/lib/test_event_filter.py

@lpaolini
Copy link
Contributor Author

Give me an example of an event that comes through.

There you go.

Screenshot_20240927-122334

@yozik04
Copy link
Collaborator

yozik04 commented Sep 27, 2024

Add "-zone_tamper_trouble=False". Should fix.
And "-trouble=False", to discard "No trouble for ..."

'trouble,-clock,-restore,-zone_tamper_trouble=False,-trouble=False',

@lpaolini
Copy link
Contributor Author

Thanks! I wish I could understand this syntax fully :-) I'll try digging into the code...

In any case, I think treating restore events as emergency notifications with mandatory acknowledgment is a bit too much. Perhaps priority 0 or even -1 would be more appropriate for this kind of events. Wouldn't it?

@yozik04
Copy link
Collaborator

yozik04 commented Sep 27, 2024

Not that simple.
We have two things that emit events that end up sending notifications.

  • Live events sent by the panel.
  • Property changes that were detected during RAM memory periodic reads by PAI.

For Live events it is easy to filter out what you want as most of them have 'restore' tags set.
Property changes are mostly booleans and there are no restore tags assigned to the property changes.

BTW: you probably can use:
'live,trouble,-clock'

This will send events only for Live events sent by the panel.

But I recommend you to fix the root cause of the trouble =) It is not a normal situation.

@lpaolini
Copy link
Contributor Author

Thanks for the explanation!

Sure, I'll try to fix the root cause of the trouble. Not trivial though, as it seems to be caused by sun rays hitting one of the outdoor IR sensors at some time in the morning, and that seems to be interpreted as a masking attempt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants