I’m having that error on join-request, or uplinks.
I have tried with different gateways.
It is the log:
2023-12-15T12:31:28.308394Z INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_id=“eu868_2” topic=“eu868/gateway/24e124fffef038f4/event/up” qos=0 json=false
2023-12-15T12:31:28.510290Z INFO up{deduplication_id=53d4c5f9-0e0f-4616-aff9-6e85f82d1604}: chirpstack::uplink: Uplink received m_type=JoinRequest
2023-12-15T12:31:28.513329Z ERROR up{deduplication_id=53d4c5f9-0e0f-4616-aff9-6e85f82d1604}: chirpstack::uplink::join: Handle join-request error error=rx_info_set is empty
Adding some info (next error belongs to another error frame, but error is the same) I have configured the application region as eu868_3 to disable adr when we force the join request. The server shows reception of JoinRequest at same time that error appears on log. The frame contains RXInfo, but region is configured as eu868_2. JoinAccept is not send.
After some attempts, the region of the RXInfo is eu868_3 and device can be joined.
Gateways with devices that are configured on eu868, appears with metadata eu868_2, or eu868_3.
It seems if uplink messages sets randomly as different configurations of the same region.
Thank you.
# This file contains an example EU868 configuration.
[[regions]]
# ID is an user-defined identifier for this region.
id="eu868"
# Description is a short description for this region.
description="EU868"
# Common-name refers to the common-name of this region as defined by
# the LoRa Alliance.
common_name="EU868"
...
# Topic prefix.
#
# The topic prefix can be used to define the region of the gateway.
# Note, there is no need to add a trailing '/' to the prefix. The trailing
# '/' is automatically added to the prefix if it is configured.
topic_prefix="eu868"
region_eu868_2.toml
# This file contains an example EU868 configuration.
[[regions]]
# ID is an user-defined identifier for this region.
id="eu868_2"
# Description is a short description for this region.
description="EU868_LOW_DR"
# Common-name refers to the common-name of this region as defined by
# the LoRa Alliance.
common_name="EU868"
...
# Topic prefix.
#
# The topic prefix can be used to define the region of the gateway.
# Note, there is no need to add a trailing '/' to the prefix. The trailing
# '/' is automatically added to the prefix if it is configured.
topic_prefix="eu868_2"
region_eu868_3.toml:
# This file contains an example EU868 configuration.
[[regions]]
# ID is an user-defined identifier for this region.
id="eu868_3"
# Description is a short description for this region.
description="EU868_NO_ADR"
# Common-name refers to the common-name of this region as defined by
# the LoRa Alliance.
common_name="EU868"
...
# Topic prefix.
#
# The topic prefix can be used to define the region of the gateway.
# Note, there is no need to add a trailing '/' to the prefix. The trailing
# '/' is automatically added to the prefix if it is configured.
topic_prefix="eu868_3"
How many gateways are you using concurrently? Perhaps I’ve missed something, but if you get messages on the topic for “eu868” topic, it means that the uplink message came from the Gateway Bridge that is associated with the “eu868” topic (not “eu868_2” nor “eu868_3”). A gateway can only be pointed to 1 gateway bridge at any time and a gateway bridge can only support a single channel plan.
If you are using multiple LoRa gateways, please note that LoRa nodes always communicate in a broadcast fashion; any gateway in range is supposed to be able to receive a copy of the message. So as long as it is listening on the correct channel.
EU868 defines 3x fixed channels, which are 868.1, 868.3 and 868.5MHz, so I am surprised that you’re not getting JOIN REQUEST on all the topics.
Hi sp193:
It seems that I have missunderstood how chirpstack works.
What I wanted to do is having some devices with a plan NO_ADR, and other devices with CUSTOM_ADR, them both belong to EU868.
I don’t mind if I can use only one gateway, or two gateways, but I’m going to have to study how to do it.
However, I have been trying to config eu868_3 topic on chirpstack_gateway_bridge.toml (only for test), but it still sending to eu868. Solved: chirpstack.yml was overwritting topic variable
I would like to ask you a two question:
Can be two or more chirpstack_gateway_bridge configurations living together? - Must I configure the gateway to send topic to eu868_3 instead eu868?
If you intend to have one gateway bridge using multiple configurations, no. It’s intended for you to have one configuration per gateway bridge. For this reason, we need one gateway bridge instance for every possible permutation of channel plan and gateway backhaul protocol.
For example, you want to use GWMP (the UDP packet forwarder’s protocol) and BasicStation, and also have 8-channel and 16-channel EU868 plans. This means 4x gateway bridges.
By the way, I didn’t know that you can disable ADR via the gateway bridges. Is there really no way to just use one variant of EU868?
I’m not sure if you are aware, but it is optionally possible for devices to have ADR disabled. So disabling it from the LNS is not the only way.
Hi sp193:
Our scenary is:
We have to join several devices on our office. The devices are very close to the gateway, so, if we enable ADR, they falls down to S.F. 7
The joined devices go to installation place. If they have been configured with S.F. 7, a lot of them will have problems to reach the installation gateway until they become higher Spread Factor.
What I want to do is having two plan EU868 and EU868_NO_ADR and configure new devices on EU868_NO_ADR while they are joined until they are finally installed. Once they are on the final installation, change plain to EU868 (whit ADR), and let the installation gateway possition to handle the best S.F. and Power choice.
At the first of the post I thought that including two plains on chirpstack_gateway_chirpstack_1 was enough. But they must be on different mqtt topics, and, it seems there must be two gateway bridges co-living. This is my next step.
In this type of scenario, I’ve had good experiences running separate network servers for installation/configuration and production, and then move the devices from one to the other for deployment. Letting devices rejoin naturally in the field ensures that they will work correctly if/when they lose power or otherwise need to join in the future. It’s also a bit easier to conceptualize.
Hello, Bconway:
Yesterday I launched two bridges:
< 1701 UDP -------- Topic: eu868_no_adr >
< 1700 UDP -------- Topic: eu868 >
And I could reach the solution I was looking for.
As you say, I think that separated networks is a good practice too.
I want to have all devices on the production server Database, but bridge with no_adr can be deployed on installation server and configure it to send frames to the Production mqtt broker.
Finally, solution was:
Configure several plan for same region EU868. They must have different topic.
Include all plans on chirpstack-server configuration.
Configure different gateway-bridges. Each of them have its own UDP port and topic corresponding with plan configured in the first point.
I had to disable environment variables configuration on the chirpstack.toml file (it is running on docker)
