Alerts with custom scripts

[atcasanova]

So, I guess it would be nice to have an option to run basic shell scripts on events like new device, device connect, disconnect, etc.
Some variables like IP, MAC_ADDR and HOSTNAME would be built-in. I have an android application that i use to receive custom alerts (using push notifications by one-signal free api), and would be nice to use pi.alert with it :)

[jokob-sk]

Hey!

Thanks fo contributing!

Most of what you've described should be theoretically possible with the existing Plugings system. Give it a read:

https://github.com/jokob-sk/Pi.Alert/tree/main/front/plugins

The notification could be I think relayed via AppRise.

[jokob-sk]

Also could you give me some examples (2-3?) of what scripts you'd run? Ideally in the format:

I want to be able to do XYZ so that ZYX. I considered these approaches XYZ

It gives me a more concrete idea of the value of the feature request. The more details the better. I might extend the plugins system based on those stories.

[jokob-sk]

I'm also unsure when (what are trigger conditions?) the notification would be triggered in this context and what it should contain... so yes, please overexplain if possible :)

[atcasanova]

I'll focus in my case:

i've already got a homebrew notification system. I've written a simple android app that will get notifications from my onesignal account. Then i wrote a shell script that is basically a curl to onesignal with my account parameters, plus the headings, content and URL for each notification. So whenever i want something to notify me on my phone, i would call that script like

./notifier.sh "New device" "IP: 192.168.1.39\nMAC: 01:02:03:04:05:06" "http://pialert.lan"

and my phone would get it. I already noticed that PiAlert supports a lot of services, but I don't want to sign up to another one, or write a webhook handler or something like that because my case is already simplified. I just need to run a script using PiAlert's data as parameters. I guess this would increase a lot in flexibility. I guess a textarea where i could paste my script and use special placeholders like {{DEVICE_IP}} and {{DEVICE_MAC}} for PiAlert data would be enough.

Also this way we could add conditions and a variety of other things to handle notifications better.

[jokob-sk]

Thanks for the details!

I spent some time thinking about it and I'm not saying I'm not going to implement this, but...

There are a few issues with homebrew setups as different people will have different requirements for inputs. In the long term implementing bespoke notification systems is not maintainable in the long run.

It would be more feasible to implement a plugin system for notification services, but then I'm starting to implement an apprise alternative.

and my phone would get it. I already noticed that PiAlert supports a lot of services, but I don't want to sign up to another one, or write a webhook handler or something like that because my case is already simplified.

I understand that, but I also can't implement all edge cases.

An alternative would be to modify your script to check the API endpoints: https://github.com/jokob-sk/Pi.Alert/blob/main/docs/API.md

If I'm going to implement a script-based notification system, it probably won't support the passing of parameters and will be quite basic, as in something that happened. But then that's the purpose of webhooks. So I'm really torn.

paste my script and use special placeholders like {{DEVICE_IP}} and {{DEVICE_MAC}} for PiAlert data would be enough.

Pialert sends notifications on port changes as well as external IP changes so your script would be triggered for all these use cases.

Have a look at the plugin system. You might be able to figure out a plugin that gets you 90% there and then if the script notification is really universal and doesn't require passing of variables, but the whole notification body, then I can implement something that is more usable by a wider user base, not only something that's catering to one specific use case.

Also this way we could add conditions and a variety of other things to handle notifications better.

and that's when even more complexity in implementing this comes in. Again, the request sounds simple, but the code overhead introduced by these changes don't offer a lot of benefits to other use cases, except to your particular setup.

[jokob-sk]

Won't implement as per reasoning above