No rule for device-id continuity when one device becomes several, so adopting the multi-load split orphans metering history

[cayossarian]

Summary

devices/circuit.md §"Multi-load breakers (tandem and quad)" models a package as a feed circuit plus one load circuit per load. A publisher that ships a package as a single circuit today and adopts that model later turns one device into several. The specification does not say which of the resulting devices, if any, keeps the original device id — and consumers key durable state on that id.

The situation

A publisher not yet implementing the multi-load model publishes a tandem or quad as one circuit device: one meter, one switch, one breaker with a single rating. That is a reasonable tree — nothing in the specification requires the split, and circuit.md describes it as how the hardware is modelled rather than as a conformance requirement.

Adopting circuit.md:159-176 later replaces that one device with:

• a feed circuit carrying the meter, the switch and the info/spaces footprint, and
• one load circuit per load carrying info and its own breaker.

One device becomes N+1. The framework has no statement about what happens to the original device id when that occurs.

Why the id matters

Homie device ids are the stable handle consumers build durable state on. In practice that state includes long-run energy accumulation keyed to a device, user-facing entity identity, and per-device configuration a user has set. framework.md treats the device id as an identity rather than an address, which is what makes it usable that way.

For a multi-load package the outcome is not symmetric:

• If the feed inherits the id, the metering history stays attached to the device that still publishes meter, and the loads are new devices carrying only protection data — which is what they are.
• If a load inherits it, the history follows a device that no longer publishes meter at all, and the aggregate readings appear on a new id.
• If none does, the package's accumulated energy is orphaned and cannot be reattached, because nothing in the tree relates the new devices to the retired id.

Only the first is lossless, and a consumer cannot infer which occurred: after the split it sees a device that vanished and several that appeared, with connection/fed-by-device-id relating the new devices to each other but not to the old one.

Scope

This is not specific to multi-load breakers — it is the general question of device-identity continuity when a publisher re-models existing hardware into a different device shape. Multi-load breakers are simply the case the specification has now defined a target shape for, so it is the case where the transition is foreseeable and can be specified before publishers make divergent choices.

A related asymmetry already exists in the specification: capabilities/connection.md relates devices that coexist, and nothing relates a device to one it replaced.

Proposed resolution

Any of these would close it; the choice is the maintainers'.

1. State the rule for the multi-load split specifically in devices/circuit.md: the feed circuit SHOULD inherit the device id of the circuit it replaces, since it inherits the meter and the footprint. This is the smallest change and resolves the foreseeable case.
2. State a general rule in framework.md for re-modelling: when one device becomes several, the device that retains the metering point retains the id.
3. Provide a supersession record — a property on a new device naming the device id it replaces — so a consumer can reattach durable state without a convention. More general and more expensive; probably only worth it if re-modelling is expected to recur.

Option 1 is enough for the case at hand. Option 2 costs little more and would cover the next re-modelling without another issue.