It doesn’t seem to be an authorization issue, you’d get a Connection Refused: not authorised error message in that case. Instead, if I try to connect using a wrong port (I’m running mosquitto at 1883), e.g. mosquitto_sub -h localhost -p 1900 -v -t “gateway/+/rx, I get Error: Connection refused as a response. So maybe check with explicit host and port?
Of course, check that mosquitto is actually running too.
Feeling pretty dumb asking this but how would I check if mosquitto is actually running? I’ve been given a GW, loraserver which were “all set up” and I am kind of in the dark with all of this because it was supposed to be working
As opposed to what, the gateway? Could you clarify your setup? It seems you are running two mosquitto instances, which is odd. In any case, I’d recommend reading the project’s overview and the architecture found there, and then check the whole documentation to see what your deployment shoulkd look like.
Yes, as opposed to gateway. Did you see both my posts? The first one is from the GW and the second one from the server. It looks like mosquitto starts and exits immediately on GW from what I see above (not sure).
Thing is this setup I have has been given to me and I haven’t been changing anything. It should be done correctly and follow the architecture guide you provided.
In the notes I have been given it says mosquitto has been deployed on server.
What I meant is that it doesn’t make sense to have a mosquitto broker in your gateway if you have an external loraserver. You run mosquitto on the gateway when you want to run all the loraserver stack locally, because lora-gateway-bridge, loraserver and lora-app-server connect to the same broker. In a typical layout, the broker is running in a server that’s reachable by all 3 services, however they are deployed (e.g., we run lora-gateway-bridge at our gateways, and loraserver + lora-app-server + mosquitto at a central server, but you could use different machines for those as long as they are reachable).
Anyway, it seems originally you tried to subscribe to the broker at the gateway and it wasn’t running (though if it was it would still be wrong to try to do it, as the server’s broker is the one working with your stack), so problem solved.