I have some questions regarding the support of this feature in the long term.
Relay gateways are not connected to an ip network, so the software stack can’t be updated as I understand.
How can I be sure that I can use the relays in the future without having to update them in the field because of some compatibility issues with other components of the stack?
When you have >10.000 locations this is not an option. The cost and the risk would be to high.
What do you think of this scenario?
Does a Chirpstack Mesh in general make sense in a 1500m2 two floor building with a single border gateway and multiple relays?
If there are >50 sensors per location and there are multiple relays close by, as I understand every relay will replicate the uplink. In my understanding this would influence the network saturation heavily.
It sounds like you’re working on a commercial project. In my opinion, this is an occupational risk of adopting free, open-source projects; it’s down to how stable the interfaces between modules are and how committed the maintainers are to keeping it forward & backward-compatible.
Since it’s young, I suppose we cannot tell how it’ll age. But you have the choice to hold off upgrading, if incompatibilities appear at some point.
The usecase of this system is to support cases where you don’t want to/cannot have a full IP-based backhaul. e.g. out in the field, where there’s no cell coverage.
LoRaWAN’s range can be awesome at times (it can penetrate 4 floors in my building), so you need to try it out first to know how suitable either solution (using LoRa gateways with fully-functional backhauls or mixing in the mesh function) is.
I haven’t used Chirpstack’s mesh function before, but there’s always two unused channels in the SX1301 that were meant for meshing/backhauling. So I guess you could attempt to use the unused channels and datarates to avoid polluting the normal channels used by devices.
I’m talking about the standard LoRa channel (fixed-SF) and the FSK channel.
I am planning to make a small change in the next release (no eta yet), which will change the heartbeat message (Protocol - ChirpStack open-source LoRaWAN® Network Server documentation) into an “event” payload, where the value is a TLV (type-length-value) payload. There is still one payload type bit available which will be used for a “command” payload, where the value will also be a TLV payload.
The plan is to provide a list of “known” types, e.g. heartbeat, battery level, maybe some additional metrics (number of messages received / transmitted) and also provide a range for “proprietary” types. The plan is to make it possible to handle these payloads externally (e.g. command).
This would make it possible to implement proprietary management commands over LoRaWAN, which might help you to manage large-scale Mesh deployments.