Multi-site support

[simon-ball]

Ahoy!

I currently run a pair of instances of BirdNET-Pi, to support observations at home and at my girlfriend's folks' cabin (about 150km away in a very different environment), and I have two more sites in mind pending discussions with the neighbours. Currently, that means running 2 (soon to be 4) independent but nearly identical virtual machines, segmenting available storage etc. The only differences between them are:

• Different co-ordinates and birdweather ID
• Different block/allow lists (e.g. at home, I have a bunch of species blocked because passing trains imitate kingfisher, puffin, bittern and peregrine; while none of those are issues at the cabin)

The intention of this discussion is to explore

1. whether there is sufficient interest to justify the complexity of trying to make BirdNET-Pi capable of supporting multiple sites within a single instance
2. evaluating all the various complexities that would need to be taken into account to achieve that

I suspect it's a fairly narrow niche, so I won't be offended if it's too minor to be worth bothering with.

As far as I can see, the various components that would need to be adapted would be:

• Configuration data. There's a bunch of configuration data that would need to be made site-specific. Co-ordinates, allow-list/block-list, birdweather api key, and probably more

• Configuration interface: How to provide a sensible means of providing this data, without adding needless complexity for the far more common case of a single-site instance

• Frontend interface. Somewhat similar to Identify detections by RTSP stream #172, how to adjust the various reports, notifications and visualisations to make clearwhat observations are coming from where

As far as I can tell, the database backend and analysis scripts are broadly compatible already, since they the major difference there would be recieving/storing a more varied group of lat/long co-ordinates.

[Emmo213]

I've actually thought about something similar where if I had a BirdNET-Pi in the front of my house and the back of my house it'd be nice to have a single dashboard to see everything. I didn't pursue it yet but here are some of my thoughts on it:

• While supporting multiple instances in a single master instance would be nice I think it would end up cluttering the code too much, especially since there's a desire to not stray too much from the original project.
• My first thought was to create a separate project as an aggregator. Push the alerts from each instance to MQTT, have the new project read from MQTT, have a dashboard with links back to the original alert if desired. I think this could be done really without any changes to the current BirdNET-Pi code and then the aggregator would just be a separate project. I think this may be the most flexible, and fun to code, solution but would also require the most time.
• Another option would be to do something using a 3rd party like Grafana. This example from Grafana they've dubbed Obirdability takes the log files from BirdNET-Pi and has some really nice dashboards around them although I found their specific setup lacking in a few ways, with the largest being that the logs they're reading has detections (>80% probability) but that aren't considered detections from BirdNET for various reasons. It'd be better to only have detections that BirdNET thinks are detections to be consistent, but this solution could be updated fairly easily to support multiple instances, and it's entirely possible to host your own Grafana instance if desired.

[wenestvedt]

I am also interested in having a front yard/back yard pair. Combining the statistics, but still being able to dig down to specifics, would be a lot of fun.