From 1311c87d4e0af4ec5d972d0a549132a1266d2d66 Mon Sep 17 00:00:00 2001 From: cayossarian <23534755+cayossarian@users.noreply.github.com> Date: Sun, 13 Sep 2026 16:43:38 -0700 Subject: [PATCH 1/2] docs: name PV Nameplate Capacity and correct the adopted-entity delete rules The Solar table and the additional-inverter paragraph called the sensor "Nameplate Capacity", which is the battery's sensor. The PV one is named "PV Nameplate Capacity", beside PV Vendor and PV Product. The adopted-entity section said a deleted reading comes back while the panel still publishes it and stays gone once the panel stops. That missed the case where a later release models the reading: the panel keeps publishing, the integration stops adopting it, and the adopted entity is left behind until deleted, after which it does not return. The delete rules and their summary now turn on whether the reading is still adopted. --- README.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 3f43a274..b624a299 100644 --- a/README.md +++ b/README.md @@ -182,18 +182,18 @@ On **Import Limit**, and present only when the panel publishes them. These are t From 2.1.x these live on a **Solar** device of their own rather than on the panel's card, alongside PV Power and PV Panel Link. -| Sensor | Device Class | Unit | Notes | -| ------------------ | ------------ | ---- | ------------------------------------------------------------------------------------ | -| PV Vendor | — | — | PV inverter vendor (e.g., "Enphase", "Other") | -| PV Product | — | — | PV inverter product (e.g., "IQ8+") | -| Nameplate Capacity | — | W | DC array size recorded at installation; informational, never a limit. Off by default | +| Sensor | Device Class | Unit | Notes | +| --------------------- | ------------ | ---- | ------------------------------------------------------------------------------------ | +| PV Vendor | — | — | PV inverter vendor (e.g., "Enphase", "Other") | +| PV Product | — | — | PV inverter product (e.g., "IQ8+") | +| PV Nameplate Capacity | — | W | DC array size recorded at installation; informational, never a limit. Off by default | If you upgraded, these keep their entity ids, unique ids and history — but not the panel's area, since an entity takes its area from its device and the Solar device starts without one. Assign it an area, or anything area-scoped (dashboards, automations, voice targeting a room) stops matching them. New installations get ids from the new device name — `sensor.span_panel_solar_pv_vendor` rather than `sensor.span_panel_pv_vendor`. Both are correct and neither changes again. Each additional solar inverter (published from firmware r202639) gets a **Solar Inverter** device of its own, named after the circuit that feeds it where one -does, with its own PV Vendor, PV Product and Nameplate Capacity, and its PV Panel Link where the panel reports one. The PV entities on the **Solar** device +does, with its own PV Vendor, PV Product and PV Nameplate Capacity, and its PV Panel Link where the panel reports one. The PV entities on the **Solar** device never move: they keep describing the inverter they always did, beside PV Power, the panel's total. Where the panel cannot say which inverter they described — an inverter no circuit feeds, for example behind a Tesla Gateway, or several already reported when you upgraded — they describe all of your inverters together. An inverter device the panel no longer reports stays, unavailable, until you delete it. Each inverter's power is the power of the circuit that feeds it, which the @@ -438,16 +438,17 @@ Three things worth knowing before you build on one: own. - **What the delete button does**, since it is not quite what you would expect: - - Delete a reading while your panel is still publishing that property and it comes back — switched off — at the next reload, carrying whatever you curated for - it. Curation is keyed on the wire address rather than on the entity, so deleting the entity does not discard it. There is no setting to suppress the entity, - because leaving it switched off is already that. - - Delete one after your panel has stopped publishing it and it stays gone, because nothing exists to recreate it from. + - Delete a reading that is still adopted — your panel still publishes it and it has not been modeled since — and it comes back, switched off, at the next + reload, carrying whatever you curated for it. Curation is keyed on the wire address rather than on the entity, so deleting the entity does not discard it. + There is no setting to suppress the entity, because leaving it switched off is already that. + - Delete one after your panel has stopped publishing it, or after it has been modeled properly, and it stays gone, because nothing exists to recreate it from. -So deletion means "hide it until next time" for a live reading and "clear it out" for a dead one, and your panel decides which. +So deletion means "hide it until next time" for a reading that is still adopted and "clear it out" for one that no longer is. **These entities are permanent in id, not in identity.** If one of these readings is later modeled properly (delivered as an official part of the integration), -that entity is a new entity with its own id and its own history — the adopted one is not renamed into it. That is why a vendor reading you have come to depend -on is worth raising in an issue: being modeled is what turns it into something with a real name, a proper category and statistics out of the box. +that entity is a new entity with its own id and its own history — the adopted one is not renamed into it. The adopted one stops updating and is left behind +until you delete it. That is why a vendor reading you have come to depend on is worth raising in an issue: being modeled is what turns it into something with a +real name, a proper category and statistics out of the box. ### The Adopted Tab From 5317107811e596e33a793287994977ddae15c438 Mon Sep 17 00:00:00 2001 From: cayossarian <23534755+cayossarian@users.noreply.github.com> Date: Sun, 1 Nov 2026 09:53:03 -0800 Subject: [PATCH 2/2] docs(sensor): name PV Nameplate Capacity in the comment that keeps its name The comment explaining why the name never changes quoted "Nameplate Capacity", which is the battery sensor; the PV sensor is "PV Nameplate Capacity". --- custom_components/span_panel/sensor_definitions.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/custom_components/span_panel/sensor_definitions.py b/custom_components/span_panel/sensor_definitions.py index 03792711..59806721 100644 --- a/custom_components/span_panel/sensor_definitions.py +++ b/custom_components/span_panel/sensor_definitions.py @@ -1045,7 +1045,7 @@ class SpanPVMetadataSensorEntityDescription( entity_registry_enabled_default=False, # The array's DC size as recorded at installation: informational, and # never a limit on what `pv_power` can read. The name stays - # "Nameplate Capacity" because renaming it would change the entity id + # "PV Nameplate Capacity" because renaming it would change the entity id # every new installation derives. value_fn=lambda pv: pv.nameplate_capacity_w, ),