v3.23.1

Getting Started Devices Gateways Integrations Reference
Get The Things Stack

Reference

    Overview
  • Adaptive Data Rate
  • API
  • Application Packages
  • Billing with Stripe
  • Command-Line Interface
  • Components
  • Configuration
  • Data Formats
  • Data Retention and Privacy
  • Email Templates
  • Federated Authentication
  • Frequency Plans
  • FUOTA
  • Gateway RTT
  • Glossary
  • ID and EUI Constraints
  • Last Activity
  • LoRa Basics Station Implementation Guide
  • LoRaWAN Backend Interfaces Interoperability
  • LoRaWAN Specification and Regional Parameters
  • Networking
  • Packet Broker Routing
  • Packet Forwarders
  • Purging Entities
  • Rate Limiting
  • Resource Limiting
  • Root Certificates
  • Telemetry
  • Tenant Management
  • Web UI Branding

Last Activity

This guide provides some in depth information about how the Last activity values in the entity overviews of the Console are calculated.

What does “Last Activity” mean?

The Console provides indicators that help you identify when the last activity from the entity was registered by the network. This section explains how these values are determined in more detail.

The Console will use the following data, whichever is most recent, to determine the Last activity:

End devices

  1. Starting time of the (pending) session of the end device. (Initial page load)
  2. Timestamp of the latest uplink stored in the MAC state data of the end device. (Initial page load)
  3. Timestamp of ns.up.data.receive (uplink received), ns.up.join.receive (join received) or ns.up.rejoin.receive (rejoin received). (Kept updated from the event stream)

Gateways

  1. Timestamp of the last status message received, as provided by the gateway’s status endpoint. (Initial page load)
  2. Timestamp of the last uplink received, as provided by the gateway’s status endpoint. (Initial page load)
  3. Timestamp of gs.downlink.send (downlink sent), gs.uplink.receive (uplink received) or gs.status.receive (status received). (Kept updated from the event stream)

Applications

  1. Timestamp of ns.up.data.receive (uplink received), ns.up.join.receive (join received) or ns.up.rejoin.receive (rejoin received) of any end device of this application. (Initial page load using the stored historical data of the event stream)
  2. Timestamp of ns.up.data.receive (uplink received), ns.up.join.receive (join received) or ns.up.rejoin.receive (rejoin received) of any end device of this application. (Kept updated from the event stream)

Note that whether an initial Last activity value can be displayed depends on whether:

  1. any relevant events have ever been sent by the end devices in the application (see end device section above)
  2. any relevant events have been retained by the retention policy configured for storing events via --events.redis.store.* config options that the deployment is running with.

This means that when the Last activity value is not available for an application, it does not necessarily mean that the application’s end devices did not have any activity yet. It is currently not possible to aggregate the derived Last activity information of all end devices in the application.

← ID and EUI Constraints LoRa Basics Station Implementation Guide →

On this page

  • What does “Last Activity” mean?

The Things Stack

Getting Started

Devices

Gateways

Integrations

Reference

Contributing

GitHub

Forum

About Us

The Things Network

The Things Industries

About this page

Last changed by Ben Olayinka on 11 Oct 2021.
doc: Create console troubleshooting (#591)

Edit on Github