UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[ammawel]

@Tino-0
Hallo,
mindestens ebenso spannend wie das Ergebnis finde ich den Weg, eine Korrektur durch ChatGPT machen zu lassen.

Bis vor ein paar Tagen dachte ich, dass nach der Anpassung durch Marc Berg die aktuellen Werte zuverlässig im Ordner measuregrps01 liegen, aber nach hinzufügen der Herzfrequenz zu den Messungen der Body-Smart-Waage fing das Chaos wieder an: aktuelle Herzfrequenz in 01 und aktuelles Gewicht in 02, dann mal beides in 01 u.s.w.. Das Entfernen der Herzfrequenzmessung brachte wieder Ordnung ins Chaos.

Zwei Fragen zu Deiner Lösung:

• Basiert Deine Modifikation auf der bereits geänderten main.js vom github-Verzeichnis des ursprünglichen Ersteller TA2K (https://github.com/TA2k/ioBroker.withings)? In dieser Version wurde die Sortierung von Marc Berg ja bereits eingepflegt.
• Wirst Du auch ein pull-request erstellen, sodass Deine Änderungen eingepflegt werden können und hoffentlich eine stabil funktionierende Version des Adapters entsteht?

Danke für Deine Mühen,
vG, Achim

[ammawel]

@Tino-0
Problem: Was nimmt man als Trigger? Eine Aktualisierung der Werte in lastMeasures tritt bei jedem refresh des eingestellten Updateintervalls auf, eine Änderung der Werte scheidet auch aus...
Bisher habe ich auf eine Änderung von date in measuregrp01 getriggert - so 100%ig verlässlich ist das aber auch nicht mehr nach den Erfahrungen mit der Herzfrequenz (s.o.).

[Tino 0]

@ammawel

Hallo,

ChatGPT hat es so implementiert, wobei bei lastActivity noch ein Fehler drin war und es ist oben eine neue Version drin.

Zitat von ChatGPT
Fazit: Woher kommt der „letzte Wert“? – Kurzfassung

1. lastMeasures
   Die Withings-API liefert measuregrps ungeordnet.
   Dein Adapter sortiert sie zuerst nach Zeit absteigend (date → created → modified).
   Danach ist Index 0 immer die neueste Messung.
   writeLastMeasures() geht von oben nach unten durch und nimmt pro Mess-Typ nur den ersten Treffer.
   → Ergebnis: Der neueste Wert pro Typ.

2. lastActivity
   Der Adapter sortiert activities nach modified absteigend.
   Danach ist activities[0] die neueste Aktivität.
   writeLastActivity() schreibt genau diesen Eintrag.
   → Ergebnis: Immer die aktuellste Aktivität.

3. lastSleep / lastSleepSummary
   Sleep-Daten (series) werden nach startdate oder modified absteigend sortiert.
   Dadurch ist series[0] die neueste Nacht.
   writeLastSleepSummary() nimmt genau diesen Eintrag.
   → Ergebnis: Immer die aktuellste Sleep-Summary.

Ultrakurz:
Sortierung entscheidet, nicht Withings.
Alles wird neueste zuerst sortiert.
Der Adapter nimmt immer das erste Element [0] nach der Sortierung.
Deshalb bekommst du überall den wirklich letzten Wert.

Zitat Ende:

Wenn morgen das Sleep durchläuft, werde morgen mal den pull-request erstellen.

Gruß Tino

[ammawel]

@Tino-0
Ja, der Algorithmus von ChatGPT ist schön und liefert die neuesten Werte. Genau das, was man braucht.
Aber woran erkenne ich, dass der Wert erneuert wurde - das z.B. eine neue Wägung stattgefunden hat - und dass das neue Gewicht irgendwo gespeichert, verrechnet oder sonst was werden soll? Bei mir wird es z.B. mit anderen Parametern in eine csv-Datei geschrieben.
Das Gewicht muss sich gegenüber der letzten Wägung nicht ändern und aktualisiert wird der Wert in lastMeasures immer, wenn das im Adapter eingestellte Updateintervall auslöst, bei mir alle 10 Minuten. Diese beiden Eigenschaften scheiden als Trigger also aus.

[Tino 0]

@ammawel

Es ist oben wieder eine neue Version jetzt mit Update Datum:

....lastMeasures.1
....lastMeasures.1_update
....lastMeasures.5
....lastMeasures.5_update

Als Datum wurden "date" ausgewählt.

Zitat CharGPT
Welchen Zeitstempel willst du als „Update“-Zeit für lastMeasures verwenden?
Die Withings-Measure-Group enthält drei mögliche Zeitfelder:

✔ date
→ Der eigentliche Messzeitpunkt (Unix)

✔ created
→ Wann die Messung auf dem Server erstellt wurde (Unix)

✔ modified
→ Wann die Messung zuletzt geändert wurde (Unix)

Gruß Tino

[ammawel]

@Tino-0
Super, fast perfekt. "Fast" weil die Zeit als String im ioBroker erscheint.
Konkret:
lastMeasures.1_update sagt 2025-11-18T06:06:05.000Z als String,
die Messung war zur Zeit 1763445965000, entsprechend 18.11.2025 07:06:05
Natürlich kann man das im Script umbasteln, aber vlt. kann ChatGPT das direkt in eine "normale" Zeitangabe ändern.

Vielen Dnk für "eure" Mühen,
vG Achim

[Tino 0]

@ammawel

habe es geändert, oben ist eine neue Version drin.

Gruß Tino

[ammawel]

@Tino-0
die Zeitangabe ist immer noch vom Typ String, jetzt allerdings in einem ISO-Format.
Sollte das nicht wie für Datum-/Zeit-Werte in Javascript und ioBroker üblich eine Zahl sein, die die Millisekunden seit dem 1.1.1970 angibt (Unix-Angabe)?
Die date-Angaben der measuregrpsXX sind doch auch vom Typ Number und geben die Millisekunden an.

[Tino 0]

@ammawel

die war im ISO Format 2025-11-18T06:06:05.000Z jetzt ist sie in .toLocaleString("de-DE")

1. ISO-8601 (der Standard für alles, ideal fürs Logging & ioBroker)

new Date(ts * 1000).toISOString()

Format:
2025-02-19T10:32:55.000Z


✓ Maschinentauglich
✓ Sortierbar
✓ Universell
✓ ioBroker liebt es

2. Lokales Datum + Zeit (z.B. „2025-02-19 11:32:55“)

new Date(ts * 1000).toLocaleString("de-DE")

Beispiel:
19.02.2025, 11:32:55

3. Nur Datum

new Date(ts * 1000).toLocaleDateString("de-DE")

Ergebnis:
19.02.2025

4. Nur Uhrzeit

new Date(ts * 1000).toLocaleTimeString("de-DE")

Ergebnis:
11:32:55

5. UNIX Timestamp

Wenn du den Rohwert willst:

ts    // Sekunden
Date.now() // Millisekunden

Was willst du haben?

Gruß Tino

[ammawel]

"Was willst du haben?" :blush: ja ja, hab verstanden :blush:
ernsthaft: auf keinen Fall einen String, ganz normal die Millisekunden seit dem 1.1.1970 als Typ Number,
also z.B. 1763502691926 für jetzt, damit kann man problemlos jedes gewünschte Anwenderformat erzeugen

Gruß Achim

[Tino 0]

@ammawel

so jetzt schaue mal es gibt jetzt zusätzlich noch den 1_timestamp.

[ammawel]

uff...

• XX_timestamp hat den richtigen Zahlenwert
• wenn die Eigenschaft "role" für XX_timestamp nicht "value" sondern "date" ist, erhält man im Objektbaum des ioBrokers auch eine Darstellung als Datum, obwohl es immer noch eine Zahl ist, nach der man sortieren kann, Differenzen bilden kann, in jedem beliebigen Datums- / Zeitformat anzeigen lassen kann etc.

Dann ist ein zusätzlicher Datenpunkt mit dem Datum als String nicht mehr erforderlich, eher verwirrend, und XX_update könnte entfallen.
Vorschlag: Entweder XX_timestamp (würde ich bevorzugen) oder XX_update

Ich habe das mal im Objektbaum für 1_timestamp geändert:

[Tino 0]

@ammawel

so aber jetzt!

Gruß Tino

[ammawel]

Perfekt!
Vielen Dank für Deine Arbeit, Mühen und die Geduld.
Mir hat der Abend viel Spaß bereitet, jetzt reicht es aber auch.
Viele Grüße und gute Nacht
Achim

[Tino 0]

@ammawel

gleiche

[Tino 0]

moin,

ich habe noch einmal etwas geändert, die Rolle date wird immer gesetzt bei (date|startdate|enddate|timestamp|modified|created) in den Datenpunkten lastActivity und lastSleep. Neuste Version ist oben drin.

Gruß Tino

[ammawel]

@Tino-0
Moin,
ich hab auch noch was:
tsRaw ist um Faktor 1000 zu klein, zur Zeit sind das Sekunden, es müssen aber für ein richtiges Datum-Objekt Millisekunden sein.

Zeile 398 müsste mMn dann so aussehen (gerade getestet):

const tsRaw = Number(grp.date * 1000) || null; // Millisekunden

Edit:
Im Objektbaum wird das Datum mit dem zu kleinen Wert zwar richtig angezeigt (warum?), wenn man aber den Wert editiert, stimmt das Datum in den Datumsfeldern die dann angezeigt werden nicht mehr. Mit Faktor 1000 passt es.

Edit:
Die Withings-Api liefert wohl generell Sekunden statt Millisekunden...

[ammawel]

const tsRaw = typeof grp.date === "number" ? grp.date * 1000 : null;

[Tino 0]

@ammawel

ist geändert in

const tsRaw = typeof grp.date === "number" ? grp.date * 1000 : null;

[Tino 0]

@ammawel

so sollte jetzt in dem https://github.com/TA2k/ioBroker.withings sein.

Gruß Tino