Help testing ChirpStack v4 (test releases)!

Announcements
29

HI @orne

I was just wondering how you configure a gateway to be in a different region.

Whilst we are in EU, we have a partner in New Zealand. We added the gateway, but the region still says EU. It is not apparent where to change the region?

Can you advise?

Thanks

30

I managed to change the region, and I think I understand now. If one is to have multiple regions, do we simply need to create another gateway bridge and add it to the stack and then point the gateway at the associated bridge?

31

Hello!
Is there a way to disable frame counter validation for ABP devices? Although this is not good practice, it would be great for development and debugging.

32

Any hint where to place uplink_dwell_time_400ms configuration in 4.0?

I tried to put it in the region toml but is not being picked and sent by chirpstack

[[regions]]

name=“au915_1”
common_name=“AU915”

uplink_dwell_time_400ms=false
downlink_dwell_time_400ms=false

33

you 0 the frame counters on the device page and click on reactivate device.

1 Like
34

Please see these diagrams explaining the two possible options:

  • Separate MQTT brokers
  • Use the region topic prefix

https://www.chirpstack.io/docs/architecture.html

1 Like
35

You must put it under [regions.network]

3 Likes
36

Let me check, this config is available but the UI components in the web-interface might be missing.

Edit: Fixed in Add missing isDisabled and setSkipFcntCheck switches (UI). · chirpstack/chirpstack@cfb4290 · GitHub

1 Like
37

Hi everyone :blush:

I am agree with you my problem is solved.I am very happy. I am share this thread with my brother who wants also know about this Help testing ChirpStack v4 (test releases)! - #35 by brocaar.

Have a nice day to all the members :innocent:

38

are the keys the same? I tried putting them there and still no mac message is sent.

40

When I click Generate certificate in the MQTT integration, there’s an error saying “Read mqtt ca_cert”. How to get this working?

41

Please see this documentation to set this up: Mosquitto TLS configuration - ChirpStack open-source LoRaWAN® Network Server documentation.

42

Hi,

I’ve done that as well. I’ve tried that, also on multiple paths too, but the error still shows up, which means it failed to read right? https://github.com/chirpstack/chirpstack/blob/96fe672fc7790b4321b3729bbf70b3e6318db83f/chirpstack/src/certificate.rs#L122

43

i was part-way through an initial deployment on V3 and decided i’d cut my losses and start again in V4 rather than face imminent migration. It is so good!! And more intuitive. And so far no real rough edges.

44

Will this allow me to use Semtech Basic Station to connect to the server?
I need to test the latest SBS on a LoRa Gateway.

The latest release of the Chirpstack 3.x server results in my gateway displaying this error message when connecting using SBS. (Error message is from SBS itself)

“Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:45.188 [S2E:WARN] Received ‘dnmsg’ before ‘router_config’ - dropped”

(From the log snippet below)

MHdr=00 JoinEui=70b3:d57e:f000:390a DevEui=1234:aaaa:7890:bb55 DevNonce=32609 MIC=691823539
Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:44.934 [AIO:XDEB] [3|WS] > {“msgtype”:“jreq”,“MHdr”:0,“JoinEui”:“70-B3-D5-7E-F0-00-39-0A”,“DevEui”:“12-34-AA-AA-78-90-BB-55”,“DevNonce”:32609,“MIC”:691823539,“RefTime”:0.000000,“DR”:0,“Freq”:903500000,“upinfo”:{“rctx”:0,“xtime”:57420895471269764,“gpstime”:0,“fts”:-1,“rssi”:-46,“snr”:11.75,“rxtime”:1662646604.934659}}
Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:44.935 [AIO:XDEB] [3] socket write bytes=299
Sep 8 14:16:45 RG1xx29D9CE user.info event_mon[449]: Event: SDC_E_SCAN
Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:45.187 [AIO:XDEB] [3] socket read bytes=242
Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:45.188 [AIO:XDEB] [3|WS] < {“msgtype”:“dnmsg”,“DevEui”:“01-01-01-01-01-01-01-01”,“dC”:0,“diid”:58697,“pdu”:“202f7f28b9a2b634b28ce39f5fcc11a4cf”,“priority”:1,“RxDelay”:5,“RX1DR”:10,“RX1Freq”:926900000,“RX2DR”:8,“RX2Freq”:923300000,“xtime”:57420895471269764,“rctx”:0}
Sep 8 14:16:45 RG1xx29D9CE user.notice lora: 2022-09-08 14:16:45.188 [S2E:WARN] Received ‘dnmsg’ before ‘router_config’ - dropped
Sep 8 14:16:45 RG1xx29D9CE user.info php-cgi[3382]: lrd-sdk: LRD_WF_GetSSID():2991 returned SDCERR_FAIL

45

Let me start by saying I’m not sure who I should be bringing this report to (RAKWireless vs. here). I decided to start here because Chirpstack v4 docs indicate that the v3 gateway bridge should work with Chirpstack v4 in protobuf mode—Am I correct in understanding that backwards compatibility with protobuf formats is expected?

Our problem: We have many RAK7289 gateways running the WisGateOS. I don’t believe–but don’t know for sure–that WisGate uses chirpstack-gateway-bridge internally; however, one way or another they support both Chirpstack’s JSON and protobuf protocols. I have had much success with this gateway and Chirpstack v3.

When upgrading to Chirpstack v4 things have mostly worked. I see uplinks for other nearby devices and JoinRequests from my sensors. I see Chirpstack command a downlink over MQTT, but that is where things end. When the command is received by the gateway, it reports:

Fri Sep 23 15:47:48 2022 daemon.info gwBridge[12210]: Pb txinfo is NULL

Which isn’t that useful, but indicates the protobuf message was somehow not as expected. I did notice that the downlink protobuf definitions have had some changes in the code and there is now a “legacy” structure. I’m still trying to grok how that is involved, but I suspect it is part of the issue.

Does Chirpstack v4 somehow detect old versions of the protocol? Perhaps that check is not sufficient for RAK’s bridge? Should everything be backwards compatible and the bug on RAK’s side? Should this be reported on GitHub?

We are very excited about Chirpstack v4. The new UI is great and everything is very easy to deploy. Thank you for working on and gifting us this work!

46

@abalmos
Not 100% tested. But Chirpstack V4 requires that the MQTT topic starts with the region.

Chirpstack V3 event_topic_template="gateway/{{ .GatewayID }}/event/{{ .EventType }}"
Chirpstack V4 event_topic_template="eu868/gateway/{{ .GatewayID }}/event/{{ .EventType }}"

On the RAK gateway, In LoRaWAN Network Settings try to add the region to the MQTT Topi Template Setup

image
image1212×784 32.3 KB

e.g. if region is US915_1

V3 V4
gateway/{{eui}}/event/up us915_1/gateway/{{eui}}/event/up
gateway/{{eui}}/command/down us915_1/gateway/{{eui}}/command/down
gateway/{{eui}}/event/ack us915_1/gateway/{{eui}}/event/ack
gateway/{{eui}}/event/stats us915_1/gateway/{{eui}}/event/stats
47

Hi @beegee_1926

Thanks for the response, I do appreciate it!

Unfortunately, we already have the topics configured that way. Uplink (from sensors not part of this network) and gateway stats work fine. I’m not sure about ACKs because I can’t get anything to join without downlinks.

I am relatively confident that the gateway is receiving the downlink protobuf messages because the gateway log message

Fri Sep 23 15:47:48 2022 daemon.info gwBridge[12210]: Pb txinfo is NULL

has a 1-to-1 correspondence with Chirpstack sending a downlink command over MQTT. Also note that txinfo was part of that message.

Thanks!
Andrew

48

Only if you are running the latest ChirpStack Gateway Bridge v3. Have you confirmed this?

49

@brocaar Yikes. The protocol is in fact not backwards compatible. That is pretty unfortunate, because now to move to the new code base, every gateway in the network first needs to be updated.

Thanks for the quick response. I have asked RAK about supporting this here: Can't upgrade to Chirpstack v4 - Support new MQTT protocol - LPWAN Industrial Gateways / Concentrators - RAKwireless Forum

Andrew