[release] ChirpStack Application Server v3.12

ChirpStack Application Server v3.12.0


LoRa Cloud DAS GNSS resolving

This implements the handling of LoRa Cloud Device & Application Services GNSS payload on pre-configured port (default 198).


Implement global and per organization dashboard of active devices and gateways. Please note that for devices, you must configure the expected uplink interval in the device-profile so that ChirpStack knows the difference between an active and inactive devices.


  • Add WebSocket ping (30s interval) to avoid that load-balancers close the connection after inactivity.
  • Add Prometheus metrics for MQTT integration.
  • Make it possible for organization admins to update the name of the organization.
  • Add logout_url configuration option for OpenID Connect authentication.


  • Fix create FUOTA deployment and network-server with empty name. (#511)
  • Fix ‘can’t evaluate field TLS in type struct’ error for configfile command. (#518)
  • Fix /api/network-servers error when using API key. (#488)
  • Fix /api/gateway-profiles error when using API key. (#525)

Neat dashboard! It doesn’t seem to be taking into account active gateways fully, though. Since gateways are now required to be registered to forward traffic (as of last release, maybe?), the following shouldn’t be possible, I think:

Screen Shot 2020-08-26 at 10.56.37 AM

Sure enough, the gateway is active, though:

Screen Shot 2020-08-26 at 10.57.01 AM

This is with the default 1-day expected interval.

agreed with you.
active/inactive status flapping out
and still inactive until it gets the next status update
this causes some confusion

Would it help if I make the expected stats interval configurable like I have done with the devices? Currently I’m assuming the default packet-forwarder interval of 30 seconds (+ some margin).


yes i think this will be the solution

Which default packet forwarder interval is that, stats you mean? If so, we set that for much longer. But yeah, configurable would work well.

Correct, the last seen is based on the stats and the active / inactive is based on the last seen. The reason for using the stats and not every uplink is that the latter one could generate a lot more queries when the gateway receives uplinks for many devices where the stats has a predictable interval.

After version update, the number of network servers has tripled. It turned out three each.

Thanks for reporting. There was one API cleanup related to the network-server listing. I think I have missed one distinct in the SQL query. Will fix this asap.

1 Like

This fixes the issue:

It was because of the left join (which can match multiple times for the same network-server record).

1 Like

ChirpStack Application Server v3.12.1


  • Fix duplicated network-server entries in API and web-interface.
  • Fix auto-complete select placeholder. (#526)

I have just implemented this. Will be included in the next version :slight_smile: Thanks for the feedback!

1 Like

There seems to be an issue with websockets in this release, I get a lot of
“[write] error writing websocket message: write tcp> i/o timeout”
messages in the log, and the feed seems to miss LoRa packets.


I am also facing same problem


I have a debugged WebSocket issue and it’s caused due to the below commit.

I have tested chirpstack-application-server without WebSocketProxy with a 30s interval and it’s working fine.


Thanks for testing. I’ll roll back the change in the next release until I have found a better approach for the ping / pong.

1 Like

Dashboards looks nice! One thing tho - how is the DR taken into account? I can see one device with DR7 on my test server.

AFAIK there were two devices operating on DR7 - one of them is currently on DR5 and other one is inactive for about 8 months.

Wouldn’t it be better (if possible) to tie it with device activity? Or set some other interval for which the DR stats would be shown?


Maybe that is a good point. Currently each device record has a dr field which stores the last used dr. The dashboard aggregates the values of all devices (of which the dr is set). It does not exclude inactive devices.

I’m looking forward to more feedback on this. Filtering on active devices should be straightforward to implement. I’m interested to hear more opinions on this approach :slight_smile:

Please pardon me if this is the wrong place to ask this question. I’m very much a newbie to both ChirpStack and Docker.

When there is a new release like this, do the Docker images get updated automatically? I can’t tell from the docker download page (https://hub.docker.com/r/chirpstack/chirpstack-application-server/). I ran the appropriate Docker command (“docker pull chirpstack/chirpstack-application-server”) and it appeared to update my image (“Status: Downloaded newer image for chirpstack/chirpstack-application-server:latest”), but after a restart it still appears to be version 3.10.0. Is there something else I need to do after the “pull”+restart, or has the Docker image not yet been updated to 3.12?

Thanks a lot in advance!

I would advise to look into Docker tags :slight_smile: That way you know exactly which version you are fetching.

1 Like