Home › Methodology

Methodology

Short version: every fact links to its source and its fetch date. Where we don't know something, we say Unknown instead of guessing.

1. Device list (evcc)

All 632 devices come from the open-source evcc templates (commit e9bf069433, fetched 2026-10-19). Each template names brand, model, usages (grid/pv/battery), capabilities, requirements and caveats. We show energy device types only (batteries, inverters, hybrid inverters, EV chargers, meters). Excluded for now:

One page per physical device. evcc often has several templates for the same product (e.g. Alfen Eve via Modbus and via OCPP). We merge templates with the same brand and the same model name (ignoring suffixes like “(OCPP)”, “(Modbus)”, “(via GX)”) into one device page that lists each connection method with its own source. 26 devices have more than one method. Entries without a model name in evcc get a name derived from brand + device type, marked on the page.

Curated corrections (kept in the build pipeline so they survive refreshes): Discovergy is shown as a metering service (meter), not an inverter; Tessie and the “vehicle API-only charger” are car cloud services and are excluded as chargers; the Home Assistant and ioBroker templates are data sources, not devices, and are excluded.

Brands not in evcc. Brands that energy suppliers list but evcc has no template for (e.g. ZinVolt, HYXiPOWER, Midea, Bliq, Homevolt) get a brand page with only the supplier facts and sources; evcc is shown as “Not in evcc”. Single products named by a supplier (e.g. the HomeWizard Plug-In Battery on Eneco's page) get a minimal device page with only those facts.

Device type is derived from the template folder and its usages: a meter template with both pv and battery usage is shown as a hybrid inverter; names containing “meter”, “kWh”, “CT” etc. are shown as meters. Connection type (Modbus TCP/RTU, local HTTP, cloud, OCPP, EEBus, MQTT) is inferred from the template's parameters (e.g. a modbus parameter, a host parameter, or only cloud credentials). It describes how evcc talks to the device, not every way the device can be reached. “Firmware notes” are evcc requirements/caveats that mention firmware.

2. Home Assistant

For 22 brands that matter in the Netherlands we checked Home Assistant core integration manifests (home-assistant/core @ 261a8864f4; docs pages on home-assistant.io returned HTTP 200) and the HACS default repository index on 2026-10-19. Candidate matches were reviewed by hand; unrelated matches (routers, dehumidifiers, other-brand wallboxes) were dropped. “Local/cloud” for core integrations is the manifest's iot_class; for HACS it is read from the repository description and may be Unknown.

This is a brand-level match. An integration for “Zendure” is shown on every Zendure device page, but we have not verified that it supports each specific model. Brands outside this list show Home Assistant support as Unknown.

3. Supplier apps

We read each supplier's official public pages on 2026-10-19 and recorded the brands (and, where given, conditions or models) they say they can steer:

These lists are brand-level. Frank Energie, for example, writes “Met voorwaarden — Omvormers vanaf 2018” for SolarEdge inverters and says compatibility is only certain after you register the device in the app. “Not listed” means the brand is absent from a list the supplier publishes for that device category. Where no list exists (e.g. ANWB chargers, Vattenfall, meters in general) we show Unknown. Essent was not checked yet.

4. Model-level data (planned)

Model-level verification (Frank's per-brand model pages, supplier apps) and moderated user reports (“works for me on firmware X”) are planned. Until then, treat a brand match as “worth checking”, not as a guarantee.

5. Updates

The database is rebuilt weekly; differences in supplier pages are listed on the changes page. Spotted an error? Tell us.