- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#41
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 12 Dezember 2025, 13:46:22Hallo Wolle02,
Eine Verringerung des Soll-SoC wird sofort umgesetzt.
Nachverfolgen kann man es mit dem Debug "batteryManagement".
Wenn diese Erwartung nicht erfüllt wird, sei es durch weniger PV oder mehr Verbrauch als erwartet, erhöht sich der SoC nicht wie erwartet und durch die evtl. neue Ziel-SoC Erhöhung um 5% ist der SoC unter Soll-SoC. Je nach Verhalten des BMS kann eine Unterschreitung des Soll-SoC um X % das BMS veranlassen eine Ladung aus dem Netz vorzunehmen. Eventuell kann man die Schwelle des BMS einstellen ab wann es mit Nachladung reagiert.
Jetzt kommt es darauf an wie dein BMS gebaut ist. Wenn es beispielsweise mit Prozentwerten arbeitet, könntest du im Modul die Schrittweite der SoC-Anpassung verkleinern mit ctrlBatSocManagementXX->stepSoC.
Beachte dabei aber den Zusammenhang careCycle * stepSoC = 100 wie in der Hilfe erwähnt.
Dadurch wird die Wahrscheinlichkeit erhöht, dass eine Ladung durch PV doch noch z.B. innerhalb der nächsten 3 Tage auf den erhöhten Soll-SoC erfolgt ohne dass sich das BMS veranlasst fühlt mit Netzstrom zu laden.
LG,
Heiko
Zitatkann man eigentlich den Zeitpunkt an dem der OTP-SoC neu berechnet und eingestellt wird irgendwo einstellen oder fixieren?Der opt. SoC wird ständig neu berechnet, aber erst nach der halben Strecke zwischen Sonnenauf- und Untergang aktiviert sofern der neue SoC höher als der alte Sollwert ist. Die care Zeit spielt auch noch eine Rolle.
Eine Verringerung des Soll-SoC wird sofort umgesetzt.
Nachverfolgen kann man es mit dem Debug "batteryManagement".
Code Auswählen
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> today -> PV fc: 859 Wh, con till sunset: 1884 Wh, Surp: -1025 Wh
2025.12.12 13:22:09.012 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> tomorrow -> PV fc: 4704 Wh, con till sunset: 13906 Wh, Surp: -5726 Wh (75% con)
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> selected energy for charging (the higher positive Surp value from above): 0 Wh
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - basics -> expected energy for charging after application Share factor: 0 Wh
2025.12.12 13:22:09.013 1: SolCast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 45 %
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 0 Wh, need until maxsoc: 1421 Wh
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 10 %, remain days until care SoC: 19, Target: 45 %
2025.12.12 13:22:09.014 1: SolCast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: 100 %, newtarget: 45 %
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 0, Target: 45 % (no change)
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step4 Bat 01 - basics -> docare: 0, lowSoc: 10 %, upSoc: 50 %
2025.12.12 13:22:09.015 1: SolCast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 45 %
2025.12.12 13:22:09.016 1: SolCast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 45 %
2025.12.12 13:22:09.016 1: SolCast DEBUG> SoC Step6 Bat 01 - force charging request: no (Battery is sufficiently charged)
ZitatAm Anfang war er zum Ende des Sonnentages, so um den Sonnenuntergang herum, dann war er plötzlich um Mitternacht und aktuell ist er morgens um halb sechs. Das führt dazu, dass die Batterie dann Nachts plötzlich auf einen bestimmten SoC-Wert entladen wird, nur um dann ein paar Stunden später mittels Zwangsladung aus dem Netz wieder auf einen neuen SoC geladen zu werden.Wenn ich dich richtig verstehe, steht die Batterie morgens durch die Entladeprozesse auf dem gesenkten Soll-SoC. Das ist richtig, weil erwartet wurde, dass die Batterie über den kommenden Tag wieder aufgeladen wird.
Wenn diese Erwartung nicht erfüllt wird, sei es durch weniger PV oder mehr Verbrauch als erwartet, erhöht sich der SoC nicht wie erwartet und durch die evtl. neue Ziel-SoC Erhöhung um 5% ist der SoC unter Soll-SoC. Je nach Verhalten des BMS kann eine Unterschreitung des Soll-SoC um X % das BMS veranlassen eine Ladung aus dem Netz vorzunehmen. Eventuell kann man die Schwelle des BMS einstellen ab wann es mit Nachladung reagiert.
Jetzt kommt es darauf an wie dein BMS gebaut ist. Wenn es beispielsweise mit Prozentwerten arbeitet, könntest du im Modul die Schrittweite der SoC-Anpassung verkleinern mit ctrlBatSocManagementXX->stepSoC.
Beachte dabei aber den Zusammenhang careCycle * stepSoC = 100 wie in der Hilfe erwähnt.
Dadurch wird die Wahrscheinlichkeit erhöht, dass eine Ladung durch PV doch noch z.B. innerhalb der nächsten 3 Tage auf den erhöhten Soll-SoC erfolgt ohne dass sich das BMS veranlasst fühlt mit Netzstrom zu laden.
LG,
Heiko
#42
Automatisierung / Aw: Unerklärlicher Zustand im ...
Letzter Beitrag von ch.eick - 12 Dezember 2025, 13:42:31Zitat von: passibe am 12 Dezember 2025, 13:33:30Das hier ist doch gar kein Gast?Ich habe es nur geschrieben, da das gleiche auch bei einem Gast sein könnte und es somit zusammenhängend ist.Zitat von: Marko1976 am 09 Dezember 2025, 19:16:34TYPE ROOMMATE
Mein Problem war ähnlich und ich wuste das mit dem gone/none nicht
#43
Automatisierung / Aw: Fehlende Logeinträge im Fi...
Letzter Beitrag von passibe - 12 Dezember 2025, 13:39:31Wieso deine Trigger mit state nicht funktionieren wurde dir doch schon 2x in dem anderen Thread erklärt?
https://forum.fhem.de/index.php?topic=143291.msg1353509#msg1353509
Erste Anlaufstelle ist, wie ich drüben schon gesagt habe, der Event Monitor. Dort kannst du mittels Markieren der Zeile und "Create/Modify Device" auch direkt die richtige Regex sehen.
https://forum.fhem.de/index.php?topic=143291.msg1353509#msg1353509
Erste Anlaufstelle ist, wie ich drüben schon gesagt habe, der Event Monitor. Dort kannst du mittels Markieren der Zeile und "Create/Modify Device" auch direkt die richtige Regex sehen.
#44
Automatisierung / Aw: Fehlende Logeinträge im Fi...
Letzter Beitrag von frober - 12 Dezember 2025, 13:36:06Ist Quatsch, hab's verwechselt
#45
Automatisierung / Aw: Unerklärlicher Zustand im ...
Letzter Beitrag von passibe - 12 Dezember 2025, 13:33:30 #46
Automatisierung / Aw: Unerklärlicher Zustand im ...
Letzter Beitrag von ch.eick - 12 Dezember 2025, 13:24:05Zitat von: CoolTux am 09 Dezember 2025, 19:25:10Verreist oder auch gone wird genommen wenn absent länger wie 32 Stunden oder so steht. Schau mal in die Commandref da sollte es gut erklärt sein.Moin,
bei Gästen wird anstelle von gone der Status auf none gesetzt, das hatten wir gerade in dem anderen Thread.
Dann sollte man noch "eventMap home:zuhause absent:abwesend none:verreist gotosleep:bettfertig asleep:schläft awoken:aufgestanden" setzen, damit es richtig im Gast angezeigt wird.
VG Christian
#47
Solaranlagen / Anbindung Solakon One mit Fhem
Letzter Beitrag von rippi46 - 12 Dezember 2025, 13:23:58Hallo ,
habe seit ein paar Tagen einen Solakon One Batteriespeicher mit itegriertem Wechselrichter.
Die Einrichtung mit der Solakon App auf dem Handy hat relativ einfach und problemlos funktioniert.
Jetzt wollte ich aber ähnlich wie beim Deye Wechselrichter (Deye SUN-M200G4-EU-Q0) auch die Werte in fhem erfassen und grafisch darstellen.
Da es eine HA-Integration schon gibt ich aber nicht zweierlei Systeme betreiben wollte und ich in fhem noch nichts gefunden hatte,
habe ich versucht schon einmal die meisten Werte auszulesen. Falls es jemand gebrauchen kann ist hier meine RAW-Definition.
Gruß rippi
habe seit ein paar Tagen einen Solakon One Batteriespeicher mit itegriertem Wechselrichter.
Die Einrichtung mit der Solakon App auf dem Handy hat relativ einfach und problemlos funktioniert.
Jetzt wollte ich aber ähnlich wie beim Deye Wechselrichter (Deye SUN-M200G4-EU-Q0) auch die Werte in fhem erfassen und grafisch darstellen.
Da es eine HA-Integration schon gibt ich aber nicht zweierlei Systeme betreiben wollte und ich in fhem noch nichts gefunden hatte,
habe ich versucht schon einmal die meisten Werte auszulesen. Falls es jemand gebrauchen kann ist hier meine RAW-Definition.
Code Auswählen
efmod SolakonOne ModbusAttr 1 30 192.168.178.150:502 TCP
attr SolakonOne dev-h defPoll=1
attr SolakonOne dev-i defPoll=1
attr SolakonOne enableControlSet 1
attr SolakonOne event-min-interval .*:600
attr SolakonOne event-on-change-reading .*
attr SolakonOne icon solar
attr SolakonOne maxTimeoutsToReconnect 3
attr SolakonOne obj-h30000 I_Model, len=16, unpack=(a16)
attr SolakonOne obj-h30016 I_SerialNumber, len=16, unpack=(a16)
attr SolakonOne obj-h30032 I_Manufacturer, len=16, unpack=(a16)
attr SolakonOne obj-h37611 B1_Average_Temperature, expr=$val / 10, revRegs=1, type=signed short big
attr SolakonOne obj-h37612 bms1_soc, expr=$val / 1, type=signed short big
attr SolakonOne obj-h37617 B2_Average_Temperature, expr=$val / 10, revRegs=1, type=unsigned short big
attr SolakonOne obj-h37618 B3_Average_Temperature, expr=$val / 10, revRegs=1, type=signed short big
attr SolakonOne obj-h37635 bms1_design_energy, expr=$val / .1, type=signed short big
attr SolakonOne obj-h38322 bms1_soh, expr=$val / 1, type=signed short big
attr SolakonOne obj-h39000 protocol_version, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39053 rated_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39055 max_active_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39070 pv1_voltage, expr=$val / 10, unpack=s>
attr SolakonOne obj-h39071 pv1_current, expr=$val / 100, unpack=s>
attr SolakonOne obj-h39072 pv2_voltage, expr=$val / 10, unpack=s>
attr SolakonOne obj-h39073 pv2_current, expr=$val / 100, unpack=s>
attr SolakonOne obj-h39118 total_pv_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39134 active_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39141 internal_temp, expr=$val / 10, revRegs=1, type=signed short big
attr SolakonOne obj-h39149 cumulative_generation, expr=$val, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39201 eps_voltage, expr=$val / 10, revRegs=1, type=signed short big
attr SolakonOne obj-h39204 eps_current, expr=$val / 10, revRegs=1, type=signed short big
attr SolakonOne obj-h39216 eps_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39227 battery_voltage, expr=$val / 10, revRegs=1, type=signed short big
attr SolakonOne obj-h39228 battery_current, expr=$val / 1000, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39230 battery_power, expr=$val, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39237 battery_combined_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39279 pv1_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39281 pv2_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39316 daily_generation, expr=$val, len=2, revRegs=1, unpack=s>s>
attr SolakonOne obj-h39424 battery_soc, expr=$val, unpack=s>
attr SolakonOne obj-h46003 remote_active_power, expr=$val / 1, len=2, revRegs=1, unpack=s>s>
attr SolakonOne room Balkonkraftwerk,Haus_Oberweier
attr SolakonOne silentReconnect 1
attr SolakonOne sortUpdate 1Gruß rippi
#48
Sonstige Systeme / Aw: Netatmo Modul - 38_netatmo...
Letzter Beitrag von tomcat.x - 12 Dezember 2025, 13:20:33flydd ist ja nicht der Entwickler des Moduls, also war ich auch nicht davon ausgegangen, dass der Stand ins SVN hochgeladen wurde. Daher habe ich eine Ausnahme für Update definiert.
#49
Sonstiges / Aw: Neue Versionen und Support...
Letzter Beitrag von Elektron - 12 Dezember 2025, 12:41:18Hallo zusammen,
Hat sich jemand die Modbus Anbindung eines Venus E von Marstek umgesetzt?
Wäre sehr interessiert, wenn das jemand teilen könnte?
Vielen Dank und Grüße Michael
Hat sich jemand die Modbus Anbindung eines Venus E von Marstek umgesetzt?
Wäre sehr interessiert, wenn das jemand teilen könnte?
Vielen Dank und Grüße Michael
#50
FHEM Development / Aw: FHEM auf OpenWrt
Letzter Beitrag von betateilchen - 12 Dezember 2025, 12:25:57Du bemerkt auf Deiner github Seite mehrere Dinge, die Dir aufgrund der Verzeichnis- und Dateistruktur das Leben bei der Umsetzung schwer machen.
Was ich nicht verstehe: warum tust Du Dir den ganzen Stress mit den verteilten Dateien an? Würdest Du die Umsetzung anstatt mit Konfigurationsdateien mit einer sqlite Datenbank durchführen, wären ein Großteil Deiner Probleme nicht mehr existent.
Diese Mechanismen sind alle bereits implementiert und funktionieren seit über 11 Jahren stabil.
Und wenn man das Ganze statt in ein lokales sqlite auf einen MariaDB Server ablegt, kann diese Datenbank sogar außerhalb der OpenWRT Plattform liegen
Dass man jetzt bei einem solch grundlegenden Umbau von FHEM wieder anfängt, diesen Dateien-Wust abzubilden, geht mir nicht in den Kopf.
Was ich nicht verstehe: warum tust Du Dir den ganzen Stress mit den verteilten Dateien an? Würdest Du die Umsetzung anstatt mit Konfigurationsdateien mit einer sqlite Datenbank durchführen, wären ein Großteil Deiner Probleme nicht mehr existent.
- uniqueId wird in der Datenbank gespeichert
- gplot Dateien für SVG kämen aus der Datenbank
- das statefile wäre in der Datenbank
- modulbezogene Dateien diverser Module (z.B. holiday, RSS, InfoPanel) lägen in der Datenbank
- 99_myUtils.pm könnte in der Datenbank liegen (entscheidet der Anwender selbst)
Diese Mechanismen sind alle bereits implementiert und funktionieren seit über 11 Jahren stabil.
Und wenn man das Ganze statt in ein lokales sqlite auf einen MariaDB Server ablegt, kann diese Datenbank sogar außerhalb der OpenWRT Plattform liegen
Dass man jetzt bei einem solch grundlegenden Umbau von FHEM wieder anfängt, diesen Dateien-Wust abzubilden, geht mir nicht in den Kopf.