networknet

Lab note / IoT & Prometheus

Giving home systems a common metrics language.

Exporting solar, climate, smart-device and energy-meter signals from GoodWe, Daikin, Shelly and DSMR P1 into Prometheus—and making them useful in Grafana.

01 / The pattern

One destination. Different routes.

A solar inverter on the local network, climate units behind a SaaS API and smart devices in a vendor cloud do not naturally belong in the same operational view. Prometheus exporters provide the translation layer: each integration handles its own protocol, authentication and data shape, then exposes metrics through the same HTTP contract.

That separation keeps vendor-specific complexity at the edge. Prometheus only needs to scrape a predictable endpoint, while Grafana can work with stable names, labels and health signals. DSMR P1 energy-meter data joins the same wider home-metrics landscape.

GoodWe solar Daikin climate Shelly devices DSMR P1 energy
TranslateExporters:9100/metrics
CollectPrometheusscrape + store
UnderstandGrafanaquery + visualise
The exporter is the boundary: vendor protocols go in; consistent, inspectable metrics come out.

02 / Three boundaries

The interface changes. The operating model stays familiar.

01Local network

GoodWe / solar

Read the inverter close to the source.

The GoodWe exporter connects to the inverter’s local UDP API on port 8899, reads runtime data and maps it to labelled metrics. Solar power, generation, AC and DC values, temperature, work mode and Wi-Fi strength become available without routing the data through an external service.

  • Poll10 seconds by default
  • Identityinverter label
  • NetworkUDP/8899 to one Vault-supplied IP
goodwe_power_watts goodwe_daily_generation_kwh goodwe_temperature_celsius goodwe_up
02Cloud API

Daikin / climate

Work within a cloud API’s identity and rate limits.

The Daikin exporter polls the Onecta API for all climate units in one request. OIDC tokens are bootstrapped once through a dead-end Cloudflare Worker callback, persisted on a PVC and refreshed by the exporter. A ten-minute poll interval uses 144 of the account’s 200 daily requests, leaving room for normal app use.

  • Poll10 minutes
  • Identitydevice_name + device_id
  • NetworkOutbound HTTPS only
daikin_indoor_temperature_celsius daikin_target_temperature_celsius daikin_is_on daikin_last_scrape_success_timestamp
03Cloud control

Shelly / smart devices

Normalize device generations behind one query surface.

Shelly’s /device/all_status endpoint returns every account device in one request. The exporter recognizes the different Gen1 and Gen2+ response shapes and maps both onto the same relay, power, temperature and humidity metrics. Device IDs and channels keep the series useful without exposing devices directly on the LAN.

  • Poll30 seconds by default
  • Identitydevice_id + optional channel
  • NetworkOutbound HTTPS to Shelly Cloud
shelly_relay_power_watts shelly_temperature_celsius shelly_device_online shelly_scrape_errors_total

03 / Metric language

Name the signal—and the health of the path.

Useful exporters expose more than device values. They also make collection health visible, so a flat line can be distinguished from a broken integration.

A

Domain signals

Watts and kilowatt-hours for solar; temperatures, modes and setpoints for climate; relay state, power, humidity, battery and RSSI for Shelly devices.

B

Stable identity

Labels such as inverter, device_id, device_name and channel keep one metric family useful across devices.

C

Exporter health

Up state, error counters and last-success timestamps reveal whether the source is current, unavailable or failing to collect.

ExporterUpstreamCollectionPrimary concern
GoodWeLocal inverterUDP/8899 · 10sSecret IP and narrow LAN egress
DaikinOnecta SaaSHTTPS · 10mOIDC token lifecycle and daily API budget
ShellyCloud Control APIHTTPS · 30sOne-call discovery and generation normalization

04 / Day-two operation

Treat small integrations like real infrastructure.

The value of the pattern is not only the dashboard. It is the repeatable operational shape around every exporter: container build, Kubernetes deployment, controlled secrets, restricted network paths, Prometheus scraping and a Grafana view.

  1. 01

    Keep secrets out of Git

    Vault-backed External Secrets supply local addresses or cloud credentials at runtime. Sensitive values stay out of manifests and logs.

  2. 02

    Constrain the runtime

    Non-root containers, dropped capabilities, read-only root filesystems and targeted NetworkPolicies reduce what each integration can do.

  3. 03

    Make absence explicit

    Missing fields are skipped instead of being reported as zero, and scrape timestamps and counters expose stale or failed collection.

  4. 04

    Let GitOps carry the pattern

    Flux reconciles the Kubernetes resources; static Prometheus jobs collect the exporters; Grafana dashboards complete the feedback loop.

What this creates

Not one oversized home-automation integration, but a set of small translators with clear responsibilities. Each understands one source. Together, they give the homelab a shared language for energy, climate, device state and operational health.

05 / Source notes

The implementation documents.

This article is based only on the README and design notes for these three exporters.