experimental-silo feeds powersync-nightly and landing-silo feeds
powersync-testing, not the other way round. DEPLOY.md in the deploy
repository is the source of truth and says so in two places: its channel
table and its infrastructure inventory, where the core forks are named
etm-nymea-nightly for experimental-silo and etm-nymea-testing for
landing-silo.
Three places carried the labels backwards, all introduced by 30b58db
this morning: the diagram, the sentence on reverting a merge that breaks
the nightly, and the promotion channel list.
The order of the chain itself was already right and is untouched, as is
everything else in the document.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The chain climbs experimental-silo, then landing-silo, then main: a
change is attempted in testing before it becomes a nightly candidate for
stable. The document had the two silos the other way round, which is how
the Fronius work ended up one rung below stable while it had only ever
been verified against the bench simulator.
Corrected in the diagram, the promotion criteria, the fix table and its
downward path, the packaging channel list and the agent rules. The
channel each branch feeds is unchanged: experimental-silo is testing,
landing-silo is nightly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two points the document got wrong. The stable branch is main, not
master: the remote has never had a master. And the promotion chain was
written as if it existed, while landing-silo and experimental-silo were
created only today, the first as empty branches off main.
Nothing else in the document is touched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Committed verbatim from the working tree, where it had been sitting
uncommitted. Written by Patrick, not by the agent: this commit only puts
it under version control so the promotion chain it describes can be
corrected against reality in the next one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Étape 1 complete: V2C Trydan nymea plugin (Modbus TCP, status Partial).
Plugin (IntegrationPluginV2c):
- discoverThings: delegates to V2cTcpDiscovery, maps results to
ThingDescriptors; createMethod "user" bypasses discovery.
- setupThing: registers a NetworkDeviceMonitor (IP tracking on DHCP
renewal), creates TrydanModbusTcpMaster, wires reachableChanged →
initialize() → state update on initializationFinished(), then starts
periodic polls on a 30s PluginTimer.
- updateThingStates: ChargeState 0/1/2 → pluggedIn/charging;
power = (PauseState==0 AND Lock==0) per evcc trydan.go Enabled().
- handleDynamicConflict: if Dynamic==1 (V2C internal PV optimizer),
write PauseDynamic=1 to suppress it. NEVER write Dynamic=0 (silences
ChargePower telemetry). Writes only on state transition to minimize
flash wear. cf. github.com/evcc-io/evcc/issues/28047.
- Action "power": writes PauseState then Lock (always in mirror), then
fire-and-forgets PauseDynamic if Dynamic==1. Action handlers filter
writeCompleted by register address to avoid reacting to concurrent
background writes.
- Action "maxChargingCurrent": clamps to [minIntensity, maxIntensity],
writes Intensity. Below 6A → pause instead of invalid setpoint.
JSON (integrationpluginv2c.json):
- ThingClass "trydan" implementing evcharger + connectable + networkdevice.
- settingsTypes: suspendInternalOptimizer (bool, default true) — allows
the user to disable Dynamic conflict management if they want the V2C
PID to remain active alongside the HEMS.
- State "chargeEnergy" exposed as diagnostic only (NOT sessionEnergy) —
firmware reliability on this register is unvalidated; cf. evcc #28047.
Build (v2c.pro):
- MODBUS_CONNECTIONS intentionally empty: the modbus-tool code generator
assumes non-overlapping block reads; leaving it empty skips generation
while still linking nymea-modbus via the PKGCONFIG in modbus.pri.
VendorId 56c3e7bb… is new (no existing V2C vendor in the repo).
PluginId f0692725… is new (generated for this plugin).
PORTING_STATUS_modbus.md documents register sources, the 4 items that
require validation on real hardware, and the "no beta matrix" constraint.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
