- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Max_Meyer - 17 Juli 2025, 03:17:58Zitat von: hugomckinley am 16 Juli 2025, 19:05:55Könntest du mir beispielhaft die notwendigen Definitionen eines deiner Geräte zukommen lassen, vielleicht kan ich ja was abkucken?Hallo Hugo,
Das mach ich gerne - wird aber bisschen dauern da ich derzeit nur mit dem Handy unterwegs bin und so das kopieren von Code fehlerträchtig ist. Ich hoffe das passt?
Ich habe die Lösung gewählt weil die eigentlichen Device auf unterschiedlicher Hardware laufen so bleib ich flexibel.
Gruß Gerd
#2
DOIF / Aw: Speicherfüllstand
Letzter Beitrag von passibe - 17 Juli 2025, 01:11:42Scheint so, als würde das Reading speicherfuellstand kein Event erzeugen, wenn es aktualisiert wird.
Schau doch mal im Eventmonitor, ob da zu dem Zeitpunkt wo du es erwartest ein solches Event auftaucht. Eventuell ist ja im mySenec-Device eines der event-* Attribute gesetzt?
Sonst gib uns doch mal ein list von mySenec also einfach eingeben
Noch zwei Dinge:
1. Im Forum bitte Code-Tags benutzen und 2. die Klammern um die Auslösebedingungen kannst du weglassen, das funktioniert auch ohne, also:
Schau doch mal im Eventmonitor, ob da zu dem Zeitpunkt wo du es erwartest ein solches Event auftaucht. Eventuell ist ja im mySenec-Device eines der event-* Attribute gesetzt?
Sonst gib uns doch mal ein list von mySenec also einfach eingeben
Code Auswählen
list mySenecund die Ausgabe davon hier posten.Noch zwei Dinge:
1. Im Forum bitte Code-Tags benutzen und 2. die Klammern um die Auslösebedingungen kannst du weglassen, das funktioniert auch ohne, also:
Code Auswählen
defmod <DOIF-Name> DOIF ([mySenec:stromerzeugung]>700 or [mySenec:speicherfuellstand]>50) (set ST1_out on) DOELSE (set ST1_out off) #3
Anfängerfragen / Aw: [Gelöst] Alexa, ständige N...
Letzter Beitrag von passibe - 17 Juli 2025, 00:54:21Alles klar. Dann poste mal bitte Infos zu Betriebssystem, Art der Installation (Docker?) usw. auch node bzw. npm-Version.
Und bitte einmal die Ausgabe von
Und poste mal die entsprechenden Log-Auszüge, sowohl vom FHEM-Log als auch vom alexa-fhem-Log, mehr als nur eine Zeile, vielleicht auch mit etwas Kontext. Zum Beispiel so, dass man anhand der Timestamps sieht, in was für einem Intervall/wie oft das neustartet, usw.
Und bitte noch ein list vom alexa Device.
Danke!
Und bitte einmal die Ausgabe von
Code Auswählen
ps -aux | grep -E '(alexa|ssh)'Und poste mal die entsprechenden Log-Auszüge, sowohl vom FHEM-Log als auch vom alexa-fhem-Log, mehr als nur eine Zeile, vielleicht auch mit etwas Kontext. Zum Beispiel so, dass man anhand der Timestamps sieht, in was für einem Intervall/wie oft das neustartet, usw.
Und bitte noch ein list vom alexa Device.
Danke!
#4
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
#5
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
#6
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
#7
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.
#8
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... #9
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
#10
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!