Verifiable live data in Home Assistant.
Point a Home Assistant REST sensor at Dynamic Feed and every value arrives inside an Ed25519-signed envelope with its own provenance and freshness — so your automations act on data they can attribute and check the age of, not a bare number. Read-only: it surfaces data, it never controls a device or makes a safety decision.
The call
No custom component, no key. Use built-in REST sensors against the keyless POST /v1/batch endpoint, and expose the freshness/provenance block as sensor attributes.
# A keyless Home Assistant REST sensor — paste into configuration.yaml.
# The value lives at results[0].data.; provenance/freshness ride along as attributes.
rest:
- resource: https://dynamicfeed.ai/v1/batch
method: POST
headers: {"Content-Type": application/json}
payload: '{"calls":[{"tool":"grid_carbon","args":{"region":"nsw"}}]}'
scan_interval: 600
sensor:
- name: "Dynamic Feed Grid Carbon Intensity"
value_template: "{{ value_json.results[0].data.carbon_intensity_g_per_kwh }}"
unit_of_measurement: "gCO2/kWh"
json_attributes_path: "$.results[0].data"
json_attributes: ["provenance", "freshness", "method", "derived"] Sample response
{ "carbon_intensity_g_per_kwh": 624, "region": "nsw", "derived": true,
"method": "live AEMO dispatch weighted by AEMO CDEII emission factors",
"provenance": { "source": "AEMO NEMWEB", "measured_at": "2026-06-14T14:55:06+10:00" },
"freshness": { "state": "live", "age_seconds": 90, "max_age_seconds": 600 },
"signature": { "alg": "Ed25519", "key_id": "df-ed25519-4cb32e72f333", "sig": "..." } }Why live data
You could point a Home Assistant REST sensor straight at a weather or grid API and get a bare number. Routing through Dynamic Feed adds three things to every datapoint in one uniform envelope: provenance (the upstream source, URL and licence), freshness (a state of live / stale / unavailable plus age, so an automation can decline to run on stale data), and an Ed25519 signature over the whole response that an auditor can re-check out-of-band. Home Assistant's Jinja can't verify Ed25519 itself, so the reference config exposes the signature block rather than claiming to verify. It is a read-only bridge: it surfaces verifiable data, it does not switch, dim, lock or actuate anything, and it makes no safety decision. A signature proves a datapoint existed unchanged at a time — not that the value is correct — and it is evidence, not a safety guarantee; your automations own every decision.
Use it for
- Run an energy-heavy appliance only when grid carbon is low and the reading is live
- Show outdoor air quality (US AQI, PM2.5) on a dashboard with its source and age
- Cross-check a local weather station against a signed, attributed feed
- Log the signature block so a value an automation acted on is verifiable later
FAQ
Do I need a custom component or an API key?
No. It uses Home Assistant's built-in REST sensor platform against the keyless POST /v1/batch endpoint. There is nothing to install and no secret to store. Copy the rest: block into configuration.yaml (or a package file), edit the city/region, and restart.
Does it control my devices?
No. It is strictly read-only — it pulls values into sensors. It never switches, dims, locks or actuates anything and makes no safety decision. Whether to act on a reading is your automation's call, on your hardware.
Can Home Assistant verify the Ed25519 signature?
Not in a value_template — Jinja can't do Ed25519. The reference config exposes the signature block so you can verify it out-of-band (e.g. a shell_command or AppDaemon app mirroring scripts/verify_awareness.py). The canonicalization is json-sorted-compact; the public key is at /.well-known/keys.