You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the client ID is not an EUI64, a warning is printed.
If the client ID is an EUI64, it's used as the gateway ID
This only covers the very specific use case where the gateway ID has to be taken from the client ID. If we just want the client ID to be set, we either have the gateway ID overridden or a warning printed. This behavior should be documented.
My suggestion is to add an option. Either a use_client_id_as_gateway_id=boolean in the mqtt section or a gateway_id_source=string (backend/mqtt_client_id) in the integration section. This way a fatal error can be generated if the target configuration is inconsistent.
The text was updated successfully, but these errors were encountered:
The use-case for this is the last will and testament feature, as in this case we must know the gateway id before connecting to the MQTT broker (as the LWT is a connection parameter).
I would like to avoid adding more config options for the sake of complexity, but I agree that this could be documented better.
Actually, if we set client_id in the MQTT auth, the CSGB will try to use it as the gateway ID:
chirpstack-gateway-bridge/internal/integration/mqtt/backend.go
Line 150 in a20e0ac
This only covers the very specific use case where the gateway ID has to be taken from the client ID. If we just want the client ID to be set, we either have the gateway ID overridden or a warning printed. This behavior should be documented.
My suggestion is to add an option. Either a
use_client_id_as_gateway_id=boolean
in the mqtt section or agateway_id_source=string (backend/mqtt_client_id)
in the integration section. This way a fatal error can be generated if the target configuration is inconsistent.The text was updated successfully, but these errors were encountered: