- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 16 Juli 2025, 21:35:50ZitatSehe ich das richtig, dass man bei der surpmeth "median" oder "avg" nicht sagen kann, ob das der Median oder der Durchschnitt der letzten 5sec oder der letzten 5 Minuten ist, sobald man einen oder mehrere Consumer/Inverter mit asynchron=1 hat? In diesem Fall ist ja plantControl->cycleInterval eigentlich nicht mehr relevant bei vielen Events, da ja jeder eine Neuberechnung auslöst.Ja, das siehst du richtig.
Sehe ich das richtig?
ZitatDieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.Ja richtig. Die asynch-Einstellung ist in diesem Kontext nicht hilfreich.
Wenn man eine regelmäßige Bezugsgröße bzgl. der Zyklusabarbeitung braucht, sollte asynch nicht gesetzt werden.
Evtl. kann man mit "locktime" ergänzend auf das Schaltverhalten Einfluß nehmen.
LG,
Heiko
#2
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von hugomckinley - 16 Juli 2025, 21:10:32Sehe ich das richtig, dass man bei der surpmeth "median" oder "avg" nicht sagen kann, ob das der Median oder der Durchschnitt der letzten 5sec oder der letzten 5 Minuten ist, sobald man einen oder mehrere Consumer/Inverter mit asynchron=1 hat? In diesem Fall ist ja plantControl->cycleInterval eigentlich nicht mehr relevant bei vielen Events, da ja jeder eine Neuberechnung auslöst.
Sehe ich das richtig?
Hintergrund: Bisher prüfe ich, ob der Überschuss für eine gewisse Zeit (einige Minuten, kommt auf den Verbraucher an) über seiner Leistung + Zuschlag liegt. Das führt dazu, dass ein kurzes Aufreißen der Wolkendecke, nicht zu einem Einschalten führt. Ebenso in umgekehrter Richtung, dass eine Wolke die 2 Minuten die PV-Leistung senkt nicht zum Ausschalten des Verbrauchers führt.
Dieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.
Nebeneffekt ist, dass ich bei mir über die Wartezeiten die Verbraucher priorisieren kann. z.B. erhöht die Poolpumpe die Leistung nach 3 Minuten, die Wärmepumpe schaltet aber erst nach 6 Minuten ein, um ein Takten möglichst zu vermeiden. Das führt auch dazu, dass die WP nur dann aktiv wird, wenn der Überschuss für beide reicht. Wenn der Überschuss zwar für die Poolpumpe oder die Wärmepumpe reicht, aber nach dem Hochschalten der Poolpumpe sich die WP nicht mehr ausgeht, wird dieser Timer in den folgenden Minuten nach dem Hochschalten der Poolpumpe zurück gesetzt und die Wärmepumpe muss (weiter) warten, oder es geht sich gar nicht mehr aus.
d.h. über das unterschiedlich verzögerte Einschalten kann ich die Verbraucher priorisieren und die waittimer sorgen für ein stabiles und schwankungstolerantes Schaltverhalten.
So schaltet die WP als erstes aus, denn ohne kann die Pumpe wahrscheinlich weiter laufen. Damit die WP nicht zu oft taktet, aber erst nach z.B. 7 Minuten und die Pumpe nach 9 Minuten usw.
Das alles hat jetzt noch nichts mit einem Forecast zu tun, denn das ist nur das Folgen der Überschussleistung und da brauche ich keine Vorhersage, da dieses Verhalten von Sonneaufgang bis Sonnenuntergang gilt.
Die Verbesserung/Erweiterung, die ich mir durch SF erhoffe ist, dass ich mit der Vorhersage dann die Wärmepumpe fürs Haus, Batterieladung und E-Auto in Abhängigkeit der Prognose zum passenden Zeitpunkt "einzwicken" kann, damit es im Haus warm ist und das Auto voll (genug) wird usw.
In dieser Zeit können dann andere (niederpriorisierte) "Überschussverbraucher" ausgeschaltet, bzw. runter geregelt werden. z.B. muss das Auto geladen werden, auch wenn der Pool noch keine Badewanne ist
Dieses Verhalten sollte auch möglich sein, wenn diese hochpriorsierten Verbraucher (WP-Haus, e-Auto, Batterieladung) über die Prognose von SF gesteuert werden und die "Überschussvernichter" extern, wie bisher. Vom Gefühl her ist das besser zu kontrollieren, wenn alles über SF läuft.
Ausserdem wäre es leichter beherschbar, wenn das ganze Strommanagement an einer Stelle passiert und nicht vom Zusammenspiel von zwei Systemen, die nur indirekt üner den Überschuss kommunizieren, abhängt.
Ich weiß nicht, ob das hier die richtige Stelle ist, aber das sind so meine Überlegungen und mir will nicht einfallen, wie ich das mit SF abbilden kann, ohne etwas mit den waittimern von DOIF vergleichbarem.
Bitte um Korrektur, oder Hinweise, ob ich da auf dem Holzweg bin, oder ob ich nur nicht sehe, wie das funktionieren kann.
Grüße,
Hugo
Sehe ich das richtig?
Hintergrund: Bisher prüfe ich, ob der Überschuss für eine gewisse Zeit (einige Minuten, kommt auf den Verbraucher an) über seiner Leistung + Zuschlag liegt. Das führt dazu, dass ein kurzes Aufreißen der Wolkendecke, nicht zu einem Einschalten führt. Ebenso in umgekehrter Richtung, dass eine Wolke die 2 Minuten die PV-Leistung senkt nicht zum Ausschalten des Verbrauchers führt.
Dieses Verhalten könnte ich mit dem Median oder dem Durchschnitt wahrscheinlich auch abbilden, aber nur wenn das der Wert in einem gewissen (einstellbaren) Zeitraum ist und nicht über eine gewisse Anzahl von Werten, da ich ja nicht sagen kann, ob das der Median/Durchschnitt von 30 Sekunden oder 5 Minuten ist.
Nebeneffekt ist, dass ich bei mir über die Wartezeiten die Verbraucher priorisieren kann. z.B. erhöht die Poolpumpe die Leistung nach 3 Minuten, die Wärmepumpe schaltet aber erst nach 6 Minuten ein, um ein Takten möglichst zu vermeiden. Das führt auch dazu, dass die WP nur dann aktiv wird, wenn der Überschuss für beide reicht. Wenn der Überschuss zwar für die Poolpumpe oder die Wärmepumpe reicht, aber nach dem Hochschalten der Poolpumpe sich die WP nicht mehr ausgeht, wird dieser Timer in den folgenden Minuten nach dem Hochschalten der Poolpumpe zurück gesetzt und die Wärmepumpe muss (weiter) warten, oder es geht sich gar nicht mehr aus.
d.h. über das unterschiedlich verzögerte Einschalten kann ich die Verbraucher priorisieren und die waittimer sorgen für ein stabiles und schwankungstolerantes Schaltverhalten.
So schaltet die WP als erstes aus, denn ohne kann die Pumpe wahrscheinlich weiter laufen. Damit die WP nicht zu oft taktet, aber erst nach z.B. 7 Minuten und die Pumpe nach 9 Minuten usw.
Das alles hat jetzt noch nichts mit einem Forecast zu tun, denn das ist nur das Folgen der Überschussleistung und da brauche ich keine Vorhersage, da dieses Verhalten von Sonneaufgang bis Sonnenuntergang gilt.
Die Verbesserung/Erweiterung, die ich mir durch SF erhoffe ist, dass ich mit der Vorhersage dann die Wärmepumpe fürs Haus, Batterieladung und E-Auto in Abhängigkeit der Prognose zum passenden Zeitpunkt "einzwicken" kann, damit es im Haus warm ist und das Auto voll (genug) wird usw.
In dieser Zeit können dann andere (niederpriorisierte) "Überschussverbraucher" ausgeschaltet, bzw. runter geregelt werden. z.B. muss das Auto geladen werden, auch wenn der Pool noch keine Badewanne ist
Dieses Verhalten sollte auch möglich sein, wenn diese hochpriorsierten Verbraucher (WP-Haus, e-Auto, Batterieladung) über die Prognose von SF gesteuert werden und die "Überschussvernichter" extern, wie bisher. Vom Gefühl her ist das besser zu kontrollieren, wenn alles über SF läuft.
Ausserdem wäre es leichter beherschbar, wenn das ganze Strommanagement an einer Stelle passiert und nicht vom Zusammenspiel von zwei Systemen, die nur indirekt üner den Überschuss kommunizieren, abhängt.
Ich weiß nicht, ob das hier die richtige Stelle ist, aber das sind so meine Überlegungen und mir will nicht einfallen, wie ich das mit SF abbilden kann, ohne etwas mit den waittimern von DOIF vergleichbarem.
Bitte um Korrektur, oder Hinweise, ob ich da auf dem Holzweg bin, oder ob ich nur nicht sehe, wie das funktionieren kann.
Grüße,
Hugo
#3
DOIF / Speicherfüllstand
Letzter Beitrag von Calivati - 16 Juli 2025, 20:47:00Hallo zusammen, ich habe wieder mal eine Frage, bei der ich nicht weiterkomme. Ich möchte eine Aktion definieren, in Abhängigkeit von der Stromerzeugung oder dem Speicherfüllstand. Dazu habe ich folgendes definiert:
(([mySenec:stromerzeugung]>700) or ([mySenec:speicherfuellstand]>50)) (set ST1_out on) DOELSE (set ST1_out off)
Als reading erhalte ich aber nur: e_mySenec_stromerzeugung 111.11, kein reading zum Füllstand
Wenn ich auf der cmd-line {ReadingsVal("mySenec","speicherfuellstand","error")} eingebe, dann bekomme ich einen Wert zurück.
Bin wie immer für jeden Tipp dankbar.
Peter
(([mySenec:stromerzeugung]>700) or ([mySenec:speicherfuellstand]>50)) (set ST1_out on) DOELSE (set ST1_out off)
Als reading erhalte ich aber nur: e_mySenec_stromerzeugung 111.11, kein reading zum Füllstand
Wenn ich auf der cmd-line {ReadingsVal("mySenec","speicherfuellstand","error")} eingebe, dann bekomme ich einen Wert zurück.
Bin wie immer für jeden Tipp dankbar.
Peter
#4
Sonstige Systeme / Aw: linux usb hid input modul
Letzter Beitrag von schaedeldx - 16 Juli 2025, 20:28:34Hallo, kann mir vielleicht jemand helfen?!
Habe das Modul eingebunden, ich habe einen USB-RFID-Reader.
Ich habe alles eingerichtet, in FHEM kommen auch EV_SYN- und EV_MSC-Events an, wenn ich sie nicht unterdrücke.
Ich bekomme aber keine Tags übermittelt.
Lokal bekomme ich diese angezeigt, wenn das Device in FHEM nicht verbunden ist.
Ich habe auch schon in FHEM verbose 5 eingestellt, da kommt aber nichts. Ich bin den Thread schon mehrfach durchgegangen und habe schon zwei .pm installiert, ohne Erfolg. Mehrere Einstellungen haben nicht funktioniert.
Hier meine aktuelle Config:
define hid linuxHid event5
attr hid collect EV_KEY
attr hid ignoredTypes EV_SYN,EV_MSC
attr hid room Patchschrank
attr hid userReadings EV_KEY,EV_LED,EV_REP
und hier die Device-Info:
{
'id' => {
'version' => '0x0110',
'vendor' => '0xffff',
'product' => '0x0035',
'bus' => '0x0003'
},
'uniq' => '08FF20171101',
'name' => 'IC Reader IC Reader',
'handler' => 'event5',
'eventTypes' => '0x120013',
'eventTypesStr' => 'EV_SYN,EV_KEY,EV_MSC,EV_LED,EV_REP',
'keys' => 'e080ffdf01cfffff fffffffffffffffe'
}
Wäre mega, wenn mir jemand da Tipps geben könnte. Vielen Dank.
Habe das Modul eingebunden, ich habe einen USB-RFID-Reader.
Ich habe alles eingerichtet, in FHEM kommen auch EV_SYN- und EV_MSC-Events an, wenn ich sie nicht unterdrücke.
Ich bekomme aber keine Tags übermittelt.
Lokal bekomme ich diese angezeigt, wenn das Device in FHEM nicht verbunden ist.
Ich habe auch schon in FHEM verbose 5 eingestellt, da kommt aber nichts. Ich bin den Thread schon mehrfach durchgegangen und habe schon zwei .pm installiert, ohne Erfolg. Mehrere Einstellungen haben nicht funktioniert.
Hier meine aktuelle Config:
define hid linuxHid event5
attr hid collect EV_KEY
attr hid ignoredTypes EV_SYN,EV_MSC
attr hid room Patchschrank
attr hid userReadings EV_KEY,EV_LED,EV_REP
und hier die Device-Info:
{
'id' => {
'version' => '0x0110',
'vendor' => '0xffff',
'product' => '0x0035',
'bus' => '0x0003'
},
'uniq' => '08FF20171101',
'name' => 'IC Reader IC Reader',
'handler' => 'event5',
'eventTypes' => '0x120013',
'eventTypesStr' => 'EV_SYN,EV_KEY,EV_MSC,EV_LED,EV_REP',
'keys' => 'e080ffdf01cfffff fffffffffffffffe'
}
Wäre mega, wenn mir jemand da Tipps geben könnte. Vielen Dank.
#5
Unterstützende Dienste / Aw: Neues Modul: Signalbot (In...
Letzter Beitrag von kabanett - 16 Juli 2025, 20:24:44Danke! Die java Version passt jetzt.
Jetzt habe ich folgenden Fehler,
Jetzt habe ich folgenden Fehler,
Code Auswählen
Failed to register: Invalid verification method: Before requesting voice verification you need to request SMS verification and wait a minute.obwohl ich den von mir beschriebenen Weg bis auf 2. gemacht habe... #6
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 16 Juli 2025, 19:30:53Hallo Hugo,
wenn du eine Funktion außerhalb des SolarForecast-Packages im "main" aufrufen willst, mußt du die Funktion mit zwei führenden Doppelpunkten schreiben, also z.B.:
Funktionen in der 99_myUtils.pm liegen im "main" Package, welches man damit erreicht. Auch "main::CheckWPOff" wäre möglich.
LG,
Heiko
wenn du eine Funktion außerhalb des SolarForecast-Packages im "main" aufrufen willst, mußt du die Funktion mit zwei führenden Doppelpunkten schreiben, also z.B.:
Code Auswählen
{::CheckWPOff}
Funktionen in der 99_myUtils.pm liegen im "main" Package, welches man damit erreicht. Auch "main::CheckWPOff" wäre möglich.
LG,
Heiko
#7
Solaranlagen / Aw: PowerFlow [animiertes SVG,...
Letzter Beitrag von ergerd - 16 Juli 2025, 19:20:06Ich hatte mich schon gewundert, bin aber noch nicht auf Feherlsuche gegegangen 
Danke für das schöne Powergrid!
Danke für das schöne Powergrid!
#8
Unterstützende Dienste / Aw: Neues Modul: Signalbot (In...
Letzter Beitrag von Adimarantis - 16 Juli 2025, 19:19:55root ist ok. Was ich vergessen habe, ist dass du Java 21 dann noch in den Pfad aufnehmen musst:
Code Auswählen
pi@raspi400:~ java --version
openjdk 17.0.15 2025-04-15
OpenJDK Runtime Environment (build 17.0.15+6-Debian-1deb12u1)
OpenJDK 64-Bit Server VM (build 17.0.15+6-Debian-1deb12u1, mixed mode, sharing)
pi@raspi400:~ $ export JAVA_HOME=/opt/java
pi@raspi400:~ $ export PATH=/opt/java/bin:$PATH
pi@raspi400:~ $ java --version
openjdk 21.0.2 2024-01-16 LTS
OpenJDK Runtime Environment Temurin-21.0.2+13 (build 21.0.2+13-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.2+13 (build 21.0.2+13-LTS, mixed mode, sharing)
#9
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von hugomckinley - 16 Juli 2025, 19:12:41Da hätte ich auch noch gleich eine Frage dazu, wo ich keine Antwort gefunden habe:
Ist es möglich als PerlCode bei swoncond eine Funktion aus der 99_myUtils.pm zu verwenden.
Ein erster Versuch führt leider nur zu:
Grüße,
Hugo
Ist es möglich als PerlCode bei swoncond eine Funktion aus der 99_myUtils.pm zu verwenden.
Ein erster Versuch führt leider nur zu:
Code Auswählen
ERROR in interruptable or swoffcond Code execution: Undefined subroutine &FHEM::SolarForecast::CheckWPOff called at (eval 170417) line 1.Die Funktion lässt sich aber in der Befehlszeile von FHEM aufrufen und funktioniert.Grüße,
Hugo
#10
Anfängerfragen / Aw: [Gelöst] Alexa, ständige N...
Letzter Beitrag von hugomckinley - 16 Juli 2025, 19:07:20Leider nein, das war einer der ersten Versuche.
Alexa-fhem funktioniert auch ganz normal, aber es müllt mir das Log zu und startet eben immer neu.
Alexa-fhem funktioniert auch ganz normal, aber es müllt mir das Log zu und startet eben immer neu.