Summary
connection can say that a downstream node is not an eBus device. It cannot say the same about an upstream one. That asymmetry is not merely untidy: combined with the conditional in power-flows, it leads a conformant consumer to a wrong conclusion about a common topology.
The asymmetry
Downstream has an escape hatch:
feeds-role — Summary role of a downstream node that is not published as its own eBus device, or that is surveyed-empty: LOADS, SUBPANEL, SOLAR, STORAGE, GENERATOR, MIXED, UNUSED. … Complements feeds-device-*, which is used when the downstream is an eBus device.
Upstream has none. The only upstream references are the fed-by-* triplet, and both usable members require the upstream device to be on the bus:
fed-by-device-id — Homie device ID of the device wired upstream … Omitted when the upstream side is the utility, an implicit busbar, or unknown.
fed-by-device-type — $description.type of the upstream device. Published with fed-by-device-id.
So a publisher fed by a device that is not an eBus device — a conventional panel, another vendor's equipment, an upstream DER with no eBus presence — has nothing to publish. It must omit, and omission is defined to mean something else.
Why this produces a wrong answer rather than a missing one
power-flows.md makes grid conditional on topology and tells a consumer how to detect that topology:
grid holds only where the service lugs are the utility connection point. Two common topologies break that: an upstream DER … and an enclosure chain, where this enclosure is fed by another rather than by the service. … A consumer must not derive one from the other without knowing the topology, which it can read from the lugs device's connection node: fed-by-device-id names the intervening device when there is one.
That instruction assumes the intervening device is nameable. When it is not, the publisher omits fed-by-device-id, and the documented reading of that absence includes "the upstream side is the utility". A consumer following both documents therefore concludes the lugs are the utility connection point, and derives grid by negating the lugs reading — which power-flows.md explicitly says is wrong in exactly this topology.
The failure is silent and produces a plausible number. Nothing in either document is individually incorrect; the gap is only visible when they are read together.
Note the downstream side does not have this problem: a consumer meeting feeds-role = SUBPANEL knows there is a downstream panel even though it has no device id to follow.
Proposed shape
Three options, in rough order of preference.
-
fed-by-role, mirroring feeds-role. Summary role of an upstream node that is not published as its own eBus device. A candidate value set: UTILITY, PANEL, STORAGE, SOLAR, GENERATOR, MIXED, UNKNOWN. Symmetric with the downstream side, and a reader who has understood feeds-role needs no new concept.
-
Let fed-by-device-type stand alone, dropping "Published with fed-by-device-id". A publisher could then say "an enclosure feeds me" without naming it. Smaller change, but it does not express "the utility feeds me", since the utility is not a device type, so it only half closes the gap.
-
A narrow boolean such as fed-by-utility. Directly fixes the power-flows collision and nothing else. Cheapest, and least useful to anything that comes later.
Whichever is chosen, the requirement the power-flows conditional actually needs is a way to distinguish "I am fed directly by the utility" from "I am fed by something I cannot name". Today both are spelled as absence, and only the first is a safe basis for the grid derivation.
A note on UNUSED's analogue: feeds-role carries UNUSED to positively record "surveyed, nothing connected", which has no upstream meaning — anything energized is fed by something — so an upstream role set does not need it.
(This surfaced while implementing a publisher for an enclosure that sits behind another panel rather than at the service entrance, and finding no way to say so. It is framed here vendor-neutrally: any publisher in an enclosure chain, or behind equipment that is not on the bus, has the same gap.)
Summary
connectioncan say that a downstream node is not an eBus device. It cannot say the same about an upstream one. That asymmetry is not merely untidy: combined with the conditional inpower-flows, it leads a conformant consumer to a wrong conclusion about a common topology.The asymmetry
Downstream has an escape hatch:
Upstream has none. The only upstream references are the
fed-by-*triplet, and both usable members require the upstream device to be on the bus:So a publisher fed by a device that is not an eBus device — a conventional panel, another vendor's equipment, an upstream DER with no eBus presence — has nothing to publish. It must omit, and omission is defined to mean something else.
Why this produces a wrong answer rather than a missing one
power-flows.mdmakesgridconditional on topology and tells a consumer how to detect that topology:That instruction assumes the intervening device is nameable. When it is not, the publisher omits
fed-by-device-id, and the documented reading of that absence includes "the upstream side is the utility". A consumer following both documents therefore concludes the lugs are the utility connection point, and derivesgridby negating the lugs reading — whichpower-flows.mdexplicitly says is wrong in exactly this topology.The failure is silent and produces a plausible number. Nothing in either document is individually incorrect; the gap is only visible when they are read together.
Note the downstream side does not have this problem: a consumer meeting
feeds-role = SUBPANELknows there is a downstream panel even though it has no device id to follow.Proposed shape
Three options, in rough order of preference.
fed-by-role, mirroringfeeds-role. Summary role of an upstream node that is not published as its own eBus device. A candidate value set:UTILITY,PANEL,STORAGE,SOLAR,GENERATOR,MIXED,UNKNOWN. Symmetric with the downstream side, and a reader who has understoodfeeds-roleneeds no new concept.Let
fed-by-device-typestand alone, dropping "Published withfed-by-device-id". A publisher could then say "an enclosure feeds me" without naming it. Smaller change, but it does not express "the utility feeds me", since the utility is not a device type, so it only half closes the gap.A narrow boolean such as
fed-by-utility. Directly fixes thepower-flowscollision and nothing else. Cheapest, and least useful to anything that comes later.Whichever is chosen, the requirement the
power-flowsconditional actually needs is a way to distinguish "I am fed directly by the utility" from "I am fed by something I cannot name". Today both are spelled as absence, and only the first is a safe basis for thegridderivation.A note on
UNUSED's analogue:feeds-rolecarriesUNUSEDto positively record "surveyed, nothing connected", which has no upstream meaning — anything energized is fed by something — so an upstream role set does not need it.(This surfaced while implementing a publisher for an enclosure that sits behind another panel rather than at the service entrance, and finding no way to say so. It is framed here vendor-neutrally: any publisher in an enclosure chain, or behind equipment that is not on the bus, has the same gap.)