MQTT Device management events

TTN Network and Services The Things Stack v3
1

Hi all,

I’m trying to get notifications of when devices are created/updated/deleted in a TTN application so I can manage the provisioning of them in another system.

In the API documentation https://www.thethingsnetwork.org/docs/applications/mqtt/api.html there is some information about device events which look like what I want.

image

After some trial and error my dotNet client can connect and I can successfully subscribe to topics. I have tried the following topics (can’t find much documentation about topic formats) but when I create/delete/update EndDevices in a TTN application I have not got any notifications.

string topic;
topic = $"v3/{username}/devices/{clientId}/events/update";
//topic = $"v3/{username}/devices/{clientId}/events/create";
//topic = $"v3/{username}/devices/{clientId}/events/delete";
//topic = $"v3/{username}/devices/+/events/+";
//topic = $"v3/{username}/devices/+/events/create";
//topic = $"v3/{username}/devices/+/events/update";
//topic = $"v3/{username}/devices/+/events/delete";
//topic = $"v3/{username}/devices/+/events/+";

I have also tried different QoS levels just incase
.MqttQualityOfServiceLevel.AtMostOnce);
.MqttQualityOfServiceLevel.AtLeastOnce);
.MqttQualityOfServiceLevel.ExactlyOnce);

What am I missing, am I on the right track?

Thanks

@KiwiBryn

2

That’s the V2 documentation. For V3, you want https://thethingsstack.io/integrations/mqtt/ When in doubt, just subscribe to # to get all events for your application, so you can debug and extract the full topic for the events you need.

Aside:

While I guess that your code may have {username} equal the application id, and {clientId} the device id, these are confusing parameter names. Just to be sure: an MQTT client id is usually a random ID identifying just that: the MQTT client (needed when expecting queued messages when the client re-connects using the same id, but I think TTN V2 and V3 don’t support that anyhow). So, I’d not expect that to match a TTN device id. And the user name is really the application id.

For create events (if V3 supports those), you’ll obviously need a wildcard for the device id.

3

Thanks arjanvanb

Getting V2 when I really wanted V3 docs in Google results has tripped me up before.(forgot site:)

I have had a look at the V3 docs at

https://thethingsstack.io/integrations/mqtt/

There don’t appear to be any references to device management events unlike the V2 docs at

https://www.thethingsnetwork.org/docs/applications/mqtt/api.html

Where there is only the briefest mention of device management events

Are device management events supported in V3?

@KiwiBryn

4

So, what does subscribing to the wildcard # get you?

5

The scope of the v3 Application Data API that is available over MQTT is limited to the (LoRaWAN) Application Server. The documentation for it can be found on the page already referenced above: https://thethingsstack.io/integrations/mqtt/

At time of writing, you can only subscribe to the following topics (wildcards are supported):

  • v3/{application id}/devices/{device id}/join
  • v3/{application id}/devices/{device id}/up
  • v3/{application id}/devices/{device id}/down/queued
  • v3/{application id}/devices/{device id}/down/sent
  • v3/{application id}/devices/{device id}/down/ack
  • v3/{application id}/devices/{device id}/down/nack
  • v3/{application id}/devices/{device id}/down/failed
  • v3/{application id}/devices/{device id}/service/data

The v3 Events API that includes events from the entire stack (including device create/update/delete events) is currently available over gRPC and HTTP streams only, not over MQTT. The API reference for it can be found here: https://thethingsstack.io/reference/api/events/

3 Likes
6

Are there specific reasons why this is currently not supported over MQTT?
Will MQTT support be added to the v3 Events API?

1 Like
7

We designed our v3 APIs to allow for better scalability and reliability than our v2 APIs.

The first goal of the v3 design was to create a better “separation of concerns”. We split the stack into a number of components (Identity Server, Gateway Server, Network Server, Application Server, Join Server, etc.) with their own APIs. Events are not a concern of any of these, so it didn’t make sense to expose it on any of these components (and thus, we made it part of the Console while we research a possible “Events Server”).

We also wanted a better separation between the “data plane” (forwarding LoRaWAN messages), the “control plane” (device management) and the “observability” (events, metrics). With such a separation we can “gracefully degrade” our service in case of problems (infrastructure, DoS, etc.). We think that it is important to keep forwarding application traffic (the data plane) as much as possible. The impact of (temporarily) being unable to create/update devices (the control plane) or monitor the events is much smaller. By using MQTT for only high-priority application traffic, and not for low-priority events, we make it much easier to keep everything online.

So for the time being we have 3 MQTT APIs:

  • The Gateway Data MQTT API (v2) on port 1881/8881
  • The Gateway Data MQTT API (v3) on port 1882/8882
  • The Application Data MQTT API (v3) on port 1883/8883

If there’s a lot of user demand, we could consider exposing another MQTT API for events. If anyone is interested in working on this, please create an issue on GitHub where we can discuss the details. And when everything is worked out, you’re very welcome to implement this and submit a pull request.

2 Likes
9

I had a look at https://thethingsstack.io/reference/api/events/ there are dozens of events, a dozen end_device events and I think there are 3 events which I care about.

If this is a “firehose” of events is there anyway to filter them down to just the ones which I handle?

I have not used gRPC before so I’m reading the docs…

KiwiBryn

10

This topic was automatically closed after 30 days. New replies are no longer allowed.