Sensoren ändern weil Total != String1 + String2

Solar Forecast ML Einrichtung & Hilfe
1

Ich möchte gerne meine Sensoren umstellen und hätte gerne eure Meinung, vor allem von Zara.

Ich habe diese Sensoren:
DC Total aus Huawei

  • Vorteil: Zeigt an, sobald Solarstrahlung die Zellen erreicht
  • Nachteil: Ist nicht konsistent zu der Summe der beiden Strings
    DC Total Calculated vom Solarteure
  • Vorteil: ist konsistent zur Summe der beiden Strings (rechnet String1 + String2)
  • Nachteil: Zeigt erst später an, springt am Anfang von 0 auf ca. 200-300W, weil Strings erst ab 0.2A etwas anzeigen.

DC String 1 und 2 aus Huawei

  • Vorteil: zeigt die zur Verfügung stehende Leistung an
  • Nachteil: zeigt erst etwas an, wenn der Strom 0.2A überschreitet → Am Anfang ein Sprung auf ca. 100-150W

Was will ich erreichen?

  • SFML mit korrekten Sensoren bedienen, vor allem wegen Konsistenz von Total = string1 + String2
  • Schatten der beiden Strings beobachten können (Sommer Kamin bei String1; Winter Bäume bei String2)

Ich sehe zwei Lösungen:

  • den Total calculated mit String1/String2 zu benutzen
    bedeutet jedoch, das am Anfang/Ende immer ein Sprung entsteht und SFML fälschlicherweise die Sensoren als AC-Sensoren detektieren könnte.
  • Die Strings selber zu berechnen, das scheint mir die bessere Lösung zu sein.

Lösung zwei würde ich folgendermassen umsetzen:
Differenz = Total - String1 - String2 //gibt mir eine Abweichung von Total zu der Summe beider Strings zurück.
Dann die beiden Strings neu berechnen:
String1 = String1 + Differenz * 0,444 // Die Differenz zum String1 anteilig addieren (16 Module)
String2 = String2 + Differenz * 0,556 // Die Differenz zum String2 anteilig addieren (20 Module)

Vorteil dieser Lösung:

  • Schatten geht korrekt bei den beiden Strings mit ein
  • Total ist konsistent zu den beiden Strings
  • String1 und String2 steigen bereits am Anfang an langsam mit an.

Nachteil dieser Lösung:

  • eine kleine Ungenauigkeit in der wirklich erzeugten Solarleistung in Bezug auf dem Inverter (ca. <1%)

Da es hier jedoch um die Prognose geht und nicht die erzeugte Energie - was dann ja auch AC wäre - kann ICH den Nachteil gut verschmerzen.

Wie sieht es aber dann mit SFML aus? @Tom-HA , macht das Sinn? Kann meine jetzige Konfiguration für die Buckel mit ursächlich sein?

Zur Verdeutlichung ein Ausschnitt von heute morgen:

image
image1631×566 50.9 KB

Bisher benutze ich die blaue Linie als Total und die orangene und Grüne für die Strings.
Neu würde ich die blaue beibehalten und die rosa und Lilane für die Strings benutzen.

Gruß Ralf

1 „Gefällt mir“
2

Hi @Tom-HA ,

den Fragen von @alteMade möchte ich mich anschließen.
Ich habe heute morgen das log nach warnings durchsucht.

custom_components.solar_forecast_ml.data.data_panel_group_sensor_reader - WARNING - Panel group learning disabled for this hour: group sum 0.600 kWh does not match DC yield 0.500 kWh. Please verify that all panel group sensors and the yield sensor measure the same DC energy basis in kWh, use the same time window, and do not overlap.

Solche Meldungen habe ich ab und an, insbesondere am frühen Morgen und am späten Abend.
Zwei Entitäten die ich verwende stammen direkt aus der Kostalintegration, nur der PV1+2täglich ist ein Verbrachszähler aus dem PV Total Zähler der Kostalintegration.
Allerdings stimmen die Zeitpunkte nicht überein. Die rote Linie müsste ja immer wenn blau oder gelb steigen, ebenfallls eine Treppenstufe bilden. Tut sie aber nicht.

Was ich auch nicht verstehe der Eintrag im log ist von 9:05 Uhr und führt 0.5 und 0.6 kWh auf. Die screenshots zeigen aber 0.6, 0.5 und 1.00

Screenshot 2026-05-20 at 11-06-35 Verlauf – Home Assistant
Screenshot 2026-05-20 at 11-06-35 Verlauf – Home Assistant1643×595 21.8 KB

WhatsApp Image 2026-05-20 at 11.09.30
WhatsApp Image 2026-05-20 at 11.09.302040×1536 383 KB

Kostal kann ich ja nicht intelligenter machen. Wäre es jetzt nicht besser statt dem PV1+2täglich einen template Sensor zu verwenden, erstellt aus der Summe von PV1 day + PV2 day?

Gruß Stefan

3

Hallo Ralf,

Kurz und knapp: Ja, das macht grundsätzlich Sinn!

Für SFML ist nicht der ganz frühe kleine Anstieg das Wichtigste, sondern dass die Werte sauber zueinander passen.
Also: Total und Strings müssen dieselbe Grundlage haben und zusammen stimmig sein, vor allem wenn es um String-Verhalten, Schatten und das Lernen der Gruppen geht.

Deshalb sehe ich deine Überlegung ähnlich wie du:

Die Variante mit DC Total Calculated plus den beiden Huawei-Strings ist zwar auf den ersten Blick sauber, hat aber den Nachteil, dass die Strings morgens und abends erst verspätet anspringen.
Damit verlierst du genau in der Phase etwas Information, die für die Beobachtung von Schatten und weichem Tagesbeginn eigentlich interessant ist. → SFML hat extre Berechnungen für Twilight-Stunden, die dann zickig werden könnte.

Daher ist die zweite Idee der bessere Ansatz:
Also die beiden Strings so zu korrigieren, dass sie zusammen sauber zum Total passen, aber trotzdem ihr jeweiliges Verhalten behalten.
Der Vorteil daran ist, dass SFML dann konsistente Werte bekommt und gleichzeitig die Unterschiede zwischen String 1 und String 2 sichtbar bleiben. Genau das ist für die Schattenbetrachtung wichtig und löst das Problem nachhaltig und ist das was Du möchtest.

Der kleine Nachteil mit der leichten rechnerischen Ungenauigkeit halte ich dabei für vertretbar. Wir reden hier nicht über eine geeichte Abrechnung, sondern über eine Prognose- und Lernbasis. Wenn du damit auf rund 1-2 Prozent Abweichung bleibst, ist das aus deutlich weniger problematisch als inkonsistente Sensoren.

Zu deiner Frage wegen der Buckel:
Ja, das kann durchaus ein Grund sein. Wenn Total und Strings nicht sauber zusammenpassen, ist das für SFML keine ideale Datengrundlage. Dann können unsaubere Effekte entstehen. Daher ist es plausibel, dass die aktuelle Konstellation dazu beiträgt. Ich hatte mir das ja schon mal angesehen, aber Probleme das zu reproduzieren.

Fazit

  • Wenn du bei SFML mit String-Sensoren arbeiten willst, ist Konsistenz wichtiger als der “perfekte originale” Einzelwert.
  • Für dein Ziel mit Schattenbeobachtung ist die zweite Lösung deutlich sinnvoller.
  • Die Strings künstlich so anzupassen, dass sie zusammen wieder sauber dem Total entsprechen, ist in diesem Fall aus meiner Sicht legitim, solange der Unterschied max 1-2% beträgt.-> Das ist aber ein Wert ins Blaue geraten!
  • Grundsätzlich: Iieber eine kleine, kontrollierte Rechenkorrektur als dauerhaft widersprüchliche Sensorwerte.

Wenn du es möglichst einfach halten willst, wäre meine Empfehlung also:
Nimm die Lösung, bei der String 1 und String 2 so korrigiert werden, dass die Summe wieder sauber zum Total passt und die String-Unterschiede trotzdem erhalten bleiben.

Ich bin sehr gespannt!!!

1 „Gefällt mir“
4

Hallo Stefan,
Ja das macht 100% Sinn. Die Abweichungen sind zwar Minimal, aber summieren sich natürlich in ein Muster auf. Entscheidet ist hier nicht der Wert selber, sondern die prozentuale Abweichung! Die ist gerade bei kleinen Werten enorm.
Diese Abweichungen kommen meistens von HA selbst (Rundungsfehler, Zeitmuster, Aktualisieungen, Delta, ..) im Kontext mit Werten aus der benutzen Integration selbst.
Dein Vorschlag den “Yield-Sensor” aus den beiden Gruppensensoren zu bilden ist eine saubere Lösung! würde für die von Dir beschriebene Stunde 10% der Fehler auf einen Schlag eleminieren!
→ Ich hatte das selbe Problem, als ich die orgiginalen Anker Sensoren genommen habe… katastrophe! Ich addiere mittels der HA eigenen SQL Integrationen die Gruppenwerte direkt aus der HA DB und im selben Atemzug erstelle ich daraus einen Riemann.. seit dem ist Ruhe. Weiterer Vorteil: Sensorausfälle und Co werden besser kompensiert.

Hier der SQL-Code.. den Du natürlich anpassen musst:

Riemann Gruppe 2 als Beispiel bei mir:

WITH riemann_calc AS (
  SELECT 
    CAST(state AS DECIMAL(10,2)) as watt,
    last_updated_ts,
    LEAD(last_updated_ts) OVER (ORDER BY last_updated_ts) as next_ts
  FROM states
  WHERE metadata_id = 53
    AND FROM_UNIXTIME(last_updated_ts) >= CURDATE()
    AND state NOT IN ('unknown', 'unavailable')
    AND state REGEXP '^[0-9]+(\\.[0-9]*)?$'
)
SELECT 
  ROUND(COALESCE(SUM(
    watt * 
    (COALESCE(next_ts, last_updated_ts + 300) - last_updated_ts) / 3600.0 / 1000.0
  ), 0), 2) as state
FROM riemann_calc
WHERE watt >= 0;

Das ergibt einen sauberen Riemann ohne Lücken und resistent..

1 „Gefällt mir“
5

ich hab auch eine huawei anlage und nur einen gesamt dc. darum berechne ich meine strings aus v und a der strings und addiere sie zu gesamt:

  - sensor:
      - name: PV-String Ost Watt
        unique_id: pv_string_ost_watt
        unit_of_measurement: W
        device_class: power
        state_class: measurement
        icon: mdi:solar-panel
        state: >
          {% set v  = states('sensor.wechselrichter_pv_1_spannung') | float(0) %}
          {% set a  = states('sensor.wechselrichter_pv_1_strom')    | float(0) %}
          {{ (a * v) | max | round(0) }}

        availability: "{{ true }}"

  - sensor:
      - name: PV-String West Watt
        unique_id: pv_string_west_watt
        unit_of_measurement: W
        device_class: power
        state_class: measurement
        icon: mdi:solar-panel
        state: >
          {% set v  = states('sensor.wechselrichter_pv_2_spannung') | float(0) %}
          {% set a  = states('sensor.wechselrichter_pv_2_strom')    | float(0) %}
          {{ (a * v) | max | round(0) }}

        availability: "{{ true }}"

  - sensor:
      - name: PV-Strings Gesamt Watt
        unique_id: pv_strings_gesamt_watt
        unit_of_measurement: W
        device_class: power
        state_class: measurement
        icon: mdi:solar-panel
        state: >
          {% set a  = states('sensor.pv_string_ost_watt') | float(0) %}
          {% set b  = states('sensor.pv_string_west_watt') | float(0) %}
          {{ (a + b) | max | round(0) }}

        availability: "{{ true }}"
1 „Gefällt mir“
6

Das ist smart, so verhinderst Du, dass sie auseinander driften!! Clever!!!

7

Ich habe einfach die Sensoren der beiden Strings in einem template Sensor addiert.
Alle anderen Methoden sind mir zu schwierig :see_no_evil_monkey:

Ich glaube das geht.
{{ states('sensor.kostal_wechselrichter_energy_pv1_day') | float(0)
 + states('sensor.kostal_wechselrichter_energy_pv2_day') | float(0) }}
1 „Gefällt mir“
8

Klar, das ist eigentlich genau das Gleiche :slight_smile:

1 „Gefällt mir“