Hi there!
We have a Loraserver implementation runing with several RAK831 gateways.
We want to deploy 25 new gateways using the RA7249 DIY gateway.
The MQTT bridge currently installed in the latest RAK7249 firmware doesn’t support Loraserver message format.
Is there anything I can do to make it work?
Both stats and uplink packages differ in format (Loraserver uses protobuff and RAK current implementation uses JSON)
Thanks in advance.
Hello @stormforce133,
You could host the LoRa Server on a separate machine. Configure the RAK7249 to work as an MQTT Bridge and point it to the aforementioned machine. Will this do?
Regards
Vladislav
Our LoRaServer is in another machine, it is actually in a Compute Engine VM on Google Cloud.
The MQTT Bridge is pointing to this VM.
The issue es that the LoRaServer marshaller can’t process the package:
Jun 21 15:11:02 camuzzi-outbound-service loraserver[30221]: time="2019-06-21T15:11:02-03:00" level=error msg="gateway/mqtt: unmarshal gateway stats error" data_base64="eyJtYWMiOiI2MGM1YThmZmZlNzRkMjcxIiwidGltZSI6IjIwMTktMDYtMjFUMTg6MTE6MDJaIiwicnhQYWNrZXRzUmVjZWl2ZWQiOjAsInJ4UGFja2V0c1JlY2VpdmVkT0siOjAsInR4UGFja2V0c1JlY2VpdmVkIjowLCJ0eFBhY2tldHNFbWl0dGVkIjowfQ==" error="unexpected EOF"
Jun 21 15:11:08 camuzzi-outbound-service loraserver[30221]: time="2019-06-21T15:11:08-03:00" level=info msg="gateway/mqtt: uplink frame received"
Jun 21 15:11:08 camuzzi-outbound-service loraserver[30221]: time="2019-06-21T15:11:08-03:00" level=error msg="gateway/mqtt: unmarshal uplink frame error" data_base64="eyJyeEluZm8iOnsibWFjIjoiNjBjNWE4ZmZmZTc0ZDI3MSIsInRpbWVzdGFtcCI6NjUyOTcxMTY0LCJmcmVxdWVuY3kiOjkxNzQwMDAwMCwiY2hhbm5lbCI6MywicmZDaGFpbiI6MCwiY3JjU3RhdHVzIjoxLCJjb2RlUmF0ZSI6IjQvNSIsInJzc2kiOi01OCwibG9SYVNOUiI6OS41LCJzaXplIjoyMywiZGF0YVJhdGUiOnsibW9kdWxhdGlvbiI6IkxPUkEiLCJzcHJlYWRGYWN0b3IiOjEwLCJiYW5kd2lkdGgiOjEyNX0sImJvYXJkIjowLCJhbnRlbm5hIjowfSwicGh5UGF5bG9hZCI6IkFFVlFSekl6VFZSVENYUWhBQXVqQkFCNGNBWDQrWk09In0=" error="proto: can't skip unknown wire type 4"
Here is a package from LoRaGateway Bridge running in a raspberry:
And here is a package from the RAK7249:
(i cant upload more than 1 picture)
(these are stat packages)
Here is the afromentioned picture:
We’re using LoRaServer 3.0. As far as I know, the default marshaller up to version 2.x was JSON, now it switched to Protobuff
The RAK gateways is working fine, it redirects all the join requests to LoRaServer. Here is the proof 
Hi @stormforce133,
Looking at the qutote below from the LoRaServer forum, I would say the issues is as you expected.
LoRa Server v3 is not compatible with LoRa Gateway Bridge v2.x, but LoRa Server v2.7+ is compatible with LoRa Gateway Bridge v3!
So I would say no dice with LoRaServer 3.0. Perhaps downgrade, or wait for RA7249 Update (the latter I can not guarantee).
Sorry I am not more helpful.
Regards
Vladislav
Yikes…
I can’t downgrade without redeploying all the databases and gateways currently in production.
I guess I’ll have to wait or opt for Raspberry based gateways.
Thanks anyway!
Hi @stormforce133,
This sounds way to troublesome indeed. Perhaps the Master @yutao could find a solution ?
I am sure he will advice you ASAP on the best course of action.
Regards
Vladislav
@Oskariot I’m using MQTT.fx!
@Hobo Thanks for your support. I’ll wait to see if there’s any news, I can’t downgrade LoRaServer now because I have several production gateways.
@stormforce133, thank you for hint 
… so RAK831 is running with loraserver 3.xx w/o problem? I have tried it with RAK2245 with no success, How have you set the environment? I.e packet forwarder/GW settings/loraserver? With 2.6 it works for me but not with 3.xx … I have gone several time through configuration files generated vanilla with loraserver/GW tweak it with no success, it seems that I’m running in circles like squirrel 
@Oskariot
I had the same issue. I resolved it here: https://forum.loraserver.io/t/gw-does-not-exist-on-config-received/4685/6
Ok, I’ll try it, … and are you running GW bridge on GW or on server with Loraserver 3.xx installed (in the cloud)?
I run GW Bridge on each gateway. It runs very well and the Raspberry Pi Debian is super stable
One/two last questions (I hope 
) : so you have installed gateway bridge v 3.xx on RasPI, OS is vanilla raspbian and you have compiled RAK packet forwarder for raspbian?
No problem
I’ve used stock Debian with TTN packet forwarder. Then I installed GW Bridge and configured it to allow configuration changes and packet_forwarder restarts with this 3 lines:
base_file="/opt/ttn-gateway/bin/global_conf.json"
output_file="/opt/ttn-gateway/bin/local_conf.json"
restart_command="sudo systemctl restart ttn-gateway"
Then I allowed the user gatewaybridge to be able to restart the process in the sudoers file:
gatewaybridge ALL= NOPASSWD: /bin/systemctl restart ttn-gateway
PD: I also had to change the restart script for the TTN packet forwarder (`/etc/opt/ttn-gateway/bin/start.sh’) because the restart PIN was different:
# Reset iC880a PIN
SX1301_RESET_BCM_PIN=17
Hi @stormforce133, well you have to be bright minded 
, I’ll try to translate it to my brain surface 
. Where did you get this Debian with TTN packet forwarder? Why didn’t you use “standard” LoRa Gateway OS prepared by Loraserver community (broocar)? Is there any issue with it? Cheers.
Because then I configured my gateways there was no Gateway OS
TNN packet forwarder already solves the auto start script and all that crap that always annoys me
I am testing a RAK2245 using lora-gateway-os-base and I found a couple of issues.
First, I noticed mqtt publish messages from the gateway for stats were reaching the lora-server with topic “gateway/{id}/stats”, but the lora-server was subscribed to topic “gateway/+/event/+”, so I modified the lora-gateway-bridge.toml to add “/event/” to each topic template in section backend.mqtt as follows:
[backend.mqtt]
uplink_topic_template=“gateway/{{ .MAC }}/event/rx”
downlink_topic_template=“gateway/{{ .MAC }}/event/tx”
stats_topic_template=“gateway/{{ .MAC }}/event/stats”
ack_topic_template=“gateway/{{ .MAC }}/event/ack”
config_topic_template=“gateway/{{ .MAC }}/event/config”
Then the lora-server started receiving the mqtt messages, but it fired an error: level=error msg=“gateway/mqtt: unmarshal gateway stats error” error=“unexpected EOF”
I ended up here looking for a solution and I found it, lora-gateway-bridge.toml have a parameter to use protobuf encoding instead json, that is what lora-server v3 is expecting. I just changed parameter marshaler=“protobuf” and now lora-app-server is showing gateway stats as expected.
(from lora-gateway-bridge.toml)
Payload marshaler.
This defines how the MQTT payloads are encoded. Valid options are:
- v2_json: The default LoRa Gateway Bridge v2 encoding (will be deprecated and removed in LoRa Gateway Bridge v3)
- protobuf: Protobuf encoding (this will become the LoRa Gateway Bridge v3 default)
- json: JSON encoding (easier for debugging, but less compact than ‘protobuf’)
I hope this helps anyone having the same issues.
Hi @Nesken, great addition to our discussion , yes, this parameter is one of the changes on loraserver platform side version 3.xx. So you have already tested “standard” loraserver OS v 3.xx on RasPI with PI HAT 2245. It sounds good for me and safe for my brain I have to try it. Any other issue on the way of sending messages to loraserver?, by the way, you have your loraserver locally on RasPI or on different HW/server/cloud?