Hi
I currently run a number of private single channel LoRa mesh networks. They’re not perfect but they work.
I’m thinking of switching to a chirpstack mesh network, as it should be more robust, multi channel etc.
Currently the LoRa modules on my sensors are also repeaters for other sensors.
Ideally I’d like to stick with this model which would entail adding sensors to the relay gateways.
Does anyone know how hard this would be?
Late reply but that’s how the Chirpstack gateway mesh works. The relay gateways will also work as gateways themselves to receive uplinks from end devices.
Sorry, I don’t think my question was clear enough.
I want to actually connect environmental sensors to the relay gateways, not by radio but to use the relay gateways as sensors.
It would be messy, especially to have them uplink through Chirpstack and appear in the UI. Although I’m sure it is possible, for example there is a LoRaWAN simulator out there to perform stress tests on your network, it creates “fake” Lorawan uplinks from different gateways, I believe it works by sending UDP packets to your gateway bridge that mimic real gateway uplinks.
The extra layer of complexity here is that you want to use the gateway mesh, which typically proxies traffic directly to/from concentratord, so to have the sensors on serial connections on the relay gateway, you would have to figure out how gateway mesh component interacts with concentratords API to pass along uplinks, then mimic that behavior with the incoming serial connections, translating them into whatever type of API request concentratord expects for Mesh packets.
You would also have to deal with how Chirpstack views these, you’d likely have to make these gateway sensors their own “device” in Chirpstack’s perspective, which means you would have to handle keys and encrypting the necessary data such that the gateway can send it over the mesh and the server can decrypt it, you’d likely want to have these sensors activated as ABP devices so you don’t have to handle the join process as well. But you’d have to pass the data to concentratord as if it was a fresh uplink that came from a device that is activated on your server.
Typically a mesh uplink goes:
Concentratord receives uplink from a device (could be a gateway but lets keep it simple) and passes it to the Gateway Mesh component.
The Gateway Mesh component wraps the packet in some additional mesh details, then passes it back to concentratord, telling concentratord that this is now a downlink (but it should broadcast it in uplink frequencies such that the next gateway will receive it).
Concentratord then broadcasts the downlink (in uplink frequencies) to the next gateway.
You would have to skip steps 1 and 2, but transform the data from your local sensors into a similar format the gateway mesh component would. Then use concentratord’s API to send that message to the next gateway in the chain.
One thing that I’m planning to update in the next release (no timeline yet) is the heartbeat payload. I’m planning to refactor this into a TLV (tag, length, value) payload such that multiple payloads can be supported, including proprietary payloads. Then the heartbeat will be one of these payloads. This that then also could be added is battery power, location, etc…
Once this is in place it would mean a feature could be added to collect data through any command (e.g. to output your sensor data) and send this as an event with a proprietary tag. Would that work?
I’m not the OA, but this is a great idea and would be super-helpful for us as well.