Grafana Home Dashboard Plugin for Indigo

An Indigo plugin that logs device and variable states to InfluxDB for visualization with Grafana. Create beautiful time-series dashboards to track your home automation data over time.

Features

• InfluxDB Client: Connects to your external InfluxDB 1.7/1.8 server, or InfluxDB 3 via its v1 compatibility API
• Granular Control: Advanced inclusion/exclusion criteria to control which devices and states are logged
• Data Filtering: Prevent erroneous values from being logged with min/max ranges and percentage change thresholds
• Smart Updates: Configurable minimum update frequency to avoid gaps in graphs
• Utility Functions: Device and state exploration tools to help configure your dashboards

Requirements

Indigo Requirements

• Indigo 2025.1 or higher
• macOS with Python 3.11+

External Server Requirements

• InfluxDB 1.7 or 1.8 (NOT compatible with 2.x)
  • Docker: docker run -p 8086:8086 -v /path/to/data:/var/lib/influxdb influxdb:1.8
  • Homebrew: brew install influxdb@1
  • Download: https://portal.influxdata.com/downloads/
• or InfluxDB 3 (Core/Enterprise) reached through its v1 compatibility API
  • Select "InfluxDB 3" in the plugin's InfluxDB Version dropdown
  • The database must already exist and the credentials/token must have write access — the plugin does not create databases or retention policies on InfluxDB 3 (retention is managed server-side)
  • For token auth, leave the username as configured on your server and supply the token as the password (v1-compat convention)
• Grafana (for visualization, optional but recommended)
  • Docker: docker run -p 3000:3000 grafana/grafana
  • Homebrew: brew install grafana
  • Download: https://grafana.com/grafana/download

Installation

1. Download the latest release from GitHub Releases
2. Double-click the .indigoPlugin file to install
3. Configure your InfluxDB connection in the plugin configuration

Configuration

InfluxDB Connection

Configure the connection to your InfluxDB server in the plugin configuration:

• InfluxDB Server Host: Hostname or IP address of your InfluxDB server (e.g., localhost, 192.168.1.100)
• Use SSL: Enable if your InfluxDB server uses HTTPS
• InfluxDB Version: InfluxDB 1.7/1.8 (default) or InfluxDB 3 (v1 compatibility API)
• InfluxDB HTTP Port: HTTP API port (default: 8086)
• InfluxDB User: Username for authentication
• InfluxDB Password: Password for authentication
• InfluxDB Database: Database name (created if it doesn't exist on InfluxDB 1.x; must already exist on InfluxDB 3)
• Retention Policy: How long to keep data (6 months, 1 year, 2 years, 5 years, or forever) — applied on InfluxDB 1.x only; InfluxDB 3 retention is managed server-side

Inclusion / Exclusion Criteria

Control which devices and states are logged:

How it works: 1. Excluded devices will never have any information sent to InfluxDB 2. Included devices will have ALL states sent to InfluxDB 3. All other devices will have only the global include states sent

Global Include States: These states will be logged for all devices (unless excluded). Default states include: - onState, state.onOffState - energyCurLevel, energyAccumTotal - sensorValue, value.num - batteryLevel - HVAC states (coolSetpoint, heatSetpoint, state.hvac_state)

Minimum Update Frequency: Configure how often to send updates even if values haven't changed. This prevents gaps in graphs for infrequently changing devices. Options: 5, 10, 15, 30, or 60 minutes.

Advanced Features

Data Filters

Create sophisticated filtering rules to prevent bad data from reaching InfluxDB:

• Min/Max Value Filtering: Only log values within a specific range
• Percentage Change Filtering: Only log values if they haven't changed by more than a specified percentage
• Per-Device or Global Rules: Apply filters to specific devices or all devices
• Lock Minimum Updates: Pause minimum frequency updates for devices that fail filters

Access via: Plugins → Grafana Home Dashboard → Configure data filters (advanced)

Device Exploration

Utility tools to help you understand what data is available:

• Explore Device: Print all states for a specific device to the Indigo Event Log
• Explore State: Find all devices that have a specific state

Access via: Plugins → Grafana Home Dashboard → Explore device/state

Grafana Dashboard Setup

1. Install Grafana on your network
2. Add InfluxDB as a data source:
   • URL: http://your-influxdb-host:8086
   • Database: Same as configured in the plugin
   • User/Password: Same as configured in the plugin
3. Create dashboards or import community dashboards
4. Query the device_changes measurement for device data
5. Query the variable_changes measurement for variable data

Example Query

SELECT "energyCurLevel" FROM "device_changes"
WHERE "name" = 'Living Room Light'
AND time >= now() - 24h

Data Structure

Device Changes

• Measurement: device_changes
• Tags: name, folderId, folder (if in a folder)
• Fields: All device states (based on inclusion criteria), plus the device liveness fields below

Device Liveness Fields

Every device point also carries, automatically and regardless of your inclusion criteria:

These let you tell a device that has stopped communicating from one that is merely quiet. Without them, a device that dropped off the network months ago looks identical in Grafana to a thermostat holding steady overnight — both are a flat line, because the plugin keeps re-sending the last known value as a heartbeat so your graphs don't gap.

Alert on secondsSinceLastSuccessfulComm, not lastChanged — a quiet-but-healthy device also has a frozen lastChanged. A useful "offline device" panel:

SELECT last("secondsSinceLastSuccessfulComm") FROM "device_changes"
WHERE $timeFilter GROUP BY "name"

Sort descending and set the unit to seconds. Anything much larger than a few times your Minimum Update Frequency is worth investigating.

What these fields do not catch

A device can keep communicating normally while one of its readings is stuck — a sensor that still answers polls but always reports the same temperature, for example. Indigo considers such a device healthy, so both timestamps stay current and the liveness fields will not flag it.

That failure mode is a value problem, not a communication problem, and it is best detected in Grafana by asking whether a reading has moved at all over a long window:

SELECT spread("sensorValue") FROM "device_changes"
WHERE time > now() - 24h GROUP BY "name"

A spread of exactly 0 over 24 hours, for a reading that ought to vary, means the value is stuck even though the device looks alive. Use the liveness fields for "is it there?" and a spread check for "is it still telling me anything?".

Two things to get right before alerting on this, or it will cry wolf and be ignored:

• Compare each device against its own history, not against zero. A flat reading is only suspicious if that device has varied before. Plenty of readings are legitimately constant — a closet luminance sensor that always reads 0, a setpoint, a battery level, a relay. Flag a device only when spread over 24h is 0 and its spread over the previous 30 days was greater than 0.
• It misses a value stuck with dither. A sensor alternating 69.1 / 69.2 has a spread of 0.1, not 0, so a comparison against zero will not catch it. Comparing today's spread against the device's own historical spread does.

Scope it to readings that physically vary — sensorValue on sensors, for example. Across 31 temperature sensors over 24 hours on the author's system, exactly one was flat while every other swung 1.2–21.7 °F, so the separation is clean where the check applies.

⚠️ Do not add lastChanged or lastSuccessfulComm to your include-states list. They are already sent on every point. Adding them to the include list makes every change to them generate its own data point, which can multiply your write volume dramatically. For this reason they are hidden from the include-states picker.

Devices that have never communicated (virtual devices, device groups, some plugin-backed devices) simply omit these fields rather than reporting as maximally stale.

Variable Changes

• Measurement: variable_changes
• Tags: varname
• Fields: name, value, value.num (if numeric)

Version History

v2026.8.0 (Filter Fixes + Device Liveness)

• New: device liveness fields on every point — tell a dead sensor from a quiet one (see Device Liveness Fields)
• Fixed: "percent changed" filters were ignored during the periodic minimum-frequency update, so a bad value the filter had blocked could still reach InfluxDB on the next heartbeat
• Fixed: the "lock minimum frequency updates after filter failure" option could leave a device locked permanently, silently stopping all of its data
• Fixed: "percent changed" filters on states written as state.<name> or <name>.num, and filters where the previous value was zero, silently passed everything through
• Fixed: filter blocks that lock a device now say so in the filter log, and a locked device announces itself in the Indigo event log instead of only under debug logging — a locked device sends nothing at all for any of its states, which otherwise looks exactly like a device that is simply quiet
• Fixed: the filter property dropdown accumulated duplicate entries over time

v2026.7.0 (InfluxDB 3 Support)

• InfluxDB Version dropdown: choose InfluxDB 1.7/1.8 or InfluxDB 3 (v1 compatibility API) in the connection settings
• Asynchronous batched writes: state changes are queued and written in batches on a background thread, so the plugin (and its config dialog) stays responsive even against servers with slow write acknowledgments
• Better type-conflict handling: InfluxDB 3 error responses are now understood, so fields with a mismatched column type are converted instead of the data point being dropped

v2025.0.0 (Modernization Release)

BREAKING CHANGES: - Removed bundled InfluxDB and Grafana servers - Plugin now requires external InfluxDB 1.7/1.8 server - Updated to Indigo SDK 2025.1 (Python 3.11+)

Improvements: - Upgraded all Python dependencies to latest versions - Simplified architecture: InfluxDB client only - Removed ~500 lines of server management code - Switched to pip requirements.txt for dependency management - Calendar versioning adopted (2025.0.0)

v2.0.1 (Previous Version)

• Bundled InfluxDB 1.7 and Grafana servers
• Python 3 compatibility
• Server management and auto-recovery

Migration from v2.x

Important: Version 2025.0.0 is a breaking change that removes the bundled InfluxDB and Grafana servers. You must set up external servers before upgrading.

1. Install InfluxDB 1.8 on your network (see Requirements section)

2. Migrate existing data (if you have existing data from v2.x): ```bash # On your Indigo server, export data from old plugin location influxd backup -portable -database indigo /path/to/backup

   # On new InfluxDB server, restore data influxd restore -portable -db indigo /path/to/backup ``` 3. Install Grafana separately (see Requirements section) 4. Update plugin to v2025.0.0 5. Configure connection to your external InfluxDB server 6. Reconfigure Grafana to point to new InfluxDB server

Support & Documentation

• Documentation: Wiki
• Support Forum: Indigo Forums
• Example Dashboards: Forum Thread
• Issues: GitHub Issues

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Credits

• Original author: Mike Lamoureux
• JSON Adaptor: Dave Brown (Copyright 2017, 2018)
• InfluxDB: InfluxData Inc.
• Grafana: Grafana Labs

Disclaimer

This plugin is provided as-is with no warranty. While it has been tested with Indigo 2025.1, use at your own risk. Always backup your Indigo database before installing plugins.