Withings Modul - 32_withings.pm (Support)

[arthur_dent_2015]

Hallo,

habe seit einigen Tagen diese Meldung im Log:

Code Auswählen Erweitern

withings: getUserDetail json error Invalid Params: action is specified in URL and in GET/POST dataKennt jemand den Grund dafür?
Vielen Dank
LG Ralf

Die Meldung hab ich auch alle 15 Minuten im Log. Die Werte im Device sind alle aktuell.
Gruß
Arthur

[erdnar]

Hallo,

habe seit einigen Tagen diese Meldung im Log:

Code Auswählen Erweitern

withings: getUserDetail json error Invalid Params: action is specified in URL and in GET/POST dataKennt jemand den Grund dafür?

Ist jetzt sicher nur bedingt hilfreich:
Ich habe heute das WithingsModul erstmalig (wegen neuer Waage) installiert.
Der Fehler taucht ab Installation im 15-Minutenrythmus auf.
Danke
ErdnaR

[roelleke]

Bei mir tritt der Fehler ebenfalls für jeden User auf. Wäre schön zu wissen was da falsch läuft.

[reder]

Hallo markus-m,

zu dem in #495, #496 und #497 gemeldeten Fehler habe ich die Ursache gefunden.
Der Patch ist eine Zeile. Zeilennummern beziehen sich auf Release 19 / 2024-06-08
($Id: 32_withings.pm 28952).

Symptom

Code Auswählen Erweitern

withings: getUserDetail json error Invalid Params: action is specified in URL and in GET/POST data
Alle 15 Minuten, einmal pro USER-Device. Bei mir mit drei USER-Devices 178 Zeilen pro
Tag - das FHEM-Hauptlog besteht praktisch nur noch daraus. Der Log3-Level ist in
Zeile 1720 hart auf 1 gesetzt, per verbose also nicht wegzudrücken.

Messwerte kommen normal weiter, die laufen über /cgi-bin/v2/measure (action=getvasistas).
Betroffen sind nur die User-Metadaten.

Warum alle 15 Minuten

Zeile 2124-2126: bringt ein Poll keine neuen Messwerte
($newlastupdate == $lastupdate and $i == 0), ruft das USER-Device
withings_getUserDetail() auf. Das ist der Normalfall - man wiegt sich nicht alle
15 Minuten. Dazu einmal beim Start über withings_initUser, Zeile 1224.

Ursache

withings_getUserDetail ist die einzige Funktion im Modul, die noch den alten
Dispatcher scalews.withings.com/index/service/... verwendet (Zeile 1707). Alle
übrigen, funktionierenden Calls gehen auf /cgi-bin/... :

Code Auswählen Erweitern

/cgi-bin/account      action=get / getuserslist
/cgi-bin/association  action=getbyaccountid
/cgi-bin/device      action=getproperties
/cgi-bin/v2/measure  action=getvasistas
jeweils mit action im POST-Body. /index/service/user auf scalews ist offenbar
serverseitig weggefallen.

Warum die Fehlermeldung in die Irre führt

Sie behauptet, action stehe in der URL und im Body. FHEM sendet es aber nur
einmal: das data-Hashref wird in HttpUtils.pm Zeile 698-707 zum urlencodierten
POST-Body zusammengebaut und in Zeile 746-750 mit
Content-Type: application/x-www-form-urlencoded verschickt. Die URL in Zeile 1707 hat
keinen Querystring. Wer der Meldung folgt, sucht also an der falschen Stelle - das
erklärt vermutlich, warum der Fehler seit Juli offen ist.

Vermutung zur Herkunft des Textes, ohne Beweis: für den index/service-Dispatcher setzt
das Modul action an einer Stelle tatsächlich doppelt - Zeile 772/775,
auth.withings.com/index/service/once?action=get plus data => {action => 'get'}. Dieser
Call funktioniert weiterhin, sonst käme kein Login zustande. Möglicherweise wirft
derselbe Dispatcher die Meldung inzwischen auch dann, wenn action nur im Body steht.

Patch, Zeile 1707

Code Auswählen Erweitern

-    url => $hash->{'.https'}."://scalews.withings.com/index/service/user",
+    url => $hash->{'.https'}."://scalews.withings.com/cgi-bin/user",
action => 'getbyuserid' bleibt unverändert im data-Hashref. Der Endpoint ist empirisch
bestätigt, nicht aus einer Doku abgeleitet.

Verifikation

Nach FHEM-Neustart:

1. Die Meldung ist weg.
2. Wichtiger, weil das "still" von "funktioniert" unterscheidet: list <USER-Device>
  zeigt die Internals, die Zeile 1226-1232 aus der Antwort füllen - shortName,
  userName, birthdate, age, gender, created, modified - dazu status 0 als
  API-Bestätigung. Vorher waren die leer, weil getUserDetail undef zurückgab.

Wer nur Punkt 1 prüft, kann einen stummgeschalteten Fehler nicht von einem behobenen
unterscheiden. Punkt 2 ist der eigentliche Nachweis.

Betroffene Version

Release 19 / 2024-06-08. In fhem-mirror/master unverändert, ein update behebt es also
nicht. Getestet auf FHEM unter Raspberry Pi, aktuelles Update-Level.

Bis das eingebaut ist

Code Auswählen Erweitern

attr global exclude_from_update 32_withings.pm
Achtung, eine Lücke: das greift bei update, update all und update force,
aber nicht bei einem gezielten update 32_withings.pm. 98_update.pm läuft
dann in den $isSingle-Zweig (Zeile 325 sowie 353-354) und überspringt die Skip-Logik in
Zeile 365-368 - der Patch wäre weg.

markus-m, magst du das übernehmen?

Viele Grüße Reder