echodevice: wait for refreshtoken im sekundentakt

[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]

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

[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.


P.S.: Kann schonmal bestätigen das nun kein Refresh stattfindet da Cookie gültig bleibt.
Wie lange das geht wissen wir nicht. Aber so spiegelt das Device auch eher den Zustand den es hat.
Auch wird ein neues reading last_auth_check_ok mit OK beantwortet, also cookie gültig.

Gruß,
Stefan

[michael.winkler]

Hallo, ich habe das Verhalten auch gerade festgestellt. Ich werde mir das Problem anschauen. Wann das Modul seinen Refresh macht, kann frei definiert werden! https://www.mwinklerblog.de/smarthome/eigene-module/echodevice/#Attribute (siehe npm_refresh_intervall)

[michael.winkler]

Wenn das Problem auftritt, hat das einen Grund. Falls jemand das Problem hat bitte mal im ./cache/alexa-cookie/.. Verzsichnisch schauen. Dort müsste eine XXrefresh-cookie.js Datei liegen. Direkt daneben sollte ein XXresult.json liegen (XX wir dynamisch vergeben.) Diese Datei mal mit einem "tail -f ./pfad/XXresult.json" öffnen. Hier solle man dann sehen warum er keinen Refresh machen konnte. In meinem Fall konnte mein System keinen Refresh mehr durchführen, da mein Refreshtoken ungültig war! Folgendes habe ich dann gemacht:
1. node gekillt (ps -A | grep node) und dann den Prozess gekillt.
2. Neuen Token per "NPM_login new" erstellt.
3. Refresh Token per "NPM_login refresh" getestet.

[duu75]

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?

Kann da nichts erkennen, was nach Startdatum und Zeit aussieht.
Habe den Adapter auch erst gestern Abend erstmalig aus Verzweiflung installiert.
Von daher läuft der erst seit 7.6.26

  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.

7.6.26 20:04

  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.

Hatte Log leider nur auf Error, jetzt auf Info gestellt und warte mal ab was so kommt.

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

[stefanru]

Hallo Michael,

danke für deine Antwort! Ich habe das auch durchgespielt — aber der nächste Refresh nach 6000s schlägt bei mir auch nach frischem NPM_login new wieder fehl.
Reinschki hat im Forum-Thread #144852 das auch schon beschrieben: nach dem Login geht es 1-2 Stunden, dann kommt HTTP 400 "Auth time of token is expired" auf /auth/register zurück.
Trifft alle Node-Versionen (16-24) und alle alexa-cookie2-Versionen (4.2.0 + 5.0.3), also vermutlich serverseitig bei Amazon.

Wenn der Refresh fehlschlägt, geht das Modul aktuell in einen Loop und versucht jede Sekunde neu — das zieht den Raspberry runter (apptime zeigt 1000+ NPMWaitForCookie-Timer nach ein paar Stunden, ~50 MB/h Memory-Wachstum).

Ich habe das jetzt in einer gepatchten Version gefixt:
- Polling auf 30s gedrosselt, max 10 Versuche dann sauber abbrechen
- 10-Min-Backoff vor dem nächsten Refresh-Versuch
- Smart-Refresh-Gate: vor /auth/register erst /api/customer-status prüfen (Logik aus Apollon77's alexa-remote2 v8.0.4). Solange das HTTP 200 liefert, ist der Cookie noch gültig und der buggy Refresh-Endpoint wird komplett übersprungen.
- EPIPE-Handler im Wrapper-Skript für Node 22+

Patch-Datei mit Doku ein Post höher.

Läuft seit 2 Tagen stabil bei zwei Accounts. Magst du einen Blick drauf werfen ob sich was davon ins Modul einbauen ließe?


Gruß,
Stefan

[michael.winkler]

Mach mal einen refresh von deinem Token. Läuft es dann auch noch?

[duu75]

Wenn das Problem auftritt, hat das einen Grund. Falls jemand das Problem hat bitte mal im ./cache/alexa-cookie/.. Verzsichnisch schauen. Dort müsste eine XXrefresh-cookie.js Datei liegen. Direkt daneben sollte ein XXresult.json liegen (XX wir dynamisch vergeben.) Diese Datei mal mit einem "tail -f ./pfad/XXresult.json" öffnen. Hier solle man dann sehen warum er keinen Refresh machen konnte. In meinem Fall konnte mein System keinen Refresh mehr durchführen, da mein Refreshtoken ungültig war! Folgendes habe ich dann gemacht:
1. node gekillt (ps -A | grep node) und dann den Prozess gekillt.
2. Neuen Token per "NPM_login new" erstellt.
3. Refresh Token per "NPM_login refresh" getestet.

Alles gemacht und es wird das create und refresh cookie erzeugt und in FHEM ist connected und vorhanden angezeigt, aber es geht bei mir gar nichts mehr.

Weder ein get devices ->  Echo is not connected. Aborting...
Oder auf den Echos z.B. set ECHO speak Test  ->  ECHO is not connected. Aborting...

Total tot, obwohl die Cookie Sache nach NPM_login new sauber aussieht

[stefanru]

Hi Michael,

wie gesagt ich habe 2 Accounts.

Einen meiner Accounts habe ich mit login new vor ca 3 Stunden angemeldet. Dort habe ich jetzt einen Refresh gemacht, danach wie erwartet:
amazon_refreshtoken wait for refreshtoken
da der refresh ja nicht geht.

Meine Fixe verhinden nur die System last und unnötige refreshes so wie im ioBroker Modul auch.
Heißt der Fehler wird erst viel später sichtbar, aber er bleibt.
Vorteil: Systemlast niedriger, Problem taucht erst auf wenn auch ein neues Token benötigt wird.

Der Refresh ansich ist kaputt, da geht kein weg dran vorbei.
Da wird wohl Apollo77 nachlegen müssen.


@duu75: Dein Verhalten kann ich bei mir nicht nachvollziehen.
Hast du alexa-cookie2 v5.0.3 und alexa-remote2  v8.0.4.
Bei mir gehen speak usw nach wie vor auch nach 3 Tagen+.

Gruß,
Stefan

[KyleK]

Ich hab auch "geforscht" und lokal rumexperimentiert.
Herausgekommen ist eine modifizierte Version von alexa-cookie2, bei der der Step "Register App" (via /auth/register) beim refresh einfach weggelassen wird.

Ich hab mir die Cookies und so mal genauer angeschaut:
Mir scheint, wir benötigen nur 3 Dinge von alexa-cookie2:
1. den refreshToken, um neue Cookies abfragen zu können (das passiert via /ap/exchangetoken/cookies)
2. Schritt 1 stellt die "localCookies" bereit, die für die meisten (alle?) HTTP Requests im echodevice-Modul benötigt werden.
3. Den CSRF-Wert


Ich hab also die alexa-cookie.js wie folgt erweitert:

Code Auswählen Erweitern

    this.refreshAlexaCookie_new = (__options, callback) => {
        if (!__options || !__options.formerRegistrationData || !__options.formerRegistrationData.refreshToken) {
            callback && callback(new Error('No former registration data provided for Cookie Refresh'), null);
            return;
        }

        if (typeof __options === 'function') {
            callback = __options;
            __options = {};
        }

        _options = __options;

        __options.proxyOnly = true;

        initConfig();

        getLocalCookies(_options.formerRegistrationData.amazonPage, _options.formerRegistrationData.refreshToken, (err, localCookie) => {
            if (err) {
                callback && callback(err, null);
            }

            _options.logger && _options.logger(`getLocalCookies: ${JSON.stringify(localCookie)}`);


            loginData = _options.formerRegistrationData;
            loginData.localCookie = localCookie;
            getCSRFFromCookies(loginData.localCookie, _options, (err, resData) => {
                if (err) {
                    callback && callback(new Error(`Error getting csrf for ${loginData.amazonPage}`), null);
                    return;
                }
                loginData.localCookie = resData.cookie;
                loginData.csrf = resData.csrf;
                delete loginData.accessToken;
                delete loginData.authorization_code;
                delete loginData.verifier;
                delete loginData.loginCookie;
                delete loginData.frc;
                delete loginData.map;
                delete loginData.deviceId;
                delete loginData.deviceAppName;
                delete loginData.deviceSerial;
                delete loginData.tokenDate;
                delete loginData.macDms;
                loginData.dataVersion = 2;
                _options.logger && _options.logger(`Final Registration Result: ${JSON.stringify(loginData)}`);
                callback && callback(null, loginData);
            });
        });
    };

    this.stopProxyServer = (callback) => {
        if (proxyServer) {
            proxyServer.close(() => {
                callback && callback();
            });
        }
        proxyServer = null;
    };

und dann in 37_echodevice.pm beim Erzeugen der <nr>refresh-coookie.js wird refreshAlexaCookie_new() gerufen.


Soweit so gut

[michael.winkler]

Hi Stefan,

Wenn Dein Refresh nicht mehr funktioniert, dann ist bei dir mehr kaputt. Ich würde dir vorschlagen, dass du Deine NPM Umgebung aktualisierts. Anbei der Link: https://www.mwinklerblog.de/modul-echodevice-npm/

Ich würde das alexa-cookie Verzeichnis im Cacheverzeichnis vorher umbenennen. Danach dann die Installation entweder per FHEM GUI oder per SSH machen. Ich persönlich favorisiere die SSH Variante.

Danach noch mein ein new und dann ein Refresh. Wenn der Refresh nicht funktioniert, wäre interessant was in der Resultdatei steht.

[michael.winkler]

Ihr könnt gerne alle Eure eigenen Module weiterentwickeln, ich kann mich da auch gerne zurückziehen und nur noch für mich das Modul weiterentwickeln.

[stefanru]

Hi Michael, nein so ist das überhaupt nicht gemeint.
Schau es dir in ruhe an.

Ich denke der Refresh tut nach einer gewissen Zeit nicht.
Das ist was wir hier alle als Problem hatten.
Danach pollt das Modul sehr aggresiv jede Sekunde und Timer akkumulieren sich.

Mehr wollte ich dazu nicht sagen.
Ich habe für mich erstmal eine Lösung mit der ich meine Echos weiter betreiben kann und mein Raspberry läuft.

Natürlich warte ich auf einen sauberen Fix von dir und mein Code kann gerne benutzt oder verworfen werden wenn nicht zielführend.

Sorry wenn das falsch rüber kam.

Gruß,
Stefan

[michael.winkler]

Hi Michael, nein so ist das überhaupt nicht gemeint.
Schau es dir in ruhe an.

Ich denke der Refresh tut nach einer gewissen Zeit nicht.
Das ist was wir hier alle als Problem hatten.
Danach pollt das Modul sehr aggresiv jede Sekunde und Timer akkumulieren sich.

Mehr wollte ich dazu nicht sagen.
Ich habe für mich erstmal eine Lösung mit der ich meine Echos weiter betreiben kann und mein Raspberry läuft.

Natürlich warte ich auf einen sauberen Fix von dir und mein Code kann gerne benutzt oder verworfen werden wenn nicht zielführend.

Sorry wenn das falsch rüber kam.

Gruß,
Stefan

Nachdem jetzt der Zweite Benutzer mit seiner eigenen Modulweiterentwicklung ums Eck kam, dachte ich schreibe Euch das mal.

Mach mal bitte ein get Status an deinem Account Device und schicke mir die Daten zu. Ich würde gerne mal etwas prüfen.