Category has been in the plugin contract since it was written — apis-external,
drives-external, drives-local — and every builtin declared the same one, so it
grouped nothing. Two of the three talk to a wallbox and one talks to a car
manufacturer, and those are different questions an operator arrives with: the
Toyota card is where a driver's account gets linked, the Anker and Greencell
cards are where a charger's broker and credentials live. So vehicles and
chargers join the constants and the three builtins say which they are.
The panel groups on that field rather than on a list of names, which is what
keeps an external plugin from needing panel code. Tab order mirrors the
constants; a category with nothing in it gets no tab, and a single group hides
the bar entirely, so an install with one connector looks exactly as it did.
A category the panel does not recognise — or an empty one — falls to the
external-APIs tab rather than vanishing, because a plugin nobody can see is a
plugin nobody can disable. The selected tab falls back to the first group when
its own goes away, which is what removing the last external plugin does.
Registration still asks only for name, base URL and provider, so a plugin
registered at runtime lands under Other APIs until its manifest names a
category. That path already works and is the honest default: the panel is
guessing about a service it has never spoken to, and the service can say.
The header lockup is the other half. It was a copy of the Web App's mark rather
than the same mark, and copies drift — a 32px icon against 28, a 24px wordmark
against 21.6, "Driver" at text-strong instead of white, "Vault" a step lighter
than brand-400. The Web App's Logo.vue moves in verbatim, props included. The
one thing it cannot inherit is which variant to render: the Web App's rail is
always dark, while this panel flips with its own theme toggle, so on-dark is
bound to the theme and the hand-rolled bar fills that existed to survive that
flip are gone.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Toyota put the /v1/global/remote read routes behind AWS SigV4 in mid-2026. A
bearer token is no longer a credential there, so the doors-and-windows card has
been asking a gateway that answers 403 — the one section of the provider tab
that could only ever have been in error. The MyToyota app reads that state from
/v1/vehicle/status now and pytoyoda followed it in 5.2.0; so does the connector.
The electric route did not move, and the comment above the endpoint block says
which of the two namespaces each one lives in, because the obvious tidy — sweep
the rest onto /v1/vehicle/* — would break the ones that still work.
The same migration gave the climate reads a home worth porting: /v1/vehicle/
climate-status is what the cabin is doing, climate-settings the preset it was
told to do it at. Both are GETs with a vin, both are new cards on the tab, and
their headings are in all three languages on both apps. Nothing about the tab's
plumbing changed to hold them — a section is an id, an action, and whatever JSON
comes back, which is the point of that shape.
Left where they are: the POST wake calls. Upstream refreshes a stale reading by
waking the modem, and this connector is documented as read-only, so climate and
status show what the car last reported rather than what it would say if asked
twice. The cost is a reading that can be hours old, and it is the honest one to
pay for a connector that promises not to touch the vehicle.
Two tests keep the migration from being undone by hand: one fails if any
advertised capability points back at a retired route, the other if a capability
is advertised without being wired into Invoke, which is the way the next
endpoint would go missing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Let each user run the Toyota Connected plugin under their own MyToyota
credentials and enable/disable it for themselves in the Web App, while a
superadmin (and, in an organization, an org admin) can impose settings
from above. Resolution is a cascade — top wins, and a lower level only
fills fields the levels above left blank:
- org user: API Server (superadmin) -> org admin -> user
- org-less user: API Server (superadmin) -> user
The MyToyota email + password resolve together as a pair from the highest
layer that supplies an email; brand resolves on its own; enablement is
strictly per-user, gated by the global master switch and the org gate.
API Server:
- plugins.Manager gains RawConfig / HealthCheckWith / InvokeWith so the
cascade can read global config and probe/invoke under a per-caller
resolved config.
- internal/api/integrations.go resolves the cascade and serves
GET/PUT /api/integrations/toyota, POST .../health, GET .../vehicles.
Secrets and inherited usernames are masked before leaving the server.
- The toyota builtin's credentials are no longer required at the global
layer, so the master switch can be enabled without global credentials.
- setup-pocketbase.mjs adds a pluginSettings JSON field to the users and
organizations collections (the user and org layers of the cascade).
Web App:
- api.js gains getToyota/saveToyota/testToyota.
- Settings grows an Integrations section: an enable toggle, credential
fields with locked / "inherited from" states, a brand select, an
org-scope switch for admins, and a live test-connection button.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Port pytoyoda's authentication and read-only data flow to a Go builtin
plugin behind the existing plugin contract. Implements the three-legged
ForgeRock/OAuth2 login (authenticate callback loop, authorize, token
exchange), silent refresh with full re-auth fallback, and the full
Toyota gateway header set with backoff on 429/5xx.
Exposes read-only capabilities: vehicles, telemetry, location, health,
status, electric, notifications, and service-history. Config takes a
MyToyota email/password and a Toyota/Lexus brand select.
Europe-only and read-only, matching pytoyoda's limitations.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
