chirpstack / chirpstack Goto Github PK

ChirpStack open-source LoRaWAN Network Server

License: MIT License

Shell 0.04% Dockerfile 0.02% Makefile 0.13% Rust 85.53% HTML 0.01% TypeScript 14.18% CSS 0.05% Nix 0.02% JavaScript 0.01%

lorawan lora iot chirpstack internet-of-things

chirpstack's Introduction

ChirpStack open-source LoRaWAN(R) Network Server

ChirpStack is an open-source LoRaWAN(R) Network Server which can be used to set up LoRaWAN networks. ChirpStack provides a web-interface for the management of gateways, devices and tenants as well to set up data integrations with the major cloud providers, databases and services commonly used for handling device data. ChirpStack provides a gRPC based API that can be used to integrate or extend ChirpStack.

Documentation and binaries

Please refer to the ChirpStack website for documentation and pre-compiled binaries.

Building from source

Requirements

Building ChirpStack requires:

Nix (recommended) and
Docker

Nix

Nix is used for setting up the development environment which is used for local development and for creating the binaries.

If you do not have Nix installed and do not wish to install it, then you can use the provided Docker Compose based Nix environment. To start this environment execute the following command:

make docker-devshell

Note: You will be able to run the test commands and run cargo build, but cross-compiling will not work within this environment (because it would try start Docker within Docker).

Docker

Docker is used by cross-rs for cross-compiling, as well as some of the make commands.

Starting the development shell

Run the following command to start the development shell:

nix-shell

Or if you do not have Nix installed, execute the following command:

make docker-devshell

Building the UI

To build the ChirpStack UI, execute the following command:

make build-ui

Running ChirpStack tests

Start required services

ChirpStack requires several services like PostgresQL, Redis, Mosquitto, ... to be running before you can run the tests. You need to start these services manually if you started the development shell using nix-shell:

docker compose up -d

Run tests

Run the following command to run the ChirpStack tests:

make test

Building ChirpStack binaries

Before compiling the binaries, you need to install some additional development tools (for cross-compiling, packaging, e.d.). Execute the following command:

make dev-dependencies

Run the following command within the ./chirpstack sub-folder:

# Build AMD64 debug build (optimized for build speed)
make debug-amd64

# Build AMD64 release build (optimized for performance and binary size)
make release-amd64

# Build all packages (all targets, .deb, .rpm and .tar.gz files)
make dist

License

ChirpStack Network Server is distributed under the MIT license. See also LICENSE.

chirpstack's People

Contributors

Stargazers

Watchers

Forkers

isgasho netmoregroup breezykermo nexusenvision ambuznego jmarcelino vicmgs mogaleaf max-keyn yunhorn 2dadsgn milbai johndyer24 hubenokdev inkwell-data mstenkaer dragonxu zukobronja grechjoseph cavenhe thingsixfoundation mfabiodias sbra tomsievers binbinskywalker matrixd2 alex9779 ldorigo mateusgx zeapo truongdk astridihub maxreb jinchuu1391 sandeeprajup timcooijmans protoxide22 godzilathakur rissw gougakos spindel metaphaz h-shimomichi dolfandringa sgnconnects xiaoran456 ornyilmaz chandrawi fuqingxin fraanx maxbyz gristlekinginc lak1357 gprpaes jthiller msiemens ederuiter steveqi vogsphe-re nerv55 geoid-org baothien1301 momobel london2103 crazyjay97 innovation-labs-technical-hub kelah wattsense michaeldjeffrey minhdinhtran shawaj andereyaa jwmonaco mogogomo thalesfsp yseun99 zjdyzww lakshmanachimata dwinurhadia allenliie deflateawning kevinyankai sp193 senaiapy senaiapys pululuk suyambuganesh82 xoseperez panandreas yusufstawan the-people-network-thailand tuxlinuxien radiofreeoklahoma kwrjoseph simonarnell euroiot kdima23 mrbluestsky kurtmc ccall48

chirpstack's Issues

Publishing grpc-web

Would you consider publishing grpc-web to npm? So that it can be used in other UIs to query the chirpstack server?

Implement Java code generation for Protobuf API

No code-generation for Java has been implemented yet. This can be ported from the github.com/brocaar/chirpstack-api repository.

Support WASM for Encode and Decode

Chirpstack support to use javascript for custom Encode and custom Decode .

WebAssembly is other choice for this case, user can use other language to write endcode and decode which they know well , Rust/Go/Javascript/.... , now i just create this issue to tracing this feature.

Maybe we can support it in the future.

No device region option for CN470 and corresponding config file

Implement GCP Cloud IoT Core GW <> NS backend

Unable to authenticate using mosquitto-go-auth due to format change of password_hash in user table

Hi all,
I'm testing chirpstack 4.0.0-rc.3.
And I'm doing mosquitto-go-auth at https://www.chirpstack.io/project/guides/mqtt-authentication. Yes, it works for ChirpStack Application Server v3.

In the v4, the auth_opt_hasher_iterations seems to change from 100000 to 10000.
And the table names are changed from organization to tenant and organization_user to tenant_user.
So I modified the mosquitto-go-auth as below.

auth_opt_hasher pbkdf2
auth_opt_hasher_salt_size 16           # salt bytes length
auth_opt_hasher_iterations 10000       # number of iterations
auth_opt_hasher_keylen 32              # key length
auth_opt_hasher_algorithm sha512       # hashing algorithm, either sha512 (default) or sha256
auth_opt_hasher_salt_encoding base64   # salt encoding, either base64 (default) or utf-8
...
auth_opt_pg_userquery select password_hash from "user" where email = $1 and is_active = true limit 1
auth_opt_pg_superquery select count(*) from "user" where email = $1 and is_admin = true
auth_opt_pg_aclquery select distinct 'application/' || a.id || '/#' from "user" u inner join tenant_user tu on tu.user_id = u.id inner join tenant t on t.id = tu.tenant_id inner join application a on a.tenant_id = t.id where u.email = $1 and $2 = $2

However, the format of password_hash in v4 is not compatible with mosquitto_go_auth any more.
The password_hash format in v3 works fine.

The password_hash format in v4 is not compatible with mosquitto_go_auth

Mosquitto-go-auth required the password_hash format to be like this PBKDF2$sha512$100000$2WQHK5rjNN+oOT+TZAsWAw==$TDf4Y6J+9BdnjucFQ0ZUWlTwzncTjOOeE00W4Qm8lfPQyPCZACCjgfdK353jdGFwJjAf6vPAYaba9+z4GWK7Gg==

After I manually update the v4 user with v3 password_hash, mosquitto-go-auth can anthenticate with user credentials in Postgres.

Is there any workaround to change the mosquitto-go-auth to fit v4?
Or we need to set the format of password_hash in v4 back to v3 to be compatible with mosquitto-go-auth?

Thanks a lot and have a nice day.

Unable to run the project after cloned. Using docker and their compose files

chirpstack_chirpstack-ui_1 exited with code 0
branch im on : master
steps to reproduce.

clone the repo
install docker and docker compose
run 'docker-compose build'
run 'docker-compose up'.

ignore the -d command so that you can see the error logs or console outputs.

Redis password configuration missing

I'm setting Chirpstack v4 in a cluster and unless i disable Redis authentication i'm unable to get Chirpstack pod running healthy. Disabling Auth in Redis fixes it.

Gateway activity is not consistent on the dashboard

In the dashboard, the donut chart marks the gateway as inactive 40 seconds after the last stat received. This is probably calculated to match the standard interval of 20 seconds.

On the other hand, markers on the map are marked as inactive after 5 minutes.

See example here:

It could be interesting to be able to configure the interval after which the gateway could be considered inactive, similar to devices, because the statistics interval can be configured by the user at the gateway level.

Having a common interval of 5 minutes might be a good start.

Feature to pass organization ID into MQTT topic

As discussed in this topic would it be possible to add organization ID into the topic to subscribe only to topics belonging to this organization.

May be something like that?

  # MQTT integration backend.
  [application_server.integration.mqtt]
  # Event topic template.
  event_topic_template="organization/{{ .OrganizationID }}/device/{{ .DevEUI }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="organization/{{ .OrganizationID }}/device/{{ .DevEUI }}/command/{{ .CommandType }}"

and of course still have application if needed

  # MQTT integration backend.
  [application_server.integration.mqtt]
  # Event topic template.
  event_topic_template="organization/{{ .OrganizationID }}/application/{{ .ApplicationID }}/device/{{ .DevEUI }}/event/{{ .EventType }}"

  # Command topic template.
  command_topic_template="organization/{{ .OrganizationID }}/application/{{ .ApplicationID }}/device/{{ .DevEUI }}/command/{{ .CommandType }}"

Anyway, another option could be to have tag or variable to application that will be pass into json, like that we could filter by tags other side, don't know which one is simpler to you.

Implement automatic formatting for JS / TSX source code

I think we should use prettier and eslint for JS / TSX code.

Support TimescaleDB / Primary key in Postgres integration

If you are not familiar, TimescaleDB is an extension for Postgres that improves performance for time series data through their "hypertable" structure. It seems like a good fit for event_* tables, particularly, event_up. It also offers query functions like time_bucket and continuously updated materialized views, which pair quite nicely with Grafana—my goal in this request.

Supporting TimescaleDB should, in theory, just require throwing

SELECT create_hypertable('event_up', 'time', migrate_data => true);

at the database.

The trouble is that deduplication_id is currently a primary key and, therefore, a unique index of event_* tables. Due to TimescaleDB's use of Postgres table partitioning, all partition columns must also be part of all unique indexes. In TimescaleDB the time column is always a partition column. As a result, event_* tables are not suitable to be converted to a TimescaleDB hypertable.

One solution is to drop the unique (primary key) requirement on the deduplication_id column. This seems to work fine, and from what I can tell does not affect Chirpstack. Does deduplication_id really need a UNIQUE index on it?

Another solution is to change the primary key to something like PRIMARY KEY (deduplication_id, time). Of course, that changes the semantics and likely isn't your goal here.

Would Chirpstack be willing to change the index on deduplication_id for the event_* tables to a plain, non-unique one? Perhaps this could be protected behind a TimescaleDB configuration option in the Postgres integration?

Packages for other Operating Systems

Hello ChirpStack project,

is it planned to provide further pre-built packages for further operating systems like CentOS or even FreeBSD, OpenBSD or NetBSD?
Currently only Ubuntu / Debian is available.

I would be interested in FreeBSD.

Events or the LoRaWAN frames tabs empty due to antivirus

When I open the "Events" or the "LoRaWAN frames" tab in the online interface, no data will be shown for the first 4 minutes.
The chrome inspector shows that for the post requests of StreamDeviceEvents and StreamGatewayFrames does not return anything for the first 4 minutes.

According to the console log

DEBUG gRPC{uri=/api.InternalService/StreamGatewayFrames}: chirpstack::api: Started processing request
Sep 26 23:58:12.893  INFO gRPC{uri=/api.InternalService/StreamGatewayFrames}: chirpstack::api: Finished processing request status="200" latency=12.940832ms

these endpoints should have returned something.

I know for sure that data is parsed and received, because I see messages on mqtt. Also the link metrics are updated.

Setup:

latest chirpstack using docker
udp-packet-forwarder as gateway (docker, rakwireless/udp-packet-forwarder:latest)

Thanks for the help

N.B. in the image, "Wachten" means "Wait/Delay"

Default Admin Password uses pbkdf2

I was trying to change the default admin:admin password from the terminal and found that you are using a very outdated pbkdf2 way to hash your passwords. I wrote a simple bash script to change the password from looking at the Go function used, this attempt failed. Is there an easier way to change the password via command line?

func hashWithSalt(password string, salt []byte, iterations int) string {
// Generate the hash. This should be a little painful, adjust ITERATIONS
// if it needs performance tweeking. Greatly depends on the hardware.
// NOTE: We store these details with the returned hash, so changes will not
// affect our ability to do password compares.
hash := pbkdf2.Key([]byte(password), salt, iterations, sha512.Size, sha512.New)

// Build up the parameters and hash into a single string so we can compare
// other string to the same hash.  Note that the hash algorithm is hard-
// coded here, as it is above.  Introducing alternate encodings must support
// old encodings as well, and build this string appropriately.
var buffer bytes.Buffer

buffer.WriteString("PBKDF2$")
buffer.WriteString("sha512$")
buffer.WriteString(strconv.Itoa(iterations))
buffer.WriteString("$")
buffer.WriteString(base64.StdEncoding.EncodeToString(salt))
buffer.WriteString("$")
buffer.WriteString(base64.StdEncoding.EncodeToString(hash))

return buffer.String()

Example Password as default: PBKDF2$sha512$100000$4u3hL8krvlMIS0KnCYXeMw==$G7c7tuUYq2zSJaUeruvNL/KF30d3TVDORVD56wzvJYmc3muWjoaozH8bHJ7r8zY8dW6Pts2bWyhFfkb/ubQZsA==
Reversed Engineer equation:
"PBKDF2$" + "sha512$" + "1000$" + "base64.salt" + "$" + "base64.hash"

Simple Bash Script:
algo="PBKDF2$"
hashed="sha512$"
int="1000$"
money="$"
ID=$(ec2metadata --instance-id)
hash=$(openssl passwd -6 "$ID")
salt=$(openssl passwd -6 "chirpstack")
b64hash=$(echo -n "$hash" | openssl enc -base64)
b64salt=$(echo -n "$salt" | openssl enc -base64)
pass="$algo$hashed$int$b64salt$money$b64hash"
sudo -u postgres psql -d chirpstack_as -c "UPDATE public."user" SET password_hash= '$pass' WHERE email='admin'"

I dont see anywhere , except npm and go where pbkdf2 is still being used? I more commonly see bcrypt, scrypt, mkpasswd , and openssl as ways to generate password hashes. Postgres rejects my solution , since It exceeds 200 characters. This would also not be able to be decrypted by the Go function that hashes it ands stores in postgres db chirpstack_as in the user table under admin .

References:
https://pkg.go.dev/golang.org/x/crypto/pbkdf2
https://forum.chirpstack.io/t/how-to-decode-the-user-password-from-the-database/4720

Incorrect default decodeUplink and encodeDownlink

The default function in Device-profile templates and Device-Profile should be modified to the below instead?
I tested the below and it works.

function decodeUplink(input) {
  return {
    data: {
      temp: 22.5
    }
  };
}

function encodeDownlink(input) {
  return {
    bytes: [225, 230, 255, 0]
  };
}

This is in the ChirpStack v4.

Thanks a lot and have a nice day.

Extrem long load times at live LoRaWAN frames

We are currently facing extreme long load times for the live LoRaWAN frames. It seems related to #44, but there was no fix provided.

Our current Setup:

All up-to-date Kubernetes deployment of Chirpstack
chirpstack/chirpstack:4.1
chirpstack/chirpstack-gateway-bridge:4.0
eclipse-mosquitto:2
redis:7-alpine

Additional Info:

on a Windows machine, we are receiving the live LoraWAN frames after 5 min++
on a Mac machine, the response will never be received

The logs are looking correctly for me

�[2m2023-01-09T08:47:00.899247Z�[0m �[34mDEBUG�[0m �[1mgRPC�[0m�[1m{�[0m�[3muri�[0m�[2m=�[0m/api.InternalService/StreamGatewayFrames�[1m}�[0m�[2m:�[0m �[2mchirpstack::api�[0m�[2m:�[0m Started processing request
�[2m2023-01-09T08:47:00.901267Z�[0m �[32m INFO�[0m �[1mgRPC�[0m�[1m{�[0m�[3muri�[0m�[2m=�[0m/api.InternalService/StreamGatewayFrames�[1m}�[0m�[2m:�[0m �[2mchirpstack::api�[0m�[2m:�[0m Finished processing request �[3mstatus�[0m�[2m=�[0m"200" �[3mlatency�[0m�[2m=�[0m2.031913ms
�[2m2023-01-09T08:47:00.901959Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253147620-0
�[2m2023-01-09T08:47:00.902059Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253160243-0
�[2m2023-01-09T08:47:00.902153Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902162Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253169651-0
�[2m2023-01-09T08:47:00.902170Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902197Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253169751-0
�[2m2023-01-09T08:47:00.902271Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902279Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253469744-0
�[2m2023-01-09T08:47:00.902298Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902310Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253587700-0
�[2m2023-01-09T08:47:00.902346Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902361Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253747605-0
�[2m2023-01-09T08:47:00.902369Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902426Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253750509-0
�[2m2023-01-09T08:47:00.902440Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902461Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253769630-0
�[2m2023-01-09T08:47:00.902467Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902491Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel
�[2m2023-01-09T08:47:00.902495Z�[0m �[35mTRACE�[0m �[2mchirpstack::framelog�[0m�[2m:�[0m Frame-log received from stream �[3mkey�[0m�[2m=�[0mup �[3mid�[0m�[2m=�[0m1673253769735-0
�[2m2023-01-09T08:47:00.902557Z�[0m �[35mTRACE�[0m �[2mchirpstack::api::internal�[0m�[2m:�[0m Message received from Redis Stream channel

If there is help or more information needed, please reach out to me.

LoRaWAN Relay TS011-1.0.0

Hi,

I would like to have LoRaWAN Relay capability in Chirpstack according to https://lora-alliance.org/lora-alliance-press-release/lora-alliance-announces-new-relay-feature-that-extends-lorawan-coverage-for-metering-utilities-smart-cities-and-industrial-applications/

The possibility to use Relay devices allows for cheaper network management.

List tenants for a user API

Currently, there is no way to query through the API for a list of tenants that a user is in. It would be helpful to provide this ability for UIs that will make use of the Chirpstack API to provide a different user experience. Presumably the changes to allow for this should be minimal.

Implement json support for gateways

At this moment, the gateway does not keep track of the encoding that the gateway uses to communicate with ChirpStack. In v3 it performs a check if the payload is binary Protobuf or JSON. The encoding is then stored per gateway to correctly encode the downlink commands.

Implement Azure IoT Hub GW <> NS backend

Tenant user rights

Platform: Chirpstack 4 on Docker, OpenSUSE 15.4.

When an unprivileged user logs in, Add gateway, Delete gateway, Delete device buttons are enabled. After clicking on any of these buttons, the user is logged out.

Wrong downlink bandwich in US915_0

Hi I'm using the chirpstack docker project [master branch. Deployed a few minutes ago from scratch]
Right now all upstream seems correct and I have no issues with uplinks data. But I have an issue with the downlink bandwidth.

I have configured a device profile like this

and also for ABP

and enabled only class C

I left region_us915_0.toml as the default one
Based on loraWAN parameters the downlink channel 0 should be in the frequency 923300000 and bandwidth 500K
but in practice, I face such issue

The chirpstack network server tries to push a downlink in 125K bandwidth which is wrong and my downlink lost.
I checked my gateway logs too. they are the same.

I really appreciate any help you can provide.

Integration output discards key from JSON object if value is 0 or null

Tested with MQTT intergation on application/+/device/+/event/up. When data: null, but also dr: 0 or fCnt: 0, the respective key is not present in the JSON object at all.

Device Metrics are not recorded when auto-detection is not activated

In v4, device metrics are not recorded and therefore do not appear on the dashboard of devices when “Automatically detect measurement keys” is disabled in the device profile, even when keys are created manually.
Reactivating this option after a short or long period of time make it work again.

Unable to get gateway certificate through UI

When clicking the 'Generate Certificate' button, get:

Error
Read gateway ca_cert

in the console:

{
    "code": 13,
    "message": "Read gateway ca_cert",
    "metadata": {
        "access-control-allow-credentials": "true",
        "access-control-allow-origin": "http://chirpstack.xxxx.com:8080",
        "access-control-expose-headers": "grpc-status,grpc-message",
        "alt-svc": "h3=\":443\"; ma=86400, h3-29=\":443\"; ma=86400",
        "cf-cache-status": "DYNAMIC",
        "cf-ray": "740fbf2ebeaba965-SYD",
        "connection": "keep-alive",
        "content-length": "0",
        "content-type": "application/grpc-web-text+proto",
        "date": "Fri, 26 Aug 2022 21:44:06 GMT",
        "grpc-message": "Read%20gateway%20ca_cert",
        "grpc-status": "13",
        "nel": "{\"success_fraction\":0,\"report_to\":\"cf-nel\",\"max_age\":604800}",
        "report-to": "{\"endpoints\":[{\"url\":\"https:\\/\\/a.nel.cloudflare.com\\/report\\/v3?s=taepJXzTrpDrX6Rt1ad2b32RgWGaDT4P1i4y30aluv%2FTCVcuXxOe4cCpZc1tMtgTI2emwv9eOsfguigiHDhdDEPK2qGmQHPHR4kF7rsnPYCLGlz5eYHUU%2Bw8CxrZrBOB2ij7W3f00IAiFiktRusqYA%3D%3D\"}],\"group\":\"cf-nel\",\"max_age\":604800}",
        "server": "cloudflare"
    }
}

Feature request: Pass vendor information from device-profile template

Hi,
I could need the vendor (and model) information of a device. The device-profile templates contain vendor information (and sometimes model information in the name).

Would it be possible to pass the vendor information from a device-profile template to the actual device profil?
Or do I just miss any API call to get this information for a device?

Another way I can think of to get vendor/model information into a device profile would be to enter it in description (e.g. as JSON). Is there a better way?

Do you accept PRs for the lorawan-devices-repository you forked from TTN?

Best Regards

Put back fCnt in ChirpStack v4

Hi ChirpStack team,
I remember in ChirpStack v3, we have fCnt in the Web GUI.
This is removed in ChirpStack v4. We have to click on the (+) to see the fCnt.
The fCnt is very useful to monitor if any packets are lost or if the device has been rebooted.

So I think it is useful to bring fCnt back in the above GUI.
Thanks a lot and have a nice day.

CayenneLPP Float Values Zero Decimal

Information from chirpstack with MQTT with .0 decimal. If the value has .0 shouldn't be changed to int?
Strange float values conversions

Current Setup:
chirpstack/chirpstack:4.1
chirpstack/chirpstack-gateway-bridge:4.0
eclipse-mosquitto:2
Device Profile: Class C LorawanV1.03 Codec Cayenne LPP

MQTT -> Chirpstack -> Arduino -> Chirpstack ->MQTT -> Server
Send Message (Arduino):
{ "digital_out_11": 1, "digital_out_12": 1, "digital_out_13": 0, "analog_out_1": 1, "gyrometer_11": { "x": 123, "y": 0, "z": 0 }, "gyrometer_12": { "x": 127, "y": 127, "z": 127 }, "gyrometer_13": { "x": 123.5, "y": 3, "z": 0 }, "gyrometer_14": { "x": 127, "y": 127, "z": 127 } }

Chirpstack:

Received MQTT:
{ "analogOutput": { "1": 1.0 }, "digitalOutput": { "12": 1.0, "11": 1.0, "13": 0.0 }, "gyrometer": { "13": { "y": 3.0, "z": 0.0, "x": 123.5 }, "11": { "x": 123.0, "y": 0.0, "z": 0.0 }, "12": { "z": 127.0, "x": 127.0, "y": 127.0 }, "14": { "y": 127.0, "z": 127.0, "x": 127.0 } } }

For Digital Outputs the values should be 0 or 1 not 0.0 or 1.0
For example Gyrometer 11 the number should be { "x": 123, "y": 0, "z": 0 } not { "x": 123.0, "y": 0.0, "z": 0.0 }
It’s normal de order xyz change to yzx or zxy

Server -> MQTT -> Chirpstack -> Arduino
Send Message:
{ "devEui": "a8610a3337306e0c", "confirmed": true, "fPort": 2, "object": { "analogOutput": { "1": 101, "31": 0, "103": 2.3, "104": 10.0 }, "digitalInput": { "31": 0, "103": 1, "104": 0, "110": 0, "112": 1 }, "digitalOutput": { "31": 1 }, "analogInput": { "109": 0, "105": 1.3 }, "gyrometer": { "104": { "x": 0.7, "y": 81.5, "z": 41.5 } } } }

Received:
{ "digital_in_31": 0, "digital_in_103": 1, "digital_in_104": 0, "digital_in_110": 0, "digital_in_112": 1, "digital_out_31": 1, "analog_in_105": 1.299999952, "analog_in_109": 0, "analog_out_1": 101, "analog_out_31": 0, "analog_out_103": 2.289999962, "analog_out_104": 10, "gyrometer_104": { "x": 0.699999988, "y": 81.5, "z": 41.5 } }

I send analogInput: "105": 1.3, and received "analog_in_105": 1.299999952,
I send analogOutput "103": 2.3 and received "analog_out_103": 2.289999962,
I send gyrometer": { "104": { "x": 0.7, and received "gyrometer_104": { "x": 0.699999988,

Another example with full message:

{
  "deduplicationId": "-",
  "time": "2023-01-09T18:19:38.662433378+00:00",
  "deviceInfo": {
    "tenantId": "-",
    "tenantName": "ChirpStack",
    "applicationId": "-",
    "applicationName": "Modulos_Rega",
    "deviceProfileId": "-",
    "deviceProfileName": "IOTDEVC",
    "deviceName": "Rega_06",
    "devEui": "-",
    "tags": {}
  },
  "devAddr": "-",
  "adr": true,
  "dr": 5,
  "fCnt": 16,
  "fPort": 2,
  "confirmed": true,
  "data": "AQMAZAsBAQwBAQ0BAAuGMAwAAAAADIYxnDGcMZwNhjA+ASwAAA6GMZwxnDGc",
  "object": {
    "gyrometer": {
      "14": { "y": 127.0, "z": 127.0, "x": 127.0 },
      "11": { "x": 123.0, "y": 0.0, "z": 0.0 },
      "12": { "x": 127.0, "z": 127.0, "y": 127.0 },
      "13": { "y": 3.0, "z": 0.0, "x": 123.5 }
    },
    "analogOutput": { "1": 1.0 },
    "digitalOutput": { "12": 1.0, "13": 0.0, "11": 1.0 }
  },
  "rxInfo": [
    {
      "gatewayId": "-",
      "uplinkId": 24309,
      "rssi": -75,
      "snr": 10.8,
      "channel": 3,
      "location": {},
      "context": "fw5lSw==",
      "metadata": { "region_name": "eu868", "region_common_name": "EU868" }
    }
  ],
  "txInfo": {
    "frequency": 867100000,
    "modulation": {
      "lora": {
        "bandwidth": 125000,
        "spreadingFactor": 7,
        "codeRate": "CR_4_5"
      }
    }
  }
}

API - ListDevicesRequest - List all devices without providing an application_id?

I would like to determine all devices operating within a ChirpStack instance regardless of tenant or application.

However, the ListDevicesRequest access pattern requires an application_id argument to be provided (Line 204 of
/chirpstack/src/api/device.rs).

To account for the application_id requirement, I am using a nested access approach where I (1) determine all tenants, (2) determine all applications per tenant, and (3) determine all devices per application.

Is there a better way to determine all devices operating within a ChirpStack instance?

Implement data migration utility for v3 -> v4 migration

Update GW <> NS api definitions

Cleanup duplicate fields. There is no need to define modulation and modulation_info for example, as the modulation can already be derived from modulation.
Change bandwidth kHz to Hz
Change code-rate from string to enum
Validate where float64 can be changed to float32 (e.g. altitude)
Validate how this can be implemented in a backwards compatible way such that ChirpStack can handle both v3 as v4 gateways

Dismatching device coderate

Dear @brocaar, I see in chirpstack v4 chirpstack/chirpstack/src/downlink/helpers.rs, here only chirpstack_api::gw::CodeRate::Cr45.into() is used for all devices despite their requested coderate:

pub fn set_tx_info_data_rate(
    tx_info: &mut chirpstack_api::gw::DownlinkTxInfo,
    dr: &DataRateModulation,
) -> Result<()> {
    match dr {
        DataRateModulation::Lora(v) => {
            tx_info.modulation = Some(gw::Modulation {
                parameters: Some(gw::modulation::Parameters::Lora(gw::LoraModulationInfo {
                    bandwidth: v.bandwidth,
                    spreading_factor: v.spreading_factor as u32,
                    code_rate: chirpstack_api::gw::CodeRate::Cr45.into(),
                    polarization_inversion: true,
                    code_rate_legacy: "".into(),
                })),
            });
        }
        DataRateModulation::Fsk(v) => {
            tx_info.modulation = Some(gw::Modulation {
                parameters: Some(gw::modulation::Parameters::Fsk(gw::FskModulationInfo {
                    datarate: v.bitrate,
                    frequency_deviation: v.bitrate / 2, // see: https://github.com/brocaar/chirpstack-gateway-bridge/issues/16
                })),
            });
        }
        DataRateModulation::LrFhss(_) => {
            return Err(anyhow!("LR-FHSS is not supported for downlink"));
        }
    }

    Ok(())
}

I believe that’s why I face this warning in my packet-forwarder:

chirpstack forum

and I believe that’s why I face infinite loop of Join Request from my device ISM2400.

P.S.: In my opinion this behaviour is wrong, since device may have different coderates - not only 4/5

Implement JS codec timeout

The current JS codec implementation does not enforce a max. runtime. For security reasons, it should be possible to configure a max. allowed execution time for JS codecs.

build dist failed

I did execute: make dist
but after of 8 hours the build failed.

Parse true/false as 1/0 on device metrics

There's quite a lot of codecs that exist in the TTN repository (pulling this in is lovely by the way, great work) that return true/false values.

It would be lovely if these could be graphed as 1/0 on the device metrics page that's new in v4 as it would be useful to track a binary state over time.

Questions: Some questions regarding downlinks and different device classes

Thanks for the good work with this awesome LoRa app server!

Is it possible to send downlinks with a common device profile supporting both class A and C devices?
I have a class A device, but I am unable to send downlinks to the device when using a device profile where "Device supports Class-C" is also checked. If I disable the Class C support on the profile it works. So is it required to always have a unique device profile per region and device class?
When sending downlinks to a class A device, it must send the data on the uplink port. Is this not handled by chirpstack? I would expect that I should be able to leave the FPort in the downlink unset and that chirpstack handles the port assignment automatically, but now it seems that I must wait for an uplink, then store that FPort, and then use that when I send downlinks, correct?

Unable to list ADR algorithms for device profile using gRPC

Hi,

I am trying to create a device profile programmatically using gRPC, since I need to list the available ADR algorithms in order to set the proper AdrAlgorithmId of the device profile to create.

I have generated the C# client classes from your proto files using your docker compose setup. I am successfully using many of the other clients and their gRPC methods, but this one below does not seem correct since it does not authenticate even though I pass in the authentication bearer token as for all other successful client calls.

Exception
Grpc.Core.RpcException: 'Status(StatusCode="Unauthenticated", Detail="")'

var headers = new Metadata
{
    { "Authorization", $"Bearer {apiKey}" }
};

var deviceProfileClient = new DeviceProfileServiceClient(channel);
var response = await deviceProfileClient.ListAdrAlgorithmsAsync(new Empty(), headers);

Store device-sessions in database to simplify backups and disaster-recovery

Currently device-sessions are only stored in redis. When the device-sessions are lost, devices have to re-join, something that is not automated on all devices. The result is that the redis 'database' should be considered persistent-data and should backed-up in addition to the PostgreSQL database.

It would be easier if the device-sessions would be backed up in the database so only a database-restore is needed as disaster-recovery.

Documentation of MQTT misses devEui field for v4 for downlink commands

https://www.chirpstack.io/application-server/integrations/mqtt/

The devEui field is missing in the documentation as it is required in the payload for downlink commands

MQTT Integration json events do not adhere to the protobuf definition

I am writing an mqtt integration in golang and as the integration event definitions (imported from github.com/chirpstack/chirpstack/api/go/v4/integration) do contain the necessary json:".." annotations I was hoping to be able to use something like this to decode an uplinkevent:

event := &integration.UplinkEvent{}
_ = json.Unmarshal(msg.Payload(), event)
fmt.Printf("Received: %+v\n", event)

This works for some fields, but for most fields (eg: DeviceInfo, RxInfo, TxInfo) this does not work as the data received mqtt does not seem to adhere to the json field names specified in the integration event definition.
For example see: https://github.com/chirpstack/chirpstack/blob/master/api/go/integration/integration.pb.go#L288 where the json field is defined as device_info but in the integration event it is sent as deviceInfo

This is the raw json we receive

 {"deduplicationId":"1caa3b80-9a09-4b8e-a244-9c4bef5f169c","time":"2023-02-11T11:59:27.902047+00:00","deviceInfo":{"tenantId":"52f14cd4-c6f1-4fbd-8f87-4025e1d49242","tenantName":"ChirpStack","applicationId":"00372e31-0620-4671-8270-237632a4e227","applicationName":"[281] TEST_GATEWAY","deviceProfileId":"1593e74b-6c04-4dcc-b280-6f9bf87c2bb2","deviceProfileName":"A84041DB2184D988","deviceName":"A84041DB2184D988","devEui":"a84041db2184d988","tags":{}},"devAddr":"00000001","adr":true,"dr":5,"fCnt":5,"fPort":2,"confirmed":true,"data":"BYIIAlgeoKU=","rxInfo":[{"gatewayId":"a84041ffff249aac","uplinkId":27545,"time":"2023-02-11T11:59:27.902047+00:00","rssi":-44,"snr":13.8,"channel":1,"rfChain":1,"location":{},"context":"0u4nEA==","metadata":{"region_config_id":"eu868","region_common_name":"EU868"},"crcStatus":"CRC_OK"}],"txInfo":{"frequency":868300000,"modulation":{"lora":{"bandwidth":125000,"spreadingFactor":7,"codeRate":"CR_4_5"}}}}

Unmarshalled with the code above it looks like this:

Received: &{state:{NoUnkeyedLiterals:{} DoNotCompare:[] DoNotCopy:[] atomicMessageInfo:<nil>} sizeCache:0 unknownFields:[] DeduplicationId: Time: DeviceInfo:<nil> DevAddr: Adr:true Dr:5 FCnt:0 FPort:0 Confirmed:true Data:[5 130 8 2 88 30 160 165] Object:<nil> RxInfo:[] TxInfo:<nil>}

Disclaimer: I don't know if this is supposed to be used this way (although the docs mention JSON based on the Protocol Buffers JSON mapping), if there is a better way of unmarshalling an integration event in go please let me know.

Expose through API/MQTT whether device is currently in Class A or Class B

Application may need to know if device is operating in class A or it has upgraded to class B. It would be good if the classB flag would be exposed through MQTT event and in API device service.

Application details and device details page are very slow

The page application page (/#/tenants/{tenantId}/applications/{applicationId}) and device page (/#/tenants/{tenantId}/applications/{applicationId}/devices/{deviceId) ) are really slow (more than 30 seconds to load).

For information, we have 700+ devices in one application.

I looked into the http requests of the page, I think the problem may be that the request POST /api.ApplicationService/Get is returning too much data at once. (It returns 8.55 MB in my browser)

Provide way to limit DevAddr allocation within NetID

Currently ChirpStack will assign a random DevAddr from the entire allowable range of a NetID.
If an operator wanted to limit the range of DevAddrs assigned to devices within their instance, they would not be able to do so.

Adding a configuration setting for DevAddr assignments could look something like

[network]
  net_id = "000001"
  devaddr_range = ["02000000", "020000AA"]

This allows for a few different scenarios.

Standing up a test instance of ChirpStack with your own NetID and keeping test devices from bleeding into Production DevAddr space.
Multiple operators sharing a NetID without overlapping.
Could be used to more quickly deny traffic not meant for the Instance.

There could be a more robust DevAddr allocation scheme that would allow for other scenarios like:

Migrating devices across ChirpStack instances that share a NetID.
Partitioning DevAddrs within Applications in an Instance.

But that is potentially overcomplicating the ask here.

chirpstack V4: Only EU868 is selectable in Device Profile -> Region configuration

using latest version, setting up device profile, in region configuration only EU868 is available, even when chosing another region.

i always get the handle uplink error using v4

all the things works fine after docker restart, but after running a while, maybe 2 or 3 hours, maybe a whole day, i will get the same error in logs.
i have stuck in this error for a week, can u give me some suggestions?

Sep 09 04:27:49.477 DEBUG gRPC{uri=/api.InternalService/StreamDeviceEvents}: chirpstack::api: Started processing request
Sep 09 04:27:49.478 DEBUG gRPC{uri=/api.InternalService/StreamDeviceEvents}: chirpstack::api: Started processing request
Sep 09 04:27:49.479  INFO gRPC{uri=/api.InternalService/StreamDeviceEvents}: chirpstack::api: Finished processing request status="200" latency=1.745125ms
Sep 09 04:27:49.480  INFO gRPC{uri=/api.InternalService/StreamDeviceEvents}: chirpstack::api: Finished processing request status="200" latency=1.96641ms
Sep 09 04:27:49.936 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:49.936 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:49.938 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:49.938 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:50.079 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:50.079 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:50.080 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:50.080 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:50.512 ERROR chirpstack::uplink: Deduplication error error=timed out waiting for connection
Sep 09 04:27:50.513 ERROR chirpstack::uplink: Deduplication error error=timed out waiting for connection
Sep 09 04:27:50.513 ERROR chirpstack::uplink: Deduplication error error=timed out waiting for connection
Sep 09 04:27:50.513 ERROR chirpstack::uplink: Deduplication error error=timed out waiting for connection
Sep 09 04:27:50.513 ERROR chirpstack::uplink: Deduplication error error=log_uplink_for_gateways error
Sep 09 04:27:50.513 ERROR up{deduplication_id=4e8a7e30-e713-4b78-92f7-fe2f7d268d20}: chirpstack::uplink::data: Handle uplink error error=Get device-session
Sep 09 04:27:50.513 ERROR chirpstack::uplink: Deduplication error error=log_uplink_for_gateways error
Sep 09 04:27:50.513 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.514 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.514 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.514 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.514 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.514 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.515 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.515 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.515 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.515 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.515 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.516 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.515 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.516 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.516 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.516 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.516 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.516 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.517 ERROR chirpstack::uplink: Deduplication error error=Zero items in collect set
Sep 09 04:27:50.517  INFO chirpstack::gateway::backend::mqtt: Message received from gateway region_name="as923" topic="as923/gateway/ac1f09fffe015ed3/event/up" qos=0 json=false
Sep 09 04:27:50.517 TRACE chirpstack::uplink: Adding uplink event to deduplication set key="up:collect:08c0eea7b803120a1a0808c8d00710072801:805350200080b3160a7d8855fc52a222"
Sep 09 04:27:50.517 TRACE chirpstack::eventlog: Event-log received from stream key=status id=1662690659222-0
Sep 09 04:27:50.517 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662690659229-0
Sep 09 04:27:50.517 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.518 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662690662929-0
Sep 09 04:27:50.518 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.518 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662690666934-0
Sep 09 04:27:50.518 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.518 TRACE chirpstack::eventlog: Event-log received from stream key=join id=1662691825952-0
Sep 09 04:27:50.518 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662691831858-0
Sep 09 04:27:50.518 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.518 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.519 TRACE chirpstack::eventlog: Event-log received from stream key=status id=1662691835757-0
Sep 09 04:27:50.519 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.519 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662691835764-0
Sep 09 04:27:50.519 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.519 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662691839474-0
Sep 09 04:27:50.519 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.519 TRACE chirpstack::eventlog: Event-log received from stream key=up id=1662691843468-0
Sep 09 04:27:50.519 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.519 TRACE chirpstack::api::internal: Message received from Redis Stream channel
Sep 09 04:27:50.939 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:50.939 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:50.941 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:50.941 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:51.082 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:51.082 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:51.083 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:51.083 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:51.941 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:51.941 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:51.943 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:51.943 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:52.084 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:52.084 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:52.085 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:52.085 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:52.944 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:52.944 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:52.946 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:52.946 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:53.086 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:53.086 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:53.087 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:53.088 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:53.947 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:53.947 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:53.949 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:53.949 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:54.089 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:54.089 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:54.090 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:54.090 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:54.951 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:54.951 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:54.953 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:54.953 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:55.091 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:55.091 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:55.092 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:55.092 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:55.954 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:55.955 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:55.956 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:55.956 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:56.094 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:56.094 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:56.095 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:56.095 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:56.958 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:56.958 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:56.960 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:56.960 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:57.097 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:57.097 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:57.098 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:57.098 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:57.960 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:57.960 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:57.962 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:57.962 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:58.100 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:58.100 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:58.101 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:58.101 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:58.964 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:58.964 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:58.966 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:58.966 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:27:59.103 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:27:59.103 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:27:59.104 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:27:59.104 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:27:59.966 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:27:59.966 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:27:59.968 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:27:59.968 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:00.105 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:00.105 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:00.106 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:00.106 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:00.969 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:00.969 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:00.971 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:00.971 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:01.107 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:01.107 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:01.109 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:01.109 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:01.972 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:01.972 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:01.974 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:01.974 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:02.109 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:02.110 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:02.111 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:02.111 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:02.975 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:02.975 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:02.977 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:02.977 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:03.111 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:03.112 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:03.113 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:03.113 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:03.979 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:03.979 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:03.981 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:03.981 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:04.115 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:04.115 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:04.116 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:04.116 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:04.981 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:04.981 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:04.983 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:04.983 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:05.117 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:05.117 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:05.119 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:05.119 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:05.984 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:05.984 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:05.986 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:05.986 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:06.120 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:06.120 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:06.121 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:06.121 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:06.988 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:06.988 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:06.990 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:06.990 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:07.122 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:07.122 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:07.123 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:07.123 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:07.990 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:07.990 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:07.993 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:07.993 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:08.125 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:08.125 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:08.126 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:08.126 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:08.993 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:08.993 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:08.995 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:08.995 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:09.127 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:09.127 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:09.129 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:09.129 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:09.996 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:09.996 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:09.998 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:09.998 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:10.129 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:10.129 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:10.131 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:10.131 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:10.999 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:10.999 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:11.001 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:11.001 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:11.131 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:11.132 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:11.133 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:11.133 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:12.002 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:12.002 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:12.004 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:12.004 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:12.134 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:12.134 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:12.135 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:12.136 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:13.005 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:13.005 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:13.007 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:13.007 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:13.137 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:13.137 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:13.138 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:13.138 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:14.008 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:14.008 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:14.010 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:14.010 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:14.140 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:14.140 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:14.141 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:14.141 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:15.012 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:15.012 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:15.014 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:15.014 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:15.142 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:15.142 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:15.143 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:15.143 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:16.015 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:16.015 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:16.021 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:16.021 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:16.145 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:16.145 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:16.147 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:16.147 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:17.021 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:17.021 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:17.023 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:17.023 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:17.148 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:17.148 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:17.150 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:17.150 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:18.024 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:18.024 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:18.026 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:18.026 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:18.151 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:18.151 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:18.152 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:18.152 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:19.028 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:19.028 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:19.030 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:19.030 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:19.153 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:19.153 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:19.154 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:19.154 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:19.480 ERROR chirpstack::api::internal: Reading event-log returned error: timed out waiting for connection
Sep 09 04:28:19.480 TRACE chirpstack::api::internal: DropReceiver drop method called
Sep 09 04:28:20.030 TRACE chirpstack::downlink::scheduler: Starting class_b_c_scheduler_loop run
Sep 09 04:28:20.030 TRACE chirpstack::downlink::scheduler: Getting devices that have schedulable queue-items
Sep 09 04:28:20.032 TRACE chirpstack::downlink::scheduler: Got this number of devices with schedulable queue-items device_count=0
Sep 09 04:28:20.032 TRACE chirpstack::downlink::scheduler: class_b_c_scheduler_loop completed successfully
Sep 09 04:28:20.156 TRACE chirpstack::downlink::scheduler: Starting multicast-group queue scheduler loop run
Sep 09 04:28:20.156 TRACE chirpstack::downlink::scheduler: Getting schedulable multicast-group queue items
Sep 09 04:28:20.157 TRACE chirpstack::downlink::scheduler: Got this number of multicast-group queue items count=0
Sep 09 04:28:20.157 TRACE chirpstack::downlink::scheduler: Multicast-group queue scheduler run completed successfully
Sep 09 04:28:20.520 ERROR chirpstack::uplink: Deduplication error error=timed out waiting for connection
Sep 09 04:28:20.520 ERROR chirpstack::gateway::backend::mqtt: Processing gateway event error: timed out waiting for connection topic="as923/gateway/ac1f09fffe015ed3/event/up" qos=0

my docker-compose.yml

version: "3"

services:
  chirpstack:
    image: chirpstack/chirpstack:4.0.0-rc.4
    command: -c /etc/chirpstack
    restart: unless-stopped
    volumes:
      - ./configuration/chirpstack:/etc/chirpstack
      - ./lorawan-devices:/opt/lorawan-devices
    depends_on:
      - postgres
      - mosquitto
      - redis
    ports:
      - 8080:8080

  chirpstack-gateway-bridge-as923:
    image: chirpstack/chirpstack-gateway-bridge:4.0.0-rc.2
    ports:
      - 1700:1700/udp
    volumes:
      - ./configuration/chirpstack-gateway-bridge:/etc/chirpstack-gateway-bridge
    depends_on: 
      - mosquitto

  chirpstack-rest-api:
    image: chirpstack/chirpstack-rest-api:4.0.0-rc.1
    command: --server chirpstack:8080 --bind 0.0.0.0:8090 --insecure
    ports:
      - 8090:8090
    depends_on:
      - chirpstack

  postgres:
    image: postgres:9.6-alpine
    volumes:
      - ./configuration/postgresql/initdb:/docker-entrypoint-initdb.d
      - postgresqldata:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=root

  redis:
    image: redis:5-alpine
    volumes:
      - redisdata:/data

  mosquitto:
    image: eclipse-mosquitto:2
    ports:
      - 1883:1883
    volumes: 
      - ./configuration/mosquitto/mosquitto.conf:/mosquitto/config/mosquitto.conf
      - ./configuration/mosquitto/acl:/mosquitto/acl
      - ./configuration/mosquitto/passwd:/mosquitto/passwd

volumes:
  postgresqldata:
  redisdata:

ChirpStack UI does not display version

I didn't see anywhere in the UI the current ChirpStack running version.

Am I blind ?

It could be displayed after the ChirpStack Logo (in the header.ant-layout-header.layout-header).

Device Queue doesn't happen when Application Integration fails

I, for example, have a HTTP integration running in my Application and if the sending of the Uplink data fails for whatever reason the Queue is not dealt with.

After removing the HTTP integration and resending a uplink, the Queue was processed and is now empty.

Gateway not connecting to chirpstack

Bit confused here, I have this config for my gateway on a raspberry pi (using v4 chirpstack os):

# This configuration provides a Semtech UDP packet-forwarder backend and
# integrates with a MQTT broker. Many options and defaults have been omitted
# for simplicity.
#
# See https://www.chirpstack.io/gateway-bridge/install/config/ for a full
# configuration example and documentation.


[general]
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level=4

# Log to syslog.
#
# When set to true, log messages are being written to syslog.
log_to_syslog=true


# Gateway backend configuration.
[backend]
# Backend type.
type="concentratord"

# ChirpStack Concentratord backend.
[backend.concentratord]

# Check for CRC OK.
crc_check=true

# Event API URL.
event_url="ipc:///tmp/concentratord_event"

# Command API URL.
command_url="ipc:///tmp/concentratord_command"


[integration]
marshaler="protobuf"

[integration.mqtt]

event_topic_template="au915_0/gateway/{{ .GatewayID }}/event/{{ .EventType }}"

state_topic_template="au915_0/gateway/{{ .GatewayID }}/state/{{ .StateType }}"

command_topic_template="au915_0/gateway/{{ .GatewayID }}/command/#"

[integration.mqtt.auth]
type="generic"

[integration.mqtt.auth.generic]
# server="ssl://mqtt-alpha.joelhowse.com:8883"
servers=[
	"tcp://mqtt-alpha.joelhowse.com:1883"
]

And then have another server where I'm running the mosquitto broker and chirpstack service, I did initially try set up TLS but decided I need to get it running first, and then add that after if I need.

On my server, the chirpstack service has the config:

 Logging.
[logging]

  # Log level.
  #
  # Options are: trace, debug, info, warn error.
  level="info"


# PostgreSQL configuration.
[postgresql]

  # PostgreSQL DSN.
  #
  # Format example: postgres://<USERNAME>:<PASSWORD>@<HOSTNAME>/<DATABASE>?sslmode=<SSLMODE>.
  #
  # SSL mode options:
  #  * disable - no SSL
  #  * require - Always SSL (skip verification)
  #  * verify-ca - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)
  #  * verify-full - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)
  dsn="postgres://chirpstack:chirpstack@localhost/chirpstack?sslmode=disable"

  # Max open connections.
  #
  # This sets the max. number of open connections that are allowed in the
  # PostgreSQL connection pool.
  max_open_connections=10

  # Min idle connections.
  #
  # This sets the min. number of idle connections in the PostgreSQL connection
  # pool (0 = equal to max_open_connections).
  min_idle_connections=0


# Redis configuration.
[redis]

  # Server address or addresses.
  #
  # Set multiple addresses when connecting to a cluster.
  servers=[
    "redis://localhost/",
  ]

  # TLS enabled.
  tls_enabled=false

  # Redis Cluster.
  #
  # Set this to true when the provided URLs are pointing to a Redis Cluster
  # instance.
  cluster=false


# Network related configuration.
[network]

  # Network identifier (NetID, 3 bytes) encoded as HEX (e.g. 010203).
  net_id="000000"

  # Enabled regions.
  #
  # Multiple regions can be enabled simultaneously. Each region must match
  # the 'name' parameter of the region configuration in '[[regions]]'.
  enabled_regions=[
    "au915_0",
  ]


# API interface configuration.
[api]

  # interface:port to bind the API interface to.
  bind="0.0.0.0:8080"

  # Secret.
  #
  # This secret is used for generating login and API tokens, make sure this
  # is never exposed. Changing this secret will invalidate all login and API
  # tokens. The following command can be used to generate a random secret:
  #   openssl rand -base64 32
  secret="__probably shouldn't show this__"

where everything there seems to be working well. I've removed all other configuration files except region_au915_0.toml which looks like:

# This file contains an example AU915 example (channels 0-7 + 64).
[[regions]]

  # Name is an use-defined identifier for this region.
  name="au915_0"

  # Common-name refers to the common-name of this region as defined by
  # the LoRa Alliance.
  common_name="AU915"

  # Gateway configuration.
  [regions.gateway]

    # Force gateways as private.
    #
    # If enabled, gateways can only be used by devices under the same tenant.
    force_gws_private=false


    # Gateway backend configuration.
    [regions.gateway.backend]

      # The enabled backend type.
      enabled="mqtt"


      # MQTT configuration.
      [regions.gateway.backend.mqtt]

        # Event topic template.
        event_topic="au915_0/gateway/+/event/+"

        # Command topic template.
        command_topic="au915_0/gateway/{{ gateway_id }}/command/{{ command }}"

        # MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
        # server="tcp://localhost:1883"
	server="tcp://mqtt-alpha.joelhowse.com:1883"

	qos=0

(The mosquitto broker is running on the same machine so it should be able to connect locally but just using the same hostname for completeness).

My gateway currently doesn't have any devices connected (that's a problem for another day) but I can't seem to get the chirpstack server to recognise the gateway.

In the mosquitto logs you can see the gateway is successfully communicating with the broker because I see:

au915_0/gateway/e45f01fffe571757/state/conn e45f01fffe571757
au915_0/gateway/e45f01fffe571757/event/stats 
                                            ????Ǟ(R
modelrak_2245_au915R
config_versionR

hal_versionVersion: 5.0.1;R#
concentratord_version
4.0.0-rc.1?e45f01fffe571757
au915_0/gateway/e45f01fffe571757/event/stats 
                                            ???ː?(R
modelrak_2245_au915R
config_versionR

hal_versionVersion: 5.0.1;R#
concentratord_version
4.0.0-rc.1?e45f01fffe571757
au915_0/gateway/e45f01fffe571757/event/stats 
                                            ̩????(R
modelrak_2245_au915R
config_versionR

hal_versionVersion: 5.0.1;R#
concentratord_version
4.0.0-rc.1?e45f01fffe571757
au915_0/gateway/e45f01fffe571757/event/stats

So it's clearly sending through the stats events. In the UI, when I add the gateway with the same ID I would expect to see the 'Last Seen' field set, but it just says never. I can't for the life of me figure out where the communication is failing??

Any ideas?? What could I be doing wrong. Trying to keep things as simple as possible

[easy] Http Integration multiple URLs separator mistake

For integration (streaming events) via HTTP multiple urls could be specified.

In the code they are split with whitespace:

https://github.com/chirpstack/chirpstack/blob/master/chirpstack/src/integration/http.rs#L22

But the hint in the UI for this input field insists it should be comma!

https://github.com/chirpstack/chirpstack/blob/master/ui/src/views/applications/integrations/HttpIntegrationForm.tsx#L46

I would gladly create PR myself but I don't know which way you prefer it to be fixed - either change the code to use comma (slight probability to break some running installation) - or to change the tooltip. I guess the code fix is better as it doesn't make good logic with further whitespace removal.