PV-strings

Sluit #312. Geleverd in drie fasen — v1.7.0 (gegevens) → v1.7.1 (kaarten) → v1.7.2 (documentatie + afwerking van de release).

Wat je krijgt

Biedt je omvormer sensoren per string en vindt de automatische ontdekking in het entiteitenregister ≥ 2 strings, dan maakt SEM per string twee nieuwe entiteiten aan:

sensor.sem_pv_string_pv1_power         # W,  MEASUREMENT
sensor.sem_pv_string_pv1_daily_energy  # kWh, TOTAL, daily-reset

sensor.sem_pv_string_pv2_power
sensor.sem_pv_string_pv2_daily_energy
                  …                    # up to pv4 (discovery cap)

Zet ze in Lovelace in een grafiek, stel er meldingen op in, of bekijk ze op de eigen stroomkaarten van SEM — zijn er ≥ 2 strings, dan tonen de drie stroom- kaarten (sem-flow-card, sem-solar-card, sem-system-diagram-card) automatisch een strook met labels per string:

[ PV1  5.20 kW ]  [ PV2  3.10 kW ]      ← chips above the main card content
   existing card body unchanged

Installaties met één string zien er pixel voor pixel hetzelfde uit als v1.6.x — geen nieuwe entiteiten, geen kaartwijzigingen.

Ondersteunde omvormermerken

De automatische ontdekking zit in hardware_detection.discover_pv_strings_from_registry en herkent deze naampatronen voor entiteiten:

Staat je merk er niet bij maar gebruikt het een van die patronen, dan werkt de ontdekking al — er is geen codewijziging in SEM nodig. Gebruikt het een ander patroon, meld dan een GitHub- issue met je entiteit-ID’s en we voegen de regex toe.

Terugval: samenstellen uit V+I

Sommige integraties bieden spanning en stroom per string, maar geen vermogen — meestal drivers op basis van Modbus. Het meest voorkomende geval onder SEM-gebruikers is Huawei Solar Modbus, dat sensor.inverter_pv_1_spannung (V) en sensor.inverter_pv_1_strom (A) per string publiceert maar geen pv_1_power.

SEM regelt dit automatisch. Na de ontdekking van directe vermogenssensoren loopt een parallelle hardware_detection.discover_pv_string_vi_pairs hetzelfde register af op zoek naar bij elkaar horende V+I-paren die passen bij:

Wordt voor plek N een volledig V+I-paar gevonden, dan vermenigvuldigt SEM bij het uitlezen V × I om de watts per string samen te stellen. De afnemers verderop (kaarten, energieteller, som-invariant) weten niet hoe de waarde is verkregen.

Conflicten oplossen: heeft dezelfde plek ZOWEL een directe vermogenssensor ALS een V+I-paar, dan wint de directe vermogenssensor. Dat is een echte meting; het samenstellen uit V+I is een berekende terugval, iets minder nauwkeurig omdat het de eigen MPPT-rendementsberekening van de omvormer niet meeneemt.

Hoe de ontdekking werkt

1. De ontdekking draait één keer bij het instellen van de integratie (SEMCoordinator.async_initialize_energy_dashboard).
2. De zaadentiteit is je bron voor zonnevermogen uit de configuratie van het Energie- dashboard van HA (energy_dashboard.solar_power).
3. SEM loopt het entiteitenregister af op zoek naar bijbehorende sensoren — hetzelfde platform (bijv. huawei_solar) en dezelfde config_entry_id als het zaadje.
4. Elke bijbehorende sensor wordt vergeleken met de regexen per omvormermerk hierboven.
5. Er worden maximaal 4 treffers bewaard (de ontdekkingsgrens komt overeen met het aantal plekken van de K-Flow-kaart en dekt elke omvormer met meerdere strings die we kennen).

Wat als ik mijn strings niet zie?

Controleer, in deze volgorde:

1. Het zaadje bestaat — stelt je Energie-dashboard van HA een zonnebron in? De ontdekking begint daar. Instellingen → Dashboards → Energie → Zonneproductie.
2. De strings zitten in dezelfde integratie als het zaadje — heb je bijvoorbeeld een Huawei-omvormer als zonnebron en een aparte sensor.solar_string_1_power uit een handmatige template, dan komt het platform niet overeen en slaat de ontdekking hem over.
3. Het patroon past — je entiteit-ID hoort iets te bevatten als pv1_power, mppt1_power, dc_power_1, tracker_1_power of string_1_power. Controleer de echte entiteit-ID in Ontwikkelhulpmiddelen → Toestanden van HA.
4. Je hebt er minstens 2 — len < 2 wordt tegengehouden; een installatie met één string maakt geen sensoren per string aan.
5. De ontdekking heeft gedraaid — zoek in home-assistant.log naar Per-PV-string discovery found N strings. Zie je die regel niet, dan ontbreekt het zaadje of is de integratie van het Energie-dashboard na SEM geladen.

Intern

Som-invariant vastgelegd in tests/test_per_string_energy.py: sum(solar_power_per_string.values()) ≈ solar_power binnen afronding.

Gedrag van een string in rust

Zodra een string in de teller verschijnt, blijft hij zichtbaar tot de dagwisseling (lokale middernacht). Een wolk die midden op de dag één paneel- veld beschaduwt, zet de zichtbare teller niet terug naar 0 — hetzelfde gedrag dat SEM gebruikt voor stromen per laadpaal.

Wat (nog) niet in de scope zit

• Toerekening per string naar bestemming (“PV1 → huis, PV2 → batterij”) — strings zijn bronnen; de evenredige verdeling zou nuttig zijn, maar de gebruiker vroeg alleen om zichtbaarheid per string. Meld een issue als je dit nuttig zou vinden.
• Kosten / besparingen per string — SEM houdt besparingen op systeemniveau bij; rendement per string zou een kostenbasis per string vereisen (panelen-op-deze-string × prijs). Buiten de scope.
• Solcast-voorspelling per string — Solcast accepteert meerdere locaties, maar de voorspellingsverwerking van SEM zou vlakken aan strings moeten koppelen. Aparte functie.

Zie MULTI_CHARGER.md (Engels) voor het symmetrische patroon aan de bestemmingskant (toerekening van stromen per laadpaal).