- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#11
Anfängerfragen / Aw: Mähroboter Navimow Integra...
Letzter Beitrag von sweetie-pie - 07 August 2026, 14:39:34Moin,
ich habe jetzt auch so einen Mäher und da ich noch nichts gefunden habe, spiele ich z.Z. mit OpenAI Codex um eine Integration zu bauen (Python).
Ich würde aber über mqtt gehen wollen, perspektivisch wäre dann eine navimow2mqtt-Docker-Container eine denkbare Lösung (Grüße an zigbee2mqtt).
Das macht es portabler und für andere Smart-Home Integrationen nutzbar.
Mäher <-> navimow-Cloud <-> navimow2mqtt <-> mqtt-server <-> fhem
Hört sich langsam an, geht aber wirklich fix.
Was bisher geht:
In fhem habe ich es dann halt als mqtt-Device eingebunden.
Steuern geht noch nicht, brauche ich eigentlich auch nicht.
Ich muss nur wissen ob er gerade unterwegs, gerade für die Beregnung.
Um an einen gültigen, initialen Token für das Skript zu kommen, braucht es noch Klimmzüge:
Dafür gibt es ein Helper-Skript, dass die Home-Assisant Anmeldung bei Navimow nachahmt.
Dazu muss eine interaktive Anmeldung erfolgen, dann wird per Callback der Token entgegengenommen und in eine Datei geschrieben.
Autorefresh macht dann das Skript selber.
Ob das jemals das alpha-Stadium verlässt, weiß ich nicht.
Also wenn jemand schon eine stabile, funktionierende Lösung hat, freue ich mich über Feedback.
Gruß
sweetie-pie
ich habe jetzt auch so einen Mäher und da ich noch nichts gefunden habe, spiele ich z.Z. mit OpenAI Codex um eine Integration zu bauen (Python).
Ich würde aber über mqtt gehen wollen, perspektivisch wäre dann eine navimow2mqtt-Docker-Container eine denkbare Lösung (Grüße an zigbee2mqtt).
Das macht es portabler und für andere Smart-Home Integrationen nutzbar.
Mäher <-> navimow-Cloud <-> navimow2mqtt <-> mqtt-server <-> fhem
Hört sich langsam an, geht aber wirklich fix.
Was bisher geht:
- state = "idle","docked","paused","returning","mowing"
- battery = 0-100
In fhem habe ich es dann halt als mqtt-Device eingebunden.
Steuern geht noch nicht, brauche ich eigentlich auch nicht.
Ich muss nur wissen ob er gerade unterwegs, gerade für die Beregnung.
Um an einen gültigen, initialen Token für das Skript zu kommen, braucht es noch Klimmzüge:
Dafür gibt es ein Helper-Skript, dass die Home-Assisant Anmeldung bei Navimow nachahmt.
Dazu muss eine interaktive Anmeldung erfolgen, dann wird per Callback der Token entgegengenommen und in eine Datei geschrieben.
Autorefresh macht dann das Skript selber.
Ob das jemals das alpha-Stadium verlässt, weiß ich nicht.
Also wenn jemand schon eine stabile, funktionierende Lösung hat, freue ich mich über Feedback.
Gruß
sweetie-pie
#12
Codeschnipsel / Aw: Notdienst Apotheke via jso...
Letzter Beitrag von Sailor - 07 August 2026, 13:32:23Moin tosammen
Ich habe mich an die Vorschläge gehalten inklusive
und bekomme eine Fehlermeldung im Log:
und auch kein Reading mit Ausnahme
Ist die Seite wieder umgestrickt worden oder mache ich was falsch?
Gruß
Sailor
Ich habe mich an die Vorschläge gehalten inklusive
Code Auswählen
attr apotheke2 get2Data tx_aponetpharmacy_search[action]=result&tx_aponetpharmacy_search[controller]=Search&tx_aponetpharmacy_search[search][plzort]=Hamburg&tx_aponetpharmacy_search[search][date]=&tx_aponetpharmacy_search[search][street]=+&tx_aponetpharmacy_search[search][radius]=5&tx_aponetpharmacy_search[search][lat]=&tx_aponetpharmacy_search[search][lng]=
und bekomme eine Fehlermeldung im Log:
Code Auswählen
2026.08.07 13:15:58.458 3: apotheke2: error while parsing JSON data: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 3 (before "<div class="tx-apone...") at lib/FHEM/HTTPMOD/Utils.pm line 701.
2026.08.07 13:15:58.458 3: apotheke2: Content-Type was application/json
2026.08.07 13:16:20.740 3: apotheke2: timer interval changed to 60 seconds
2026.08.07 13:16:51.528 3: apotheke2: Content-Type was text/html; charset=utf-8
2026.08.07 13:16:52.312 3: apotheke2: error while parsing JSON data: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 3 (before "<div class="tx-apone...") at lib/FHEM/HTTPMOD/Utils.pm line 701.
2026.08.07 13:16:52.312 3: apotheke2: Content-Type was application/json
und auch kein Reading mit Ausnahme
Code Auswählen
data-token <Jede Menge Hex Zahlen>
Ist die Seite wieder umgestrickt worden oder mache ich was falsch?
Gruß
Sailor
#13
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 07 August 2026, 13:24:59Du könntest uns bei Gelegenheit auch mal Screenshots von den realen Balkendiagrammen zeigen die sich nun mit dem Modell ergeben.
Es sollte deutlich anders als bisher aussehen, auch wenn es sicher noch Verbesserungspotenziale geben wird.
Es sollte deutlich anders als bisher aussehen, auch wenn es sicher noch Verbesserungspotenziale geben wird.
#14
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von TheTrumpeter - 07 August 2026, 13:14:09So, ich habe den Vormittag über noch weitere Anpassungen gemacht. Alle Empfehlungen, die von Gemini nun noch kommen, sind nicht umsetzbar bzw. sinnvoll.
Damit belasse ich das erstmal so und beobachte, wie es sich mit weiteren Daten zur Kühlung entwickelt.
### 📊 FANN-Analyse & Optimierungs-Bericht (Modul 76_SolarForecast.pm)
**Status des letzten Trainingslaufs (07.08.2026):** `Trainingsbewertung: Retrain`
* **Laufzeit:** 2.004 Sekunden (ca. 33 Min.) | **Algorithmus:** INCREMENTAL
* **Modell-Güte:** R² = 0.53 (Wärmepumpen-Grundstruktur steht felsenfest)
* **Fortschritt:** Das Lockern der Fehlertoleranz (`BitFail-Limit=0.36`) hat gegriffen. Die `Validation Bit_Fail` sind spürbar von 63 auf **48** gesunken. Das Lernverhalten ist mit **18.3 % Epochenausnutzung** sehr gesund.
---
#### 1. 🔍 Wo liegen aktuell die größten Schwachstellen?
* **Der unnachgiebige "Feature-Overkill" (`123 Inputs`):**
Das Netz wird mit Eingangskanälen überflutet. Die ideale 14-7-Architektur muss dadurch zu viele Verknüpfungen berechnen. Die echten, harten Schaltsignale der Wärmepumpe gehen mathematisch im Rauschen unter.
* **Starres, blockiertes Overfitting (`MSE diff = 0.006542 > 0.005`):**
Da das Netz durch die höhere Aktivierungssteilheit (`Steepness=1.5`) schärfer trennt, lernt es die Rauschkomponenten der 123 Inputs im Trainingsset noch präziser auswendig. Der Validierungsfehler zieht nicht nach und blockiert die Modulfreigabe.
* **Gedeckelte Modell-Steigung (`ModelSlope = 0.54`):**
Die Peak-Verbräuche der Wärmepumpe (z. B. Warmwasser- oder Heiztaktungen) werden im Forecast systematisch geglättet. Das harte Profilkriterium (`slope_min=0.60`) bleibt unerreichbar.
---
#### 2. 🛠� Die wirksamsten Maßnahmen mit dem größten Hebel
* **Maßnahme 1: Radikale Feature-Reduktion (Inputs reduzieren) ⬇️**
* *Hebel:* Dies ist die einzig verbleibende Stellschraube. Jedes gestrichene historische Feature (z. B. unbedeutende Vergangenheitsstunden) eliminiert dutzende synaptische Gewichte. Das Overfitting bricht zusammen und das Modul erteilt die Freigabe.
* **Maßnahme 2: Reduktion der Prognose-Features (Forecast-Horizonte reduzieren) ⬇️**
* *Hebel:* Verringert die Anzahl der parallel verarbeiteten Wetterstunden in die Zukunft, um die mathematische Last von den Eingangsschichten des Netzes zu nehmen.
---
#### 3. ⚠️ Hinweise auf strukturelle Probleme
* **Reine Datensättigung auf der Eingangsseite (Ausoptimiert):**
Es liegt kein Hyperparameter- oder Algorithmusproblem vor. Das Lernverhalten ist numerisch stabil, was die extrem geringe Standardabweichung der Validierung (`0.000020`) beweist. Das strukturelle Problem ist ausschließlich die mangelnde Relevanzdichte der 123 Eingangsdaten im FHEM-Modul. Jedes weitere Tuning an den Hyperparametern verschiebt nur noch Nachkommastellen.
---
#### 4. 🚀 Konkrete, umsetzbare nächste Schritte
Da das rein mathematische Netz-Tuning abgeschlossen ist, muss nun zwingend die FHEM-Konfiguration der Datenquellen angepasst werden, um die Freigabe zu erzwingen:
1. **Historienstunden im FHEM-Modul hart kappen:**
Suche in den Attributen des Moduls nach Parametern wie `aiConHistoryHours`. Falls dieser Wert auf 24 oder höher steht, konsequent auf **6 oder maximal 12 Stunden** herabsetzen. Verbrauchsmuster von vor über einem Tag enthalten für die Wärmepumpen-Steuerung keine verwertbare Signalstärke.
2. **Redundante Wetterdaten-Inputs deaktivieren:**
Überprüfe, ob mehrere Wetter- oder Strahlungsprognosen (z. B. DWD und Proplanta parallel) aktiv in das Netz einspeisen. Ungenutzte Kanäle abschalten. **Ziel: Beim nächsten Trainingsstart muss die Anzeige `Inputs` zweistellig sein (unter 90).**
3. **Architektur und Hyperparameter einfrieren:**
Belasse alle anderen Werte exakt so, wie sie jetzt sind (`14-7` Hidden Layers, `INCREMENTAL`, `Learning Rate = 0.0001`, `Momentum = 0.7`, `Steepness = 1.5`, `BitFail-Limit = 0.36`). Die Struktur passt perfekt, sobald die Inputs abgemagert sind.
4. **Abschließendes Training starten:**
Triggere nach der Bereinigung der Inputs ein manuelles Retrain. Die MSE-Differenz wird sofort unter 0.005 kollabieren, die Slope über 0.60 springen und die `Retrain`-Blockade gelöst.
Damit belasse ich das erstmal so und beobachte, wie es sich mit weiteren Daten zur Kühlung entwickelt.
### 📊 FANN-Analyse & Optimierungs-Bericht (Modul 76_SolarForecast.pm)
**Status des letzten Trainingslaufs (07.08.2026):** `Trainingsbewertung: Retrain`
* **Laufzeit:** 2.004 Sekunden (ca. 33 Min.) | **Algorithmus:** INCREMENTAL
* **Modell-Güte:** R² = 0.53 (Wärmepumpen-Grundstruktur steht felsenfest)
* **Fortschritt:** Das Lockern der Fehlertoleranz (`BitFail-Limit=0.36`) hat gegriffen. Die `Validation Bit_Fail` sind spürbar von 63 auf **48** gesunken. Das Lernverhalten ist mit **18.3 % Epochenausnutzung** sehr gesund.
---
#### 1. 🔍 Wo liegen aktuell die größten Schwachstellen?
* **Der unnachgiebige "Feature-Overkill" (`123 Inputs`):**
Das Netz wird mit Eingangskanälen überflutet. Die ideale 14-7-Architektur muss dadurch zu viele Verknüpfungen berechnen. Die echten, harten Schaltsignale der Wärmepumpe gehen mathematisch im Rauschen unter.
* **Starres, blockiertes Overfitting (`MSE diff = 0.006542 > 0.005`):**
Da das Netz durch die höhere Aktivierungssteilheit (`Steepness=1.5`) schärfer trennt, lernt es die Rauschkomponenten der 123 Inputs im Trainingsset noch präziser auswendig. Der Validierungsfehler zieht nicht nach und blockiert die Modulfreigabe.
* **Gedeckelte Modell-Steigung (`ModelSlope = 0.54`):**
Die Peak-Verbräuche der Wärmepumpe (z. B. Warmwasser- oder Heiztaktungen) werden im Forecast systematisch geglättet. Das harte Profilkriterium (`slope_min=0.60`) bleibt unerreichbar.
---
#### 2. 🛠� Die wirksamsten Maßnahmen mit dem größten Hebel
* **Maßnahme 1: Radikale Feature-Reduktion (Inputs reduzieren) ⬇️**
* *Hebel:* Dies ist die einzig verbleibende Stellschraube. Jedes gestrichene historische Feature (z. B. unbedeutende Vergangenheitsstunden) eliminiert dutzende synaptische Gewichte. Das Overfitting bricht zusammen und das Modul erteilt die Freigabe.
* **Maßnahme 2: Reduktion der Prognose-Features (Forecast-Horizonte reduzieren) ⬇️**
* *Hebel:* Verringert die Anzahl der parallel verarbeiteten Wetterstunden in die Zukunft, um die mathematische Last von den Eingangsschichten des Netzes zu nehmen.
---
#### 3. ⚠️ Hinweise auf strukturelle Probleme
* **Reine Datensättigung auf der Eingangsseite (Ausoptimiert):**
Es liegt kein Hyperparameter- oder Algorithmusproblem vor. Das Lernverhalten ist numerisch stabil, was die extrem geringe Standardabweichung der Validierung (`0.000020`) beweist. Das strukturelle Problem ist ausschließlich die mangelnde Relevanzdichte der 123 Eingangsdaten im FHEM-Modul. Jedes weitere Tuning an den Hyperparametern verschiebt nur noch Nachkommastellen.
---
#### 4. 🚀 Konkrete, umsetzbare nächste Schritte
Da das rein mathematische Netz-Tuning abgeschlossen ist, muss nun zwingend die FHEM-Konfiguration der Datenquellen angepasst werden, um die Freigabe zu erzwingen:
1. **Historienstunden im FHEM-Modul hart kappen:**
Suche in den Attributen des Moduls nach Parametern wie `aiConHistoryHours`. Falls dieser Wert auf 24 oder höher steht, konsequent auf **6 oder maximal 12 Stunden** herabsetzen. Verbrauchsmuster von vor über einem Tag enthalten für die Wärmepumpen-Steuerung keine verwertbare Signalstärke.
2. **Redundante Wetterdaten-Inputs deaktivieren:**
Überprüfe, ob mehrere Wetter- oder Strahlungsprognosen (z. B. DWD und Proplanta parallel) aktiv in das Netz einspeisen. Ungenutzte Kanäle abschalten. **Ziel: Beim nächsten Trainingsstart muss die Anzeige `Inputs` zweistellig sein (unter 90).**
3. **Architektur und Hyperparameter einfrieren:**
Belasse alle anderen Werte exakt so, wie sie jetzt sind (`14-7` Hidden Layers, `INCREMENTAL`, `Learning Rate = 0.0001`, `Momentum = 0.7`, `Steepness = 1.5`, `BitFail-Limit = 0.36`). Die Struktur passt perfekt, sobald die Inputs abgemagert sind.
4. **Abschließendes Training starten:**
Triggere nach der Bereinigung der Inputs ein manuelles Retrain. Die MSE-Differenz wird sofort unter 0.005 kollabieren, die Slope über 0.60 springen und die `Retrain`-Blockade gelöst.
#15
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von oelidoc - 07 August 2026, 12:08:05Hallo Heiko,
vielen Dank für deine wie immer super verständliche und ausführliche Erklärung.
Liebe Grüße
oelidoc
vielen Dank für deine wie immer super verständliche und ausführliche Erklärung.
Zitat von: DS_Starter am 07 August 2026, 11:56:22Akzeptieren, dass die letzten 10 % BMS‑Domäne sind:Ich werde deinen Rat befolgen und lediglich mal Set_LadeP_max=50 versuchen.
Liebe Grüße
oelidoc
#16
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 07 August 2026, 11:56:22Hallo Oelidoc,
ich habe zwar keine solche Anlage und kann keine Erfahrung einbringen, aber ich steuere mal das Ergebnis meiner kurzen Recherche bei.
Vielleicht hilft dir das schon etwas und kannst es mit BYD Usern verifizieren:
Du stößt vermutlich an Grenzen der SMA/BYD‑Logik, die SolarForecast nicht übersteuern kann.
Was vermutlich passiert
CmpBMS ist nur ein ,,Wunschzettel" an den WR:
Die Registergruppe 40793–40801 liefert dem STP SE Zielwerte (Set_LadeP_max, ChargeAbort etc.), aber der WR/BYD‑BMS darf diese ignorieren, wenn interne Schutz‑ oder Pflegealgorithmen greifen (Top‑Balancing, SoC‑Kalibrierung, Zellpflege). Das ist in den SMA‑Unterlagen sinngemäß so beschrieben: das Batteriemanagement hat Vorrang vor externen Vorgaben.
Set_LadeP_max=0 ist kein ,,hartes Stoppsignal":
Bei SMA steht 0 in vielen Leistungs‑Registern für ,,keine Begrenzung" bzw. ,,Default verwenden". Es ist gut möglich, dass der WR 0 bei Set_LadeP_max nicht als ,,Ladeleistung verbieten", sondern als ,,kein Limit" interpretiert und deshalb mit seiner internen Kennlinie weiter bis 100 % lädt.
Abort wirkt nur in bestimmten Modi:
Einige Abort‑Flags greifen nur bei Netzladung oder bestimmten Betriebsarten, nicht bei PV‑Direktladung oder bei vom BMS initiierten Pflegezyklen. Wenn der BYD‑BMS dem WR sagt ,,jetzt bitte vollmachen/top‑balancen", hat dieses Kommando Vorrang vor deinem Modbus‑Abort.
SMA/BYD wollen regelmäßig 100 % sehen:
Viele Hochvolt‑Speicher verlangen gelegentlich eine Vollladung, um Zellbalancing und SoC‑Kalibrierung zu machen. Das passiert typischerweise im Bereich 90–100 % und dauert genau in der Größenordnung, die du beobachtest (15–20 min). Externe Leistungsbegrenzungen werden in dieser Phase oft übersteuert.
Was du konkret tun kannst
Nicht mit 0 arbeiten, sondern mit kleinem Limit testen:
Statt Set_LadeP_max=0 z.B. einen sehr kleinen Wert (z.B. 50–100 W) schreiben und schauen, ob der WR dann tatsächlich die Ladeleistung reduziert. Wenn er dann brav begrenzt, weißt du: 0 bedeutet ,,kein Limit", nicht ,,Stop".
WR‑seitige SoC‑Ziele prüfen:
Im STP‑SE gibt es teils Einstellungen für ,,Betriebsreserve", ,,Backup‑Reserve" oder minimale/maximale SoC‑Ziele. Wenn dort z.B. 100 % als Ziel hinterlegt sind, wird der WR versuchen, das zu erreichen, egal was SolarForecast vorgibt.
Akzeptieren, dass die letzten 10 % BMS‑Domäne sind:
Für Verschleißreduzierung ist es meist ausreichend, den Akku im Alltag zwischen z.B. 20–90 % zu halten. Wenn BYD/SMA sich gelegentlich die 90–100 % für Balancing ,,nehmen", ist das eher positiv für Zellgesundheit und SoC‑Genauigkeit, auch wenn es deiner Wunschlogik widerspricht.
LG,
Heiko
ich habe zwar keine solche Anlage und kann keine Erfahrung einbringen, aber ich steuere mal das Ergebnis meiner kurzen Recherche bei.
Vielleicht hilft dir das schon etwas und kannst es mit BYD Usern verifizieren:
Du stößt vermutlich an Grenzen der SMA/BYD‑Logik, die SolarForecast nicht übersteuern kann.
Was vermutlich passiert
CmpBMS ist nur ein ,,Wunschzettel" an den WR:
Die Registergruppe 40793–40801 liefert dem STP SE Zielwerte (Set_LadeP_max, ChargeAbort etc.), aber der WR/BYD‑BMS darf diese ignorieren, wenn interne Schutz‑ oder Pflegealgorithmen greifen (Top‑Balancing, SoC‑Kalibrierung, Zellpflege). Das ist in den SMA‑Unterlagen sinngemäß so beschrieben: das Batteriemanagement hat Vorrang vor externen Vorgaben.
Set_LadeP_max=0 ist kein ,,hartes Stoppsignal":
Bei SMA steht 0 in vielen Leistungs‑Registern für ,,keine Begrenzung" bzw. ,,Default verwenden". Es ist gut möglich, dass der WR 0 bei Set_LadeP_max nicht als ,,Ladeleistung verbieten", sondern als ,,kein Limit" interpretiert und deshalb mit seiner internen Kennlinie weiter bis 100 % lädt.
Abort wirkt nur in bestimmten Modi:
Einige Abort‑Flags greifen nur bei Netzladung oder bestimmten Betriebsarten, nicht bei PV‑Direktladung oder bei vom BMS initiierten Pflegezyklen. Wenn der BYD‑BMS dem WR sagt ,,jetzt bitte vollmachen/top‑balancen", hat dieses Kommando Vorrang vor deinem Modbus‑Abort.
SMA/BYD wollen regelmäßig 100 % sehen:
Viele Hochvolt‑Speicher verlangen gelegentlich eine Vollladung, um Zellbalancing und SoC‑Kalibrierung zu machen. Das passiert typischerweise im Bereich 90–100 % und dauert genau in der Größenordnung, die du beobachtest (15–20 min). Externe Leistungsbegrenzungen werden in dieser Phase oft übersteuert.
Was du konkret tun kannst
Nicht mit 0 arbeiten, sondern mit kleinem Limit testen:
Statt Set_LadeP_max=0 z.B. einen sehr kleinen Wert (z.B. 50–100 W) schreiben und schauen, ob der WR dann tatsächlich die Ladeleistung reduziert. Wenn er dann brav begrenzt, weißt du: 0 bedeutet ,,kein Limit", nicht ,,Stop".
WR‑seitige SoC‑Ziele prüfen:
Im STP‑SE gibt es teils Einstellungen für ,,Betriebsreserve", ,,Backup‑Reserve" oder minimale/maximale SoC‑Ziele. Wenn dort z.B. 100 % als Ziel hinterlegt sind, wird der WR versuchen, das zu erreichen, egal was SolarForecast vorgibt.
Akzeptieren, dass die letzten 10 % BMS‑Domäne sind:
Für Verschleißreduzierung ist es meist ausreichend, den Akku im Alltag zwischen z.B. 20–90 % zu halten. Wenn BYD/SMA sich gelegentlich die 90–100 % für Balancing ,,nehmen", ist das eher positiv für Zellgesundheit und SoC‑Genauigkeit, auch wenn es deiner Wunschlogik widerspricht.
LG,
Heiko
#17
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von oelidoc - 07 August 2026, 11:31:37STP-SE + BYD HVS – WR ignoriert Set_LadeP_max=0 in Ladeschlussphase trotz aktivem loadAbort
Hallo zusammen,
ich betreibe SolarForecast v2.9.4 mit einem SMA STP 8.0-SE + BYD HVS 7.7 und steuere die Batterieladung über die CmpBMS-Registergruppe (40793-40801, OpMod 40236=1438). Modbus-Steuerung ist am WR aktiv (Modbus P-Vorgaben auf Eingang 2: Ein).
Ziel: Verschleißreduzierung durch smartPower + loadAbort=90:500:80, um die Batterie im Normalbetrieb nicht bis 100 % zu laden.
Beobachtung: Trotz aktivem Battery_ChargeAbort_01=1 und kontinuierlich geschriebenem Set_LadeP_max=0 (alle 70 s) lädt der WR die Batterie in ~15-20 Minuten von ~90 % auf 100 % durch.
Konfiguration:
ctrlBatSocManagement01:
careCycle=20
loadAbort=90:500:80
loadStrategy=smartPower
loadTarget=100
lowSoc=5
maxSoC=100
safetyMargin=0:0
upSoC=50
setupBatteryDev01:
pinmax=7680
pinreduced=400
poutmax=7680
Log der Steuerung (eigenes Skript, ruft batLoadMgmnt aus ctrlUserExitFn auf; dt = Sekunden seit letztem Aufruf):
10:40:10 chaMax=488W dt=70s
10:41:20 chaMax=1252W dt=69s
10:42:30 chaMax=1027W dt=54s
10:43:40 chaMax=0W dt=69s [ABORT] <- ChargeAbort greift bei SoC=93%
10:47:10 chaMax=0W dt=70s [ABORT]
10:48:20 chaMax=0W dt=69s [ABORT]
...
11:02:20 chaMax=0W dt=69s [ABORT] <- Akku bei 100%
Das Skript schreibt kontinuierlich und im erwarteten 70-s-Takt (kein Aussetzer). Die Registergruppe wird jedes Mal komplett geschrieben (BMS_Mode=1438 zuerst, dann LadeP_min=0, LadeP_max=0, EntladeP_min=0, EntladeP_max=7680, GridWSpt=0).
Was ich weiß:
Register sind WriteOnly (Rücklese-Reading zeigt immer 4294967295 – ignoriert)
Das Schreiben funktioniert grundsätzlich: In früheren Ladephasen hat chaMax=0 den WR nachweislich gestoppt (real geprüft am Current_PowerBatIn_01).
Der SunnyHomeManager ist NICHT im prognosebasierten Ladebetrieb (SunnyPortal deaktiviert)
Netzsystemdienstleistungen umsetzen: Nein (im WR)
SoH der Batterie: 95 %
daysUntilBatteryCare_01=12 (also kein SF-seitiger Wartungszyklus fällig)
Frage:
Kennt jemand dieses Verhalten? Ignoriert der STP-SE / BYD in der Ladeschlussphase (letzte ~10 % SoC) externe BatChaMaxW-Vorgaben, evtl. wegen interner Zellbalancierung? Gibt es eine bekannte Kombination von Registern (z.B. OpMod-Wert oder zusätzliches Register), um das zuverlässiger zu unterbinden?
Vielen Dank für jeden Hinweis!
Gruß
oelidoc
Hallo zusammen,
ich betreibe SolarForecast v2.9.4 mit einem SMA STP 8.0-SE + BYD HVS 7.7 und steuere die Batterieladung über die CmpBMS-Registergruppe (40793-40801, OpMod 40236=1438). Modbus-Steuerung ist am WR aktiv (Modbus P-Vorgaben auf Eingang 2: Ein).
Ziel: Verschleißreduzierung durch smartPower + loadAbort=90:500:80, um die Batterie im Normalbetrieb nicht bis 100 % zu laden.
Beobachtung: Trotz aktivem Battery_ChargeAbort_01=1 und kontinuierlich geschriebenem Set_LadeP_max=0 (alle 70 s) lädt der WR die Batterie in ~15-20 Minuten von ~90 % auf 100 % durch.
Konfiguration:
ctrlBatSocManagement01:
careCycle=20
loadAbort=90:500:80
loadStrategy=smartPower
loadTarget=100
lowSoc=5
maxSoC=100
safetyMargin=0:0
upSoC=50
setupBatteryDev01:
pinmax=7680
pinreduced=400
poutmax=7680
Log der Steuerung (eigenes Skript, ruft batLoadMgmnt aus ctrlUserExitFn auf; dt = Sekunden seit letztem Aufruf):
10:40:10 chaMax=488W dt=70s
10:41:20 chaMax=1252W dt=69s
10:42:30 chaMax=1027W dt=54s
10:43:40 chaMax=0W dt=69s [ABORT] <- ChargeAbort greift bei SoC=93%
10:47:10 chaMax=0W dt=70s [ABORT]
10:48:20 chaMax=0W dt=69s [ABORT]
...
11:02:20 chaMax=0W dt=69s [ABORT] <- Akku bei 100%
Das Skript schreibt kontinuierlich und im erwarteten 70-s-Takt (kein Aussetzer). Die Registergruppe wird jedes Mal komplett geschrieben (BMS_Mode=1438 zuerst, dann LadeP_min=0, LadeP_max=0, EntladeP_min=0, EntladeP_max=7680, GridWSpt=0).
Was ich weiß:
Register sind WriteOnly (Rücklese-Reading zeigt immer 4294967295 – ignoriert)
Das Schreiben funktioniert grundsätzlich: In früheren Ladephasen hat chaMax=0 den WR nachweislich gestoppt (real geprüft am Current_PowerBatIn_01).
Der SunnyHomeManager ist NICHT im prognosebasierten Ladebetrieb (SunnyPortal deaktiviert)
Netzsystemdienstleistungen umsetzen: Nein (im WR)
SoH der Batterie: 95 %
daysUntilBatteryCare_01=12 (also kein SF-seitiger Wartungszyklus fällig)
Frage:
Kennt jemand dieses Verhalten? Ignoriert der STP-SE / BYD in der Ladeschlussphase (letzte ~10 % SoC) externe BatChaMaxW-Vorgaben, evtl. wegen interner Zellbalancierung? Gibt es eine bekannte Kombination von Registern (z.B. OpMod-Wert oder zusätzliches Register), um das zuverlässiger zu unterbinden?
Vielen Dank für jeden Hinweis!
Gruß
oelidoc
#18
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 07 August 2026, 11:18:03Zitatwenn der Lademodus (PV-Überschuss) implementiert würde, ergäbe sich die Frage wann das BEV geladen wird eventuell aus einem Schwellwert des SoC und der PV-Prognose wann Überschusskapazität in Relation zum prognostizierten Hausverbrauch zur Verfügung stünde.Absolut richtig. Schwellenwert brauchen wir nicht einmal, das macht die KI für uns.
Aber die grundlegende Schwierigkeit ist, dass der SOC der BEV-Batterie erst dann verfügbar ist wenn der BEV angesteckt ist. Für eine Prognose im Vorfeld - also noch kein BEV angeschlossen, aber wir wollen trotzdem vorhersagen wann er geladen wird - fehlt diese Info einfach.
ZitatFür normale BEV Ladung müsste eventuell für den Nutzer ein Schlüssel eingeführt werden, in dem er sein Ladeverhalten als Profil grundsätzlich skizzieren kann.Ja, das ist eine gute Idee. Dort könnte ein "Einsatzplan" hinterlegt werde, also wann plane ich als Nutzer typischerweise die Aufladung meines EV.
Diese Daten müssen natürlich einigermaßen praktikabel hinterlegbar sein. Sie werden dann auch in der Langzeitspeicherung im stündlichen Datensatz gespeichert, damit der Zusammenhang im Training vorhanden ist.
Das wäre ein "Planbit".
Konzeptionell: Matcht die aktuelle Stunde mit dem hinterlegten "Einsatzplan"? -> Ja? "Planbit=1" -> Nein? "Planbit=0"
Diese Info wird für eine KI sehr wertvoll sein, denn sie steht sowohl im Trainining, als auch für eine Prognose zusammen mit PV/Überschuß-Prognose (Prio/Auto-Bit) zur Verfügung.
Einzig der SOC bleibt ein Problem.
LG,
Heiko
#19
Solaranlagen / Aw: PowerFlow [animiertes SVG,...
Letzter Beitrag von schwatter - 07 August 2026, 11:17:04Moin,
noch ein kleines Update. Momentan werden beim Seitenaufruf initial die Werte mit dem devSateIcon an das SVG übertragen. Danach lauscht das SVG
mit addInformIdHandler nach neuen Werten. Öffnet sich das Enddevice (bei mir das Tablet) zu einem ungünstigen Zeit, dann wurde der letzte Event
verpasst und der jeweilige Ring bekommt erst mit dem nächsten Event ein Update.
Dem entgegen steht jetzt addEventListener("visibilitychange", (). Damit werden jetzt Readingwerte auch aktualisiert wenn:
Gruß schwatter
noch ein kleines Update. Momentan werden beim Seitenaufruf initial die Werte mit dem devSateIcon an das SVG übertragen. Danach lauscht das SVG
mit addInformIdHandler nach neuen Werten. Öffnet sich das Enddevice (bei mir das Tablet) zu einem ungünstigen Zeit, dann wurde der letzte Event
verpasst und der jeweilige Ring bekommt erst mit dem nächsten Event ein Update.
Dem entgegen steht jetzt addEventListener("visibilitychange", (). Damit werden jetzt Readingwerte auch aktualisiert wenn:
- der Benutzer auf einen anderen Tab wechselt.
- das Browserfenster minimiert wird.
- der Benutzer wieder zum Tab zurück kommt.
- das Tablet den Bildschirmschoner beendet
Gruß schwatter
#20
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von gameshacker - 07 August 2026, 10:54:40Hallo zusammen,
ich habe Probleme beim einbinden von einer Shelly Bulb Gen3.
Automatisch wird die Glühbirne als Generic gesetzt.
Ich habe nun das model auf shellybulbg3 gesetzt.
Die ID lautet shellycolorblbg3-48f6eeaab964
Als Generic gibts diese ausgabe
klingt erstmal das dieses Gerät nicht erkannt wird.
Wenn ich nun das Model setze gibt es diese ausgabe:
Also er füllt einiges aus, allerdings wen ich set Stehlampe ON eintrage, gibt es den Error:
error
404: No handler for Light.Set
Gibt es eine Möglichkeit die Glühbirne über Fhem zu steuern.
MQTT funktioniert auch noch nicht.
Die Gerätebezeichnung lautet: Multicolor Bulb E27 Gen3
Viele Grüße Gameshacker
ich habe Probleme beim einbinden von einer Shelly Bulb Gen3.
Automatisch wird die Glühbirne als Generic gesetzt.
Ich habe nun das model auf shellybulbg3 gesetzt.
Die ID lautet shellycolorblbg3-48f6eeaab964
Als Generic gibts diese ausgabe
Code Auswählen
Shelly Stehlampe mac: xx:xx:xx:xx:xx:xx
Shelly Stehlampe model_ID: S3BL-C010007AEU
Shelly Stehlampe model_family: Gen3
Shelly Stehlampe model_function: bulb
Shelly Stehlampe type key not found, set to "generic"
Shelly Stehlampe login: open
Shelly Stehlampe error: Stehlampe: error in command: id or component not found
Shelly Stehlampe Error
Shelly Stehlampe error: error in command: id or component not found
klingt erstmal das dieses Gerät nicht erkannt wird.
Wenn ich nun das Model setze gibt es diese ausgabe:
Code Auswählen
setstate Stehlampe model already defined as 'shellybulbg3', might be generic
setstate Stehlampe 2026-08-07 10:25:53 ap disabled open
setstate Stehlampe 2026-08-07 10:25:53 ap_clients disabled
setstate Stehlampe 2026-08-07 10:25:53 ap_name ShellyColorBlbG3-48F6EEAAB964
setstate Stehlampe 2026-08-07 10:25:53 auto_off disabled
setstate Stehlampe 2026-08-07 10:25:53 auto_on disabled
setstate Stehlampe 2026-08-07 10:25:53 ble error
setstate Stehlampe 2026-08-07 10:25:53 ble_rpc -
setstate Stehlampe 2026-08-07 10:25:53 cloud disabled
setstate Stehlampe 2026-08-07 10:25:53 eco_mode -
setstate Stehlampe 2026-08-07 10:46:32 error 404: No handler for Light.Set
setstate Stehlampe 2026-08-07 10:25:53 firmware_ID 20260710-101058/2.0.0-g87fbfa4
setstate Stehlampe 2026-08-07 10:25:53 firmware_current v2.0.0
setstate Stehlampe 2026-08-07 10:26:55 firmware_updIcon OK
setstate Stehlampe 2026-08-07 10:26:55 firmware_updText -/-
setstate Stehlampe 2026-08-07 10:48:48 login open
setstate Stehlampe 2026-08-07 10:48:48 mac xx:xx:xx:xx:xx:xx
setstate Stehlampe 2026-08-07 10:48:48 model_ID S3BL-C010007AEU
setstate Stehlampe 2026-08-07 10:48:48 model_family Gen3
setstate Stehlampe 2026-08-07 10:48:48 model_function bulb
setstate Stehlampe 2026-08-07 10:25:53 network <html>connected to <a href="http://x.x.x.x">x.x.x.x</a> (Wifi)</html>
setstate Stehlampe 2026-08-07 10:24:53 network_DNS -
setstate Stehlampe 2026-08-07 10:25:53 network_connection online
setstate Stehlampe 2026-08-07 10:25:53 network_ip-address 10.0.30.82
setstate Stehlampe 2026-08-07 10:49:15 network_rssi -65
setstate Stehlampe 2026-08-07 10:25:53 network_ssid IOT_mpk
setstate Stehlampe 2026-08-07 10:25:53 network_wifi_roaming -80
setstate Stehlampe 2026-08-07 10:25:53 protection none
setstate Stehlampe 2026-08-07 10:25:53 restart_required false
setstate Stehlampe 2026-08-07 10:34:59 rgb 000000
setstate Stehlampe 2026-08-07 10:34:59 rgbw 00000000
setstate Stehlampe 2026-08-07 10:30:03 scripts 0
setstate Stehlampe 2026-08-07 10:48:48 state model already defined as 'shellybulbg3', might be generic
setstate Stehlampe 2026-08-07 10:49:15 uptime 131450
setstate Stehlampe 2026-08-07 10:25:53 webhook_cnt 0 / 0 / 0
setstate Stehlampe 2026-08-07 10:25:53 webhook_ver 0
setstate Stehlampe 2026-08-07 10:34:59 white 0Also er füllt einiges aus, allerdings wen ich set Stehlampe ON eintrage, gibt es den Error:
error
404: No handler for Light.Set
Gibt es eine Möglichkeit die Glühbirne über Fhem zu steuern.
MQTT funktioniert auch noch nicht.
Die Gerätebezeichnung lautet: Multicolor Bulb E27 Gen3
Viele Grüße Gameshacker