- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von lorisurfen - 16 März 2026, 15:51:06Hat sich am consumer-Schlüssel locktime etwas geändert, wenn ich ein consumuer-attribut (ohne Änderung) speichern will kommt jetzt plötzlich folgende Fehlermeldung:
ZitatThe key 'locktime=0:30' is not specified correctly. Please refer to the command reference.
#92
Homematic / Aw: HM-SEC-SCO nach Exclude ne...
Letzter Beitrag von Otto123 - 16 März 2026, 15:50:25Zitat von: DeeSPe am 16 März 2026, 11:51:00"aesCommToDev" steht "ok",Das ist eigentlich ok, weil die Dinger ja auch ohne Key der VCCU mit dem Systemkey AES machen. Das SEC im Namen sagt eigentlich, das es die default Einstellung ist. Bei anderen muss man AES aktivieren, bei denen mit SEC im Namen nicht. Ich verstehe in meinem System gerade nicht warum ich die AES Readings nicht mehr habe
Das rote Leuchten am Ende bedeutet eigentlich nur das die Kommunikation irgendwie nicht geklappt hat.
Hast Du jetzt mehrere IOs die eventuell dazwischen reden könnten?
Was ist wenn Du das attr aesCommreq mal löschst? (noansi hat es auch gesehen
) #93
Homematic / Aw: HM-SEC-SCO nach Exclude ne...
Letzter Beitrag von noansi - 16 März 2026, 15:49:22Hallo Dan,
vereinfache die Kommunikation mal mit
Du willst ja zur Zeit nicht erschweren, dass ein Fremder Dir falsche Zustände zukommen lassen will.
Und da Du anscheinend pairen möchtest, versuch es mal mit hmPairForSec bei der VCCU und Knöpfchen drücken statt hmPairSerial.
Blinkcodes stehen in der Anleitung Seite 24f https://www.eq-3.de/downloads/download/homematic/bda/hm-sec-sco_um_ge_eq-3_web.pdf
Ist das physische IO ein CUL?
Gruß, Ansgar.
vereinfache die Kommunikation mal mit
Zitatattr 56ABA8 aesCommReq 0
Du willst ja zur Zeit nicht erschweren, dass ein Fremder Dir falsche Zustände zukommen lassen will.
Und da Du anscheinend pairen möchtest, versuch es mal mit hmPairForSec bei der VCCU und Knöpfchen drücken statt hmPairSerial.
Code Auswählen
2026-03-15 14:50:10 aesKeyNbr 00Sagt, dass der Default Key für die letzte AES Kommunikation verwendet wurde. 02 würde bedeuten, dass der Key Nummer 1 verwendet wurde (Faktor 2 steckt a drin).Blinkcodes stehen in der Anleitung Seite 24f https://www.eq-3.de/downloads/download/homematic/bda/hm-sec-sco_um_ge_eq-3_web.pdf
Ist das physische IO ein CUL?
Gruß, Ansgar.
#94
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 16 März 2026, 15:47:09Zitat von: tomcat.x am 16 März 2026, 15:18:09Danke für die Erläuterungen
Lese doch evtl. auch noch bitte den zugehörigen Bereich im Wiki dazu
Aktivierung des Batterie SOC- und Lade-Managements
#95
Sonstiges / Aw: FHEM nicht verfügbar
Letzter Beitrag von DeeSPe - 16 März 2026, 15:33:35 #96
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von tomcat.x - 16 März 2026, 15:18:09Danke für die Erläuterungen. Bei mir steht Battery_OptimumTargetSoC_01 auf 90 %. Das erklärt dann die 90, die ich gesehen habe. Nur konnten die halt nie erreicht werden.
Aktuell wird entladen und die Vorhersagen passen, nämlich dass die Batterie nach dieser Stunde auf dem Minimum von 10 % sein wird und danach da bleiben wird.
Aktuell wird entladen und die Vorhersagen passen, nämlich dass die Batterie nach dieser Stunde auf dem Minimum von 10 % sein wird und danach da bleiben wird.
#97
Sonstiges / FHEM nicht verfügbar
Letzter Beitrag von Tutti_Bomovski - 16 März 2026, 15:17:18Liebe Community,
ich hatte heute Nacht ein äußerst seltsames Phänomen.
Gegen 1.30 Uhr gab es im LogFile die "letzte" Aktivität.
2026.03.16 01:26:42 Eintrag
2026.03.16 01:17:07 der nächste Eintrag dann in der Liste?
2026.03.16 01:17:13 Eintrag
2026.03.16 01:32:19 der nächste Eintrag dann in der Liste?
2026.03.16 01:32:40 Eintrag + weitere andere
2026.03.16 01:17:11 Eintrag mit Uhrzeitverschiebung
2026.03.16 11:29:15 der nächste Eintrag dann in der Liste?
Danach ging über Stunden nichts mehr.
Die Weboberfläche war leider ebenfalls nicht erreichbar.
gegen 11.30 Uhr war plötzlich alles wieder "online".
Jemand eine Idee wie ich der Ursache auf die Spur komme?
ich hatte heute Nacht ein äußerst seltsames Phänomen.
Gegen 1.30 Uhr gab es im LogFile die "letzte" Aktivität.
2026.03.16 01:26:42 Eintrag
2026.03.16 01:17:07 der nächste Eintrag dann in der Liste?
2026.03.16 01:17:13 Eintrag
2026.03.16 01:32:19 der nächste Eintrag dann in der Liste?
2026.03.16 01:32:40 Eintrag + weitere andere
2026.03.16 01:17:11 Eintrag mit Uhrzeitverschiebung
2026.03.16 11:29:15 der nächste Eintrag dann in der Liste?
Danach ging über Stunden nichts mehr.
Die Weboberfläche war leider ebenfalls nicht erreichbar.
gegen 11.30 Uhr war plötzlich alles wieder "online".
Jemand eine Idee wie ich der Ursache auf die Spur komme?
#98
readingsGroup / readingsHistory / Aw: readingsGroup - longpoll A...
Letzter Beitrag von bertl - 16 März 2026, 15:03:39Um das Problem noch deutlicher darzustellen, habe ich 2 readingsGroup angelegt, welche auf die gleichen Daten zugreifen.
Einmal mit der Index-Variante und einmal ohne Index-Variante.
Bei der Variante mit dem Index funktioniert das Update von Super:Adresse-1:t nicht.
Alle anderen Werte werden wie erwartet aktualisert.
Variante mit Index (Problem):
Variante ohne Index (funktioniert):
Hat wer eine Idee?
Einmal mit der Index-Variante und einmal ohne Index-Variante.
Bei der Variante mit dem Index funktioniert das Update von Super:Adresse-1:t nicht.
Alle anderen Werte werden wie erwartet aktualisert.
Variante mit Index (Problem):
Code Auswählen
define rg.Super1 readingsGroup Super:Adresse-1:t,<Preis ;[€/L]>,<Name>,<Entf. ;[km]>,<Ort>,<Adresse>\
Super:@2,<#1>,Super95-(\d*),Tankstellenname-#1,Entfernung-#1,Ort-#1,Adresse-#1
attr rg.Super1 alwaysTrigger 2
attr rg.Super1 nonames 1Variante ohne Index (funktioniert):
Code Auswählen
define rg.Super2 readingsGroup Super:Adresse-1:t,<Preis ;[€/L]>,<Name>,<Entf. ;[km]>,<Ort>,<Adresse>\
Super:<1>,Super95-1,Tankstellenname-1,Entfernung-1,Ort-1,Adresse-1\
Super:<2>,Super95-2,Tankstellenname-2,Entfernung-2,Ort-2,Adresse-2\
Super:<3>,Super95-3,Tankstellenname-3,Entfernung-3,Ort-3,Adresse-3\
Super:<4>,Super95-4,Tankstellenname-4,Entfernung-4,Ort-4,Adresse-4\
Super:<5>,Super95-5,Tankstellenname-5,Entfernung-5,Ort-5,Adresse-5\
Super:<6>,Super95-6,Tankstellenname-6,Entfernung-6,Ort-6,Adresse-6
attr rg.Super2 alwaysTrigger 2
attr rg.Super2 nonames 1Hat wer eine Idee?
#99
FHEMWEB / Aw: VoiceButton für Fhemweb
Letzter Beitrag von schwatter - 16 März 2026, 13:58:03Mh,
ich habe es gerade erst bemerkt. Das ständige restarten der Spracherkennung bei AlwaysOn löst einen Ton aus.
Es ist mir nicht aufgefallen, da Systemtöne auf minimal waren...Daher werde ich es wohl wieder entfernen müssen.
Gruß schwatter
ich habe es gerade erst bemerkt. Das ständige restarten der Spracherkennung bei AlwaysOn löst einen Ton aus.
Es ist mir nicht aufgefallen, da Systemtöne auf minimal waren...Daher werde ich es wohl wieder entfernen müssen.
Gruß schwatter
#100
Solaranlagen / Aw: Modul für Ecoflow-Komponen...
Letzter Beitrag von KölnSolar - 16 März 2026, 13:50:03Prima, danke. Dann kann es jetzt jeder einsetzen.
Und nun noch die versprochene Dokumentation meiner Änderungen.
Erst einmal vielen Dank für das sicherlich seeeeeehr aufwändige Entwickeln des Moduls für die Ecoflow-Produkte auf Basis der von Ecoflow bereitgestellten API an Neolux.
Nun kurz zu meinen Beweggründen das Modul anzupassen:
Meine Delta2 weist/wies einen Defekt auf. Um diesen nachzuweisen ist das Verständnis und dann die Aufzeichnung der Notwendigen aus der der schier unendlichen Zahl der Readings nötig.
In der ursprünglichen Fassung war dies nicht möglich, weil:
- beim Abruf von Daten der timestamp für JEDES Datum, welches in der Cloud vorliegt, verändert wurde. Tatsächlich aber nur wenige Daten verändert werden
- Selbst ausgesetzter tatsächlicher Betrieb des physischen devices oder Störungen der Übertragung an die Ecoflow-Cloud konnten nicht erkannt werden, weil das Modul immer die in der Cloud vorhandenen Daten nach FHEM übertrug
- ein set änderte das betroffene Reading, obwohl das set vielleicht gar nicht erfolgreich war(kann u.U. vorkommen, wenn z.B. das device gar nicht mit der Cloud verbunden ist)
Das Modul nutzt nun
- konsequent update-if-changed, so dass nur veränderte readings ein event auslösen.
- das von mir selbst geforderte Attribut "no_data_20_134", was ebenfalls zu mehr Übersichtlichkeit führen sollte, habe ich entfernt, da nun mit dem Standard-Attribut suppressreadings der vergleichbare Effekt erreicht wird
- eine für mich nicht nachvollziehbare Anpassung zu den Standard-Attributen "event-on-change" habe ich entfernt.
Die Standard event-on-.... Attribute liefern nun wieder zu erwartende Ergebnisse
Die Umsetzung jedes einzelnen MÖGLICHEN device-spezifischen Datums durch get, führte zu einer sehr unübersichtlichen Anzahl von gets, obwohl diese Daten auch mit einem get "all" geliefert werden.
Folglich macht deren Berücksichtigung wenig Sinn. Ich habe diese vollständig entfernt und durch einen einzelnen Abruf "get update" ersetzt, sofern jemand Bedarf an der Aktualisierung der Daten außerhalb des zyklischen automatischen Abrufs haben sollte.
device spezifische gets sind somit nur noch für Daten realisiert, die nicht mit get update abrufbar sind. Nach aktuellen Erkenntnissen betrifft dies nur historische Daten bei PowerOcean und Stream xyz Modellen.
Im Ergebnis ist nun viel leichter ersichtlich, welche Daten sich tatsächlich im Betrieb verändern, Loggingdaten sind deutlich reduziert.
Ebenfalls für Intransparenz sorgte die Darstellung von Bildschirmausgaben nach set/get.
Tatsächlich ist es so, dass das Modul richtigerweise Non-Blocking-Get einsetzt.
Das bedeutet im wesentlichen, dass das Modul nicht blockiert, nur weil Antwortzeiten deren Server unbefriedigend sind.
Es bedeutet nun einmal aber auch, dass eine erfolgreiche Verarbeitung der set/get Befehle nicht im Augenblick des Senden ersichtlich ist, sondern erst sobald auch tatsächlich eine Antwort aus der Cloud erfolgt ist.
In der vorherigen Fassung des Moduls wurden also lediglich "alte" Informationen angezeigt. Die "Wahrheit" war erst nach einem Empfang von Daten in den readings ersichtlich, die sich u.U. flip-/flop-mäßig änderten.
Ich habe daher entweder auf Anzeigen verzichtet oder weise in den Bildschirmmeldungen zumindest darauf hin, dass "veraltete" Daten angezeigt werden.
Die device- u. readingspezifischen "adjustments", halte ich für eine sehr sinnvolle Idee von Neolux. Ich habe dazu kleinere Anpassungen vorgenommen:
- device-spezifische Anpassung der einzelnen readings-Werte, sofern modulintern zum device konfiguriert(war bereits so implementiert)
- Zeitangaben sind scheinbar immer in Sekunden. Enthält der reading-Name das Literal "time" wird automatisch in hh:mm umgerechnet
- Internal HardwareVersion entfernt; nun lesbar über die 6 hwVersion_x readings
Weitere Kleingkeiten, die ich geändert habe:
- kein set für AccessKey, da fehleranfällig; bei Änderung des AccessKey besser defmod ausführen
- set "SerialNo", "deleteReadings" entfernt
- einiges im Code zur Verbesserung der Lesbarkeit geändert, reduziert
Hier noch meine Beispiele für den sinnvollen Einsatz der Standard-Attribute.
Für eine Delta2:
Ich habe sogar manuell die timestamps der readings OHNE update in meinem FHEM so angepasst, dass ich leicht an den timestamps erkennen kann, ob und wann sich deren Wert tatsächlich geändert hat.(2025-12-31 23:59:59)
Für durchgängige Plots die Ausnahme mit event-min-interval, dass auch ohne Änderung ein update erfolgt
Für einen Powerstream:
Sicherlich habe ich noch etwas vergessen, aber so ist das leider bei umfangreichen Änderungen.
Bedenkt, dass Ihr nach Einspielen in Euer FHEM ein "reload 98_Ecoflow" machen müsst und mindestens das Attribut ecInterval löschen und ggfs. das Attribut interval anlegen müsst.
Wenn das nicht klappt, müsst Ihr das device neu anlegen. Vorsicht: Holt Euch vorher den SecretKey, da dieser beim Löschen des devices auch aus der Datei gelöscht und wieder neu eingegeben werden muss.
Und nun bin ich auf Euer Feedback gespannt.
Sicherlich werden noch die ein oder andere Anpassung am Modul notwendig, aber in absehbarer Zeit würde ich es dann offiziell mit automatischer Verteilung machen.
Have fun
Markus
Und nun noch die versprochene Dokumentation meiner Änderungen.
Erst einmal vielen Dank für das sicherlich seeeeeehr aufwändige Entwickeln des Moduls für die Ecoflow-Produkte auf Basis der von Ecoflow bereitgestellten API an Neolux.
Nun kurz zu meinen Beweggründen das Modul anzupassen:
Meine Delta2 weist/wies einen Defekt auf. Um diesen nachzuweisen ist das Verständnis und dann die Aufzeichnung der Notwendigen aus der der schier unendlichen Zahl der Readings nötig.
In der ursprünglichen Fassung war dies nicht möglich, weil:
- beim Abruf von Daten der timestamp für JEDES Datum, welches in der Cloud vorliegt, verändert wurde. Tatsächlich aber nur wenige Daten verändert werden
- Selbst ausgesetzter tatsächlicher Betrieb des physischen devices oder Störungen der Übertragung an die Ecoflow-Cloud konnten nicht erkannt werden, weil das Modul immer die in der Cloud vorhandenen Daten nach FHEM übertrug
- ein set änderte das betroffene Reading, obwohl das set vielleicht gar nicht erfolgreich war(kann u.U. vorkommen, wenn z.B. das device gar nicht mit der Cloud verbunden ist)
Das Modul nutzt nun
- konsequent update-if-changed, so dass nur veränderte readings ein event auslösen.
- das von mir selbst geforderte Attribut "no_data_20_134", was ebenfalls zu mehr Übersichtlichkeit führen sollte, habe ich entfernt, da nun mit dem Standard-Attribut suppressreadings der vergleichbare Effekt erreicht wird
- eine für mich nicht nachvollziehbare Anpassung zu den Standard-Attributen "event-on-change" habe ich entfernt.
Die Standard event-on-.... Attribute liefern nun wieder zu erwartende Ergebnisse
Die Umsetzung jedes einzelnen MÖGLICHEN device-spezifischen Datums durch get, führte zu einer sehr unübersichtlichen Anzahl von gets, obwohl diese Daten auch mit einem get "all" geliefert werden.
Folglich macht deren Berücksichtigung wenig Sinn. Ich habe diese vollständig entfernt und durch einen einzelnen Abruf "get update" ersetzt, sofern jemand Bedarf an der Aktualisierung der Daten außerhalb des zyklischen automatischen Abrufs haben sollte.
device spezifische gets sind somit nur noch für Daten realisiert, die nicht mit get update abrufbar sind. Nach aktuellen Erkenntnissen betrifft dies nur historische Daten bei PowerOcean und Stream xyz Modellen.
Im Ergebnis ist nun viel leichter ersichtlich, welche Daten sich tatsächlich im Betrieb verändern, Loggingdaten sind deutlich reduziert.
Ebenfalls für Intransparenz sorgte die Darstellung von Bildschirmausgaben nach set/get.
Tatsächlich ist es so, dass das Modul richtigerweise Non-Blocking-Get einsetzt.
Das bedeutet im wesentlichen, dass das Modul nicht blockiert, nur weil Antwortzeiten deren Server unbefriedigend sind.
Es bedeutet nun einmal aber auch, dass eine erfolgreiche Verarbeitung der set/get Befehle nicht im Augenblick des Senden ersichtlich ist, sondern erst sobald auch tatsächlich eine Antwort aus der Cloud erfolgt ist.
In der vorherigen Fassung des Moduls wurden also lediglich "alte" Informationen angezeigt. Die "Wahrheit" war erst nach einem Empfang von Daten in den readings ersichtlich, die sich u.U. flip-/flop-mäßig änderten.
Ich habe daher entweder auf Anzeigen verzichtet oder weise in den Bildschirmmeldungen zumindest darauf hin, dass "veraltete" Daten angezeigt werden.
Die device- u. readingspezifischen "adjustments", halte ich für eine sehr sinnvolle Idee von Neolux. Ich habe dazu kleinere Anpassungen vorgenommen:
- device-spezifische Anpassung der einzelnen readings-Werte, sofern modulintern zum device konfiguriert(war bereits so implementiert)
- Zeitangaben sind scheinbar immer in Sekunden. Enthält der reading-Name das Literal "time" wird automatisch in hh:mm umgerechnet
- Internal HardwareVersion entfernt; nun lesbar über die 6 hwVersion_x readings
Weitere Kleingkeiten, die ich geändert habe:
- kein set für AccessKey, da fehleranfällig; bei Änderung des AccessKey besser defmod ausführen
- set "SerialNo", "deleteReadings" entfernt
- einiges im Code zur Verbesserung der Lesbarkeit geändert, reduziert
Hier noch meine Beispiele für den sinnvollen Einsatz der Standard-Attribute.
Für eine Delta2:
Code Auswählen
attr Delta2_AC event-on-change-reading .*
attr Delta2_AC event-min-interval data_pd.inputW.*:160,data_pd.out.*W.*:160,data_pd.usb.W.*:160,data_pd.watts.*:160
attr Delta2_AC timestamp-on-change-reading .*bewirkt, dass nur für Daten, die wirklich aktualisiert wurden ein event erzeugt wird. Der readings-timestamp ändert sich auch nur bei Änderung. Nach einiger Laufzeit erkennt man die wenigen wirklich genutzten readings.Ich habe sogar manuell die timestamps der readings OHNE update in meinem FHEM so angepasst, dass ich leicht an den timestamps erkennen kann, ob und wann sich deren Wert tatsächlich geändert hat.(2025-12-31 23:59:59)
Für durchgängige Plots die Ausnahme mit event-min-interval, dass auch ohne Änderung ein update erfolgt
Für einen Powerstream:
Code Auswählen
attr Powerstream_AC event-on-change-reading .*
attr Powerstream_AC suppressReading data_20_134.*
attr Powerstream_AC timestamp-on-change-reading .*Vergleichbar den Attributen zur Delta2. Zusätzlich die Unterdrückung der unsäglichen time-schedule-Readings.Sicherlich habe ich noch etwas vergessen, aber so ist das leider bei umfangreichen Änderungen.
Bedenkt, dass Ihr nach Einspielen in Euer FHEM ein "reload 98_Ecoflow" machen müsst und mindestens das Attribut ecInterval löschen und ggfs. das Attribut interval anlegen müsst.
Wenn das nicht klappt, müsst Ihr das device neu anlegen. Vorsicht: Holt Euch vorher den SecretKey, da dieser beim Löschen des devices auch aus der Datei gelöscht und wieder neu eingegeben werden muss.
Und nun bin ich auf Euer Feedback gespannt.
Sicherlich werden noch die ein oder andere Anpassung am Modul notwendig, aber in absehbarer Zeit würde ich es dann offiziell mit automatischer Verteilung machen.
Have fun
Markus