- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
FHEM Development / Aw: FHEM auf OpenWrt
Letzter Beitrag von jw2013 - 12 Dezember 2025, 14:43:45Warum nur tue ich mir den Stress mit den verteilten Dateien an, gute Frage... Ein paar Gründe gäbe es da schon:
configDB benötigt Text::Diff
Es existiert aktuell noch kein perl-text-diff Paket für OpenWrt. Ich werde es bei Gelegenheit ins OpenWrt Packages Repository einfügen, allerdings erscheint es dann nicht mehr rückwirkend für 24.10 oder ältere Distributionen, da diese für neue Pakete bereits gesperrt sind.
Da das Text::Diff Modul aber keinen compilierten Code enthält, könnte ich das Paket als (arch=all) zu meinen FHEM Paketen hinzufügen.
configDB benötigt DBI
Es existiert aktuell ein perl-dbi Paket, allerdings existieren keine perl-dbd Pakete, und der Maintainer ist m.W.n. seit über 5 Jahren inaktiv
DBD::SQLlite für Perl auf OpenWrt
Das Modul gibt es für OpenWrt (noch) nicht. Ich werde das bei Gelegenheit auch angehen, aber anders als bei Text::Diff gibt es hier keine schnelle Lösung. Das Paket muss für die jeweilige Architektur kompiliert werden (arch=all geht hier nicht), und man müsste das auch erst so umpatchen, dass es die System-weite libsqlite3 verwendet, an Stelle der im Perl-Paket enhaltenen sqlite3.c mit ihren fast 10 MB(!). Debian macht das übrigens auch.
Es gibt keine Möglichkeit, dass das Paket offiziell für die aktuelle Release 24.10 released wird.
An der Stelle ist die Show erst mal zu Ende, aber es gibt noch weitere Gründe...
Die libsqlite3 Pakete sind ohne Perl-Bindings schon größer als die von FHEM inklusive FHEMWEB
Kann man einfach nachvollziehen, die installierte Größe entspricht auf Geräten mit SquashFS und UBIFS etwas der Größe der Installations-Pakete.
z.B. https://downloads.openwrt.org/releases/packages-24.10/mipsel_24kc/packages/
Bei Verwendung von DBI mit SQLite steigt der Speicherbedarf von FHEM dauerhaft um mehrere MB an
Viele Access Points haben insgesamt nur 128 MB RAM, da tut das schon weh...
Der Flash Speicher in diesen Geräte sollte nicht unnötig beschrieben werden
SQLite verursacht aufgrund seiner Architektur bei jedem Update mehrere Schreib-Zugriffe.
Auch gehören das statefile und die Cache-Dateien nicht ins Flash.
Selbst bei den Text-Config-Dateien von FHEM sehe ich hier noch Optimierungs-Potenzial, das save Kommando sollte z.B. nur Dateien überschreiben, die sich tatsächlich geändert haben.
Soweit die _aktuellen_ Gründe, für die Zukunft plane ich aber auch die Unterstützung von configDB ein. OpenWrt läuft ja nicht nur auf Routern, sondern auch auf PC-artigen Geräten!
Falls Interesse besteht, sollte man sich mal mit den Themen Squashfs (sehr gute Kompression) und UBIFS (gute Kompression) beschäftigen. OpenWrt verwendet diese beiden Dateisysteme auf Routern mit Flash-Speicher, während auf x86, Raspberry etc. 'normale' Dateisysteme zum Einsatz kommen.
Hoffe das erklärts für's Erste
configDB benötigt Text::Diff
Es existiert aktuell noch kein perl-text-diff Paket für OpenWrt. Ich werde es bei Gelegenheit ins OpenWrt Packages Repository einfügen, allerdings erscheint es dann nicht mehr rückwirkend für 24.10 oder ältere Distributionen, da diese für neue Pakete bereits gesperrt sind.
Da das Text::Diff Modul aber keinen compilierten Code enthält, könnte ich das Paket als (arch=all) zu meinen FHEM Paketen hinzufügen.
configDB benötigt DBI
Es existiert aktuell ein perl-dbi Paket, allerdings existieren keine perl-dbd Pakete, und der Maintainer ist m.W.n. seit über 5 Jahren inaktiv
DBD::SQLlite für Perl auf OpenWrt
Das Modul gibt es für OpenWrt (noch) nicht. Ich werde das bei Gelegenheit auch angehen, aber anders als bei Text::Diff gibt es hier keine schnelle Lösung. Das Paket muss für die jeweilige Architektur kompiliert werden (arch=all geht hier nicht), und man müsste das auch erst so umpatchen, dass es die System-weite libsqlite3 verwendet, an Stelle der im Perl-Paket enhaltenen sqlite3.c mit ihren fast 10 MB(!). Debian macht das übrigens auch.
Es gibt keine Möglichkeit, dass das Paket offiziell für die aktuelle Release 24.10 released wird.
An der Stelle ist die Show erst mal zu Ende, aber es gibt noch weitere Gründe...
Die libsqlite3 Pakete sind ohne Perl-Bindings schon größer als die von FHEM inklusive FHEMWEB
Kann man einfach nachvollziehen, die installierte Größe entspricht auf Geräten mit SquashFS und UBIFS etwas der Größe der Installations-Pakete.
z.B. https://downloads.openwrt.org/releases/packages-24.10/mipsel_24kc/packages/
Bei Verwendung von DBI mit SQLite steigt der Speicherbedarf von FHEM dauerhaft um mehrere MB an
Viele Access Points haben insgesamt nur 128 MB RAM, da tut das schon weh...
Der Flash Speicher in diesen Geräte sollte nicht unnötig beschrieben werden
SQLite verursacht aufgrund seiner Architektur bei jedem Update mehrere Schreib-Zugriffe.
Auch gehören das statefile und die Cache-Dateien nicht ins Flash.
Selbst bei den Text-Config-Dateien von FHEM sehe ich hier noch Optimierungs-Potenzial, das save Kommando sollte z.B. nur Dateien überschreiben, die sich tatsächlich geändert haben.
Soweit die _aktuellen_ Gründe, für die Zukunft plane ich aber auch die Unterstützung von configDB ein. OpenWrt läuft ja nicht nur auf Routern, sondern auch auf PC-artigen Geräten!
Falls Interesse besteht, sollte man sich mal mit den Themen Squashfs (sehr gute Kompression) und UBIFS (gute Kompression) beschäftigen. OpenWrt verwendet diese beiden Dateisysteme auf Routern mit Flash-Speicher, während auf x86, Raspberry etc. 'normale' Dateisysteme zum Einsatz kommen.
Hoffe das erklärts für's Erste
#2
Multimedia / Aw: Modul Sonos - Layout / Anz...
Letzter Beitrag von Fabiango - 12 Dezember 2025, 13:52:47Kann mir jemand zur Anpassung der Ansicht weiterhelfen oder Ideen wo ich genau danach suchen kann?
Oder verwendet keiner mehr das Modul sondern eher Sonos2Mqtt?
(Habe damit jedoch keine gute Erfahrung gemacht - Sonos Box war nicht mehr über die Sonos App erreichbar)
Oder verwendet keiner mehr das Modul sondern eher Sonos2Mqtt?
(Habe damit jedoch keine gute Erfahrung gemacht - Sonos Box war nicht mehr über die Sonos App erreichbar)
#3
Sonstige Systeme / Nuki SmartLock Pro 5 - jemand ...
Letzter Beitrag von Fabiango - 12 Dezember 2025, 13:50:49Hallo zusammen,
ich brauche eure Hilfe.
Meine Bridge und mein Opener konnte ich bereits erfolgreich in FHEM einbinden.
Meine SmartLock Pro 5 mit integriertem WLAN möchte ich gerne direkt über das WLAN in FHEM einbinden.
Matter habe ich selbst noch nicht.
Ich habe es schon mit MQTT versucht aber das geht ebenfals nicht. Das neue Gerät hat auch die MQTT Integration nicht mehr in den Einstellungen.
Wie kann ich meine beiden SmartLock Pro 5 am besten in FHEM einbinden?
Hat mir jemand ein paar Befehle dazu oder schon Erfahrungen mit den neueren Geräten?
Danke euch schon mal im voraus.
ich brauche eure Hilfe.
Meine Bridge und mein Opener konnte ich bereits erfolgreich in FHEM einbinden.
Meine SmartLock Pro 5 mit integriertem WLAN möchte ich gerne direkt über das WLAN in FHEM einbinden.
Matter habe ich selbst noch nicht.
Ich habe es schon mit MQTT versucht aber das geht ebenfals nicht. Das neue Gerät hat auch die MQTT Integration nicht mehr in den Einstellungen.
Wie kann ich meine beiden SmartLock Pro 5 am besten in FHEM einbinden?
Hat mir jemand ein paar Befehle dazu oder schon Erfahrungen mit den neueren Geräten?
Danke euch schon mal im voraus.
#4
Automatisierung / Aw: Verketten von FHEM Befehle...
Letzter Beitrag von erwin - 12 Dezember 2025, 13:50:20Um die Verwirrung noch zu ergänzen: 
Bei einem AT hat das doppelte semicolon noch eine zusätzliche Bedeutung, siehe: wiki , daher je nach dem auch 4 semicolons nötig....
l.g.erwin
Bei einem AT hat das doppelte semicolon noch eine zusätzliche Bedeutung, siehe: wiki , daher je nach dem auch 4 semicolons nötig....
l.g.erwin
#5
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.
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.
LG,
Heiko
#6
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
#7
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.
#8
Automatisierung / Aw: Fehlende Logeinträge im Fi...
Letzter Beitrag von frober - 12 Dezember 2025, 13:36:06Bei einem userReading gibt es standardmäßig kein Event, da die Gefahr zu groß ist, das es sich selbst triggert.
#9
Automatisierung / Aw: Unerklärlicher Zustand im ...
Letzter Beitrag von passibe - 12 Dezember 2025, 13:33:30 #10
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