Solhive – mein Energiemanagement für PV, Speicher, E-Auto & Wärmepumpe (kostenlos, komplett lokal – mit Live-Demo zum Ausprobieren)

[echnaton]

Hallo zusammen,

heute traue ich mich mal in den Showroom Ich möchte euch das Projekt zeigen, das mich seit dem Frühjahr fast täglich begleitet: Solhive – ein Energiemanagement-System für PV-Anlagen, das komplett bei euch zu Hause läuft.

Kurz zu mir: Ich bin gelernter Elektriker und programmiere seit gut 20 Jahren. Auf meinem Dach liegen 30 kWp auf zwei Deye-Hybrid-Wechselrichtern, dazu Heimspeicher, E-Auto und natürlich Home Assistant. Die Werkssteuerung der Wechselrichter hat mich nie glücklich gemacht: Der Speicher war vormittags schon voll (und altert dabei unnötig schnell), das Auto lud stumpf vor sich hin, und mittags gingen kilowattweise Überschüsse für ein paar Cent ins Netz. Irgendwann habe ich angefangen, das selbst zu regeln – und daraus ist ein komplettes EMS geworden.

Ein Wort in eigener Sache, weil mir Transparenz wichtig ist: Bei der Entwicklung lasse ich mich von KI unterstützen (Claude) – das möchte ich nicht verschweigen. Neu ist das für mich nicht: Als Programmierpartner setze ich Claude schon seit Längerem produktiv in meinem Programmieralltag ein. Konzept, Architektur, die Elektrik-Seite und das tägliche Testen auf der echten Anlage liegen bei mir, und über 4.600 automatisierte Tests plus ein Security-Check vor jedem Release sorgen dafür, dass die Qualität stimmt.

Was Solhive im Alltag tut:

• Das E-Auto lädt zuerst mit Sonnenstrom – sekündlich nachgeregelt, mit automatischer 1-/3-Phasen-Umschaltung; reicht die Sonne nicht, übernehmen die günstigsten Netzstunden (dynamische Tarife wie Tibber oder aWATTar)
• Der Heimspeicher lädt schonend zur Mittagsspitze statt morgens um 9 – und in der dunklen Jahreszeit füllt er sich nachts gezielt zu den Börsen-Tiefpreisen, aber nur so viel, wie morgen wirklich fehlt
• Wärmepumpe (SG-Ready & Co.), Heizstab oder Poolpumpe schalten sich bei Überschuss zu – Warmwasser wird vorausschauend in die PV-reichsten Stunden gelegt
• Die PV- und Verbrauchsprognose lernt eure Anlage selbstständig kennen – inklusive Schatten-Erkennung und dem echten Potential bei abgeregelten Anlagen
• Anomalie-Erkennung mit Telegram-Meldung – Telegram ist gleichzeitig die Fernbedienung fürs ganze System
• Wirtschaftlichkeit immer im Blick: Ersparnis, Eigenverbrauchsquote, Autarkiegrad, Amortisation – Balkonkraftwerke zählen mit
• Und die Optik gehört euch: Theme-Support mit hellem und dunklem Modus, die Farben des Interfaces lassen sich nach Geschmack anpassen

Eigenständig statt Add-on – Anbindung, wie eure Anlage es hergibt: Solhive ist ganz bewusst kein Home-Assistant-Add-on, sondern läuft eigenständig – nicht jeder hat HA im Einsatz, und nicht jeder möchte sich damit beschäftigen – die Anlage soll trotzdem einfach laufen. Wechselrichter spricht Solhive direkt an – per Modbus TCP, SunSpec, MQTT oder Solarman-Stick; wer HA nutzt, bindet es alternativ als Brücke ein (so hat das Projekt mal angefangen). Aktuell gibt es 28 Wechselrichter-Profile (Deye, Fronius, Huawei, SMA, Sungrow, KOSTAL, SolarEdge, GoodWe, Growatt, sonnen …) plus Generic-Profile, dazu 9 Wallbox-Treiber (go-e, KEBA, openWB, Heidelberg, Alfen, universelles OCPP …). Als Hardware reicht theoretisch ein Raspberry Pi in der Nähe des Wechselrichters (bei mir ist es ein Proxmox-LXC, ein Mini-PC mit 2 GB RAM tut es genauso) – installiert ist das Ganze mit einem Befehl, und beim ersten Start führt ein Einrichtungs-Assistent Schritt für Schritt durch Standort, Wechselrichter, Wallbox und Stromtarif.

Bevor ihr überhaupt ans Installieren denkt – anschauen geht ganz ohne: Unter https://demo.solhive.energy bekommt jeder Besucher für 30 Minuten eine eigene, frische Instanz – die echte Software, nur mit simulierten Geräten statt echter Hardware. Keine Anmeldung, keine E-Mail nötig. Mit einem Klick schaltet ihr zwischen „Mittag", „Abend" und „Winter" um und seht, wie sich die Anlage in der jeweiligen Situation verhält.

Eure Daten bleiben bei euch: Solhive läuft komplett lokal, es gibt keinen Cloud-Zwang. Die wenigen optionalen Funktionen, die nach außen sprechen können (anonyme Telemetrie, verschlüsselte Debug-Pakete für Fehlersuche), sind ab Werk ausgeschaltet und einzeln opt-in. Dazu gibt es eine vollständige DSGVO-Dokumentation öffentlich im Repo und eine Privatsphäre-Seite in den Einstellungen – mit Live-Vorschau dessen, was übertragen würde, Auskunft und Löschung.

Anlagen von Eltern oder Freunden mitverwalten: Das war mir persönlich wichtig, weil ich nicht der Einzige bin, der für die Familie „der PV-Mensch" ist Über das Fleet-Management seht ihr alle betreuten Anlagen in einer Übersicht mit Status-Ampel und springt per Klick auf die jeweilige Anlage. Bis zwei Anlagen ist das kostenlos – also z. B. eure eigene plus die der Eltern – bis vier Anlagen kostet es 3 €/Monat. Die 3 € sind dabei als Unkostenbeitrag gedacht: Sie finanzieren die Server-Infrastruktur dahinter – und tragen damit auch die Nutzer mit, die kostenlos ihre Familie supporten. Und auch hier Datenschutz zuerst: Der Fernzugriff ist standardmäßig aus, die „Betreuten" sehen einen Banner, sobald jemand verbunden ist, und können den Zugang jederzeit selbst abschalten.

Was kostet das Ganze? Die Software: nichts – und das ist Absicht. Beim Funktionsumfang habe ich mir ein Beispiel an anderen EMS genommen, vor allem an den kommerziellen Lösungen, die es meist nur im Abo oder mit Hardware-Bindung gibt. Genau diese Funktionstiefe soll es für Privatnutzer kostenlos geben: Solhive ist frei nutzbar, privat wie gewerblich, und der Quellcode ist seit Kurzem öffentlich einsehbar (source-available unter PolyForm Perimeter – heißt: nutzen, anpassen, forken ja; als Konkurrenzprodukt vermarkten nein).

Alle Links auf einen Blick:

Live-Demo: https://demo.solhive.energy
Website: https://solhive.energy
Quellcode + Installations-Anleitung: https://code.solhive.energy/solhive/solhive
Community-Forum: https://community.solhive.energy – ganz frisch und ehrlicherweise noch ziemlich leer, ich wage mich mit Solhive gerade erst an die Öffentlichkeit

Damit das hier keine Textwand wird, stelle ich einzelne Bereiche in den nächsten Tagen in eigenen Beiträgen hier im Thread genauer vor:

1. Das Gehirn – lernende Prognosen, Sonnenstand, Schatten und das Solarpotential bei abgeregelten Anlagen
2. Autoladen mit Sonne und Börsenstrom + die Telegram-Fernbedienung
3. Der Aufgabenplaner – Speicher-Netzladung im Winter, schaltbare Verbraucher und die vielen Kleinigkeiten

Bis dahin freue ich mich über Feedback – am liebsten direkt hier im Thread. Was fehlt euch bei euren aktuellen Lösungen? Und wenn ihr die Demo ausprobiert: Sagt mir gerne, wo ihr hängen geblieben seid – genau daraus lerne ich am meisten.

Sonnige Grüße Markus

P.S.: Ein paar Screenshots vom Dashboard (Dark und Light) hänge ich unten an.

[HaGoDo]

Wow, das ist wirklich beeindruckend.

Ich muss mich jetzt mal mit Nachdruck darum kümmern, dass ich die Zugangsdaten zu meiner SMA-Wallbox bekomme. Die Steuerung über die App gefällt mir gar nicht.

Dann werde ich das ganz sicher installieren und testen.

[noschvie]

Hallo und Gratulation zu deinem Projekt, beeindruckend!
Spannend finde ich den Vergleich mit anderen EMS Projekten.

[MartyBr]

Hier im Forum gibt es ein neues HEM:

Solhive – mein Energiemanagement für PV, Speicher, E-Auto & Wärmepumpe (kostenlos, komplett lokal – mit Live-Demo zum Ausprobieren)

Hallo und Gratulation zu deinem Projekt, beeindruckend! Spannend finde ich den Vergleich mit anderen EMS Projekten.

Solhive — Schwarmintelligenz für PV-Anlagen

Hat jemand das System schon ausprobiert?

[echnaton]

Also aktuell läuft es auf 5 Systemen produktiv, eins davon ist mein eigenes System, und dort wird halt gleichzeitig auch entwickelt. Deswegen schlussendlich auch die Vorstellung hier, da ich im Moment immer mehr kommerzielle Systeme angeboten bekomme beim surfen, und da wollte ich einfach selber etwas entwickeln. Da ich das ganze halt auch nicht nur einfach so entwickeln möchte, nur für mich selber, braucht es natürlich interessierte Testuser. Ich zeige euch hier im Thread aber auch noch ein paar Details was das System aktuell schon kann, und gehe gerne auch auf wünsche ein.

Teil 1: Das Gehirn dahinter – Prognosen, Sonnenstand, Schatten & Solarpotential

Wie im Startbeitrag versprochen, der erste Blick unter die Haube – heute zu dem Teil, auf den ich am meisten stolz bin: den lernenden Funktionen. Gerechnet und gelernt wird dabei komplett lokal auf eurer Hardware – nach draußen geht nur der Abruf der Wettervorhersage.

Die PV-Prognose. Grundlage ist der exakt berechnete Sonnenstand für euren Standort – Höhe und Richtung der Sonne, und wie diese Bahn im Jahresverlauf wandert. Dazu kommen mehrere Wettermodelle (u. a. vom DWD), die Solhive dynamisch danach gewichtet, welches Modell bei euch zuletzt am besten lag. Vorhergesagt wird dabei nicht nur pro Dachfläche, sondern pro MPPT – also je String-Eingang des Wechselrichters. Eine Ost-West-Anlage bekommt so automatisch zwei getrennte Kurven, und auch zwei Strings auf derselben Dachfläche (etwa mit unterschiedlicher Verschattung) werden einzeln vorhergesagt und einzeln gelernt. Und dann beginnt das Lernen: Jede Stunde wird die Prognose mit der Realität verglichen, Korrekturfaktoren gibt es getrennt nach Sonnenhöhe und Jahreszeit. Nach etwa zwei Wochen liegt die Prognose typischerweise bei ±8 %. Läuft der Tag anders als gedacht (Hochnebel, Saharastaub …), zieht eine Intraday-Korrektur die Erwartung für den Resttag nach. Ein Wächter sorgt außerdem dafür, dass offensichtlich gestörte Tage – Schnee auf den Modulen, Sensorausfall – die gelernten Faktoren nicht verfälschen.

Schatten werden gelernt – über den Sonnenstand, nicht über die Uhrzeit. Der Kamin wirft seinen Schatten immer bei derselben Sonnenposition, aber je nach Jahreszeit zu einer anderen Uhrzeit. Deshalb merkt sich Solhive Verschattung als Karte über Sonnenrichtung und -höhe – der gelernte Schatten „wandert" dadurch automatisch korrekt mit den Jahreszeiten mit. Die Verschattungskarte ist in der Oberfläche sichtbar, und man erkennt seinen Baum oder das Nachbarhaus tatsächlich wieder.

Das echte Solarpotential – auch bei abgeregelten Anlagen. Wer auf Nulleinspeisung oder eine Einspeisegrenze (Stichwort 70-%-Regel) gedrosselt ist, hat ein Messproblem: Der Wechselrichter regelt ab, und keiner sieht mehr, was das Dach eigentlich gekonnt hätte. Solhive erkennt Abregelungsphasen an mehreren Signalen (voller Speicher, Einspeisung nahe null, typisches Leistungs-Plateau) und schätzt das ungenutzte Potential mit. Das hat zwei Effekte: Ihr seht schwarz auf weiß, wie viele kWh verschenkt werden – eine ziemlich gute Entscheidungsgrundlage für „lohnt sich ein Speicher?" – und die Prognose lernt nicht versehentlich aus den gedrosselten Werten, was sie sonst dauerhaft zu pessimistisch machen würde.

Die Verbrauchsprognose. Ein nächtlich trainiertes ML-Modell lernt eure Haushaltsroutine: Werktag vs. Wochenende, Jahreszeit, sogar die Außentemperatur fließt ein. Bis genug Daten gesammelt sind, übernimmt eine einfachere Schätzung – es funktioniert also vom ersten Tag an und wird von Woche zu Woche besser.

Nebenbei lernt Solhive noch ein paar Dinge mit: die real nutzbare Speicherkapazität (aus echten Ladezyklen kalibriert – die weicht gern mal vom Datenblatt ab), eure typischen Auto-Ladegewohnheiten für Empfehlungen, und die Überwachung kennt die gelernte Schattenkarte: Ein bekannter Schatten löst keinen Defekt-Fehlalarm aus, ein wirklich nachlassender String dagegen schon.

Warum eigentlich keine schwereren KI-Geschütze? Berechtigte Frage – gerade ist ja überall Deep Learning drin. Ich habe mich bewusst für schlanke, robuste Modelle entschieden, aus vier Gründen. Erstens macht bei einer PV-Anlage die Physik schon den Löwenanteil: Sonnenstand und Einstrahlung lassen sich exakt berechnen, gelernt werden muss nur noch die Abweichung zwischen Theorie und eurem konkreten Dach – ein viel kleineres Problem, und kleine Probleme brauchen keine großen Modelle. Zweitens liefert ein einzelner Haushalt schlicht wenig Trainingsdaten – ein Jahr hat nur 365 Tage; riesige Modelle würden darauf eher auswendig lernen als verstehen, robuste Statistik und kompaktes ML kommen dagegen mit wenigen Wochen aus. Drittens soll das Ganze auf einem Raspberry Pi neben dem Wechselrichter laufen, nicht auf einer GPU – ein System, das eure Energiekosten senken soll, darf nicht selbst zum Stromfresser werden. Das nächtliche Training läuft in Sekunden auf der CPU. Und viertens, für mich der wichtigste Punkt: Nachvollziehbarkeit. Solhive steuert echte Hardware – Batterie, Wallbox, Wärmepumpe. Da will ich sehen können, warum das System etwas entschieden hat. Ein Korrekturfaktor pro Sonnenstand ist erklärbar, eine Black Box nicht.

Und weil die gelernten Daten schon mal da sind: Ein „Was wäre, wenn?"-Simulator rechnet auf Basis eurer echten Erträge und Verbräuche durch, was mehr Module, ein größerer Speicher oder ein anderer Stromtarif bringen würden.

Screenshots von der Prognose-Seite und der Schattenkarte hänge ich an. Mich würde ehrlich interessieren: Welche Prognose-Genauigkeit erreicht ihr mit euren aktuellen Lösungen – und traut ihr euren Werten?

Im nächsten Teil: Autoladen mit Sonne und Börsenstrom – und warum Telegram bei mir zur Fernbedienung fürs ganze System geworden ist.

Nicht wundern, ich hatte durch einen Konfigurationsfehler in meiner Anlage, in meinem Urlaub ein paar Tage wo die Prognose nicht stimmte, diese Werte vergiften aktuell noch die Langzeit-Statistik für 7d und 31d, und da ich hier nichts beschönigen will, so sah der Tag gestern aus, schon recht genau würde ich sagen. Das vergiften der Statistik hat damit zu tuen, dass ich mehrere Wechselrichter habe, und die am Anfang direkt im Code angesprochen wurden, ich aber alles auf ein Treibermodell umgestellt habe, um halt auch andere Marken zu unterstützen. In meinem Fall habe ich zwei Wechselrichter, der eine 15kW mit Betriebsart “Zero Export to CT” und angeschlossenem Smartmeter. Der zweite Wechselrichter hat 5kW und kein Smartmeter, und ich habe mein System dahin optimiert, das ich einen Software Zero Export habe, und damit habe ich Solar-Potential das nicht verwendet wurde in der Kalkulation. So kommt man zu vergifteten Statistiken Abseits davon liegt die Vorhersage immer im Bereich +/-5-6%

[HaGoDo]

Ich weiß ja nicht, ob dieser Thread auch für Support genutzt werden soll. Aber da es keinen anderen gibt, frage ich mal hier.

Bei mir läuft HA auf eine RPi5 mit 8 GB und bootfähiger NVMe mit 1 TB.
Dort wollte ich auch Solhive installieren.

In HA hab ich Advanced SSH & Web Terminal und bin darüber im Flash des RPi auf Root-Ebene.

Es gibt in der Anleitung einen Schnellstart (Bare-Metal). Der bricht ab mit der Fehlermeldung “bash: line 98: apt-get: command not found”.

Die manuelle Installation scheitert an der 2. Zeile “sudo useradd -r -s /bin/false solhive”, weil es useradd auf dem RPi nicht gibt. Zu adduser passen die Parameter nicht.

Gehe ich zu naiv an die Sache ran? Geht HA mit HAOS und Solhive nicht auf einem Gerät?

[echnaton]

Du gehst nicht naiv ran — das liegt wirklich an HAOS, nicht an dir.

Zwei Dinge stehen im Weg: Das SSH-Add-on gibt dir eine Shell im Add-on-Container (Alpine/busybox — daher kein apt-get und ein anderes adduser). Und der HAOS-Host darunter ist ein abgeschottetes Read-only-System komplett ohne Paketmanager. Auf HAOS lässt sich grundsätzlich keine Fremdsoftware installieren, nur Add-ons. Der Bare-Metal-Installer kann dort also nicht funktionieren, egal wie man ihn ansetzt.

Die gute Nachricht: Solhive muss nicht auf demselben Gerät wie Home Assistant laufen. Es redet mit HA über die Netzwerk-API — HA auf dem Pi, Solhive woanders im selben Netz ist der Normalfall (so läuft auch meine eigene Anlage).

Mein klarer Rat: ein zweites Gerät.
Alter Pi 4, Mini-PC, NAS mit Docker oder ein Proxmox-LXC. 2 Kerne + 2 GB RAM reichen völlig. Dein Pi 5 mit HAOS bleibt unangetastet, du riskierst nichts an einem laufenden System.
→ Docker: docs/install/docker.md · Proxmox-LXC: docs/install/proxmox-lxc.md

Warum ich dir nicht rate, den Pi 5 umzubauen:
Rein technisch könntest du Raspberry Pi OS aufs NVMe legen und HA + Solhive per Docker nebeneinander betreiben — 8 GB RAM und 1 TB tragen das locker. Aber: Home Assistant hat „Supervised" im Mai 2025 abgekündigt, seit Release 2025.12 ist es offiziell nicht mehr unterstützt. Übrig bleiben nur HAOS und HA Container — und HA Container hat keinen Supervisor, also keine Add-ons mehr. Dein SSH-Terminal, Backups-Add-on, Zigbee2MQTT und alles andere müsstest du selbst als Container nachbauen; Thread und Z-Wave laufen dort out-of-the-box gar nicht. Das ist ein ziemlich hoher Preis dafür, ein Netzteil zu sparen.

Solhive als HA-Add-on?
Gibt es aktuell nicht. Technisch wäre es machbar — das Docker-Image existiert bereits für arm64. Ich nehme es als Feature-Wunsch auf, einen Zeitpunkt kann ich aber noch nicht zusagen.

Falls du Variante „zweites Gerät" nimmst und es ein Pi ist: bitte das fertige Image aus der Registry ziehen und nicht selbst bauen — der Frontend-Build braucht ~1 GB RAM und geht auf Pis gern in die Knie.

mkdir -p ~/solhive && cd ~/solhive
curl -fsSL https://code.solhive.energy/solhive/solhive/raw/branch/main/docker-compose.yml -o docker-compose.yml
docker compose up -d

Und noch ein Hinweis fürs nächste Mal: für Support-Fragen haben wir seit kurzem eine eigene Ecke im Forum → https://community.solhive.energy/c/support/5. Dort gehen Fragen nicht in einem allgemeinen Thread unter und andere finden die Antwort später wieder. Diese hier beantworte ich natürlich trotzdem gern hier.

Danke fürs Melden — dass HAOS nicht geht, steht bisher nirgends in der Doku. Das ändere ich.

[HaGoDo]

Dank für die Antwort.
Ich hatte mir das fast gedacht und bin auf meinen zweiten RPi5 ausgewichen. Auf dem läuft Openhab und Nextcloud.

Dort hat die Installation per Schnellstart funktioniert, allerdings mit einigen Fehlermeldungen, z.B.

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. OpenPGP sig                                                                                                                                               nature verification failed: https://packages.sury.org/php trixie InRelease: Sub-process /usr/bin/sqv returned an error code (1), error messa                                                                                                                                               ge is: Missing key 15058500A0235D97F5D10063B188E2B695BD4743, which is needed to verify signature.
W: Failed to fetch https://packages.sury.org/php/dists/trixie/InRelease  Sub-process /usr/bin/sqv returned an error code (1), error message                                                                                                                                                is: Missing key 15058500A0235D97F5D10063B188E2B695BD4743, which is needed to verify signature.
W: Some index files failed to download. They have been ignored, or old ones used instead.
>> Installiere Basis-Pakete...
✓  Basis-Pakete installiert.
✓  python3 >= 3.12 vorhanden (3.13).
>> Verwende Python: /usr/bin/python3 (Python 3.13.5)
✓  venv-Unterstuetzung vorhanden.
>> Installiere Node 20 via NodeSource...

Letztlich ist es aber durchgelaufen, ich konnte Solhive starten, API-Key gefunden und eingetragen. Wechselrichter etc. eingetragen, Telegram funktioniert, Verbindung zu HA bin ich noch unsicher, da das Dashboard bisher keine Werte anzeigt.

Verbindungstest zu HA meldet Protokollfehler. Keine Ahnung, was da nicht funktioniert.

Token gelöscht, neu erstellt, keine Änderung.

[noschvie]

@echnaton

Es läuft auf einem RPi mit mind. 4gb Ram, es braucht zwar im normalbetrieb nur einige hundert MB, aber das bauen des Updates geschieht immer lokal, und das ist kurzzeitig etwas speicherhungrig.

Aber für die Docker Version kann das nicht gelten.

Warum liegt der Source Code nicht auf Github?
Bin nahe dran, das Projekt zu testen aber wie wird die iDM Wärmepumpe eingebunden? Hier gilt es, gemeinsam die Lücke zu schließen, oder?

[lemuba]

@echnaton

Solhive als HA-Add-on?
Gibt es aktuell nicht. Technisch wäre es machbar — das Docker-Image existiert bereits für arm64. Ich nehme es als Feature-Wunsch auf, einen Zeitpunkt kann ich aber noch nicht zusagen.

Deine Entwicklung hört sich erstmal wirklich gut an und zusätzliche/neue HEMS-Alternativen sind auch immer zu begrüßen!

Bei mir läuft HA BareMetal auf einem potenten MiniPC, sowie diverse Apps (hießen mal Add-on), inkl. evcc. No way back um irgendeine neue Software auf einen externen/zusätzlichen RPI zu installieren, zu betreiben und dann kontinuierlich administrieren zu müssen. Auch ist HA mit seiner Backup-Funktion um alle integrierten Apps mit „wegzusichern“ einfach unschlagbar.

Ich denke, wenn Du eine weitere/breitere Verbreitung und Testen von Solhive anstrebst, wäre zumindest mein allererstes Bestreben das als HA-App rauszubringen. Und selbst dann wird es schwiering gegen Lösungen wie evcc, für die es dann auch gleich noch die passende Integration gibt, um über mqtt Alle Topics als HA-Daten/Sensoren, etc. zu veröffentlichen, bzw. bereitzustellen.

[HaGoDo]

Ich glaube, ich lass das. Wenn so einfache Dinge, wie die Verbindung zu HA nicht funktionieren und die Fehlermeldung nichtssagend ist, ist das Ganze noch so unausgereift, dass ich keine Lust habe, noch mehr Zeit zu verschwenden.

Ich komme mit http://192.168.54.41:8123 problemlos auf mein HA. Das ist bei URL richtig eingetragen (mehrfach überprüft). Warum kommt, wenn ih mit dem Mauszeiger auf den rote Pukt neben “Home Assistant” gehe, die Meldung “/api/states: Request URL is missing “http://” or “https://” protocol.”

[echnaton]

@HaGoDo

Verbindungstest zu HA meldet Protokollfehler. Keine Ahnung, was da nicht funktioniert.

Token gelöscht, neu erstellt, keine Änderung.

Die URL ist richtig — das Problem ist, dass der Testknopf gegen die gespeicherte Konfiguration prüft, nicht gegen das, was gerade im Feld steht. Bitte einmal oben rechts auf Speichern klicken und danach erneut „Verbindung testen". Dann sollte statt UnsupportedProtocol die HA-Begrüßung („API running.") erscheinen, und das Dashboard füllt sich mit dem nächsten Poll-Zyklus.

Falls der Fehler nach dem Speichern bleibt: Seite einmal neu laden (F5) und schauen, ob die URL noch im Feld steht. Ist sie weg, wurde nicht gespeichert — dann hat vermutlich ein anderes Feld auf der Seite die Validierung blockiert.

Das ist ein Bedienfehler, den unsere Oberfläche provoziert — wird behoben, danke fürs Melden.

Ja das ist das Problem, was man beim entwickeln der Software hat, ich bin jemand der erst auf speichern tippt, und dann die Verbindung testet, das fällt einem dann auf die Füsse, wenn mal jemand fremdes die Software bedient.

Zu den apt-Warnungen

Die sury.org/php-Meldungen stammen nicht von uns. Das ist ein Fremd-Repo, das auf dem Pi schon vorher eingebunden war (typisch aus einer Nextcloud-/PHP-Installation); dessen Signierschlüssel fehlt bzw. wurde rotiert. apt ignoriert das Repo dann und nutzt den alten Index — für Solhive folgenlos, wie der Verlauf zeigt. Aufräumen kann er es mit dem sury-Keyring-Update oder indem er /etc/apt/sources.list.d/php.list deaktiviert, wenn Nextcloud die Paketquelle nicht mehr braucht.

Schau mal auf meiner Seite vorbei, evcc kann man nicht mit dem Funktionsumfang von Solhive vergleichen. Zumindest nicht per se. Klar, für viele Menschen ist evcc ausreichend, für einige aber nicht, vieleicht sind diese dann eher an Solhive interessiert.

by HarryP: Zusammenführung Mehrfachpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

[HaGoDo]

Alles gemacht, URL ist gepeichert, Fehlermeldung hat dich geändert zu “sensor.sn_3019271027_device: Request URL is missing “http://” or “https://” protocol.

[echnaton]

Hier noch die Erklärung zum Fehler, und da bin ich froh dass es jemanden aufgefallen ist,
da man sein eigenes Entworfenes System anders bedient wie jemand der neu dazu kommt.

Das Symptom

* „Verbindung testen" meldete **Fehler: UnsupportedProtocol**, obwohl im URL-Feld eine korrekte Adresse wie `http://192.168.54.41:8123` stand.
* Ein neu erzeugtes Long-Lived Access Token änderte nichts.
* Das Dashboard blieb leer, später erschien zusätzlich eine Meldung der Art `sensor.sn_XXXXXXXX_device: Request URL is missing “http://” or “https://” protocol`.

### Ursache 1: Getestet wurde die gespeicherte Konfiguration, nicht das Eingabefeld

Der Testknopf schickte gar nicht mit, was gerade im Formular stand — er prüfte ausschließlich die bereits **gespeicherte** Verbindung. Bei einer frischen Installation war da noch nichts hinterlegt, und die Fehlermeldung bezog sich auf genau diesen leeren Eintrag: „UnsupportedProtocol" ist die technische Formulierung für „in der Adresse fehlt http:// oder https://".
Auf dem Bildschirm stand also eine tadellose Adresse, und daneben eine Fehlermeldung über eine ganz andere, leere Adresse. Die Meldung war zwar korrekt, aber sie zeigte auf etwas, das man nicht sehen konnte.

### Ursache 2: Eine geänderte Adresse wirkte erst nach einem Neustart

Der schwerwiegendere Teil. Solhive übernimmt Einstellungen normalerweise im laufenden Betrieb. Bei der Home-Assistant-Adresse klappte das nicht: Die laufende Verbindung behielt die Adresse, mit der der Dienst **gestartet** war. Auf einer frischen Installation war das „keine" — und blieb es, egal was gespeichert wurde. Jeder Lesezugriff auf eine Entität scheiterte danach dauerhaft, das Dashboard blieb leer.

Besonders irreführend: Eine Änderung am **Token** wurde sofort übernommen, nur die **Adresse** nicht. Deshalb sah es nach einem Token-Problem aus, und ein neues Token half nie.

### Was wir geändert haben
**Damit der Test das prüft, was man sieht:**

* Der Verbindungstest prüft jetzt die **eingegebenen** Zugangsdaten — ohne sie zu speichern. Man kann also ein Token ausprobieren, bevor es in der Konfiguration landet.

* Ist der Test erfolgreich, die Eingabe aber noch nicht gespeichert, sagt Solhive das ausdrücklich dazu.

**Damit Fehlermeldungen etwas nützen:**
Statt eines technischen Klassennamens steht jetzt Klartext da, zum Beispiel:
* „192.168.1.50:8123 nicht erreichbar. IP und Port prüfen — Hostnamen wie homeassistant.local lösen auf dem Solhive-Rechner oft nicht auf, dann die IP verwenden."

* „Token abgelehnt (HTTP 401). Long-Lived Access Token in Home Assistant neu erzeugen und vollständig einsetzen."

* „… antwortet, aber nicht wie Home Assistant. Zeigt die Adresse wirklich auf HA (Standard-Port 8123)?"

* „Protokollfehler. Meist sind http:// und https:// vertauscht."

**Damit Tippfehler gar nicht erst schaden:**
Die Adresse wird beim Speichern automatisch in Form gebracht: fehlendes `http://` wird ergänzt, versehentliche Leerzeichen entfernt, verunglückte Schreibweisen wie `http//192.168.1.50:8123` repariert. Beim Token werden mitkopierte Leerzeichen und Zeilenumbrüche entfernt — die machten bisher den Zugriff kaputt und sahen dabei aus wie ein Verbindungsproblem.

**Damit die Adresse sofort wirkt:**
Eine geänderte Home-Assistant-Adresse greift jetzt ohne Neustart, genau wie das Token.

**Und damit der Neustart nicht mehr auf der Kommandozeile stattfindet:**
* Nach bestandenem Verbindungstest erscheint ein Dialog mit **„Speichern und neu starten"** — ein Klick für beides. Bei der Ersteinrichtung ist ein Neustart sinnvoll, weil Gerätetreiber und Regler die Verbindung beim Start übernehmen.

* Unter **Einstellungen → System** gibt es jetzt einen allgemeinen Knopf **„Dienst neu starten"**.

* Es gibt Einstellungen, die technisch bedingt erst nach einem Neustart greifen (Wallboxen, Wärmepumpen, OCPP-Server, Datenbank-Pfad, Sollwert-Wächter, Reiseplaner, Lastverteilung, Hausanschluss). Bisher wurden die still gespeichert und man wartete auf eine Wirkung, die nicht kam. Jetzt sagt Solhive nach dem Speichern, welcher Bereich betroffen ist, und bietet den Neustart direkt an.

[echnaton]

Der Sourcecode liegt nicht mehr auf Github, sondern auf einem selbst gehosteten Forgejo Server, das hat was mit meiner Entwicklungsweise zu tuen, ich baue mir ein feature, dann teste ich es, und bugfixe es, nächstes feature etc. Das hat bei den selbstständigen Actions und Tests dazu geführt, dass ich Github zu sehr belaste, und mein Monatskontingent schon nach zwei Wochen weg ist. Jetzt fahre ich die Tests auf einem separaten Forgejo Runner VM selber, auf meinem kleinen Heimserver der äußerst Potent ist, und da brauche ich nichts für bezahlen

Wir können gerne deine Wärmepumpe einbauen, das würde schlussendlich auch sehr vielen anderen Nutzern helfen. Schreib mir doch mal eine PN hier, mit dem Typ deiner Wärmepumpe, wie diese angebunden werden könnte, und was du damit gerne machen möchtest. Ich setze das mal dem gegenüber was gerade schon als beta eingebaut ist, und was noch fehlt, und würde dir dass dann einbauen. Du müsstest mir dann aber vieleicht ein paar Screenshots mal senden oder so, damit ich sehe wie das ganze dann wirkt.

[HaGoDo]

Vielen Dank für die ausführliche Antwort und die Änderungen, die ich allerdings bisher nicht testen kann.

Das Update über Einstellungen - System und Sicherheit - System -Update scheitet mit dieser Meldung:

Ich weiß nicht, wo ich eingreifen soll.

Eine weitere Frage:

Ich wollte mit meinem Handy auf Solhive, da wird aber wieder der Api-Key verlangt. Brauch ich den bei jedem Gerät? 43 Stellen kann ich mir schlecht merken. Kann man den Key in der config-Datei ändern (verkürzen)? Wie wär’s mit einem normalen Passwort und eine 2-Faktor-Authentifizierung?

Edit:

Nach einem Restart klappt die Verbindung zu HA. Jetzt muss ich noch ein paar Entiäten korrigieren.

[echnaton]

Probiere bitte auch nochmal das Update auf die letzte aktuelle Version, diese sollte aus der Weboberfläche eigentlich klappen, so mache ich es immer selber.

Ja, aktuell musst du noch den api-key kopieren, das war der erste teil meiner Absicherung der Anlage dass man da ansonsten nur schauen kann. Ich bin da aber offen für alles an Vorschlägen, was man noch vereinfachen kann.
Wichtig sind mir dabei aber folgende Dinge: Es muss immer noch die Sicherheit gewährleistet sein, dass nicht jemand fremdes an eure Anlagen kommt, und alle Informationen die eventuell ausgetauscht werden mit mir (Alles nur Opt-IN) müssen für euch klar nachvollziehbar sein.

[echnaton]

Teil 2: Autoladen mit Sonne und Börsenstrom – und Telegram als Fernbedienung

Weiter geht’s mit dem Thema, das bei mir den größten Unterschied auf der Stromrechnung macht: das E-Auto.

Überschussladen. Solange die Sonne liefert, fließt der Überschuss ins Auto – sekündlich nachgeregelt. Solhive schaltet dabei automatisch zwischen 1- und 3-phasigem Laden um, damit auch kleine Überschüsse ab ~1,4 kW genutzt werden können, und zwar mit Bedacht: Eine Hysterese verhindert, dass bei jedem Wolkenzug hin- und hergeschaltet wird.

Plan-Laden mit Deadline. „Bis morgen 7 Uhr auf 80 %" – Solhive plant rückwärts: Jede Stunde bis zur Deadline bekommt eine Bewertung aus Strompreis und erwartetem PV-Anteil, geladen wird in den besten Stunden. Tagsüber gewinnt meist die Sonne, nachts der Börsenpreis. Im Detail steckt Erfahrung aus einem Sommer Dauerbetrieb: PV-Stunden plant Solhive bewusst früh ein (eine PV-Prognose kann kippen, späte Wolken würden das Ziel kosten), Netzstunden dagegen möglichst spät (damit das Auto nicht stundenlang auf hohem SOC steht) – und vor der Zielzeit bleibt ein Sicherheitspuffer. Ist ein Ziel rechnerisch nicht erreichbar, sagt Solhive das ehrlich, statt es zu verschweigen.

Und genau da werden dynamische Tarife spannend. Solhive kennt Tibber, aWATTar, Energy-Charts (Fraunhofer ISE) und Octopus – oder eigene Zeit-Tarife. Im Winter, wenn die PV das Auto nicht mehr voll bekommt, heißt das: Das Auto lädt automatisch in den Tiefpreisstunden nach Mitternacht statt zum teuren Abendpeak – ohne dass ihr auf die Preiskurve schauen müsst. Wer mag, setzt zusätzlich einen Preis-Deckel („nur laden, wenn unter 15 ct").

Sicherheit inklusive. Alles wird laufend gegen den Hausanschluss gedeckelt – auch mit mehreren Wallboxen, die sich das Budget per Load-Balancing teilen. Und wenn ihr Home Assistant nutzt, erkennt Solhive über die Anwesenheit automatisch, wann das Auto überhaupt zu Hause ist.

Und alles ist dokumentiert. Jede Ladesitzung wird protokolliert – Energiemenge, Solar- und Netzanteil, Start-/End-SOC, Dauer. Die Historie lässt sich für einen frei wählbaren Zeitraum als CSV oder als fertiger PDF-Report exportieren, auf Wunsch gefiltert nach Mindest-Solaranteil. Praktisch für die eigene Ablage – oder wenn der Arbeitgeber das heimische Laden des Dienstwagens erstattet und einen Nachweis sehen will.

Die Telegram-Fernbedienung. Für den Alltag braucht es keine App und kein Dashboard – der Telegram-Bot versteht einfache Klartext-Befehle:

🚗 Auto laden

laden · laden 50 → sofort laden (bis Ladegrenze bzw. 50 %)

laden 80% 8:00 → bis 8 Uhr auf 80 %, günstigste Stunden

(Zusätze: "täglich", "unter 20ct")

vollladen → einmalig bis 100 % (lange Strecke)

solar → laufendes Laden auf reinen Überschuss umschalten

stop → Laden beenden

limit 80 → dauerhafte Ladegrenze, schont den Akku

soc 65 → Fahrzeug-SOC von Hand setzen (Autos ohne API)

fahrt 08:00 300km → plant die Ladung für eine geplante Strecke

📋 Aufgaben

netzladen 0-6 bis 90% unter 15ct → Heimspeicher nachts günstig füllen

einschalten pool 10:00-16:00 → Verbraucher im Zeitfenster schalten

warmwasser wp auf 50 bis 17:00 → Warmwasser-Ziel setzen

auftraege · auftrag löschen 3 → Aufgaben ansehen / entfernen

📊 Anlage

status · anlage · preis → Auto, Anlage und Strompreise live

hilfe → erklärt alles im Detail (hilfe laden, hilfe aufgaben …)

Der Befehl fahrt ist mein Liebling: kurz die Abfahrtszeit und die Strecke schicken, und Solhive rechnet aus, ob der Akku reicht, und plant die nötige Ladung in die günstigsten Stunden davor. (Und was hinter netzladen steckt – dem nächtlichen Günstig-Laden des Heimspeichers – bekommt im nächsten Teil ein eigenes Kapitel.)

Und der Bot redet auch von selbst: Er meldet Ladebeginn und -ende, warnt, wenn eine Ladung hängt, schickt erkannte Anomalien und die Ergebnisse der nächtlichen Backups. Im Alltag ist Telegram bei mir tatsächlich die meistgenutzte Art, mit dem System zu reden – das Dashboard öffne ich fast nur noch zum Stöbern in den Auswertungen.

Wie löst ihr das Auto-Laden heute – und was nervt euch daran am meisten? Screenshots vom Ladeplan und ein Beispiel-Chatverlauf hängen unten dran.

[HaGoDo]

Update hat jetzt funktioniert. Ich musste erst Beta auswählen, dann speichern (ohne Speichern kam die gleiche Fehlermeldung), dann updaten.

Ich habe aber weiterhin große Schwierigkeiten.

Ich habe eine AC-gekoppelte Batterie von Jackery, die überhaupt nicht berücksichtigt wird. Der Hausverbrauch muss sich verringern, wenn die Batterie geladen wird und erhöhen, wenn die Batterie entladen wird. Das passsiert nicht.

Weiterhin gelingt es nicht, dass Netzbezug und Einspeisung berücksichtigt werden. Solhive unterscheidet zwischen PV_Power und Grid_Power. Der WR liefert zwar einen Wert Grid-Power, der ist aber (bis auf 1 - 2 W) identisch mit PV_Power. Grid_Power wird offenbar für Einspeisung/Bezug verwendet. Bei dem SMA-WR ist Grid_Power aber der Wert, der ins Hausnetz geht. Einspeisung/Bezug liefert ein Smartmeter (SMA Home-Manager), dessen Entität kann man aber in Solhive nicht verwenden. Es wird eine Entität der WR erwartet.

Warum wird im Dashboard eine Wallbox angezeigt, wenn keine konfiguriert ist?

Hier zwei Screenshots, die das Geschriebene vielleicht etwas verdeutlichen. Kleine Unterschiede liegen daran, dass ich nicht zeitgleiche Screenshots machen konnte.

Solhive zeigt 3,72 kW Hausverbrauch an, wegen der Batterieladung sind es aber nur 1,505 kW.

Die 66 W Netzbezug werden auch nicht angezeigt.

PS

Es gibt ja die Solhive-Community, aber keine Möglichkeit, sich dort zu registrieren.

[MartyBr]

@echnaton
Ich habe mir gerade Solhive als LXC-Container unter Proxmox 9 installiert. Eine Frage stellt sich mir: Im Installationsscript bietest du Ubuntu an. Kann ich dort auch Debian 13 auswählen? Läuft Solhive auch unter Debian (ich frage wegen Python-vive).

Edit:
Der Container läuft und ich versuche ihn zu konfigurieren. Dabei habe ich schon den ersten Stolperstein. Ich habe zwei Wechselrichter, Kostal Piko 20 und den Kostal Plenticore G3. Der Plenticore steht in deiner Liste, der Piko 20 fehlt.
Nun habe ich den Plenticore als ersten WR ausgewählt und finde den Piko 20 nicht. Bei diesem habe ich versucht die Felder auszuwählen. Die Batterie ist am Plenticore angeschlossen, der Piko hat dementsprechend keine Felder.
Weitere Frage:
Was bedeutet dort “Smartmeter”? Den Strombezug und die Einspeisung messe ich am Stromzähler per Hichi. Die Stromflüsse im Haus werden per Kostal Smart Energy Meter gemessen.

Ich habe jetzt erstmal die Konfiguration abgebrochen und hoffe, dass du mir weiterhelfen kannst.