- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von binford6000 - 06 Juni 2026, 08:22:00Zitatund was kann ich tun, damit sowas nicht wieder passiert?Setze verbose am Account-Device auf 2. Das Behebt natürlich nicht die Ursache aber zumindest das Volllaufen des Logs.
#92
FHEM Code changes / Revision 31336: controls_fhem....
Letzter Beitrag von System - 06 Juni 2026, 08:00:42Revision 31336: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31336: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31336: controls_fhem.txt: fhemupdate checkin
#93
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von stefanru - 06 Juni 2026, 01:42:33Hi KyleK,
ok ich teste bei mir auch mal, bin sogar auf 600 gegangen, mal sehen ob das was bringt.
Ich habe auch das Modul entschärft, so dass die Prüferei bei fehlerhafter Response nicht jede Sekunde triggert sondern nur alle 30s und nach 10 Fehlversuchen aufgibt und dann erst wieder nach der refresh time versucht.
Außerdem lösche ich die Timer die eventuell stehen bleiben.
Das funktioniert gut und das Problem, dass FHEM langsam wird oder sich Timer akkumulieren ist weg.
Hier ein diff falls Micheal hier rein schaut oder wir es selbst fixen müssen.
Du darfst diesen Dateianhang nicht ansehen.
Ok also polling mit npm_refresh_intervall 600 hilft leider nicht. Geht dann halt schon nach 10 min schief. Der Refresh scheint gar nicht mehr zu funktionieren.
Gruß,
Stefan
ok ich teste bei mir auch mal, bin sogar auf 600 gegangen, mal sehen ob das was bringt.
Ich habe auch das Modul entschärft, so dass die Prüferei bei fehlerhafter Response nicht jede Sekunde triggert sondern nur alle 30s und nach 10 Fehlversuchen aufgibt und dann erst wieder nach der refresh time versucht.
Außerdem lösche ich die Timer die eventuell stehen bleiben.
Das funktioniert gut und das Problem, dass FHEM langsam wird oder sich Timer akkumulieren ist weg.
Hier ein diff falls Micheal hier rein schaut oder wir es selbst fixen müssen.
Du darfst diesen Dateianhang nicht ansehen.
Ok also polling mit npm_refresh_intervall 600 hilft leider nicht. Geht dann halt schon nach 10 min schief. Der Refresh scheint gar nicht mehr zu funktionieren.
Gruß,
Stefan
#94
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von KyleK - 06 Juni 2026, 01:27:08Standardmäßig erneuert echodevice alle 6000 Sekunden (100 Minuten) die Cookies, um mit den Amazon Servern interagieren zu können.
Eventuell ist dies zu lang, der Cookie nicht mehr 6000 Sekunden gültig.
Laut Modul-Dokumentation sollte der Cookie eigentlich 14 Tage gültig sein, ich finde im Cookie selber leider keinen Wert der indiziert, wann der Cookie abläuft.
Ich habe jetzt mal das Attribut `npm_refresh_intervall = 3000` gesetzt, vielleicht hilft eine Reduktion um die Hälfte bereits.
Eventuell ist dies zu lang, der Cookie nicht mehr 6000 Sekunden gültig.
Laut Modul-Dokumentation sollte der Cookie eigentlich 14 Tage gültig sein, ich finde im Cookie selber leider keinen Wert der indiziert, wann der Cookie abläuft.
Ich habe jetzt mal das Attribut `npm_refresh_intervall = 3000` gesetzt, vielleicht hilft eine Reduktion um die Hälfte bereits.
#95
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von KyleK - 06 Juni 2026, 00:17:05Ein Aufruf von `208refresh-cookie.js` im alexa-cookie-Verzeichnis bringt (unter anderem) folgenden Output:
Das passiert auch, wenn ich erst `208create-cookie.js` aufrufe (entspricht NPM Login New), und direkt im Anschluss `208refresh-cookie.js` starte.
Ich hab keine Ahnung was die "Auth time" ist
Ich vermute da hat sich was beim Amazon Backend geändert?
Code Auswählen
Alexa-Cookie: Response (400)
Register App Response: {"response":{"error":{"code":"InvalidToken","index":"xxxxxxxxxxx","message":"Auth time of the token is expired."}},"request_id":"xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}
Das passiert auch, wenn ich erst `208create-cookie.js` aufrufe (entspricht NPM Login New), und direkt im Anschluss `208refresh-cookie.js` starte.
Ich hab keine Ahnung was die "Auth time" ist
Ich vermute da hat sich was beim Amazon Backend geändert?
#96
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von stefanru - 06 Juni 2026, 00:09:27Ok selbes Problem hier, diese Beschreibnung passt auch bei mir:
Wichtig: Ein frischer set <dev> NPM_login new (Browser-Login mit 2FA) stellt die Funktion wieder her – aber nur für ~1–2 Stunden, dann
scheitert der nächste automatische Refresh wieder mit demselben 400 und FHEM friert erneut ein. Innerhalb eines Tages hatte ich das
mehrfach. Ein NPM_login refresh oder ein bloßer FHEM-Neustart helfen nicht.
Habe:
Node v22.22.3
npm 10.9.8
alexa-cookie2 4.2.0 und 5.0.3 probiert
37_echodevice.pm 0527 vom 2025-11-14
Gruß,
Stefan
Wichtig: Ein frischer set <dev> NPM_login new (Browser-Login mit 2FA) stellt die Funktion wieder her – aber nur für ~1–2 Stunden, dann
scheitert der nächste automatische Refresh wieder mit demselben 400 und FHEM friert erneut ein. Innerhalb eines Tages hatte ich das
mehrfach. Ein NPM_login refresh oder ein bloßer FHEM-Neustart helfen nicht.
Habe:
Node v22.22.3
npm 10.9.8
alexa-cookie2 4.2.0 und 5.0.3 probiert
37_echodevice.pm 0527 vom 2025-11-14
Gruß,
Stefan
#97
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von Gary - 05 Juni 2026, 23:57:06Ich habe leider auch dieses Problem seit ein paar Tagen.
Node v24.16.0, NPM 11.16.0
Log läuft voll und wird riesig, FHEM reagiert kaum mehr.
Cookie löschen und/oder neu anmelden hilft nur für kurze Zeit.
Ich habe jetzt auch vorläufig mal das echodevice disabled.
Node v24.16.0, NPM 11.16.0
Log läuft voll und wird riesig, FHEM reagiert kaum mehr.
Cookie löschen und/oder neu anmelden hilft nur für kurze Zeit.
Ich habe jetzt auch vorläufig mal das echodevice disabled.
#98
Einplatinencomputer / Aw: linux watchdog on raspberr...
Letzter Beitrag von RalfRog - 05 Juni 2026, 23:08:08Do you have in mind for the conf:
verbose = <level>
This overrides the command line --verbose option. Generally the verbose mode is only enabled for debugging as it creates a lot of syslog chatter, so use this option with consideration. Zero is "normal" operation (quiet), while 1 is typically used for debugging. Values of 2 or more usually generate far too many messages.
An other thing is that the watchdog is like reset. If there is only the eth0 a problem you may harm your filesystem with the watchdog.
verbose = <level>
This overrides the command line --verbose option. Generally the verbose mode is only enabled for debugging as it creates a lot of syslog chatter, so use this option with consideration. Zero is "normal" operation (quiet), while 1 is typically used for debugging. Values of 2 or more usually generate far too many messages.
An other thing is that the watchdog is like reset. If there is only the eth0 a problem you may harm your filesystem with the watchdog.
#99
Heizungssteuerung/Raumklima / Aw: ebusd bei Wolf CGB (-K)-20...
Letzter Beitrag von Resi - 05 Juni 2026, 22:18:33Hallo zusammen,
für aktuellere CSV-Dateien im Bereich Wolf/Kromschröder + ebusd v26:
Für die CGG-2-18 mit BM-Modul habe ich eine vollständige Konfiguration
veröffentlicht (inkl. HA-Integration):
https://github.com/realResi/ebusd-wolf-cgg2
Für BM-2, CHA, MM und weitere Wolf-Module:
https://github.com/puni2k/ebusd-configuration-wolf
Zur Frage "1x Warmwasser aktivieren": das funktioniert über HG15
(Speicherhysterese) — HG15 kurz auf 1K setzen triggert den FA zum
Zünden, danach Originalwert wiederherstellen. Funktioniert allerdings
nur innerhalb der im BM programmierten WW-Heizzeiten.
für aktuellere CSV-Dateien im Bereich Wolf/Kromschröder + ebusd v26:
Für die CGG-2-18 mit BM-Modul habe ich eine vollständige Konfiguration
veröffentlicht (inkl. HA-Integration):
https://github.com/realResi/ebusd-wolf-cgg2
Für BM-2, CHA, MM und weitere Wolf-Module:
https://github.com/puni2k/ebusd-configuration-wolf
Zur Frage "1x Warmwasser aktivieren": das funktioniert über HG15
(Speicherhysterese) — HG15 kurz auf 1K setzen triggert den FA zum
Zünden, danach Originalwert wiederherstellen. Funktioniert allerdings
nur innerhalb der im BM programmierten WW-Heizzeiten.
#100
Bastelecke / Aw: ESP RGBWW Controller - Fir...
Letzter Beitrag von pjakobs - 05 Juni 2026, 22:03:14So, riesen Änderung:
Ich hatte ja am Anfang entschieden, die Webapp in die eigentliche Firmware einzubauen (als Flash Strings, also direkt im Flash Binary). Mit den letzten Änderungen ist das ganze Binary trotz aller Tricks größer geworden, als meine ROM Partitionen zulassen, also musste ich mir was anderes überlegen.
Was ich nicht wollte ist, wie die Version 4 der Firmware, jedesmal die Filesystem Partition überschreiben, denn da liegt auch die ganze Konfiguration.
Der Weg, den ich jetzt gehe ist:
- die Firmware kommt mit einem extrem minimalen UI, das nur die Verbindung zum WIFI übernimmt.
- sobald die Firmware im WIFI ist, fragt sie auf Lightinator.de nach, ob es eine neue Webapp gibt, dafür hat Lightinator extra ein neues API bekommen
- die Firmware läd dann die Webapp von Lightinator.de in das lokale Dateisystem, startet neu und ab da ist das UI wie üblich zu erreichen.
Kleiner Wermuthstropfen: die HTML Dokumente aus dem Dateisystem zu liefern scheint mehr RAM zu verbrauchen als aus dem ROM, es kommt leider immer wieder dazu, dass einzelne Files nicht beim ersten Mal geladen werden. Der Controller antwortet dann mit einem "Too many connections" und einem Back Off Value, der Client sollte es dann nach ein paar Sekunden nochmal versuchen.
Leider habe ich ein paar mal schon gesehen, dass vor allem die Icons nicht angezeigt werden.
Großer Vorteil: jetzt können Webapp Versionen auch unabhängig von der Firmware ausgeliefert werden und ich hab wieder 300kB Platz für Firmware Funktionen
Das ganze gibt's im Moment nur im "Experimental" Branch - und auch nur für die Mutigen - nicht mal ich hab bisher alle Leuchten auf die Version upgedatet, sie ist also noch nicht wirklich getestet.
Ich hatte ja am Anfang entschieden, die Webapp in die eigentliche Firmware einzubauen (als Flash Strings, also direkt im Flash Binary). Mit den letzten Änderungen ist das ganze Binary trotz aller Tricks größer geworden, als meine ROM Partitionen zulassen, also musste ich mir was anderes überlegen.
Was ich nicht wollte ist, wie die Version 4 der Firmware, jedesmal die Filesystem Partition überschreiben, denn da liegt auch die ganze Konfiguration.
Der Weg, den ich jetzt gehe ist:
- die Firmware kommt mit einem extrem minimalen UI, das nur die Verbindung zum WIFI übernimmt.
- sobald die Firmware im WIFI ist, fragt sie auf Lightinator.de nach, ob es eine neue Webapp gibt, dafür hat Lightinator extra ein neues API bekommen
- die Firmware läd dann die Webapp von Lightinator.de in das lokale Dateisystem, startet neu und ab da ist das UI wie üblich zu erreichen.
Kleiner Wermuthstropfen: die HTML Dokumente aus dem Dateisystem zu liefern scheint mehr RAM zu verbrauchen als aus dem ROM, es kommt leider immer wieder dazu, dass einzelne Files nicht beim ersten Mal geladen werden. Der Controller antwortet dann mit einem "Too many connections" und einem Back Off Value, der Client sollte es dann nach ein paar Sekunden nochmal versuchen.
Leider habe ich ein paar mal schon gesehen, dass vor allem die Icons nicht angezeigt werden.
Großer Vorteil: jetzt können Webapp Versionen auch unabhängig von der Firmware ausgeliefert werden und ich hab wieder 300kB Platz für Firmware Funktionen
Das ganze gibt's im Moment nur im "Experimental" Branch - und auch nur für die Mutigen - nicht mal ich hab bisher alle Leuchten auf die Version upgedatet, sie ist also noch nicht wirklich getestet.