[MrCodeLabs]

Optionale Altersprüfung für verwendete Leistungswerte und optionale Zeitstempel der Datenquelle im bestehenden PV-Blueprint. Veraltete Werte überspringen die Übertragung. Die Wallbox kann dabei mit den zuletzt empfangenen Werten weiterarbeiten. Die Altersprüfung ist standardmäßig aus und die Sendeintervalle bleiben gleich.

183 lokale Prüfungen der Templates und Service-Aufrufe gegen den Blueprint dieses PRs bestanden. Die Prüfungen liefen außerhalb des PR-Branches. Home Assistant Core 2026.10.4 hat das Blueprint-Schema und die Eingaben bei deaktivierter und aktivierter Altersprüfung validiert. Geändert wird eine bestehende YAML-Datei. Ein Hardwaretest steht noch aus. Hassfest und HACS sind grün.

[marq24]

@OliEder could you please be so kind an review this PR - TIA (take your time)

[OliEder]

Danke für die Änderung, sie ist klein und folgt dem bestehenden Aufbau. Ich habe den Diff gelesen und die Templates aus variables: auf Home Assistant 2026.10.4 gerendert. Dabei habe ich upstream/main mit diesem Branch verglichen.

Geprüft

• Bei maximum_age_seconds: 0 sind measurements_valid, pgrid_watts, ppv_watts und pakku_watts identisch zu main, und measurements_fresh ist true. Ich habe neun Eingabekombinationen verglichen:

  • ein einzelnes Netz-Entity, auch invertiert und mit Multiplikator 1000
  • Bezug plus Einspeisung
  • drei Phasen, vollständig und unvollständig
  • Batterie aktiv
  • ein fehlendes Netz- oder PV-Entity

  Auch bei unavailable und unknown gibt es dieselben Ergebnisse wie in main.

• Altersprüfung mit 30 s Grenze:

  • Nach 20 s ist der Wert frisch, nach 31 s veraltet, bei genau 30 s noch frisch.
  • Ein veralteter Wert unter mehreren macht den ganzen Satz veraltet.
  • Ein Zustand, der mit gleichem Wert neu geschrieben wird, zählt als frisch.
  • Die Batterie wird nur geprüft, wenn sie aktiviert ist.
  • Ein fehlendes Entity ergibt "nicht frisch" und "nicht gültig".

• Zeitstempel-Sensoren: frisch, veraltet, unavailable, unknown und Unsinn verhalten sich wie erwartet. Bei zwei Sensoren genügt einer, der veraltet ist. Bei Grenze 0 werden sie ignoriert.

• last_reported gibt es ab HA 2024.3. min_version ist 2024.6.0 (Zeile 37), das passt.

Fragen

1. Zeile 290/295: 0 <= sampled_at - stamp weist auch Zeitstempel in der Zukunft ab. Eine Quelle, deren Uhr 2 s vorgeht, gilt als veraltet, und das Update fällt ohne Hinweis aus. Ist das so gewollt, oder soll es eine kleine Toleranz geben?
2. Zeile 91: Die Beschreibung der Zeitstempel-Sensoren sagt nicht, dass sie nur wirken, wenn maximum_age_seconds größer als 0 ist. Bei 0 werden sie still ignoriert. Ein kurzer Satz dazu wäre hilfreich.
3. Ein übersprungenes Update lässt die pvopt_*-Durchschnitte der Wallbox auf dem letzten Stand. Genau das beschreibt der Kopf des Blueprints als das Problem, das die Nullwerte in der Nacht lösen. Ist "überspringen" auch bei einem längeren Ausfall der Datenquelle am Tag die gewünschte Wirkung, oder sollten nach einer Weile Nullwerte gesendet werden? Ich bitte nicht um eine Änderung, mich interessiert nur, ob das eine bewusste Entscheidung ist.
4. Kleinigkeit: sample.value in power_samples funktioniert, sample['value'] wäre klarer.

Nicht geprüft

• Gerendert habe ich nur den Abschnitt variables:. Trigger, choose-Bedingungen und der Aufruf von set_pv_data liefen nicht.
• Ich habe den Blueprint nicht in der Oberfläche geladen und verlasse mich auf den verlinkten Hassfest-Lauf.
• Es gab keinen Test an einer echten go-eCharger oder mit einer echten Wechselrichter-Integration. Das gilt wie beim PR auch hier.

KI-Hinweis: "Ich habe Claude Code benutzt, um die Templates zu rendern und diesen Kommentar zu entwerfen. Die Prüfungen oben wurden ausgeführt und die Ergebnisse von mir gelesen."

[OliEder]

Nachtrag zu meinem Kommentar oben: Ich habe zusätzlich deine Tests angeschaut und ausgeführt, und deshalb ändert sich eine Rückfrage.

Was ich gemacht habe

• Ich habe deinen Fork lokal geklont (Branch feat/pv-freshness-confirmation, dort liegt tests/blueprints). Auf dem Branch feat/pv-measurement-freshness-current von Add optional measurement age checks to the PV blueprint #189 gibt es diese Tests nicht, und in Add optional measurement age checks to the PV blueprint #189 selbst auch nicht. Die im PR-Text genannten 180 Prüfungen stammen also von dem anderen Branch.
• Alle Tests auf deinem Branch laufen durch (215 grün). Dabei musste ich -o asyncio_mode=auto setzen, sonst melden alle Tests einen Fehler, weil das HA-Plugin aus requirements_dev.txt eine Async-Fixture mitbringt. Das ist nur ein Hinweis auf die Konfiguration, kein Fehler im Test.
• Dann habe ich nur tests/blueprints gegen den Blueprint aus Add optional measurement age checks to the PV blueprint #189 laufen lassen: 185 grün, 8 rot. Die 8 sind genau die Tests zu last_success_helper, night_mode und transmission_interval. Diese Eingaben gibt es in Add optional measurement age checks to the PV blueprint #189 nicht, das ist also erwartet.
• Zum Gegencheck habe ich acht Fehler absichtlich in die Altersprüfung des Blueprints eingebaut und geschaut, ob deine Tests anschlagen.

Ergebnis

• Erkannt werden fünf von acht Fehlern: Bedingung ohne measurements_fresh, < statt <= bei den Messwerten, Zeitstempel in der Zukunft erlaubt, Zeitstempel-Sensoren ignoriert und Netz nicht geprüft.
• Nicht erkannt werden drei Fälle, davon zwei relevant:
  1. Eine ausgeschaltete Batterie wird trotzdem auf das Alter geprüft. Es gibt keinen Test mit ausgeschalteter, veralteter Batterie. In meinem Lauf mit echtem HA verhält sich der Blueprint hier richtig.
  2. Die Grenze < statt <= bei den Zeitstempel-Sensoren. Die Testwerte (70 s, 400 s, +20 s) liegen weit von der Grenze entfernt, die Grenze selbst prüft kein Test. Bei den Messwerten wird sie geprüft (75 s).
  3. Ein Messwert ohne last_reported würde als frisch gelten. Das ist im Harness nicht erreichbar, weil er immer einen Wert liefert, und in echtem HA hat jeder Zustand einen. Ich nenne es nur der Vollständigkeit halber.

Änderung meiner Rückfrage 1

• Ich hatte gefragt, ob die Ablehnung von Zeitstempeln in der Zukunft so gewollt ist. Deine Tests zeigen, dass sie gewollt ist: test_report_age_boundary weist −1 s ab, test_source_clock einen Zeitstempel 20 s in der Zukunft. Die Frage ist damit nur noch, ob du eine kleine Toleranz für leicht vorgehende Uhren möchtest. Wenn nicht, wäre ein Satz in der Beschreibung des Felds hilfreich, dass Zeitstempel in der Zukunft als veraltet gelten.

Optional, nur für deinen Fork

• Zwei kleine Tests würden die Lücken oben schließen: eine ausgeschaltete, veraltete Batterie, und ein Zeitstempel-Sensor genau auf der Grenze. In das Repo von marq24 gehören sie meiner Ansicht nach nicht, dort bleiben Tests im Fork.

Grenzen dieser Prüfung

• Dein Harness ist kein echtes Home Assistant, sondern eine eigene Jinja-Sandbox mit nachgebauten states, is_number, as_timestamp und now. Meine Läufe in echtem HA und deine Tests ergänzen sich, ersetzen sich aber nicht.
• Weiterhin nichts an einer echten go-eCharger und nichts über die Oberfläche geladen.

KI-Hinweis: "Auch dieser Nachtrag ist mit Claude Code entstanden: Der Fork wurde mit Claude Code geklont und die Tests und die Fehlerprobe damit ausgeführt, die Ergebnisse habe ich gelesen."

[OliEder]

schau dir bitte die anderen Kommentare kurz an.
btw: @MrCodeLabs ich habe deinen Harness mal angeschaut. Ich mache ähnliches und baue gerade einen größer dimensionierten: https://github.com/OliEder/ha-blueprint-test-harness vielleicht magst du ihn dir ja mal anschauen.

[MrCodeLabs]

Hi @OliEder,

danke dir für dein ausführliches Feedback und den Link zu deinem Harness-Projekt! Sieht echt interessant aus, das werde ich mir in den nächsten Tagen auf jeden Fall mal genauer anschauen. :)

Aktuell ist bei mir beruflich und privat ziemlich viel los, deshalb komme ich leider nicht so oft dazu, an dem Projekt weiterzuarbeiten, wie ich gerne würde.

Deine Kommentare habe ich aber auf dem Schirm! Ich möchte mir die Punkte erst in Ruhe anschauen und durchgehen, bevor ich darauf eingehe.

Ist also nichts vergessen, dauert nur gerade alles ein bisschen länger als geplant. :)

Danke dir für deine Zeit und Unterstützung!

[MrCodeLabs]

Hi @OliEder,

danke dir fürs gründliche Review und dafür, dass du die Tests auch mit absichtlich eingebauten Fehlern ausprobiert hast!

• Zeitstempel: Zeitstempel aus der Zukunft werden weiterhin ohne Toleranz abgelehnt. Im aktuellen Commit steht das jetzt ausdrücklich drin. Die Beschreibung sagt auch, dass die optionalen Zeitstempel-Sensoren nur bei maximum_age_seconds > 0 geprüft werden. sample['value'] habe ich ebenfalls übernommen.
• Datenausfall am Tag: Das Überspringen ist bewusst so gewählt. Die Wallbox kann dabei weiter mit den zuletzt empfangenen Werten arbeiten. Sobald wieder gültige und frische Messwerte vorliegen, sendet der Blueprint wieder. Ob und wann man bei einem längeren Ausfall Nullwerte senden sollte, würde ich separat besprechen.
• Tests im Fork: Die beiden Fälle habe ich lokal ergänzt. Eine deaktivierte Batterie wird auch mit einem alten Messwert ignoriert. Ein Quellzeitstempel wird bei genau 75 Sekunden noch akzeptiert und bei 76 Sekunden verworfen. Beide Tests erkennen den jeweiligen absichtlich eingebauten Fehler. Die ursprünglich genannten 180 Checks waren lokale Prüfungen gegen den Blueprint aus Add optional measurement age checks to the PV blueprint #189. Beim Lauf mit der breiteren Testsuite hatte ich dieselben acht erwarteten Fehlschläge für Funktionen außerhalb des PRs.

@marq24, wenn du Zeit hast, könntest du dir den aktualisierten PR anschauen? Hassfest und HACS sind auf dem neuen Commit grün.

[MrCodeLabs]

Hi @OliEder,

ich habe mir deinen Harness nach deinem Hinweis hier im PR genauer angeschaut, vor allem die daylight_heartbeat-Tests. Schön zu sehen, dass aus dem Ansatz unserer go-e-Tests ein Werkzeug für ganz unterschiedliche HA-Automationen geworden ist. Danke auch für die Erwähnung in der README!

Ich probiere ihn parallel zu den beiden go-e-PRs auf einem eigenen Testzweig im Fork aus. Mich interessieren zuerst zwei Fälle: ob der Blueprint tagsüber bei veralteten Messwerten aussetzt und bei frischen Werten wieder sendet, und ob die Nullwerte bei Sonnenuntergang wie erwartet rausgehen.

Ich gebe dir gern Rückmeldung, wie es läuft. Falls sich dabei eine Verbesserung ergibt, die auch anderen hilft, würde ich sie gern bei dir beitragen.