1. Introduction
2. Architecture
3. v3 documentation
4. v4 breaking changes
5. v3 to v4 migration
8. Getting started
9. Docker
10. Debian / Ubuntu
11. Raspberry Pi
12. Ansible and Vagrant
13. Guides
    ❱
14. 1. Connecting a gateway
    2. Connecting a device
    3. Device repository and metrics
    4. Mosquitto TLS configuration
    5. Node-RED integration
    6. ThingsBoard integration
    7. Pilot Things integration
    8. Auth0.com integration
    9. Migrating from Semtech NS
    10. Roaming with Helium
15. Gateway configuration
    ❱
16. 1. Browan
    2. Dragino
    3. Kerlink
    4. Multitech
    5. RAK
    6. Tektelic
18. ChirpStack
19. Changelog
20. Configuration
21. Downloads
22. Requirements
23. Features
    ❱
24. 1. Adaptive data-rate (ADR)
    2. Channel (re)configuration
    3. Device activation
    4. Device classes
    5. Device metrics
    6. Device status
    7. Device time
    8. End-to-end encryption
    9. Frame logging
    10. Gateway management
    11. Geolocation
    12. Join server
    13. Multi-region
    14. Multicast
    15. Rejoin
    16. RX parameters (re)configuration
25. Use
    ❱
26. 1. Applications
    2. Device profiles
    3. Device-profile templates
    4. Devices
    5. Event log
    6. Frame log
    7. FUOTA
    8. Gateways
    9. Login
    10. Multicast groups
    11. Tenants
    12. Users
27. Integrations
    ❱
28. 1. Event types
    2. AMQP / RabbitMQ
    3. Apache Pulsar
    4. AWS SNS
    5. Azure Service-Bus
    6. GCP Pub/Sub
    7. HTTP
    8. IFTTT
    9. InfluxDB
    10. LoRa Cloud
    11. MQTT
    12. myDevices
    13. Pilot Things
    14. PostgreSQL
    15. ThingsBoard
    16. Building new integrations
29. Streams
    ❱
30. 1. API requests
    2. Backend Interfaces API
    3. Integration events
    4. LoRaWAN frames
    5. Uplink / downlink metadata
31. API
    ❱
32. 1. gRPC
    2. REST
    3. Go examples
    4. Python examples
    5. JavaScript examples
    6. C# examples
    7. Protocol documentation
33. Backends
    ❱
34. 1. MQTT
    2. AMQP / RabbitMQ
    3. Azure IoT Hub
    4. GCP Pub/Sub
35. Contribute & source
37. ChirpStack MQTT Forwarder
38. Introduction
39. Changelog
40. Configuration
41. Downloads
42. Installation
    ❱
43. 1. Dragino
    2. Kerlink
    3. Multitech
    4. RAK
    5. Tektelic
44. Contribute & source
46. ChirpStack Concentratord
47. Introduction
48. Changelog
49. Hardware support
50. Configuration
51. Downloads
52. Installation
    ❱
53. 1. Kerlink
    2. Multitech
54. API
    ❱
55. 1. Commands
    2. Events
56. Contribute & source
58. ChirpStack Gateway Bridge
59. Introduction
60. Changelog
61. Configuration
62. Downloads
63. Installation
    ❱
64. 1. Debian / Ubuntu
    2. Raspberry Pi
    3. Cisco
    4. Dragino
    5. Kerlink
    6. Laird
    7. MatchX
    8. Multitech
    9. Tektelic
    10. Wifx
65. Payload formats
    ❱
66. 1. Events
    2. States
    3. Commands
67. Backends
    ❱
68. 1. Basics Station
    2. Concentratord
    3. Semtech UDP
69. Integrations
    ❱
70. 1. MQTT
    2. Azure IoT Hub
    3. GCP Cloud IoT Core
71. Metrics
72. Contribute & source
74. ChirpStack Gateway OS
75. Introduction
76. Changelog
77. Image types
78. Hardware support
79. Downloads
80. Installation
    ❱
81. 1. Raspberry Pi
82. Getting started
83. Use
    ❱
84. 1. Configuration
    2. Subscribe to MQTT
    3. Log files
    4. Modifying files
    5. Software update
    6. Node-RED
85. Contribute & source

InfluxDB

If configured, the InfluxDB integration will write device data into an InfluxDB database. This makes it possible to directly visualize all device data using for example Grafana .

Getting started with InfluxDB

Getting started with Grafana

Requirements

Before this integration is able to write data into InfluxDB, the uplink payloads must be decoded. The payload codec can be configured per device profile . To validate that the uplink payloads are decoded, you can use the live device event-log feature. Decoded payload data will be available under the object key in the JSON object.

Measurements

Naming

All measurements are using the field names from the object element, joined by an underscore ( _ ) in case the object element is nested. Payload data is prefixed by device_frmpayload_data .

Example:

"object": { "temperature_sensor": { "1": 23.5

The above will translate to the measurement device_frmpayload_data_temperature_sensor_1 .

Note: When using the CayenneLPP codec camelCasing is used when the data is presented as JSON. However, for the InfluxDB naming, snake_casing is used. Thus temperatureSensor in JSON translates to temperature_sensor as measurement name in InfluxDB.

Location data

When both latitude and longitude keys are found (on the same level within the object ), both measurements are treated as a single geolocation measurement.

Example:

"object": { "latitude": 1.123, "longitude": 2.123

The above will translate to the measurement device_frmpayload_data_location with values latitude , longitude and geohash (see also Geohash ).

For aggregation, each measurement will have the following tags (additional to the device tags):

application_name

device_name

dev_eui

f_port (LoRaWAN port used for uplink)

Device uplink meta-data

For analyzing and monitoring the usage of spreading-factors, channels, etc. the InfluxDB integration will also write a measurement named device_uplink with as values a counter value 1, rssi , snr and f_cnt . For Aggregation, the following tags are available (additional to the device tags):

application_name

device_name

dev_eui

frequency

Device battery status (deprecated)

When this information is available, the device battery status will be written to the measurement name device_status_battery . For aggregation, the following tags are available (additional to the device tags):

application_name

device_name

dev_eui

Device battery level

When this information is available, the device battery level (percentage) will be written to the measurement name device_status_battery_level . For aggregation, the following tags are available (additional to the device tags):

application_name

device_name

dev_eui

Device margin status

When this information is available, the device margin status will be written to the measurement name device_status_margin . For aggregation, the following tags are available (additional to the device tags):

application_name

device_name

dev_eui