Zitat von: michael.winkler am 08 Juni 2026, 12:27:50Wenn 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.
Zitat von: stefanru am 08 Juni 2026, 09:22:48Hi 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
Zitat von: tostmann am 07 Juni 2026, 23:26:03Chrome auf macOS: notiert. Verdacht: Chromes neue Blockade für Zugriffe ins lokale Netz (Local Network Access) — Safari und Firefox haben die nicht, was zu Deinem Muster passen würde. Schau ich mir an; falls Chrome beim ersten Zugriff eine Berechtigung angefragt und sie verneint wurde, findet sie sich in den Website-