Add Time-of-Use tariff write to @teslemetry/api#49
Merged
Conversation
Closes the one true client-level gap identified by the tier-2 parity audit: no TypeScript SDK method existed for HA's time_of_use write, blocking Homey/Node-RED from ever reaching tariff control regardless of wrapper work. The generated OpenAPI client already had the underlying function (postApi1EnergySitesByIdTimeOfUseSettings); this just wires a hand-written method to it, matching the pass-through body typing used by neighboring schedule-setter methods.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
teslemetryintegration) found onegenuine client-library gap across the whole TypeScript ecosystem: Time-of-Use tariff write.
Every other absent write in either wrapper already had a method on
@teslemetry/api- this wasthe one that didn't, so no amount of wrapper work in Homey or Node-RED could close it.
TeslemetryEnergyApi.setTimeOfUseSettings(), mirroring the server'sPOST /api/1/energy_sites/{id}/time_of_use_settingsroute schema (tou_settings.tariff_content_v2).src/client/sdk.gen.ts) already had the underlyingpostApi1EnergySitesByIdTimeOfUseSettingsfunction from a prior spec sync - no codegen/specchange was needed, just a hand-written wrapper following the existing pass-through-body idiom
used by neighboring methods like
addChargeSchedule/setScheduledDeparture.PostApi1EnergySitesByIdTimeOfUseSettingsData["body"](no
any), consistent with how other complex-body setters in this file are typed.homebridge-teslemetry,n8n-nodes-teslemetry, oriobroker.teslemetryis explicitly out of scope here - those arefollow-up stories per the audit's recommendations.
What Changed
packages/api/src/TeslemetryEnergyApi.ts: newsetTimeOfUseSettings(body)method.packages/api/test/energyApi.test.ts: new test asserting the method POSTs thetou_settingsbody to the correct per-site URL and returns the parsed response..changeset/tou-tariff-write.md: minor version bump changeset for@teslemetry/api.AGENTS.md: one-line note that the generated client often already has functions forendpoints the hand-written API classes haven't wrapped yet - worth checking before assuming
an SDK gap needs a spec regen.
Risk Assessment
Low risk, additive-only change to the SDK. No existing methods or call sites touched.
Testing
pnpm --filter @teslemetry/api test- all 8 tests pass (new test included)pnpm --filter @teslemetry/api tsc- cleanpnpm lint(root, oxlint) - cleanpnpm --filter @teslemetry/api build- cleanFull narrative / original brief
[E1.4] typescript-teslemetry: add the Time-of-Use (TOU) tariff WRITE capability to
@teslemetry/api(packages/api) - identified by the parity audit(
/home/brett/firstmate/data/e14-tier2-parity-m2/report.md) as the single trueclient-library-level gap blocking tier-2 integrations from TOU control.
Scope:
the api server's route schema (the Teslemetry api repo cloned at
/home/brett/firstmate/projects/api- the energy tariff routes and their request schemas arethe source of truth; the
ENERGY_TARIFF_OUTPUTshape insrc/routes/mcp/as secondaryreference).
typing, and test patterns). Type the request per the server schema - no any-bags.
(consumers are follow-up stories).