To log messages from all applications and gateways

What is the suggested way to to log and view all messages from devices that are registered to different applications?

I’m looking for similar functionality that Actility’s Wireless Logger module in Thingpark gives, ie. to see latest (and history of) message reveiced by all the devices.

It seems that web ui can visualise messages, but only per gateway. But what if we want to see all lora uplinks/downlinks regardless of the gateway?

You could achieve this by subscribing to the application/# MQTT topic. This would mean subscribe to all MQTT topics starting with application/, thus it would match all applications and devices.

1 Like

Tried this, but seems that nothing shows. Am I missing something? In web UI, I see application’s device events coming in.

Another thing, are the tx/rxinfo published to the topic, because what I actually need to persist, is SNR, RSSI, SF and deveui information?

What I would suggest is enabling the postgresql integration, this way Chipstack will forward all device events to a sql database that will store them indefinitely, with all the data and metadata. All thats required is to set up another PSQL database (or just another table with the same database/user in your postgres container) and then add the following to your [integration] section of your Chirpstack.toml.

[integration]
  enabled=["mqtt", "postgresql"]

  [integration.mqtt]
    server="tcp://$MQTT_BROKER_HOST:1883/"
    json=true

  [integration.postgresql]
    dsn="postgres://<USERNAME>:<PASSWORD>@<HOSTNAME>/<DATABASE>?sslmode=disable"

As a side note it seems strange that you are not seeing the MQTT messages in your broker, have you already changed the [integration.mqtt] section above? Or perhaps you have an atypical TLS setup (ACL and mosquitto.conf) on your MQTT broker such that the mqtt integration isn’t posting the events to your MQTT broker. As your Chirpstack setup is still working you should at the very least be able to see the raw still encrypted messages coming from the gateway bridge if you subscribe to the topic “#” rather than “application/#”.

When I subscribe inside mosquitto container (or from outside, using 1883) I see events published as expected :

From outside using 8883 port, nothing, except when I sub to the topic #, I see something, though, but not application uplinks:

I have configured stack like this:

chirpstack.toml:
[integration]
enabled=[“mqtt”]

[integration.mqtt]
server=“tcp://$MQTT_BROKER_HOST:1883/”
json=true

acl:
pattern readwrite +/gateway/%u/#
pattern readwrite application/%u/#

mosquitto.conf:
per_listener_settings true

listener 1883 0.0.0.0
allow_anonymous true

listener 8883 0.0.0.0
max_connections -1
cafile /mosquitto/certs/ca.pem
certfile /mosquitto/certs/mqtt-server.pem
keyfile /mosquitto/certs/mqtt-server-key.pem
allow_anonymous false
require_certificate true
use_identity_as_username true
acl_file /mosquitto/acl

This is all expected behaviour, you must just be using the gateway certificates to connect instead of the applications certificates.

When you set up the ACL using:

pattern readwrite +/gateway/%u/#
pattern readwrite application/%u/#

and in the mosquitto.conf use:

use_identity_as_username true

The %u in the ACL gets replaced by the MQTT client’s (in this scenario thats you using mosquitto_sub) username, restricting a client to only view the topics with their username in them.

use_identity_as_username means it uses the CN on the certificates as your username. Presumably you are using the gateway’s certificates to connect with mosquitto_sub, thus it is only showing you the events following the pattern eu868/gateway/%u/# which are messages directly to/from the MQTT forwarder, rather than application/%u/#, which contains the application events after they have been processed and decrypted by chirpstack.

What you should do is go into the UI, under the application you want to monitor and retrieve the certificate from the “mqtt integration” button there, that will have the proper CN to view that applications MQTT events.

The reason you can view all events from inside the container or using 1883 is because of the other listener set up:

listener 1883 0.0.0.0
allow_anonymous true

Which allows any other connection on the same machine to connect without TLS and without the ACL restrictions. If you tried to connect to the mosquitto broker over port 1883 from another machine it would fail.