A ZEV pools solar production and consumption across several households behind one grid connection. Correct billing means importing every participant’s meter data, splitting each 15-minute interval of shared production and consumption fairly between them, pricing it against the community’s tariffs, and turning that into an invoice someone can actually pay. Do it manually and it’s tedious and error-prone; get it wrong and someone is quietly overpaying for power they didn’t use.
OpenZEV does that whole chain end to end.
It’s self-hosted and licensed AGPL-3.0.
OpenZEV was built with generous AI assistance — right down to the specs, ADRs and user docs. That’s a deliberate trade-off, not an oversight: some design choices might look a little unconventional compared to what a more seasoned team would land on. The project is optimized for learning, experimentation, and running my own ZEV well, not for enterprise-grade process perfection. It’s shipped as-is — check your own data and billing outputs before they reach a participant.
If you’re running (or thinking about starting) a Swiss ZEV or vZEV, the code is on GitHub and the project has its own home at openzev.ch.
]]>The result is a local, cloud-free sensor reading water tank temperature (to about 0.3°C — finer than the front panel’s own 1°C display), operating mode (heating/idle/defrost), and PV/solar state — fed straight into ESPHome and Home Assistant.
The main control board is an ATmega16-based SY-384. It talks to the front panel over a single-wire, half-duplex UART bus at 2400 baud, 8N1, optically isolated. The panel is wired with only three conductors: UART data, 5V and GND — no sensors of its own. That detail mattered: it proved that everything the panel displays, including the tank temperature, has to arrive over this one wire. It was in there somewhere.
Dumping the raw stream, a repeating 32-byte frame jumped out, always starting with the same two header bytes. Byte 5 changes every frame, and XOR-ing bytes 2–29 against it produces a stable, readable payload — after which a constant signature appears at bytes 6–9, a reliable sanity check that decoding worked. Bytes 30–31 turned out to be a CRC-16/Modbus over the rest of the frame, which let me discard corrupted frames with confidence. Decoded byte 11 splits the traffic into two families, one per direction of the conversation.
Two fields fell quickly just by watching decoded byte 10 while poking the machine: the low bits give operating mode (heating/idle/defrost), and one bit flags PV/solar mode.
My unit was sold as the cheaper model, advertised without PV/solar mode. Except it basically has one: PV mode is documented in the manual that shipped with the unit, with its own target temperatures, and the schematic has a terminal labelled “PV Input” sitting right there on the board. The firmware never lost the feature — the pricier model just adds something to drive the trigger.
So I enabled PV mode in the settings menu, wired a Shelly 1 Mini Gen3 relay onto that PV Input terminal, and let Solar Manager close it whenever my system has surplus solar. The boiler now jumps to its PV setpoint on sunny afternoons, and the bus decode confirms it by reading the resulting PV state straight back.
This was the hard part, and it took days. The obvious approach — note the display reading, find a matching byte, repeat — kept failing, because the board reads several temperature sensors (tank, evaporator, ambient, exhaust) and their bytes all shift with operating state. Two moments showing the same tank temperature on the display can have very different readings everywhere else on the bus. Spot checks confound temperature with machine state; you need a real sweep of labelled data to untangle it.
I re-enabled a camera-and-OCR rig I already had pointed at the front panel, logging the displayed temperature into InfluxDB alongside every decoded byte, and started correlating properly — Pearson correlation between the ground-truth display reading and each of roughly 60 candidate bytes.
The first attempt was a trap: overnight, as the tank cools passively, every byte that drifts downward correlates with temperature at ~0.98, because they’re all cooling together. I needed a heating event — a moment where the tank diverges from everything else — so I waited for a full day-night “V”: cool down overnight, reheat during the day. Even then, several coil-sensor bytes still scored ~0.9 on plain correlation, so I ran a time-lag scan — sliding each candidate byte forward and backward in time before recomputing the correlation. The real tank reading peaks sharply at lag zero; a coil sensor that merely follows the same daily heating rhythm peaks 90–120 minutes off, revealing it as a coincidence of timing rather than the thing itself.
That scan pointed straight at decoded byte 14: it peaks at lag zero, uses the full
0–255 range, and had been dismissed early on as noise precisely because it’s
higher-resolution than the display and wraps around. byte14 mod 64, plotted
against temperature, is a clean line — falling about 10 units per °C and wrapping
every 6.4°C. A second byte, 15, supplies the coarse band needed to disambiguate
which wrap you’re in.
No cloud, no API reverse-engineered from an app — just a wire tap, a lot of correlation, and a sensor that now feeds temperature, mode and PV state directly into ESPHome and Home Assistant. The full protocol notes, capture data and code are in the repo if you’re staring at a similarly silent appliance.
]]>node-providerid is a Go CLI that
reads or changes a Kubernetes Node’s spec.providerID directly through the etcd
v3 API, targeting embedded etcd on a k3s server by default.
providerID links a Node object to its machine in the cloud provider, and
Kubernetes treats it as immutable once set — the API server rejects any attempt
to change a non-empty value, and it can’t be cleared through kubectl edit or
kubectl patch. In practice it still ends up wrong sometimes: a Node registered
before the cloud provider was configured, a migration between providers, or a bad
--provider-id baked in at first boot. The usual fix is to drain, delete and
re-register the Node. When that isn’t practical, the only place left to correct
the value is the datastore itself — which is exactly what this tool does, as
narrowly as possible: it patches only the providerID field, guards the write
with an etcd compare-and-swap on the Node’s revision, and writes a per-key backup
first.
Worth saying plainly: set writes directly to your cluster’s backing store and
bypasses every Kubernetes safety layer — schema validation, admission control,
authorization, the lot. get is read-only and safe; set is a deliberate,
last-resort operation, and the README says so at length before you get anywhere
near running it.
burrow exposes a TCP service running outside a Kubernetes cluster to workloads running inside it, without opening inbound firewall ports or configuring static routes.
The client runs wherever the service actually lives — laptop, edge node, private
server — and dials outbound to a WebSocket endpoint on a server component
running inside the cluster. Because the client always initiates the connection,
it works through NAT, firewalls and most corporate networks. Traffic from pods
reaches the local service through that persistent tunnel; the server can
optionally manage a Kubernetes Service object per connected client, so pods
reach tunnelled services by a stable DNS name rather than tracking ports by hand.
It’s the kind of thing that’s handy for reaching a homelab machine from an
in-cluster job, or bridging a service that will never itself run in Kubernetes.
alertmanager-label-enricher is an inline proxy that sits between Prometheus and Alertmanager and enriches alert labels from external lookups — Kubernetes objects, HTTP endpoints, or a static file — before forwarding alerts on.
Prometheus’s own alert_relabel_configs already covers static and conditional
label rewriting, but nothing for a lookup against something external — for
example, adding a team label read off the Kubernetes object for the alert’s
namespace, or off a CMDB via HTTP. Because enrichment happens before
Alertmanager sees the alert, the new labels participate fully in routing,
grouping, inhibition and silences, exactly like any label Prometheus set itself.
Rules run in declared order, all matching rules apply, and later rules see labels
earlier ones added. Overwriting or dropping an existing label changes the alert’s
fingerprint in Alertmanager — which can invalidate existing silences — so both
require an explicit opt-in, while annotations (no fingerprint risk) don’t.
alertname gets extra protection since it’s Alertmanager’s primary identifying
label. A rule can be marked required, failing the whole batch closed so
Prometheus retries if its lookup fails; everything else fails open rather than
block delivery.
None of these three are trying to be a platform or a product — they each fix one specific thing that was in my way. If one of them is in your way too, they’re on GitHub and I’ll happily look at a PR.
]]>It’s heavily inspired by, and builds on protocol work from, plan44/vdcd by Lukas Zeller — the vDC API protocol handling and device model abstractions follow the patterns established in that project, and I’m grateful for the open reference implementation.
It ships as a container and, more usefully for most of my own setup, as a Home
Assistant add-on. The standalone container needs --network host, because mDNS
(DNS-SD) discovery relies on multicast traffic that a Docker bridge network would
otherwise isolate — without it, the digitalSTROM Server simply never finds the
bridge on its own. That does mean the web UI and API are reachable by anything on
the LAN with no login by default, so there’s an optional HTTP Basic Auth flag for
the standalone case; running it as a Home Assistant add-on instead gates access
through your HA session via ingress, which is the simpler and safer path if
you’re already on Home Assistant.
If you’re running digitalSTROM alongside anything else — Home Assistant, WLED, Tasmota, Zigbee2MQTT — the bridge, its docs and the Home Assistant add-on repository are on GitHub.
]]>