echodevice: wait for refreshtoken im sekundentakt

[stefanru]

Hi 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

[erdnar]

Bei mir das selbe Problem. (refreshtoken im Sekundentakt)
Nach dem Patch nur noch ca. aller 30 Sekunden.

Also vielen Dank erstmal.

[stefanru]

Habe noch etwas probiert, es hilft leider nichts was ich probiert habe.

Mit meinem Patch ist die Last nun ok.
Sobald sich bei Amazon was ändert oder etwas gefixed wird geht es auch mit dem Patch.

Der Patch hatte noch einen kleinen Bug.
Außerdem hatte ich logging auf 2 gehoben. Hab es wieder auf 3 gesetzt wie es war.
Hier nochmal ein patch fürs original:
Du darfst diesen Dateianhang nicht ansehen.

Gruß,
Stefan

[duu75]

Ich habe es bei mir aktuell wieder vorerst am Laufen, hoffentlich bleibt es so stabil.

Habe mit Try and Error alles mögliche gemacht.

npm -v
10.8.2

node -v
v20.20.2


In der folgenden Reihenfolge manuell nochmal alles drüber installiert: (was davon jetzt alles wirklich notwendig war, keine Ahnung)

sudo npm install --prefix /opt/fhem/cache/alexa-cookie alexa-cookie2
sudo npm install

Aufgrund dann der Hinweise im Install-Log nach der Installation noch:
sudo npm audit fix --force

Dann zurück in FHEM "set .... npm_login new"

Da ist dann immer noch nach der Passworteingabe "Webseite nicht verfügbar" gekommen und aber manchmal die Aufforderung zum Passwortchange mit OTP.
OTP Eingabe über den Proxy Port 3002 ging aber nie.

Dann manuell bei Amazon Webseite eingeloggt und dort den Passwortchange mittels OTP durchgeführt.

Danach mit neuem Passwort über FHEM npm_login new erfolgreich:

-rw-r--r--   1 fhem dialout  574 Jun  6 15:59 468create-cookie.js
-rw-r--r--   1 fhem dialout 8,0K Jun  6 16:01 468refresh-cookie.js

[stefanru]

Ja login new mit OTP geht eigentlich und dann bleibt das Token erstmal 6000sek ok, danach wird ein refresht gemacht und der geht schief.
Dann geht die Schleife los.
Also der Refresh scheint nicht mehr so zu funktionieren wie früher.

Sollte es bei dir @duu75 in 1 bis 2 Stunden noch gehen wäre das sehr ertaunlich und deine Versionen interessant.

Gruß,
Stefan

[duu75]

Ja login new mit OTP geht eigentlich und dann bleibt das Token erstmal 6000sek ok, danach wird ein refresht gemacht und der geht schief.
Dann geht die Schleife los.
Also der Refresh scheint nicht mehr so zu funktionieren wie früher.

Sollte es bei dir @duu75 in 1 bis 2 Stunden noch gehen wäre das sehr ertaunlich und deine Versionen interessant.

Gruß,
Stefan

Sch****  genau in dem Moment 17:42 geht es wieder jede Sekunde los.
Hat also nichts gebracht, bis auf einmal für 6000 Sekunden ein Token zu haben.

Was muss ich mit der Modul diff Datei machen?
Sind da alle notwendigen Änderungen drin, um auf 30 Sekunden zu kommen in dem Fall?

Wie merge ich so etwas in meine 37_echodevice.pm ?

Entsprechend einfach überschreiben in den angegeben Bereichen?
z.B. @@ -4455,8 +4455,26 @@

Oder gibt es da einen automatisierten Trick dafür?

[stefanru]

Ja genau das ist das Problem.
Das Token ist aber länger gültig und es geht weiter.
Wenn es dann ohne ständigen Refresh ungültig wird werden wir sehen (Tage/Wochen/Monate).
Mein Fix behebt das performance Problem und hält trotzdem die Versuche der Updates aktiv nur nicht im sekunden Takt.

Patch gegen das original Modul:
  # 1. Diff auf Pi legen (z.B. via scp oder Copy-Paste)
  # 2. Backup
  sudo cp /opt/fhem/FHEM/37_echodevice.pm /opt/fhem/FHEM/37_echodevice.pm.backup
  # 3. Test ohne zu ändern
  sudo patch --dry-run /opt/fhem/FHEM/37_echodevice.pm < /tmp/echodevice_patches.diff
  # 4. Wenn ok: echter Patch
  sudo patch /opt/fhem/FHEM/37_echodevice.pm < /tmp/echodevice_patches.diff
  # 5. In FHEM-Webinterface:
  reload 37_echodevice

Ich empfhele aber einen Neustart von FHEM, nachdem das Modul gepatched ist.
Da das original Modul Timer nicht sauber aufräumt und die dann noch rumgeistern.

Gruß,
Stefan

[duu75]

Ja genau das ist das Problem.
Das Token ist aber länger gültig und es geht weiter.
Wenn es dann ohne ständigen Refresh ungültig wird werden wir sehen (Tage/Wochen/Monate).
Mein Fix behebt das performance Problem und hält trotzdem die Versuche der Updates aktiv nur nicht im sekunden Takt.

Patch gegen das original Modul:
  # 1. Diff auf Pi legen (z.B. via scp oder Copy-Paste)
  # 2. Backup
  sudo cp /opt/fhem/FHEM/37_echodevice.pm /opt/fhem/FHEM/37_echodevice.pm.backup
  # 3. Test ohne zu ändern
  sudo patch --dry-run /opt/fhem/FHEM/37_echodevice.pm < /tmp/echodevice_patches.diff
  # 4. Wenn ok: echter Patch
  sudo patch /opt/fhem/FHEM/37_echodevice.pm < /tmp/echodevice_patches.diff
  # 5. In FHEM-Webinterface:
  reload 37_echodevice

Ich empfhele aber einen Neustart von FHEM, nachdem das Modul gepatched ist.
Da das original Modul Timer nicht sauber aufräumt und die dann noch rumgeistern.

Gruß,
Stefan

patch ist der Zauberbefehl 

Danke für den Patch und die Tips

[d0m2011]

Ja genau das ist das Problem.
Das Token ist aber länger gültig und es geht weiter.
Wenn es dann ohne ständigen Refresh ungültig wird werden wir sehen (Tage/Wochen/Monate).
Mein Fix behebt das performance Problem und hält trotzdem die Versuche der Updates aktiv nur nicht im sekunden Takt.

Patch gegen das original Modul:
  # 1. Diff auf Pi legen (z.B. via scp oder Copy-Paste)
  # 2. Backup
  sudo cp /opt/fhem/FHEM/37_echodevice.pm /opt/fhem/FHEM/37_echodevice.pm.backup
  # 3. Test ohne zu ändern
  sudo patch --dry-run /opt/fhem/FHEM/37_echodevice.pm < /tmp/echodevice_patches.diff
  # 4. Wenn ok: echter Patch
  sudo patch /opt/fhem/FHEM/37_echodevice.pm < /tmp/echodevice_patches.diff
  # 5. In FHEM-Webinterface:
  reload 37_echodevice

Ich empfhele aber einen Neustart von FHEM, nachdem das Modul gepatched ist.
Da das original Modul Timer nicht sauber aufräumt und die dann noch rumgeistern.

Gruß,
Stefan

Vielen Dank für den schnellen Patch - bei mir hat es auch funktioniert (zumindest bis jetzt).
Außer der --dry-run, der hat nicht funktioniert.