Pi Alert slows down network and affects other devices
I installed Pi Alert on a Pi Zero W running Homebridge OS and Pi Hole. After installation, Homebridge started restarting randomly and devices were no longer responding. I have 3 Airport Express bridges that I use for Airplay and thsi caused audio to cut off randomly over 5-10 seconds. Also, internet speed was slowed down on all devices connected to the router, some pages even crashing.
I set a static IP for the Pi in order to use Pihole and set its DNS as default and no secondary in the router's settings. I tried uninstalling the DNS that comes with Pi Alert, but only fully uninstalling Pi Alert and rebooting all devices and the router solved the issue.
I'm not a programmer and I dont know how to code, I'm just creating this issue to signal this to the developers, I apologize if this is not suitable.
I love Pi Alert and hope I can reinstall it someday. Been looking for a long time for a software like this and this is the best I found.
Pleease let me know if I can be of assistance in solving this.
I am not one of the developers of Pi.Alert, so I can only say something limited on the subject.
Pi.Alert does not install its own DNS, at least not in the way that it affects the network. That is perhaps a bit unfortunate expressed. With "add_pialert_DNS" during setup is meant that the name "pi.alert" is entered in the Pi-hole DNS. The later installed "dnsutils" are client software to send for example a DNS request to a server. You could try to set "PIHOLE_ACTIVE" to FALSE in the pialert.conf.
I have currently, independent of Pi.Alert on a Zero W also problems with network stability. I also had to reconfigure another Pi from WLAN to LAN. Do you have the possibility to test another Pi with Ethernet?
I took a closer look at the described problem. It looks like the Pi Zero is already a bit overloaded when the ARP scan comes, so it is a target of the scan. At least that's how I was able to reproduce it with "Shairport-Sync". If it starts the ARP scan as a "server", this can surely consume even more resources. In my eyes you have only two possibilities: Use a more powerful Pi with optional Ethernet, or do without Pi.Alert.
One thing you might want to test last: Select the 1min scan for all devices and comment out the line "pyalert.py 15 ...." via "crontab -e". So that is only one scan active at the time.
Honestly, I was expecting the Pi Zero W's overall capacity to be a problem. Will upgrade and try to see if everything runs smooth. That as soon as I can find a Pi. This shortage really sucks.
I am seeing a similar issue. In my case, I have Pi-Hole running on a different server from Pi-Alert. I simply rsync the Pi-Hole dhcp.leases and pihole-FTL.db files over every so often.
I think the slow down is due to the arp-scans which is generating an arp broadcast storm that seems to be overwhelming the network. Still trying to verify this.
Symptoms for me are some of my smart devices suddenly intermittently showing internet being down (when it is not) as well as my music server stuttering (the music files are NFS mounted from a different server). Basically anything relying on the network heavily starts to show connectivity issues.
For this reason, I reduced the retries in my fork to 3 and set only one scan cylce every 5 minutes. The additional scan cycle every 15 minutes with 12 or 16 retries was removed in my fork. I still notice a little slowdown, but overall it's running a little more stable. However, "weak" devices can still be affected. For special cases I have added a pause function to disable Pi.Alert for a defined period of time.
Thanks @leiweibau. Did not realize there were forks of the project. Is the DB file compatible with your fork? I've spent considerable effort in reviewing and tagging my network devices properly. Would hate to have to redo this from scratch.
Thinking about installing your fork on a new VM, then copying over the DB file with my previous changes. Would this work or are there schema changes in yours that would be an issue?
I have written a command line tool that can patch the DB. But a backup is advisable.
https://github.com/leiweibau/Pi.Alert/blob/main/docs/PIALERTCLI.md
In any case, test it first in a VM, not that you destroy your configuration.