Hi @niels80,
I am running such a configuration since over 2 years with Chirsptack (formerly Loraserver) now. As you I have devices using more bandwidth then TTN allows but less then my regulatory domain allows. (btw also an energy meter :-)).
My main reason for having an own (local) LNS (Lora Network Server) and Application Server is being able to have my sensors working even without internet connection. Chirpstack is hosted on a Pi Zero W which also has the concentrator board connected to it and an influxdb.
As already pointed out one needs a single LNS to handle one antenna/concentrator board, because of duty cycle calculations and conflict resolving, if we have multiple downlinks at the same time or overlapping each other in air/time space.
The problem is less the gateway IDs, then the device addresses. In your local network the gateway ID can be anything you like. Might also conflict with anything in TTN. Your packets stay inside your network anyways. The ID can be faked or changed (at least with Semtech UDP) anyways. The Loraspec assumes the gateways to be relatively dumb (and therefore cheap). What you want is, that your packets from the devices are transmitted locally and to TTN. Packet forwarders (poly and mp) can be configured with multiple LNS backends then sending the data to both resulting in the described problems of having multiple LNS wanting to control one gateway.
I “solved” this by patching mp_pkt_fwd in such a way, that it splits device traffic by netid. The “private” netIDs 00/01 are transmitted to the local chirpstack installation and all other traffic goes to TTN. This still does not solve the problem of downlinks being transmitted at the same time by two different LNS. So I added a priority mechanism based on the server. It will prioritize downlink packets from TTN and throw out all downlinks by chirpstack that might be in conflict from the packet forwarders JIT queue. In this way TTN can assume its own packets are send. As I have almost no own downlinks, I have neglected to implement a duty cycle check at the packet forwarders level.
TTN v3 packet broker can be configured in the exact same way, but would require a local installation of the TTN v3 stack. I understood as long as one only acts as “helper” and does not require routing of own netIDs packet broker is free to use (called passive roaming).
I am thinking about switching my Chirpstack to a local TTN stack installation, as it fixes the duty cycle problem. Chirpstack does not yet have a packet broker implementation, but the talks about it started.
But also packet broker does not (yet) fix the problem of having multiple LNSs feeling responsible for one gateway and conflict resolution.
Additionally my patched version (but also packet broker) “steals” all netIDs 00/01, which seem to be of use for others.
So from the (current) software side I do not see a solution (assuming you want to stay with TTN) without drawbacks. The hardware solution would be to setup a second gateway and have one working locally only and the other only for TTN which gives additional downlink bandwidth but might physically not be possible. And then one needs the material, money and around 3W power for something that can (and most likely will) be fixed with software only.