Hat sich überschnitten, habe erst hier geantwortet, und dann im Beta Forum 
Frag mal bitte einen Beta-Key an, das macht es einfacher, zumal ich gerade die ganze Sigenergy Serie einbaue. Dann bekommst du im Forum den Zugang, und wir können für deine Anlage einen eigenen Thread machen, und spamen diesen hier nicht so voll
Auch für dich, frag mal einen Beta-Key an, dann kann ich sowohl Debug Daten sehen, als auch du im Forum einen extra Thread für deine Anlage aufmachen.
Ich habe deine Anwendung aber ähnlich bei mir umgesetzt mit meinem Deye.
Hallo, kurze Frage, wie heißt die Integration (Screenshot) von Mkaiser?
@wurstblinker
Ich verwende die Integration von “mkaiser”.
Da mir die bei mkaiser vordefinierten Power Flows nicht gefallen haben (z.B. weil man keine 3 MPPTs) anzeigen konnte, verwende ich die “Sunsynk-Power-Flow-Card”. Die Yaml dafür mit den referenzierten Werten aus der mkaiser Integration kann ich bei Bedarf gern zur Verfügung stellen.
Finde ich aus mehreren Gründen einfach schade… kein Fork, kein User bezogener Container Build, … ist halt so.
1 „Gefällt mir“
Danke dir, mit der Bezeichnung der Card komme ich zurecht. 
@echnaton
Hallo Markus, ich glaube, dass ich nun die meisten Entitäten sauber eingetragen habe. Im Beta Forum ist ein Screen Shot abgelegt.
Ich hätte nur eine Bitte/Idee:
Könntest du die Doku auch im Beta Forum ablegen oder verlinken? Da gibt es bestimmt eine Rubrik “Dokumentation”.
Gruß
Martin
Hallo @echnaton,
ich glaube, Claude hat an der Stelle ein paar Dinge miteinander vermischt bzw. den Ansatz etwas anders eingeordnet, als ich es aus meiner bisherigen Erfahrung tun würde.
Ich verstehe aber grundsätzlich, was er dir da baut, was die Idee dahinter ist und warum ihr diesen Weg gewählt habt. Tatsächlich hatte ich am Anfang einen ziemlich ähnlichen Ansatz: sehr stark ML-basiert. Daher stammt übrigens auch noch das „ML“ im Namen von SFML – Solar Forecast ML.
Nun kommt allerdings das berühmte Aber: Wenn du irgendwann eine wirklich zuverlässige PV-Prognose integrieren möchtest, reichen Sonnenstand und Clear-Sky-Modell meiner Erfahrung nach nicht aus. Auch ML allein wird dabei immer wieder an Grenzen kommen – es sei denn, Claude hat da tatsächlich einen Ansatz gefunden, den ich bisher übersehen habe. 
Der größte Knackpunkt ist das Wetter, genauer gesagt das lokale Wetter am Anlagenstandort. Genau deshalb ist dieser Teil bei SFML inzwischen auch deutlich umfangreicher als vieles andere im Projekt.
Neben Ausrichtung und Sonnenstand spielen beispielsweise Verschattung, reale Anlageneffizienz, Abregelungen, Einspeiselimits, MPPT-Throttling und diverse weitere Faktoren eine Rolle.
Ich hatte dabei gewissermaßen das „Glück“, im Oktober mit der Entwicklung begonnen zu haben. Dadurch hatte ich relativ früh reale Grenzfälle wie Schnee, Raureif, Frost, sehr tiefe Wolken, Starkregen oder auch Blätter auf den Modulen in meinen Daten. Das waren ziemlich gute Lehrmeister. 
Dabei habe ich für mich festgestellt, dass LSTM und Ridge allein für diese Problemstellung nicht ausreichen.
Ich habe mich deshalb ziemlich intensiv mit dem Thema beschäftigt, viele Paper gelesen, mich mit Professoren und Fachleuten ausgetauscht, Konferenzen besucht und zahlreiche Testreihen durchgeführt. Mir war wichtig, die eigentliche Problematik erst einmal möglichst tief zu verstehen, bevor ich mich auf eine Architektur festlege. Und selbst die wird bis heute ständig weiterentwickelt.
Bei einem Punkt aus der Claude-Einschätzung würde ich allerdings klar widersprechen: der benötigten Rechenleistung und insbesondere der Kaltstartfähigkeit.
Ich weiß nicht, ob du die Entwicklung bei SFML verfolgt hast: Ich habe dafür unter anderem ein eigenes Modell mit 18 Jahren Wetterdaten in 5-Minuten-Auflösung und zusätzlich 14 Jahren Klimadaten trainiert. Das Training selbst hat mehrere Tage auf einem leistungsfähigen Rechner gedauert und ungefähr 100 kWh Energie benötigt.
Das Entscheidende ist aber: Diese Rechenleistung wird beim Anwender später nicht benötigt.
Ich konnte das Modell quantisieren und auf rund 80 MB reduzieren. Zusätzlich sorgt die Logik dafür, dass nur der für den jeweiligen HA-Standort relevante Teil verwendet wird. Dadurch dauert die entsprechende Verarbeitung selbst auf einem Raspberry Pi 4 nur etwa sechs Minuten – und auch das nur, wenn tatsächlich ein Drift erkannt wird.
Zusätzlich habe ich die Epochs begrenzt und ein Promotion-Gate eingebaut. Dadurch bleiben Shadow-Snapshots unter zwei Sekunden und ein Full-Run liegt bei ungefähr 18 Sekunden.
Deshalb würde ich die Aussage, dass so etwas lokal aufgrund der benötigten Rechenleistung praktisch nicht sinnvoll machbar sei, aus meiner bisherigen Erfahrung nicht teilen.
SFML ist meines Wissens nach derzeit außerdem der einzige echte 4-Head-Attention-Transformer für Home Assistant, der vollständig lokal läuft und bei dem für die Prognose kein einziges Byte das eigene System verlassen muss.
100 % lokal und datenschutzfreundlich geht also durchaus. Entscheidend ist aus meiner Sicht weniger die reine Modellgröße als vielmehr die Architektur und die Logik darum herum.
Was ich bei deinem Projekt übrigens wirklich interessant finde, ist die Lösung mit dem integrierten Bug-Tracker. Das hat Claude ziemlich elegant umgesetzt.
An der Stelle stehe ich mir vermutlich manchmal selbst etwas im Weg, weil ich möglichst keine Nutzerdaten bei mir speichern möchte – und schon gar keine Nutzerdaten ungeprüft an externe KI-Dienste weitergeben würde. Mir wäre dabei das Risiko zu groß, nicht vollständig kontrollieren zu können, wo diese Daten verarbeitet oder gespeichert werden.
Falls du diesen Weg weitergehst, kann ich dir aber gern ein paar Hinweise geben, wie du den Datenschutz für deine Nutzer möglichst sauber aufsetzt und gleichzeitig Themen wie DSGVO, Datenübertragung und persönliche Haftungsrisiken von Anfang an mitdenkst.
Und falls du später tatsächlich eine Prognosefunktion einbauen möchtest, kann ich dir ebenfalls gern ein paar Erfahrungen und Ideen aus meinen bisherigen Tests mitgeben. Gerade bei PV-Prognosen gibt es einige Fallstricke, die man am Anfang überhaupt nicht auf dem Schirm hat.
Mit einem ausschließlich ML-basierten Ansatz würde ich persönlich heute jedenfalls nicht mehr starten.
So oder so: spannendes Projekt und vor allem ein komplett anderer Ansatz als das, was ich mit meinem Ökosystem verfolge. Gerade deshalb finde ich es interessant zu sehen, wie sich das entwickelt.
Wenn es irgendwo einmal hakt, melde dich ruhig. Vielleicht kann ich an der einen oder anderen Stelle einen Erfahrungswert beisteuern.
Beste Grüße und weiterhin viel Erfolg und Durchhaltevermögen! (und immer eine Handbreit Wasser unter dem Kiel und wenn es eng wird ein kühles Blondes im Kühlschrank 
Gruß
Zara
@echnaton
Hallo Markus,
ich habe die Telegram Benachrichtigung in Solhive aktiviert. Ich bekomme dort und in der Glocke permanent folgende Benachrichtigungen:
Danke für die offene Rückmeldung — der Punkt ist berechtigt, und ich tu gar nicht so, als wäre der Weg weg von GitHub gratis gewesen. Fork-Button, PR mit zwei Klicks, kostenlose Build-Runner für den eigenen Fork: das ist echte Bequemlichkeit, die wir uns bewusst genommen haben.
Warum trotzdem: Solhive läuft bei dir zuhause mit HA-Token, Modbus-Zugriff im Hausnetz und deinen Verbrauchsdaten. Für so ein Projekt wollte ich Code, CI und Container-Registry nicht bei einem US-Konzern liegen haben, sondern auf eigener Hardware in Deutschland.
Forgejo ist dabei kein Anti-Open-Source-Statement — die Software kommt vom Codeberg e. V., also genau aus dieser Ecke. Codeberg selbst ging für uns nicht: dort sind nur OSI-freie Lizenzen erlaubt, und Solhive ist source-available (PolyForm Perimeter — nutzen ja, privat wie gewerblich, nur nicht weiterverkaufen). Blieb: selbst hosten.
Was ohne Account schon heute geht — mehr, als es von außen aussieht:
- Klonen: `git clone https://code.solhive.energy/solhive/solhive.git\` — kompletter Code, komplette History, kein Login.
- Image ziehen: `docker pull code.solhive.energy/solhive/solhive:latest` — anonym, amd64 und arm64.
- Eigenes Image bauen: Das Dockerfile liegt im Repo, `docker build -t solhive:mein .` genügt. Intern bauen wir es genauso — wir haben nur eigene Runner statt Microsofts.
- Anpassen und für dich forken: ausdrücklich von der Lizenz gedeckt.
- Bug melden: direkt aus der App über den Bug-Button, ganz ohne Konto.
Was wirklich fehlte, war die Selbstregistrierung — und genau die mache ich gerade auf. Ich baue die Einstellungen heute um, ab morgen kannst du dir auf code.solhive.energy selbst ein Konto anlegen. Freischalten mache ich von Hand, das ist reiner Spam-Schutz und dauert normalerweise nicht lange. Danach hast du Fork, Issues und PRs wie gewohnt.
Zwei ehrliche Einschränkungen dazu: Auf deinem Fork laufen keine CI-Prüfungen — unsere Runner stehen im privaten Netz und bleiben dort. Und sichtbar ist nur das Kernprojekt, der Rest (Lizenzserver, Infrastruktur) bleibt privat.
Beiträge sind wirklich willkommen, besonders Wechselrichter-Profile und Übersetzungen - Profile sind reine YAML-Dateien, dafür brauchst du kein Python.
Hallo Zara,
danke für die ausführliche Antwort – gerade der Teil mit den Grenzfällen war für mich der wertvollste, dazu unten mehr.
Drei Punkte von dir sitzen, und ich will da gar nicht drumherum reden:
Rechenleistung. Wenn bei mir angekommen ist, dass so etwas lokal nicht sinnvoll läuft, dann war das falsch eingeordnet. 80 MB quantisiert und 18 s Full-Run sind kein Blocker, das nehme ich so an.
Kaltstart – da würde ich nur die Achse tauschen: Mein Problem ist nicht Rechenleistung, sondern Zeit. Die Physik liefert bei mir ab Tag 1 eine brauchbare Basis, aber der standortspezifische Teil (Verschattung, reale Anlageneffizienz) braucht Wochen an Messdaten, bis die Korrekturen stehen. Ein vortrainiertes Modell hat da einen echten Vorsprung. Die Verschattung deiner Anlage muss allerdings auch deins erst lernen – insofern haben wir beide einen Kaltstart, nur an unterschiedlichen Stellen.
Und dein stärkster Punkt, den du vermutlich gar nicht als solchen gemeint hast: Du hattest im Oktober angefangen, ich im Frühjahr. Meine gelernten Korrekturfaktoren haben bis heute ausschließlich April bis August gesehen. Schnee, Raureif, Blätter, Modulverschmutzung – null Datenpunkte. Mein Verschattungs-Kataster ist außerdem saison-invariant: Ich habe zwar einen Monatsfaktor je String, der aber nur das Tagesniveau verschiebt, nicht die Form der Verschattung über den Tag. Laub im Oktober bei gleichem Sonnenstand wie im Juli fange ich damit bestenfalls grob ab. Das ist eine echte Lücke und der Winter wird mein Stresstest.
Eine Sache muss ich aber geradeziehen, weil sonst die Diskussion an meinem System vorbeigeht: Solhive prognostiziert nicht per ML und auch nicht per Clear-Sky. Scikit-learn steckt bei mir nur in der Verbrauchsprognose. Die PV-Seite ist Physik (pvlib: Sonnenstand, Einstrahlung auf Modulebene, Modultemperatur) auf echter NWP-Einstrahlung – zwei Wettermodelle geblendet, gewichtet nach ihrem gemessenen Fehler der letzten Tage, dazu ICON-EPS mit 39 Membern für die Vortagsansage. Darüber liegt eine gelernte Korrekturkette: Kataster je MPPT über Azimut × Sonnenhöhe, Monatsresiduum, Intraday, Nowcast, Umweltfaktor. Abregelung, Einspeiselimit und MPPT-Throttling sind dabei tatsächlich ein eigenes großes Kapitel – daran habe ich die letzten zwei Wochen fast ausschließlich gearbeitet.
Und dass lokales Wetter der Knackpunkt ist, kann ich dir mit einem Schaden belegen: Am 15.08. hat Rauch eines Regionalbrands die Einstrahlung gedämpft. Alle 39 Ensemble-Member waren sich einig – Faktor 0,998 – und lagen gemeinsam daneben. Der Spread erkennt eben Uneinigkeit, nicht gemeinsamen Irrtum; Aerosole stecken in den Strahlungsmodellen schlicht nicht drin. Genau dein Argument, nur von der anderen Seite.
Woher der Unterschied in unseren Ansätzen aus meiner Sicht wirklich kommt: Bei dir ist die Prognose eine Anzeige, bei mir ein Stellhebel. Solhive schaltet damit Wallbox, Wärmepumpe und Speicher – eine falsche Zahl wird direkt zu einer falschen Handlung und kostet Geld. Deshalb ist bei mir jede Korrekturstufe einzeln gedeckelt und einzeln auslesbar. Was das wert ist, habe ich Anfang August gelernt: Die Rohprognose traf auf 5,9 % genau, angezeigt wurden 165 % daneben. Ursache war die Multiplikation mehrerer für sich plausibler Stufen – Monatsfaktor 0,635 × Sonnenhöhe 0,654 × Intraday 0,88 – die alle denselben Fehler ein zweites und drittes Mal bestraft haben. Ich konnte das an dem Abend sehen, benennen und fixen, weil jede Stufe eine Zahl mit Namen ist. Dieselbe Fehlerklasse in einem 20-Mio-Parameter-Modell hätte ich beobachtet, aber nicht diagnostiziert. Das ist kein Argument gegen dein Modell – es ist der Grund, warum ich bei etwas bleibe, das ich im Zweifel zerlegen kann.
Wo ich mir wirklich unsicher bin und dich gern fragen würde: Für den 24-h-Horizont ist doch letztlich das NWP die Decke – kein lokales Modell erzeugt Information, die im Wetterinput nicht steckt. Mein Eindruck ist, dass der reale Gewinn deines Modells im Post-Processing liegt (Bias, Standortcharakteristik), und weniger in einer besseren Wettervorhersage. Bei 0–3 h glaube ich dir sofort, dass gelernte Dynamik deutlich mehr holt, als ich das mit Kalman schaffe. Hast du für den Vortag mal einen Skill Score gegen eine saubere physikalische Baseline auf demselben Standort gerechnet? Das würde mich ehrlich interessieren – nicht als Streitpunkt, sondern weil ich für meine eigene Bewertung keine gute Vergleichsgröße habe. Meine aktuellen Zahlen: Live-Anzeige zuletzt an vier Tagen in Folge 13,5 / 12,0 / 3,6 / 8,8 % Tagesabweichung, Vortagsansagen im besten Fall bei gut 4 %.
Auf dein Winter-Angebot komme ich sehr gern zurück, mit zwei konkreten Fragen: Welche Wettervariablen haben bei dir bei Schnee und Raureif tatsächlich Signal getragen? Und erkennst du Schneebedeckung bzw. Verschmutzung eher aus dem Wetter oder aus der Form der eigenen Ertragskurve?
Zum Bug-Tracker noch eine Klarstellung, weil da ein Missverständnis drinsteckt: Da ist keine KI im Spiel. Der Button legt ein Issue in meinem privaten Repo an, das war’s – es gehen keine Nutzerdaten an einen externen KI-Dienst. Dein Datenschutz-Angebot nehme ich trotzdem gern an, dann aber an der Stelle, wo es bei mir wirklich relevant wird: Ich habe eine optionale Telemetrie und einen Hub, an den Instanzen melden können. Genau da sitzen DSGVO und persönliche Haftung, und da bin ich als Einzelentwickler ziemlich sicher nicht auf dem Stand, auf dem ich sein müsste.
Danke jedenfalls, dass du dir die Zeit genommen hast – so eine fachliche Rückmeldung von jemandem, der dieselben Fallgruben schon durchlaufen hat, ist deutlich mehr wert als Zustimmung.
Beste Grüße Markus
(Das kühle Blonde steht bereit. Beim Wasser unter dem Kiel bin ich mir bei meinen Winterdaten gerade weniger sicher.)
Wie ich ja hier schon mal geschrieben hatte, ist letzte Woche meine Schwiegermutter gestorben,
deswegen bin ich das letzte Wochenende und diese Woche etwas mit angezogener Handbremse unterwegs, da wir noch sehr viel zu regeln haben.
Ich hoffe ihr seht es mir nach…
Zweieinhalb Wochen später — was sich seit dem Start dieses Threads getan hat 
Als ich Solhive hier am 14. August vorgestellt habe, wusste ich nicht, was für einen Schub die Wochen danach bringen würden. Euer Feedback — hier im Thread und über den Bug-Button in der Beta — hat den Takt vorgegeben: Seitdem sind über 100 Releases erschienen. Hier die Zusammenfassung, sortiert danach, was es euch bringt.
Das größte Stück: Die Wärmepumpe ist jetzt ein vollwertiges Gerät
Bisher war die Wärmepumpe für Solhive „ein schaltbarer Verbraucher“. Jetzt hat sie eine eigene Seite — mit allem, was dazugehört:
- Kennzahlen statt Bauchgefühl: COP, Arbeitszahl und Wärmemenge, dazu Verläufe.
- Energie nach Betriebsart: Heizen, Warmwasser und Kühlen werden getrennt bilanziert — über Tage, Wochen und Monate. Ihr seht endlich, wohin der Strom wirklich geht.
- Heizkurven-Ansicht: aus den echten Betriebsdaten eurer Anlage ermittelt, nicht aus dem Datenblatt abgeschrieben.
- Im Energiefluss-Diagramm wird die WP aufgeschlüsselt statt als ein Klumpen gezeichnet.
- Steuern, nicht nur messen: Warmwasser- und Vorlauf-Sollwert gibt es jetzt als Aufgaben im Planer — z. B. das Warmwasser mittags mit PV-Überschuss auf Temperatur bringen statt abends mit Netzstrom. Mit eingebautem EEPROM-Schutz, damit die Register eures Geräts nicht kaputtgeschrieben werden. Und wichtig: Ohne lesbaren Ausgangswert wird nicht geschrieben — Sicherheit vor Feature.
- Drei Anbindungswege: SG-Ready (deckt den Großteil des DACH-Markts ab), direkte Modbus-Profile (Stiebel, NIBE, Lambda, Ochsner, Heliotherm, Weishaupt —
frisch aus der Doku gebaut, ich suche Tester mit Echtgerät!) oder als Brücke über eure vorhandene Home-Assistant-Integration (ViCare, MELCloud, myVAILLANT, …).
Was ihr davon habt: Die Wärmepumpe ist in vielen Haushalten der größte einzelne Verbraucher — und genau da entscheidet sich, ob ein Energiemanagement Geld spart oder nur hübsche Diagramme malt.
@noschvie — deine Frage nach der iDM war einer der Anstöße dafür. Über die HA-Brücke lässt sich vieles anbinden, was eine Integration hat; schreib mir gern eine PN.
Vertrauen: Hand-Ebene und verifizierte Schaltbefehle
Ein Beta-Tester hat gemeldet, dass ein Verbraucher nicht so schaltete wie angezeigt. Die Antwort darauf ist grundsätzlich ausgefallen:
- Schaltbefehle werden nicht mehr geglaubt, sondern rückgelesen. Kommt am Gerät nicht an, was Solhive geschaltet hat, wird nachgeregelt und sauber gemeldet — statt „wird schon geklappt haben“.
- Hand/Aus/Auto je Verbraucher, wie am Schaltschrank: Wer von Hand eingreift, hat Vorfahrt vor der Automatik — ohne Solhive abschalten zu müssen.
- Ein Status ohne Stromfluss zählt nicht mehr als „lädt“ — gemessen wird die Wirkung, nicht die Behauptung.
- Fallen Messwerte aus (HA-Neustart, Sensor eingefroren), regelt Solhive nicht auf veralteten Werten weiter — die Eingänge werden auf Frische geprüft, und der Regelzyklus übersteht Ausfälle, statt stehen zu bleiben.
Was ihr davon habt: Eine Automatik, die ihre eigenen Befehle kontrolliert und bei schlechten Daten lieber die Füße stillhält, könnt ihr auch dann laufen lassen, wenn ihr nicht danebensitzt.
Der Aufgabenplaner spricht Klartext — und kennt jetzt Prioritäten
- Aufgaben haben Namen, die Liste zeigt die Konfiguration im Klartext statt als Kürzel.
- Unter der Tabelle gibt es ein lesbares Protokoll: was wurde wann geschaltet — und warum.
- Klare Rangfolge: Ein Zielzeit-Auftrag („Auto bis 8 Uhr auf 80 %“) schlägt den Dauerauftrag; erledigte Einmal-Aufträge räumen sich selbst auf.
- Ganz frisch von diesem Wochenende: eine einheitliche Prioritäts-Skala für alles. Auto, Wärmepumpe, Speicher und schaltbare Verbraucher konkurrieren um denselben Überschuss — jetzt nach einer Rangordnung, die ihr festlegt. Und wer gerade nicht drankommt, zeigt an, hinter wem er ansteht, statt kommentarlos zu warten.
Was ihr davon habt: Bei knapper Sonne entscheidet ihr, was zuerst drankommt — Auto oder Warmwasser —, nicht der Zufall. Und einer Automatik, der man beim Denken zusehen kann, vertraut man.
Wallbox-Laden deutlich robuster
Volle Transparenz: Bei mir selbst ist Mitte August eine Ladung ausgefallen — die Box bekam tausende Startbefehle und lieferte 0 W. Die Aufarbeitung hat eine ganze Serie von Härtungen gebracht: Eine veraltete Transaktions-ID blockiert keinen Ladestart mehr, der Ladestrom wird auch nach dem Start gesetzt, eine Pause beendet die Sitzung nicht mehr, nach einem Neustart wird der Zustand aktiv abgefragt, und wenn das Fahrzeug selbst beendet, wird das sauber erkannt. Außerdem: eine Kachel je Ladepunkt statt einer gemischten Ansicht, und ein Eintrag ohne Verbindungsdaten sagt euch jetzt ehrlich, dass er nichts tut.
Was ihr davon habt: OCPP-Wallboxen sind zickig verschieden. Genau diese Sonderfälle sind der Unterschied zwischen „läuft beim Entwickler“ und „läuft“.
Neue Hardware seit dem Start
- Wechselrichter-Profile: von 28 auf über 40 — neu u. a. Sigenergy SigenStor ( Tester gesucht!) und KOSTAL PIKO 10-20 (@MartyBr
). SolarEdge und sonnen wurden auf die aktuell gepflegten Integrationen umgestellt, mehrere Profile gegen den Quelltext der jeweiligen HA-Integration geprüft. - Anlagen ohne angebundenen Wechselrichter: Netzmessung ohne WR und AC-gekoppelte Speicher werden unterstützt. Solhive lohnt sich jetzt auch, wenn euer Wechselrichter (noch) keine Schnittstelle hat.
- Balkonkraftwerke: Growatt NEXA 2000 im Katalog; bei BKW mit Speicher wird die echte Solarleistung getrennt vom AC-Ausgang erfasst — die Bilanz stimmt damit auch abends, wenn der kleine Speicher entlädt.
- Zwei Wechselrichter können sich die Hauslast im Anteils-Modus teilen.
- Modbus flexibler: alle vier Adressräume, Slave-ID je Eintrag, getrennte Lade-/Entlade-Sensoren mit Vorzeichen-Einstellung — das rettet so manches „exotisch“ verkabelte Setup.
Installation, Updates, Alltag
Vieles davon geht direkt auf Rückmeldungen aus diesem Thread zurück — danke @HaGoDo und @MartyBr fürs hartnäckige Testen:
- Debian 13 wird unterstützt (zusätzlich zu Ubuntu).
- Auf HAOS bricht der Installer jetzt früh mit einer verständlichen Erklärung ab, statt kryptisch an
apt-getzu scheitern. - Der Verbindungstest prüft die Eingabe, erklärt Fehler in Menschensprache und bietet den Neustart direkt in der Oberfläche an — kein SSH mehr nötig.
- Einstellungen erklären sich: Ein ungültiger Wert kommt als verständliche Meldung direkt am Feld zurück, nicht mehr als nackter Fehlercode.
- Updates mit Ausblick: Vor dem Einspielen zeigt Solhive, was die neue Version bringt (Changelog der Zielversion), Installation per Klick aus der Changelog-Seite.
- Im LAN läuft Solhive jetzt standardmäßig über HTTP — keine Zertifikatswarnung mehr beim ersten Öffnen; TLS bleibt als Option.
- Der Einrichtungsassistent hat einen eigenen Schritt „PV-Erzeugung“, der Wechselrichter und Balkonkraftwerke abdeckt.
- Docker: Die Konfiguration übersteht Image-Updates zuverlässig.
Oberfläche & Lesbarkeit
Tagesplan v2 (PV im Vordergrund, Schaltzeiten als übersichtliche Bänder), frei zusammenstellbare Verlaufsansicht, wählbare Schriftgröße, eigene Farben je Verbraucher, ein komplettes Kontrast-Audit über beide Themes und diverse Mobile-Korrekturen. Klingt unspektakulär, macht aber den Unterschied, wenn man das Dashboard täglich ansieht — auch draußen auf dem Handy in der Sonne.
Datenschutz nachgeschärft
Eine frische Installation sendet nichts mehr nach draußen, bevor die Telemetrie-Frage beantwortet ist. Und beim Aufräumen ist der komplette GeoFence-/GPS-Code aus der Codebasis geflogen — was es nicht gibt, kann keine Daten sammeln.
Und die Beta selbst?
Der Bug-Button in der Oberfläche legt direkt ein Ticket im öffentlichen Tracker an. Dort sind inzwischen über 50 Tickets aufgelaufen — Bug-Meldungen aus der Beta, Feedback aus diesem Thread und meine eigene Arbeitsliste. Die allermeisten sind erledigt, jede mit Ursache und Fix im Ticket kommentiert; an den restlichen arbeite ich gerade. Genau dafür ist die Beta da: Jede Meldung hat das System für alle robuster gemacht. 
Ausprobieren ohne Installation: demo.solhive.energy — 30 Minuten, keine Anmeldung.
Wer mittesten will (besonders gesucht: Sigenergy und Wärmepumpen mit Modbus): gern hier melden oder PN.
Und wenn Interesse besteht, mache ich zur Wärmepumpe einen Deep-Dive wie Teil 1 und 2.
1 „Gefällt mir“
Hallo Markus,
die Aufnahme der Daten funktioniert gut. Ich hatte es heute noch einmal an Hand meiner Wärmepumpe getestet.
Auch die Trennung der Messwerte in Heizen und Warmwassergewinnung funktioniert gut.
Ich bin sehr an deinem Angebot “Deep-Dive” interessiert. Gerade auch die Steuerung ist ein wichtiger Baustein. Ich versuche mit eigenen Automaten die Wärmepumpe in einem auch für das Gerät robusten Betrieb zu halten. Meine Vitocal kann leider keine Modulation. Daher versuche ich die WP möglichst wenig zu Takten.
Viele Grüße
Martin
Teil 3 – Die Wärmepumpe: Heizen mit der Sonne
Nach Teil 1 (die Prognosen) und Teil 2 (das Autoladen) ist der Wunsch nach einem Deep-Dive zur Wärmepumpe gekommen — sehr gern, denn hier ist in den letzten Wochen am meisten passiert.
Vorweg, volle Transparenz wie immer in diesem Thread: Ich habe selbst keine Wärmepumpe. Genau das hat die Architektur geprägt — ein System, das nicht auf der Anlage des Entwicklers „schon irgendwie läuft“, sondern das bei jedem Schreibzugriff vom Schlimmsten ausgeht. Entwickelt wurde gegen eine simulierte Anlage und mit Beta-Testern; der Modus-Split weiter unten geht z. B. direkt auf den Wunsch eines Testers mit Viessmann Vitocal zurück. Was das konkret heißt, dazu am Ende mehr.
Warum überhaupt die Wärmepumpe?
Die Wallbox ist das dankbarste Gerät fürs Energiemanagement — die Wärmepumpe ist das lohnendste. Sie ist in vielen Haushalten der größte einzelne Verbraucher, sie macht aus 1 kWh Strom 3–5 kWh Wärme, und sie hat etwas, das sonst teuer ist: einen Speicher, der schon bezahlt ist. Der Warmwasserspeicher und die Gebäudemasse puffern Wärme über Stunden. Mittags mit PV-Überschuss das Warmwasser laden statt abends mit Netzstrom — das ist dieselbe Idee wie beim Autoladen, nur dass der „Akku“ hier aus Wasser und Estrich besteht.
Drei Wege, eine Wärmepumpe anzubinden
Je nach Gerät und Geduld gibt es drei Pfade:
- SG-Ready über zwei Relais — der Universalweg, funktioniert bei ~80 % der Geräte im DACH-Markt. Zwei potentialfreie Kontakte (z. B. über ein Shelly oder einen HA-Schalter) geben der WP eine von vier Stufen vor: Sperren, Normalbetrieb, Einschaltempfehlung, Anschieben. Herstellerunabhängig, robust, keine Cloud. Solhive hält dabei die vorgeschriebene Mindest-Haltezeit von 10 Minuten je Zustand ein — eine WP ist kein Relais, das man im Sekundentakt klappern lässt.
- Brücke auf eure vorhandene HA-Integration — wer ViCare, MELCloud, myVAILLANT, NIBE & Co. schon in Home Assistant hat, gibt Solhive einfach die Entities. Der schnellste Weg. Ehrliche Einschränkung: Bei Cloud-Integrationen empfehle ich fürs Steuern trotzdem SG-Ready-Relais — API-Limits und Latenz der Hersteller-Clouds sind für einen Regelkreis kein guter Untergrund. Fürs Messen ist die Brücke top.
- Modbus TCP direkt — sieben Marken-Profile (Stiebel Eltron ISG, NIBE S- und F-Serie, Lambda, Ochsner, Weishaupt, Heliotherm) mit voller Datentiefe. Die sind aus Doku und den Quelltexten der jeweiligen HA-Integrationen gebaut und verifiziert, aber noch nicht am Echtgerät bestätigt — dazu unten.
Verstehen: die Wärmepumpen-Seite
Bevor man steuert, muss man sehen. Die eigene Seite zeigt:
- COP, Arbeitszahl und Wärmemenge — live und im Verlauf. Sechs Messreihen (Vorlauf, Rücklauf, Warmwasser, Außentemperatur, Leistung, COP) sind im Energieverlauf frei kombinierbar.
- Energie nach Betriebsart: Heizen, Warmwasser und Kühlen werden getrennt bilanziert — Strom, Wärme, Laufzeit und Arbeitszahl je Modus, über Tage, Wochen und Monate. Das Schöne: Wer kWh-Zähler je Modus hat (wie die Vitocal), bekommt es exakt; wer nur einen Leistungssensor hat, bekommt es integriert; und wer gar keinen Zusatzsensor hat, bekommt den Split trotzdem — die gemeldete Betriebsart reicht für die Zurechnung. Woher jede Zahl stammt, wird ausgewiesen.
- Die Heizkurve eurer Anlage — nicht aus dem Datenblatt, sondern aus den echten Betriebsdaten ermittelt (Vorlauf gegen Außentemperatur, nur im Heizbetrieb).
- Taktverhalten: häufige Starts sind Gift für den Verdichter — die Seite bewertet das, statt es zu verstecken.
- Im Energiefluss-Diagramm ist die WP ein eigener Strang. Detail am Rande: Standby wird bewusst nicht gezeichnet — ein Strang ohne Wärme ist kein Wärmefluss.
- Nebeneffekt: Die WP kann als Außentemperatur-Quelle fürs ganze System dienen, wenn ihr keinen eigenen Sensor habt — davon profitieren auch die Prognosen aus Teil 1.
Was ihr davon habt: Eine Arbeitszahl je Betriebsart zeigt euch, ob eure WP gesund läuft — eine schleichend schlechter werdende Warmwasser-AZ sieht man im Jahresmittelwert nie.
Steuern: die Hebel
Unter der Haube gibt es — je nach Gerät — drei grundverschiedene Mechanismen, und Solhive behandelt sie sauber getrennt: den SG-Ready-Zustand, einen Leistungs-Deckel (Obergrenze in Watt, z. B. für §14a) und bei einigen Marken einen Überschuss-Sollwert („hier hast du gerade 2.400 W Sonne“), den die WP selbst in Verdichterdrehzahl übersetzt. Als Aufgaben im Planer sieht das so aus:
- Warmwasser-Ziel: „Bring den Speicher zwischen 11 und 15 Uhr auf 55 °C“ — die WP wird angeschoben, bis das Ziel erreicht ist. Der Klassiker: Sonne rein, Legionellen raus, abends duschen alle mit Mittagssonne.
- Vorlauf-Anhebung im Fenster: ein paar Grad mehr, solange Überschuss da ist — die Gebäudemasse als Speicher.
- Leistungsbegrenzung: für Geräte mit Modbus-Leistungsdeckel; zugleich der Hebel, über den eine §14a-Vorgabe des Netzbetreibers bei der WP ankommt — kontrolliert dimmen statt hart sperren.
- Und seit diesem Wochenende gilt auch hier die einheitliche Prioritäts-Skala: Auto, Speicher und Wärmepumpe konkurrieren um denselben Überschuss, ihr legt die Reihenfolge fest — und wer nicht drankommt, zeigt an, hinter wem er ansteht.
Die Regeln, die über allem stehen
Das ist der Teil, auf den ich am meisten Sorgfalt verwendet habe — gerade weil ich das Gerät nicht selbst in den Keller stellen kann:
- Kein Ausgangswert, kein Schreiben. Solhive schreibt einen Sollwert nur, wenn es ihn vorher lesen konnte — sonst gäbe es kein Zurück.
- Freigeben statt zurückschreiben. Klingt spitzfindig, ist es nicht: Manche WP fährt ohne gesetzten Sollwert ihre Heizkurve und meldet dabei den aktuellen Kurvenwert. Würde Solhive am Aufgabenende diesen Wert „zurückschreiben“, wäre die Heizkurve ab dann eingefroren — bei Geräten, die es können, wird der Sollwert deshalb wieder freigegeben.
- EEPROM-Budget. Manche Modbus-Register schreiben bei jedem Befehl in einen Speicher mit begrenzten Schreibzyklen. Ein EMS, das dort im Minutentakt schreibt, hätte das Budget mancher Bausteine nach rund 70 Tagen verbraucht. Deshalb: Totband und Mindest-Schreibabstand vor jedem solchen Register.
- Eine Fähigkeit, die lügt, ist schlimmer als eine fehlende. Was ein Gerät kann, sagt der Treiber — es wird nicht aus vorhandenen Entities geraten. Die Ochsner z. B. bietet über Modbus weder SG-Ready noch einen Leistungs-Sollwert; also bekommt ihr dort ehrlich Monitoring plus Warmwasser-Hebel angeboten, und kein Regler behauptet Erfolge, die er nicht bewirken kann.
- Die EVU-Sperre schlägt alles. Keine Solhive-Aufgabe hebt eine Netzbetreiber-Sperre auf — bei Geräten mit Überschuss-Sollwert wird während der Sperre sogar aktiv 0 W geschrieben, weil ein positiver Wert die Sperre laut Hersteller aufheben würde. Solche Fälle sind exakt der Grund für Regel 1 bis 4.
Wo das Ganze steht — und wohin es geht
Ehrlicher Statusbericht: SG-Ready und die HA-Brücke sind der solide, produktiv nutzbare Weg. Die sieben Modbus-Profile sind sorgfältig gebaut, aber am Echtgerät unbestätigt — wenn ihr eine Stiebel, NIBE, Lambda, Ochsner, Weishaupt oder Heliotherm mit Modbus-Zugang habt und Lust, der erste bestätigte Fall eurer Marke zu sein: meldet euch hier oder per PN. Ihr bekommt dafür meine ungeteilte Aufmerksamkeit.
Und der nächste Schritt ist schon in Arbeit: prognosegesteuertes Vorheizen — der Planer, der aus PV-Prognose und Strompreis das beste Warmwasser-Fenster für morgen errechnet, existiert bereits und zeigt seine Rechnung; die Verdrahtung in die Aufgaben-Steuerung kommt als Nächstes. Das ist die Stelle, an der die Prognosen aus Teil 1 und die Wärme zusammenfinden.
Wie immer gilt: demo.solhive.energy — 30 Minuten, keine Anmeldung.
Eine Woche später — was seit dem 31.08. dazugekommen ist
Seit der Zusammenfassung vom letzten Sonntag sind knapp 30 kleine Releases durchgelaufen, aktuell steht v2026.09.05.1. Der größte Teil der Woche ist wieder aus eurem Feedback entstanden — allen voran die Sigenergy-Einrichtung mit @mag2000 und die Wärmepumpen-Kacheln mit @MartyBr. Wie immer sortiert danach, was es euch bringt. Und wie immer mit dem Unangenehmen zuerst.
Zuerst das Unangenehme: die direkte Modbus-Anbindung war kaputt
Wer Solhive über Home Assistant angebunden hat — nach allem, was ich sehe, bisher alle —, war nicht betroffen. Wer den Wechselrichter dagegen direkt per Modbus TCP, SunSpec oder Solarman-Logger anbinden wollte, bekam seit Beta-Start keine Daten. Dasselbe galt für Wallboxen, Wärmepumpen und my-PV-Geräte per Modbus. Zwei Ursachen: Ein Bibliotheks-Update im Juni hatte einen Parameternamen geändert, und der Treiber hat den Fehler verschluckt — es sah aus wie „Gerät antwortet nicht". Und der Live-Lesepfad hat für diese Anbindungen schlicht nie eine Verbindung aufgebaut. Meine eigene Anlage läuft über HA, deshalb ist es mir nicht aufgefallen. Gefunden hat es die Arbeit am Sigenergy-Profil — und ein Test gegen einen echten Modbus-Server statt gegen Attrappen. Der läuft jetzt bei jedem Release mit.
Beides ist seit v2026.09.05.1 behoben, und der Weg ist gleich mit ausgebaut:
- „Verbindung testen" im Wechselrichter-Formular prüft die Eingabe vor dem Speichern und sagt je Unit-ID, ob das Gerät antwortet.
- Die Modbus Unit-ID ist einstellbar statt aus dem Profil kopiert — bei Sigenergy die Geräte-ID aus der mySigen-App.
- Ein stummes Gerät blockiert den Regler nicht mehr minutenlang: Zeitbudget, Sperre, späterer Neuversuch.
- Im HA-Pfad wird jetzt die Einheit der Entity ausgewertet — ein Sensor in kW landet nicht mehr ungerechnet als W in der Regelung. Genau dafür brauchte @mag2000 bisher ein Template; das Vorzeichen steht noch auf der Liste.
- Wer
battery_socgemappt, aber „Batterie vorhanden" nicht angehakt hat, bekommt einen Hinweis direkt am Feld statt eines lautlos fehlenden Speichers — das „schreibe ich mir auf" von weiter oben im Thread.
Ehrlicher Hinweis für alle mit direkt angebundenem Schreib-Profil (Deye per Modbus oder Solarman, Sol-Ark, Sigenergy, SunSpec): Aufgaben wie Netzladen, Betriebsart oder Einspeise-Deckel greifen ab jetzt zum ersten Mal wirklich am Gerät. Einmal in den Aufgabenplaner schauen, bevor das Update durch ist.
Was ihr davon habt: Der direkte Weg ohne HA-Umweg steht — und ihr könnt ihn vor dem Speichern prüfen, statt es an einer leeren Kachel zu merken.
@mag2000 — damit kann dein SigenStor direkt ran: Unit-ID 2 eintragen, „Verbindung testen", Rückmeldung gern in deinem Anlagen-Thread.
Speicher: Netzladen nur, wenn es sich lohnt
- Prognose-Modus „binary" (nachts nur nachladen, wenn die PV-Prognose für morgen nicht reicht) urteilt jetzt einmal pro Tag statt im Augenblick des Abrufs, gilt auch für orchestrierte Geräte und Nachtfenster, und eine Lücke in der Prognose friert das Netzladen nicht mehr ein.
- Neu: Prognose-Modus „smart". Lädt nur das, was fehlt — in den günstigsten Tarifstunden, mit der echten Laderate des Geräts, bis zu zwei Blöcke, auch über Mitternacht. Das Ziel wird zu Fensterbeginn verankert; die schwankende Prognose hätte sonst jede Nacht über zwanzig Schreibzyklen ausgelöst.
- Deye-Besitzer, zwei Dinge für euren EEPROM: Nach einem Neustart wird das Sechs-Slot-Programm nicht mehr neu geschrieben, wenn es unverändert im Gerät steht. Und Deye speichert Slot-Zeiten nur im 5-Minuten-Raster — krumme Grenzen erzeugten eine Endlos-Schreibschleife samt Telegram-Spam. Jetzt legt Solhive die Grenzen selbst aufs Raster.
- SunSpec: Die Speichersteuerung schrieb in Typenschild-Register (Model 802) statt in die Steuer-Register (Model 124). Gegen die SunSpec-Definition geprüft, noch nicht am Gerät — siehe unten.
- Die Verbrauchsprognose trainierte nie, wenn kein Außentemperatur-Sensor da war — und damit fielen still auch binary, smart und die Arbitrage aus.
Was ihr davon habt: Mit dynamischem Tarif kauft ihr nur das Defizit, und zwar dann, wenn es billig ist. Und der Speicher wird geschont, weil weniger geschrieben wird.
Aufgabenplaner: Wochentage, Monate, Überdeckung
- Wochentage sind jetzt wirklich wählbar. Volle Transparenz: Die Wiederholung „an ausgewählten Wochentagen" hatte bisher kein Feld für die Tage — die Aufgabe lief täglich. Wer das genutzt hat: einmal öffnen, Tage setzen.
- Monats-Maske für alle Aufgabenarten: Warmwasser-Boost nur im Sommer, Netzladen nur im Winter.
- Die Prioritäts-Skala vom letzten Wochenende ist überall durch — auch in allen Batterie-Aufgaben, bei Betriebsart und Deckeln. Und eine Aufgabe, die von einer höher priorisierten überdeckt wird, sagt es beim Speichern und in der Liste.
- Das Aufgaben-Protokoll nennt das Zielgerät — bei zwei Wallboxen sieht man endlich, welche den Befehl bekam.
Was ihr davon habt: Saisonale und wöchentliche Regeln ohne Automationen drumherum — und keine stille Aufgabe, die nur deshalb nichts tut, weil eine andere vor ihr steht.
Wärmepumpe: das angekündigte Vorheizen ist verdrahtet
Im Deep-Dive am Sonntag stand „kommt als Nächstes" — jetzt ist es drin:
- Die Warmwasser-Aufgabe plant nach Prognose: Sie heizt in den günstigsten PV- bzw. Tarifstunden statt stur am Fensteranfang. Nach dem Ende kommt der Ausgangswert wieder ans Gerät — vorher blieb der Boost hängen.
- Vorlauf-Sollwert: Weishaupt WBB ist rücklesbar und freigebbar; die HA-Brücke liest den Sollwert zurück und schreibt nicht mehr in jedem Zyklus — das lief bei ViCare gegen die API-Quote.
- Die Kacheln sagen die Wahrheit (danke @MartyBr fürs Nachmessen): „Wärme heute" summiert die Modus-Zähler; ohne Wärmemengenzähler steht „kein Zähler eingerichtet" statt 0,00 kWh, und die Arbeitszahl schweigt, statt Unsinn zu zeigen. Takt-Warnungen kommen nur noch aus abgeschlossenen Takten, die Statistik hat ihr Off-by-one verloren und ein Jahresfeld gewonnen.
- Eine Leistungs-Aufgabe hob die EVU-Sperre auf — behoben.
- Das Stiebel-Profil (ISG/WPM3) ist bis zur Verifikation stillgelegt. Beim zweiten Blick waren die Register nicht mit dem Datenblatt belegt, und die Warmwasser-Aufgabe hätte in ein falsches Register geschrieben. Beim NIBE-F-Profil war ein Offset-Faktor falsch, das NIBE-S-Profil ist unbestätigt. Genau das meinte ich mit „Register rate ich nicht" — lieber ein Profil weniger als eins, das lügt.
Was ihr davon habt: Die Prognosen aus Teil 1 und die Wärme aus Teil 3 arbeiten jetzt zusammen — das beste Warmwasser-Fenster für morgen wird nicht nur ausgerechnet, sondern gefahren.
Schaltbare Verbraucher: Temperatur als Auslöser
- Neu: Temperatur als Schaltbedingung für Fenster-Aufgaben, mit Hysterese. Infrarotstrahler oder Heizstab laufen nur unter einer Schwelle; fällt der Fühler aus, bleibt das Gerät aus.
- „nicht erreichbar" ist nicht mehr „aus". Ein 91 Stunden alter Messwert galt als Live-Verbrauch, ein
unavailableals ausgeschaltet. Jetzt ein eigener Zustand, mit fünf Minuten Karenz bei HA-Neustarts. - Statt eines roten Punkts zeigt die Karte, was mit dem Befehl ist: kein Rückkanal, wartet, bestätigt, Gerät widerspricht.
Was ihr davon habt: Ein Frostwächter oder ein Heizstab im Pufferspeicher braucht keine HA-Automation mehr neben Solhive — und ein toter Sensor schaltet nichts ein.
Alltag, Updates, Beta
- Keine Eingabe-Raster mehr in den Einstellungen („Vielfaches von 50 W" ist weg), nur noch plausible Grenzen.
- Der License-Key ist wieder auffindbar (Darstellung → Branding & Identität), und der Bug-Button verlinkt direkt dorthin, wenn er fehlt. Ein eingetragener Beta-Key stellt außerdem selbst auf den Beta-Kanal um und schaltet die Beta-Telemetrie ein.
- Der Bug-Button sagt jetzt, warum etwas nicht ging, statt „HTTP-Fehler 502".
- Der weiße Bildschirm nach einem Update ist Geschichte: Ein veralteter Bundle-Name führt zu einem sauberen Neuladen.
- Hinweis am Namensfeld: Umbenennen legt ein neues Gerät an — eine stabile Geräte-ID steht auf der Liste.
- IOmeter im Messpunkt-Katalog; eine OCPP-Box ohne Verbindung ist „nicht erreichbar", keine Störung; der Installer startet den Dienst beim Moduswechsel selbst neu.
- Und ein Fund, den ich lieber selbst erzähle: Der maskierte Config-Export enthielt den License-Key im Klartext. Seit dieser Woche ist er maskiert. Wer einen Export irgendwo gepostet hat, sollte kurz nachsehen.
Im Tracker sind diese Woche gut 40 Tickets angefasst worden; der Modbus-Sprint allein hat 18 neue erzeugt, acht davon sind schon wieder zu.
Tester gesucht
Vier Dinge kann ich nicht an eigener Hardware belegen:
- SunSpec-Speicher (Fronius, SMA, Kostal … mit Model 124): Funktioniert die Speichersteuerung mit v2026.09.05.1?
- Stiebel Eltron ISG / NIBE S-Serie per Modbus: die Register aus dem Datenblatt am Gerät bestätigen, bevor das Profil wieder schreibt.
- Deye, Sol-Ark oder Sigenergy direkt per Modbus oder Solarman-Logger: Liefert der Lesepfad jetzt Werte, greifen Aufgaben wie erwartet?
- Weishaupt WBB per Modbus: der Vorlauf-Offset-Pfad.
Ausprobieren ohne Installation: demo.solhive.energy — 30 Minuten, keine Anmeldung.
Wer mittesten will: gern hier melden oder PN.
Noch eine Woche — was seit dem 06.09. dazugekommen ist
Seit dem letzten Recap sind 42 Releases durchgelaufen, aktuell steht v2026.09.13.0. Diesmal gibt es weniger neue Knöpfe und mehr Regelung unter der Haube — vor allem bei Wallbox und Speicher. Zwei Dinge am Vorgehen haben sich geändert: Vor jedem Release lasse ich jetzt Prüf-Agenten mit ausdrücklich skeptischem Auftrag über den Code laufen und behebe ihre Funde zuerst. Das kostet Stunden, hat aber am Donnerstag neun Regressionen meiner eigenen Fixes gefangen, bevor sie bei euch gelandet wären. Und ich bündele Releases: höchstens zwei am Tag statt zehn, weil jedes Beta-Release auf eurer Anlage einen Build auslöst. Wie immer sortiert nach dem, was es euch bringt — und mit dem Unangenehmen zuerst.
Zuerst das Unangenehme: Das Update aus dem Dashboard hängt fest
Wer Solhive mit dem Installer eingerichtet hat — also mit dem Einzeiler, dem Proxmox-Script oder install.sh —, kommt seit dem 12.09. über das Dashboard nicht mehr auf den neuen Stand. Das Update bricht ab mit „git pull --ff-only fehlgeschlagen — wahrscheinlich lokale Divergenz. Manuelles Eingreifen erforderlich.“
Das liegt an uns, nicht an eurer Anlage. Der Installer ruft beim Einrichten npm install auf, und das npm auf eurem System schreibt dabei die Datei frontend/package-lock.json ein wenig um. Git hält sie danach für lokal geändert. Seit ein Release am 12.09. genau diese Datei ebenfalls geändert hat, verweigert das Update den Abgleich. Auch ein älterer Snapshot hilft nicht, denn die geänderte Datei stammt aus der Installation. Docker-Anlagen sind nicht betroffen. Betroffen ist bisher der Beta-Kanal; wer auf Stable ist, trifft es beim nächsten Stable-Update, und der Befehl unten hilft dann genauso.
Einmal auf der Anlage ausführen, als root — per SSH oder auf dem Proxmox-Host mit pct enter <CT-ID>:
sudo -u solhive git -C /opt/solhive status --short
Kommt genau diese eine Zeile
M frontend/package-lock.json
dann die Datei zurücksetzen:
sudo -u solhive git -C /opt/solhive checkout -- frontend/package-lock.json
Danach das Update im Dashboard noch einmal starten und den angebotenen Neustart bestätigen. Der Befehl setzt nur diese eine Datei zurück, Einstellungen und Messdaten bleiben unberührt. Zeigt status etwas anderes als diese eine Zeile, bitte nichts zurücksetzen, sondern die Ausgabe hier im Thread posten.
Die eigentliche Korrektur kommt in den Updater und den Installer. Weil eine Anlage beim Update noch ihren alten Update-Code ausführt, wirkt sie erst ab dem Update danach — bis dahin braucht es diesen einen Handgriff. Gemeldet hat es @MartyBr über den Bug-Button, danke dafür.
Was ihr davon habt: Ein Befehl, und eure Anlage bekommt wieder alles, was diese Woche dazugekommen ist. Künftig räumt das Update die Datei selbst auf.
Wallbox: ein Sicherheitspaket
Volle Transparenz: Unterbrechungen beim Laden an meiner eigenen Box haben eine Prüfung der ganzen Wallbox-Regelung ausgelöst — und die fand Dinge, die nicht sein dürfen. Alle sind seit v2026.09.13.0 behoben:
- Der Netzbetreiber-Deckel (§14a) und der Hausanschluss-Schutz ließen sich umgehen. Mehrere Wege setzten den Ladestrom, ohne durch die Deckelprüfung zu laufen; eine Sonde bekam bei einem 4,2-kW-Deckel 11 kW. Jetzt läuft jeder Weg, der einen Strom ans Gerät schreibt, durch dieselbe Kette.
- Verweigerter Phasenwechsel. Lehnte die Box den Wechsel auf eine Phase ab, startete Solhive trotzdem mit dem für eine Phase gerechneten Strom — auf drei Phasen. Bei 3,3 kW Überschuss wären das fast 10 kW gewesen. Jetzt steht vor jedem Phasenbefehl ein Gate, ein gescheiterter Wechsel wird angezeigt, und eine Box, deren Phasenlage unbekannt ist, wird vorsichtig als dreiphasig gerechnet.
- Zwei Wallboxen an einem Hausanschluss: Gleich aufteilen ist jetzt Standard. 32 A Hausanschluss: Eine Box bekommt 16 A, zwei Boxen teilen sich, was nach der Hauslast übrig bleibt, und ist das erste Auto voll, darf das zweite wieder voll ziehen. Die Reserve für Spitzenlasten sinkt von 16 A auf 2 A je Phase — mit 16 A bekam bisher schon eine einzelne Box an 32 A nie ihre 16 A. Der Haken „Volle Auslastung“ entfällt, der eigene Ladestrom wird immer herausgerechnet.
/stopper Telegram hält jetzt wirklich — bis zum Ende des Ladefensters, nicht bis zum nächsten Regeltakt. Abstecken zählt nur, wenn die Box es meldet. Dazu Countdowns an den Übergängen, und die go-e per HTTP hängt beim Stopp nicht mehr an ihrer eigenen Sperre.
Ehrlich offen: Ein echter Hänger der Box meldet sich noch nicht per Telegram, das Lade-Pingpong im Potential-Modus und die automatische 1P/3P-Umschaltung über OCPP (wie bei evcc) kommen in den nächsten Runden.
Was ihr davon habt: Sicherung und Netzbetreiber-Deckel halten auch dann, wenn die Box widerspricht oder schweigt — und zwei Boxen teilen fair, statt dass eine leer ausgeht.
Speicher: zwei Wechselrichter teilen sich die Nacht
- Neu: Grundlast als Anteil. Bisher hielt ein zweiter Wechselrichter den Netzpunkt — und fand dort nichts zu tun, solange der erste das Haus allein trug. Jetzt kann er einen Anteil der Hauslast übernehmen, etwa 50 %. Am Mittwoch lief das erstmals an einer echten Anlage, und die Messung fand vier Fehler: 38 % statt 50 %, weil ein Wechselstrom-Soll als Gleichstrom-Deckel geschrieben wurde, zwei Haken ohne Wirkung und ein Fehlalarm per Telegram. Alle vier am selben Tag behoben.
- Noch offen, entschieden, nächste Woche: Steht der eine Speicher am Boden, übernimmt der andere noch nicht — eine Nacht kostete so 4 kWh aus dem Netz, während der zweite Speicher mit über 80 % stur seine 50 % lieferte.
- Deye: EEPROM schonen. Das Zeitprogramm schreibt nur noch Abweichungen (vorher 26 Schreibbefehle je Regelschritt), und eine Kennzahl zeigt die Schreibvorgänge des Tages. Neu ist auch eine Ansicht „Von Solhive gesetzte Sollwerte“: Ihr seht, was Solhive gerade ins Gerät geschrieben hat.
- „Regelung: aus“ heißt jetzt aus. Der Schalter hält die gesamte Regelung an — Wechselrichter, Wärmepumpe, Ladepunkt — und gibt gehaltene Sollwerte zurück; vorher stoppte er nur die Lade-Automatik. Und beim Herunterfahren stellt Solhive seine Sollwerte zurück, statt einen Entlade-Deckel am Gerät stehen zu lassen.
- Sigenergy: Eine zweite Anlage ist angebunden, der Lesepfad trägt. Ihr Befund: Beim Scharfschalten der Fernsteuerung setzte Solhive den Steuermodus nicht, und der Speicher deckte die Hauslast nicht mehr — behoben, ebenso stehengebliebene Deckel nach Aufgabenende. Die Betriebsart-Auswahl kommt aus dem Gerät statt aus Deye-Konstanten, und gemischte Speicherstapel (BAT 10 + BAT 6) sind eintragbar. @mag2000, dein Fund war der erfundene 20-kW-Deckel — auch weg.
- Speicher-Kennzahlen als Karte: Vollzyklen, gemessener Wirkungsgrad, Alterungstrend aus einer Regression statt aus zwei Punkten, Nutzen des Speichers in Euro.
Was ihr davon habt: Zwei Speicher arbeiten zusammen statt nebeneinander, und der EEPROM eures Wechselrichters lebt länger.
Kennzahlen, die stimmen — auch wenn sie kleiner werden
Anlass war ein Vergleich mit eedc, Gernots PV-Auswertung für Home Assistant. Ich habe jede unserer Kennzahlen gegen seine Definitionen gehalten — 23 Tickets, die meisten unangenehm:
- Die Autarkie war systematisch zu hoch — im Monatsmittel 3,7 Punkte, weil Tagesprozente gemittelt statt Energiemengen geteilt wurden (August bei mir 82,0 → 71,9 %). Verbrauch und Autarkie haben jetzt EINE Definition, überall.
- Jede Kennzahl zeigt ihre Herleitung: Formel plus die eingesetzten Zahlen im Tooltip. Wo keine Zahl möglich ist, steht der Grund statt eines Strichs.
- Arbeitszahl ohne Kühlstrom im Nenner. Amortisation trennt Gemessenes von Hochgerechnetem (im Beispiel 25,7 → 20,1 Jahre) und schweigt im ersten Monat, statt aus zwei Wochen hochzurechnen.
- Prognosegüte ehrlicher: Die Trefferquote maß gegen die Prognose statt gegen den Ist-Wert und deckelte sich damit selbst. Neu gerechnet fiel sie bei mir von 43 auf 14 % (7 Tage) bzw. 57 auf 53 % (30 Tage). Dazu Bias und Asymmetrie, der Lernzustand samt Reset steht oben auf der Prognose-Seite, und pausiertes Lernen ist sichtbar.
- Kleinere Rechenfehler: Solaranteil je Wallbox doppelt abgezogen, Balkon-PV im Sankey doppelt gezählt, ein erfundener 20-kWp-Nenner beim spezifischen Ertrag (bei reinen Balkonanlagen Faktor 25 daneben), zwei verschiedene Umsatzsteuer-Beträge in der EEG-Bilanz, Tages-Spitzen fehlten.
Was ihr davon habt: Zahlen, denen ihr trauen könnt — auch wenn einige diese Woche sichtbar kleiner geworden sind.
Einrichten mit Home Assistant: die Auswahl passt auf
- Der Entity-Picker warnt bei falscher Größe (kWh in einem W-Feld), Momentanwert statt Zählerstand, Lebenszähler im Tagesfeld und doppelt gezählter Entity. Ein Wh-Zähler an einem Messpunkt war 1000-fach zu groß — behoben.
- Eingefrorene Sensoren werden erkannt: Solhive führt das Alter der HA-Werte mit und meldet es. Noch nur Beobachtung, verworfen wird nichts.
- Zwei alte Fehler, ehrlich benannt: Eine über die Oberfläche eingerichtete HA-Wallbox las seit Mai NIE — ein Feldname im Code war falsch, jede solche Box meldete „Störung“. Und der Fahrzeug-SOC erreichte den Regler nicht: Ladelimit, Batterie-Schonung und Stopp rechneten mit 0 % (bei einem Tester stand das Auto auf 97 %, das Limit auf 95 %, geladen wurde trotzdem). Beides behoben.
- Vorzeichen des Netz-Sensors fremder Integrationen ist stellbar — @mag2000, dein Template kann weg. Fronius-HA ist ein Profil, NRGkick ist im Katalog, und die HA-Brücke zur Wärmepumpe kennt Heizkurven-Offsets (NIBE), statt sie als Absolutwerte zu behandeln.
Was ihr davon habt: Fehler beim Einrichten fallen sofort auf — nicht Wochen später in der Bilanz.
Alltag
- Umbenennen legt kein zweites Gerät mehr an — letzte Woche „steht auf der Liste“, jetzt gebaut. Verlauf, Aufgaben und Verweise ziehen mit.
- Der Temperatur-Auslöser liest auch Thermostat-Entities (
climate.*); der Wärmepumpen-Verbindungstest hat einen Knopf und erkennt ein Gerät, das antwortet, aber schweigt. - Flussdiagramm: Das Balkonkraftwerk zeigt seinen Speicher, die Erzeuger-Karte ist so breit wie die Hauskachel; Temperaturen überall mit einer Nachkommastelle.
- In der Nacht auf Dienstag war meine Anlage 3,5 Stunden nicht erreichbar — der Uplink des Hosts, nicht Solhive. Die Analyse fand aber 614 Stellen, an denen der Regler in einem Ausfallpfad still abgestürzt wäre; ein Wächter schließt diese Klasse jetzt aus.
Tracker
121 neue Tickets diese Woche — die wenigsten aus Fehlermeldungen, die meisten aus drei systematischen Prüfungen (Kennzahlen, Wallbox, Betriebsfestigkeit) —, 57 geschlossen, 83 offen. Die Testsuite ist auf rund 8.600 Tests gewachsen.
Tester gesucht
- Zwei Wallboxen an einem Hausanschluss: Wie teilt das neue Lastmanagement bei euch?
- Zwei Wechselrichter mit Speicher: die Anteils-Grundlast.
- Sigenergy per Modbus: Deckt der Speicher bei aktiver Aufgabe die Hauslast weiter?
- Weiterhin: SunSpec-Speicher, Stiebel ISG / NIBE S per Modbus.
Ausprobieren ohne Installation: demo.solhive.energy — 30 Minuten, keine Anmeldung.
Wer mittesten will: gern hier melden oder PN.
Ich habe zwei Wechselricher: Kostal Piko 20 und den Kostal PLenticore G3 mit angeschlossener Batterie.
Ich bin ja, wie diuweisst, im Beta-Kanal unterwegs und bereit zu testen.
weiss ich doch… aber vieleicht fühlt sich ja noch wer angesprochen