We are looking at using Lora devices via a Gateway and private 4g APN to our MSAzure servers MQTT Broker and SCADA. There could be multiple Sensors and Gateways on different properties.
I am trying to figure out what is the best way to implement a system. After doing some reading online I think I would need a few components?
1 Network server - this could be a Multitech Gateway or is it better being software on the MSAZure platform (Linux box)?
2 Application server - software located on the MSAzure platform (Linux box), this sends data to the MQTT broker?
3 Our SCADA system subscribes to the MQTT Broker.
The Gateways I had (Multitech Conduit and Kerlink IBTS) were setup for other vendors so I had to get their support guys to help me reset to defaults before I could go any further…
As far as I can tell I now have them setup and the Network server /Application server installed on an old laptop running Linux mint (I’m learning all the time with Linux!)
1 Multitech - setup to use AEP, but cannot get the Gateway to come up in the application server. In Mosquitto logs on the server I can see the Gateway IP is connected. I cannot see the end node trying to join in the Mosquitto logs on the GW.
2 Kerlink - I managed to get this to connect to the application server, I can see the join requests in the Lora.log file on the GW from the end node (ST Discovery kit B-L072Z-LRWAN1 (EU868) with application keys updated to match the ones generated on the application server).But However I think this is 923mhz and I am not sure I can change my device to that freq, so I will need to get another device to allow me to try and connect!
So How can I fault find these issues? where do I need to look?
Sounds like you’ve made progress! I was looking to do the samef and this is all new to me. I purchased a WisGate Edge Lite 2 and Dragino LHT65.
You should be able to change the frequency using AT commands on the Dragino if needed (but maybe you can on yours too?).
Did you start with a known working setup? Did you begin with everything working in something like the things network to get a feel for the basics? I would start there and add/remove/replace modules until I got where I needed.
The western world has a lot of these implementations, where are you located? I’m starting with the whole reading portion to see what’s available! That’s how I stumbled on this thread.
Why are you using Linux? what are you using for the app server? Does the software exist in a container, if so maybe docker is a simpler approach. I’ve only used it once or twice but it was a breeze, well documented.
Yeah I think so… just a bit frustrating now as I am unsure where to go next…
On my discovery kit I can change the freq but this may not change it if the ‘radio’ chip is fixed.
Nah I got all the bits together and figured how hard can it be, plus the docs on Chirpstack looked pretty simple, But I may have missed something as there are bits that aren’t that clear, they don’t seem to have much in the way of diagnostic info apart from these forums.
I get most of the theory behind it all in my case its more the hands on stuff as I am not a programmer etc.
I will probably end up using something like TTN, but this has been good as it shows me all the links and how it all works.
In NZ Lora is used but typically you use TTN etc. By setting up your own private network you have more control but does mean you have more to maintain etc.
I am using the full software stack, Gateway bridge, Network server and Application server. The GWs are based on Linux, infact Raspberry PIs are commonly used. As far as I know the server software only runs on Linux, so far its not been too bad, googling command line stuff and learning how to use Linux.
Seems interesting. I think it’s time to fire up my setup and see how far I get with this. Seems we have similar interests in the outcome. If I find anything I’ll keep you posted. Busy with other projects but I’ll take a stab at it soon enough.
Serious non-demo uses should just about always run the network and application servers on traditional server platforms well connected to the Internet. Typically that means one or more cloud compute instances, and I believe that’s what you get when you follow the usual install instructions.
Running the servers on a gateway is inadvisable for more than demo (or isolated with no possible route to Internet) uses, both because it means you can essentially only have one gateway, and also because it means that the node session and crypto records are potentially lost or subverted if the field deployed gateway box is damaged or stolen or simply suffers filesystem corruption. When the servers are running in the cloud, replacing or adding a gateway is fairly seamless since no lasting state is stored in the gateways, but only in the end devices and servers, which means they can make optimal use of all of the gateways available.
Using a hardware server located on your premises is of course possible, but it needs an Internet connection that can accept incoming traffic from gateways. An old PC, a better Raspeberry pi, etc can do this - but keeping it going is up to you, and not the data center company.
1 Multitech - setup to use AEP, but cannot get the Gateway to come up in the application server. In Mosquitto logs on the server I can see the Gateway IP is connected. I cannot see the end node trying to join in the Mosquitto logs on the GW.
My impression is that AEP is a version of a self contained setup idea where the network server runs on the gateway box. You’d want instead to run the gateway in traditional packet forwarder mode, or see if there were some other more advanced chirpstack compatible mode see Multitech - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server
On my discovery kit I can change the freq but this may not change it if the ‘radio’ chip is fixed.
868 and 915 MHz LoRaWAN hardware uses the same chips and the same RF port (unlike 433 MHz which uses the low frequency pins) but the RF networks between the chip and the antenna usually have different component values, so most devices are sold for one band or the other, but a few purport to support both with the same product version. The radio chip itself has no idea which components are installed, the distinction is enforced at software (and regulatory certification) levels only.
I may end up using a server based option but am keen to understand how everything works. For my demo I juts wanted a GW bridge and then on an old laptop run the Network and Application server.
I was advised by Multitech to use AEP, I assumed when reading the install docs on Chirpstack it was just setting up the GW as a bridge and you still installed the Chripstack GW bridge and MQTT and manually confiured the Packet forwarder via the web browser.
I’ll try setting the GW to mLinux and have another go.
Doesn’t really make any sense to be even trying to run mosquitto on a gateway if that gateway is going to be interacting with Chirpstack. Rather, the gateway gets pointed at Chirpstack’s broker that handles the gateway traffic, which may or may not be the same as the one that handles the application traffic.
That’s irrelevant though, because the possibility of operating on MQTT broker on a gateway isn’t of any use in a chirpstack system installed the traditional way with the server on a different computer.
Even if you somehow could make use of it, trying to do so would be a very unwise architecture.
Bind address is only relevant to an MQTT broker, not a client. MQTT brokers should be central in the overall network infrastructure, gateways should only be trying to be MQTT clients.