The problems are as I expected related to Corona, chip availability etc.
That is just not true for having to create interfacing/upload options to more than WU. You don't need chips to write new code, do you?
I've still been trying to get my barani output to be read by weewx or a meteobridge, but it's creating too many points of failure. Yes, there is a thing called filepile (
https://github.com/tkeffer/filepile) for weewx, and it should be able to read barani output from an uploaded file to ftp, except the format isn't correct, and since the upload takes places from allmeteo, it cannot be a LAN-only ftp-server, and when you're like me, you live behind a CGNAT (StarLink or 5G/4G internet), making ftp serving close to impossibly complex. My weewx is running on LAN only. I don't feel like having to permanently hook up a VPN or zerotier or ssh-tunnel link in order to basically see/serve the data from a loop. That would just be ridiculous;
barani-devices > LoraWan gateway > LAN1 > WAN (CGNAT) > ISP > TTN > allmeteo > remote-server2 api/ftp > rsync through ssh-tunnel back to LAN1 > WeeWX in LAN > NGINX in LAN > ssh-tunnel back to remote-server2 > NGINX proxy-pass with weatherwebsite..
( i.e. [sigh..] all because barani devices can't be talking directly to a meteobridge or weewx server )
It's still incredible that the LoRaWan gateway, the Laird Sentrius device, which has about as much CPU-power as 3(!) times a MeteoBridge Pro unit, is only able to talk to either TTN or MQTT, not both at once. This gateway hardware could easily run all the meteobridge software, an extra weewx instance, a mini-webserver AND upload to TTN! But it's a closed source linux type. I've tried to hack it, but it's locked down pretty well. Such a waste of energy, that unit.