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:
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.
There seems to be an issue with websockets in this release, I get a lot of
“[write] error writing websocket message: write tcp 192.168.1.116:8080->192.168.1.100:54774: i/o timeout”
messages in the log, and the feed seems to miss LoRa packets.
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
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?