Greencell: the charger on your own broker, not a cloud it never had

The HabuDen has no cloud API to connect to. It is commissioned over Bluetooth in
the Greencell GC app, pointed at an MQTT broker the owner runs, and from then on
publishes there — so the connector is an MQTT client rather than an HTTP one,
and nothing in it reaches Greencell. The wire contract is Home Assistant's own
greencell component and the greencell_client 1.0.3 library beneath it, which is
the only published description of the topics: a BROADCAST on /greencell/broadcast
draws device announcements, and /greencell/evse/{sn}/ carries current in
milliamps, voltage, power under "momentary", the EVSE state, and the access level
chosen in the app.

That meant an MQTT client, and the server takes no dependencies, so internal/mqtt
is hand-rolled the way internal/ocpp's RFC 6455 layer is. It is scoped to what
this connector needs and says so: QoS 0 for everything we send, clean session,
no reconnect — a connection lives for one plugin call, which is exactly how the
manager builds and tears down an instance. Inbound PUBLISH is accepted at QoS 0,
1 and 2 with the acknowledgements each requires, because the QoS of a delivery is
the broker's choice and not ours; an unacknowledged QoS 1 is redelivered forever.

Read-only, and the reason is worth writing down rather than rediscovering. A
device in EXECUTE mode accepts START, STOP, SET_CURRENT and QUERY — but the topic
those go to appears in no source: not Greencell's integration page, not
greencell_client, and Home Assistant ships sensor-only for that same reason.
Publishing to a guessed topic would be a control feature whose failure mode is a
driver believing they stopped a charge. So the access level is reported, and
commandTopic is the seam: an operator who has watched their own broker and found
theirs sets it, and a state read then sends QUERY — the one command a READ-mode
device also honours — instead of waiting out the charger's publish cadence. The
day the topic is public, control is a payload away from the same field.

What the cascade resolves here is a broker, not an account, so host, port, TLS and
credentials resolve together from the highest layer that names a host: an
organization's address paired with a user's password would address a broker with
credentials never meant for it. The serial, the QUERY topic and the listen window
each describe the charger rather than the endpoint, so each resolves on its own.

Two reading rules the tests pin. A phase the device did not report stays nil
rather than zero, because zero amps on a charger is a real measurement — a JSON
null decoding to 0.0 was a live bug until a test caught it — and a partial read
returns with received/complete flags instead of failing, since a device that
publishes some topics on a slower cadence is still worth reading. And a reachable
broker with no charger on it is degraded, not down: the half we configure works
and the missing half is the device. The plugin's end-to-end tests run against an
in-process broker written to the raw wire format, so a bug in the client cannot
hide behind a matching bug in the fixture.

The apps get the third connector card. The panel needed nothing — it renders a
plugin's ConfigFields itself — but the per-user panes are still hand-written per
integration, which is now three near-copies and the argument for the generic
version already noted in the plugins README. The web form splits the broker from
the charger because the server resolves them differently. The phone card is a
declarative config against the shared widget, which gained a number field type, a
degraded state that reads amber rather than red, and a fix for a locked field
that was covering its own displayed value with dots. Twenty keys in three
languages across both apps; Greencell, HabuDen and the literal QUERY join the
proper nouns that stay in English.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

API Server/internal/plugins/README.md

@@ -167,10 +167,12 @@ go build -o bin/api-server.exe ./cmd/server
 Restart the server. The plugin appears in the panel's **Plugins** card,
 **disabled** by default.
 
-> DriverVault ships two built-in connectors today — `toyota` (Toyota Connected /
-> MyToyota, read-only vehicle data) and `anker-solix` (Anker Solix V1 EV charger)
-> — both blank-imported from `builtin/builtin.go`. The **external** kind below
-> needs no rebuild and is the easier place to start a new one.
+> DriverVault ships three built-in connectors today — `toyota` (Toyota Connected /
+> MyToyota, read-only vehicle data), `anker-solix` (Anker Solix V1 EV charger) and
+> `greencell` (Greencell HabuDen EV charger, read over the owner's MQTT broker
+> rather than a cloud API) — all blank-imported from `builtin/builtin.go`. The
+> **external** kind below needs no rebuild and is the easier place to start a new
+> one.
 
 ---
 
@@ -320,10 +322,11 @@ The contract is shaped for these; see [`doc.go`](doc.go):
   exist (`Manager.InvokeWith` / `InvokeBatchWith`, driven by the integration routes
   and `internal/api/vehicleproviders.go`); what is missing is the generic route.
 - **Resilience** — retry/backoff, circuit breaker, per-plugin latency/error metrics.
-- **Per-tenant credentials _for arbitrary plugins_** — the two built-in connectors
-  already have them, through the hand-written `/api/integrations/toyota` and
-  `/api/integrations/anker-solix` routes and their **superadmin → org admin →
-  user** config cascade. What is missing is the generic version: per-org/per-user
+- **Per-tenant credentials _for arbitrary plugins_** — the built-in connectors
+  already have them, through the hand-written `/api/integrations/toyota`,
+  `/api/integrations/anker-solix` and `/api/integrations/greencell` routes and
+  their **superadmin → org admin → user** config cascade. Each is a near-copy of
+  the last, which is the argument for the generic version: per-org/per-user
   config keyed off `ConfigFields`, so a newly registered plugin gets the same
   treatment without new endpoints.
 - **Audit logging** of plugin access. (Charger *control* commands are already