I think I am expecting something impossible. I need to open udp:1700 for Helium to send packets to my Chirpstack Gateway OS. I’ve tried ChirpStack-udp-forwarder and no go. I’ve seen a reference to using MQTT instead but have no idea how to do that. Has anyone successfully set up a Helium connection to Chirpstack Gateway OS? I’ve done everything I think I need but I can’t seem to set up udp:1700 reception with Chirpstack-concentratord. Do I have to start all over with docker instead? Chirpstack is working fine with a local concentrator but it doesn’t seem to be using udp:1700 or any udp port to transfer data.
I think you would have to pass your helium traffic to the MQTT forwarder on your OS. Which translates the UDP packets typically sent by a UDP packet forwarder into MQTT messages Chirpstack understands.
That being said I know very little about the Helium network, other than that it is supported by Chirpstack. Although my understanding was that each network within helium just works as a roaming network for the greater network, perhaps you should look into the roaming network configuration in the Chirpstack.toml if that is the case?
Thanks for your answer. I’m using the full OS image. I went through all the steps outlined in the Helium Chirpstack docs. I’ll see what sending the helium traffic to MQTT does. Not sure how that will work.
From what I can read, the helium network acts as another gateway on your network, sending UDP packets to your network server. In Chirpstack any communication between Chirpstack and a gateway must go through MQTT, it is Chipstacks only communication pipe with the gateways. The MQTT forwarder is Chirpstacks way of translating regular UDP packets into MQTT so Chirpstack can take it. So it would make sense if you had to send the Helium UDP packets to the MQTT forwarder.
In a typical installation it is 1700, as that is the port a UDP packet forwarder sends to. Although I am not sure how this is handled in the Chirpstack gateway OS, as the UDP packet forwarder is cut out and the MQTT forwarder gets it traffic directly from concentratord.
Perhaps the firewall on the CSOS just blocks this port externally? Or else the MQTT forwarder is bound to a different port or interface (i.e 127.0.0.1) in CS OS. I don’t have my Pi with me so I cannot test these things myself at the moment.
I don’t find any evidence that port 1700 is opened or even attempted to be opened in CSOS or any port for Chirpstack other than 8080 for the UI interface. I do have a LoraWan hat that seems to work OK locally without using port 1700 so they are doing something internally with the SX1301 driver. I am using ChirpStack-concentratord. Is there a way to use Semtech in parallel? Something is missing in the docs for CSOS.
So close. Helium is all set up as far as I can tell it just has no place to go.
It would take a lot of work to download the semtech concentrator on your CS OS and would kind of defeat the purpose. Also helium doesn’t require you to have a concentrator so I don’t understand why it matters.
One thing I am confused about though is how you configured the necessary Chirpstack.toml changes in your CSOS since you are using the full image? Is all of that supported by the UCI commands?
Seems a little strange to me aswell that you would want to use CSOS for this purpose, do you have a need to use the Pi as a gateway of your own? The typical reason you would use CSOS is to enable your Pi as a gateway of its own. If you want it solely for handling other peoples packets through Helium, you probably would be better just doing the docker install.
Yeah, I was intending to use my pi with concentrator as a local gateway, too. I suppose Helium would do all that alone if I could get it working. I think I did some tweaks to the config in the cli, don’t really remember. It just worked. I did have to free up the reset pin since Raspberry Pi OS reserves it for some use I don’t need. Worked fine since. I was planning to move this Pi to my second home as a Helium gateway. I have an OUI and DevAddrs and all that stuff required for it to work as a Helium hotspot with Chirpstack. I didn’t want to start all over but Chirpstack Gateway OS seems to have very limited configuration options from the UI and some barricades internally. My local LoraWan devices work fine with it and MQTT shows all the activity just fine.
I’m still waiting for Helium Console to shut down. They gave plenty of warning. Need better instructions on how to get local Chirpstack working with Helium I guess. They seem to want you to use a Helium Console Service that runs Chirpstack rather than running your own as a service. Meteo Scientific is an example that works. Everything on YouTube is geared to using that as a service. I just prefer running my own servers so I know what is going on.
think of helium as just another gateway that you ingest on the same port other external gateways would send data to using semtech udp packet forwarder (gwmp).
so if you are using eu868 region on udp port 1700 for example you would allow external gateways as true as well as setup the netid and devaddr block in the chirpstack config with your own settings you got from helium and then by using the helium-config-cli tell helium to push eu868 to you via gwmp to your IP/DOMAIN on port 1700 (make sure firewalls are not blocking).
on top of all this you will need to handle adding all the device euis and network session leys to helium so it knows what devices are yours and which to forward to you. I have not ran chirpstack os… but i have a python connector on gh that runs like a sidecar to a chirpstack-docker setup which handles all this for you.
So @kskenyon all you would have to do is enable the semtech_udp, then configure the [backend.semtech_udp] section. How you do this in the GW OS is tricky though, as simply editing your mqtt-forwarder.toml will not persist through reboots (as it is generated on boot by the script linked above). So you could change the script that generates the .toml file, which is probably your best solution for now, but that would not persist through firmware updates.
Ideally the option to enable the udp backend would be added to the UCI configuration commands, but that might go against the idea of the ‘full’ GW OS install being mainly for prototyping and testing as it would encourage adding multiple gateways to the single Pi.
