echodevice: wait for refreshtoken im sekundentakt

Begonnen von matze1999, 04 Juni 2026, 08:26:32

Vorheriges Thema - Nächstes Thema

FHEM_Starter

Hallo,

auch mich hat es nun erwischt. Der patch hat zwar geholfen, das echodevice ist connected und eine Zeit lang ist der refresh token "vorhanden". Dann wechselt er wieder auf "refresh failed".

Wird das Modul denn überhaupt noch gepflegt?

Danke und Gruß
Wolfgang

stefanru

#31
Hi duu75,

ich habe mal gesachaut.
Habe ein paar Hypothesen. ioBroker rfreshed viel seltener, erst nach 96h.
IoBroker hat aber einen besseren Auth-Check /api/customer-status. Du bekommst auf jedenfall keine Probleme wie bei FHEM mit Performance.
IoBroker nutzt alexa-remote2 als wrapper.

Nun es kann sein dass nach 96h es auch in IoBroker fehlschlägt. Aber natürlich ohne die effekte die FHEM hatte mit der Performance.
Es könnte aber auch sein dass es durch den anderen check und die Verwendung von alexa-remote2 funktioniert.

@duu75: Kannst du mir sagen ob es in Iobroker einen erfolgreichen refresh nach 96h gibt?
Wenn ja könnte ich versuchen die Logik mit alexa-remote2 auch ins modul zu bauen.

Aber erstmal gehe ich davon aus dass es nach 96h dort auch zu dem Fehler kommt.


@duu75, hätte noch 3 Fragen um das zu verifizieren, ich habe kein ioBroker:
  1. Adapter-Uptime: Im ioBroker Admin auf alexa2 → Instanzen → das "Last
     start" Datum. Lief der Adapter seit dem 04.06. wirklich am Stück,
     oder gab es zwischendrin Restarts?

  2. Cookie-Update: Im Adapter Object alexa2.0.info.cookie der "Last Change"
     Zeitstempel. Wenn der innerhalb der letzten ~12h liegt, hat der Cookie-
     Refresh-Timer (default 96h) gefeuert und du hast bis jetzt überlebt.

  3. Adapter-Log: Im ioBroker-Log nach Strings filtern:
     - "Update cookie in adapter configuration ... restarting"
     - "former registration data exist, try refresh"
     - "Error from refreshing cookies"
     Falls du da gar nichts findest seit 04.06., dann tut es wirklich,
     weil der Refresh-Timer bei Adapter-Restart neu gestartet wird und
     noch nicht gefeuert hat.

Sowohl hier als in IoBroker wird am Schluss die selbe Lib und funktionalität genutzt unterschiedlich ist nur das Timing.
96h vs 6000s also es wäre sehr hilfreich wenn du beobachtest und nach 96h ioBroker laufzeit ohne restart sollten wir etwas sehen könne.

Das beweist aber auch die Tokens leben viel länger.
Meine Devices funktionieren weiterhin auch wenn der Refresh fehlschlägt.


Gruß,
Stefan
FHEM: Raspberry PI 400+SSD Viessmann, Fronius, BYD, Wunderground, Max, Shelly, ESPEasy, FHEMPY,...  Docker + Portainer: Immich, Authelia, Caddy, Gerbera, Paperless NGX
Maintainer: Vitoconnect
GIT: https://github.com/StefanRu1
Kaffeekasse: https://www.paypal.me/stefanru01

stefanru

Ok, hat mir jetzt keine Ruhe gelassen.

Ich habe das Verhalten des ioBroker Moduls mal eingebaut.
Es wird nun immer erst geprüft ob Cookie noch gültig.
Ein Refresh findet erst statt wenn Amazon das Cookie als nicht gültig zurück liefert.
Das sollte sich nun wie ioBroker verhalten.

Somit kann es sein, dass es viel länger dauert bis ein Refresh gemacht wird. Tage bis Monate.
Aber der Refresh ist trotzdem kaputt. Aber wenn er im ioBroker gefixed wird sollte es auch bei uns gefixed werden.

Das ganze natürlich nur auf meiner Annahme, dass der Fehler bei ioBroker im Moment nur nicht sichtbar ist da kein refresh getriggert wird wegen längerer Gültigkeit und danach dort auch ein Fehler entsteht.

Ich teste das gerade, die Tests dauern nun halt viel länger, da es erst sichtbar wird wenn das Token ungültig wird.

Hier für alle interessierten der diff zum original:
Du darfst diesen Dateianhang nicht ansehen.


Gruß,
Stefan
FHEM: Raspberry PI 400+SSD Viessmann, Fronius, BYD, Wunderground, Max, Shelly, ESPEasy, FHEMPY,...  Docker + Portainer: Immich, Authelia, Caddy, Gerbera, Paperless NGX
Maintainer: Vitoconnect
GIT: https://github.com/StefanRu1
Kaffeekasse: https://www.paypal.me/stefanru01