creates tenthousands objects and states with withings.sleep #9
Comments
|
Can you provide a screenshot of the folder |
|
Hmmm. Difficult! Edit: Maybe I can extract the objects and states from the backup files directly. Would this be sufficient too? Edit II:
So in the end: running the adapter for approx. 120 nights with approx 1.400 states per night it would sum up to 168.000 states. Thats pretty close to what I'm facing. Since I configured to retrieve the last 30 days I expected older values to be deleted. But in fact it dosen't seem to be the case.
|
|
can you try the github version. Should now be sorted and series01 should have the most recent object |
|
Das ist bei mir genauso, dass unfassbar viele Objekte angelegt werden. Ich habe jetzt die neue Github-Version geladen und meinen ganzen Verzeichnisbaum von Withings gelöscht, um neu zu werden. |
|
@TA2k : What is your preferred language mon github? German or english? I tested the github version over night and Objects increased by ~540 and states by ~1500. You create states for HR, RR, ... with a current value (I'm assuming). Are the state names (-> red rectangle) timestamps? If so - it's pretty impossible to write these values to a database to analyze/visulize them using grafana, float, VIS, ... , since it's impossible to react to constantly changing state names. In the end: You can't do anything with these data. I think - what we really need here is a structure like: And this structure needs to be updated with every value the API delivers (also if someone chooses to poll last xx nights from the API). And only the newest value stays in the object tree. Every older value needs to be stored in the database. That's the only way it makes sense. All the "seriesXX" stuff doesn't make any sense to me - it's not loggable. |
|
Danke für den Screenshot ich habs jetzt glaube verstanden Wieviele timestamps kommen denn pro serie eintrag? Ich gehe zur zeit von einem aus |
|
Jetzt steht unter In dem Zusammenhang ist mir auch aufgefallen, das das oben gesagte quasi genauso für die sleepSummary gilt. Für meinen Geschmack könnte man das zusammen legen. Einheiten wären auch noch ein super Gewinn. Bei vielen Zahlen weiß man einfach nicht, wie man die interpretieren soll. Wie wird bei dem Adapter eigentlich die morgentliche Aktualisierung getriggert? |
|
Gibt es im log errors? in der api finde ich dazu nichts zur aktualisierung |
Nein. Keine Fehler - Zumindest nicht gerade. Das ist das gesammte current-log:
Das meinte ich auch nicht. Holt der Adapter sebständig Zeitgesteuert neue Daten, oder schickt die API die von sich aus? |
|
nochmal installieren |
|
Es wird immer spannender: ;) |
|
Loggst Du die Daten unter Sleep? Ich nehme die von Sleep Summarys/Data/Series01
Mit freundlichen Grüßen
Andreas Wahn
Bitte denken Sie an unsere Umwelt und ob es notwendig ist diese Email auszudrucken.
Mit What3Words finden Sie jede Adresse punktgenau:
https://w3w.co/teppiche.pflegen.angelegt
Mörfelder Landstraße 210
60598 Frankfurt
Tel: +49 69 872 00 878
Mobil: +49 157 3963 4367
Am 22. Juni 2022, 16:09 +0200 schrieb Grizzelbee ***@***.***>:
… Es wird immer spannender: ;)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
@Damrak2022
Nimm mal den Puls (rotes Rechteck). In der Summary siehst du Min, Max und Durchschnitt. Wenn Du aber zum Beispiel den Verlauf über die ganze Nacht analysieren musst, brauchst Du die Daten aus Sleep, weil Du dort das Tupel TimeStamp/Puls hast. Und nur damit kannst Du die Pulskurve über die ganze Nacht zeichnen. Deshalb sage ich ja das wir die Daten aus SleepSummary brauchen und zusatzlich:
Das ganze SeriesXX-Gedöns ist nach meinem Dafürhalten unnötig und bringt keinen Mehrwert. Zumal ich irgendwie das System noch nicht durchschaut habe. Series01 scheint immer die letzte Nacht zu sein - was über die Zeit betrachtet, dazu führt, dass sich unter |
|
nochmal probieren |
|
Ich erfasse die Daten seit heute wieder mit Influx. Allerdings habe ich mich noch nie mit den Daten aus Sleep auseinandergesetzt. Es wäre natürlich super, wenn das alles sehr gut loggen könnte um es dann in Grafana darzustellen. Mir wäre der Rückblick auf die letzten 6 Monate, oder noch besser 1 Jahr wichtig. Auf der anderen Seite dürfen natürlich die Objekte nicht so massiv ansteigen, das irgendwann wiederherstellen über 100000 Objekte vorhanden sind. Aber insgesamt fehlt mir da nochveine Menge an Hintergrundwissen. Auf jeden Fall bin ich dankbar, das es diesen Adapter gibt und er jetzt vielleicht optimiert werden kann.
Mit freundlichen Grüßen
Andreas Wahn
Bitte denken Sie an unsere Umwelt und ob es notwendig ist diese Email auszudrucken.
Mit What3Words finden Sie jede Adresse punktgenau:
https://w3w.co/teppiche.pflegen.angelegt
Mörfelder Landstraße 210
60598 Frankfurt
Tel: +49 69 872 00 878
Mobil: +49 157 3963 4367
Am 22. Juni 2022, 16:51 +0200 schrieb Grizzelbee ***@***.***>:
… @Damrak2022
Naja. Beide sind interessant und ergeben nur zusammen das ganze Bild.
Die Summary bietet die Zusammenfassung der Nacht. Das ist schon einmal super. Da fehlen mir im Grunde nur ein paar Einheiten zum besseren Verständnis.
Nimm mal den Puls (rotes Rechteck). In der Summary siehst du Min, Max und Durchschnitt. Wenn Du aber zum Beispiel den Verlauf über die ganze Nacht analysieren musst, brauchst Du die Daten aus Sleep, weil Du dort das Tupel TimeStamp/Puls hast. Und nur damit kannst Du die Pulskurve über die ganze Nacht zeichnen.
Deshalb sage ich ja das wir die Daten aus SleepSummary brauchen und zusatzlich:
• RR+Timestamp,
• HR+Timestamp
• Snoring+Timestamp,
• StartDate
• EndDate
Das ganze SeriesXX-Gedöns ist nach meinem Dafürhalten unnötig und bringt keinen Mehrwert. Zumal ich irgendwie das System noch nicht durchschaut habe. Series01 scheint immer die letzte Nacht zu sein - was über die Zeit betrachtet, dazu führt, dass sich unter sleep-series01-data-hr (und den anderen: rr, snoring) unendlich viele States ansammeln, weil sich die IDs nie wiederholen (können, da timestamps). Dadurch können sie aber auch nicht in einer DB erfasst werden.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@TA2k Aber jetzt fehlt noch der TimeStamp zu hr, rr und snoring. Die Daten ergeben nur zusammen Sinn. Deshalb ja meine Idee SLEEP und die SeriesXX komplett in Rente zu schicken und SleepSummary um die oben genannten Felder zu erweitern. Dann ergibt sich ein komplettes Bild einer Nacht - und baut sich über die Zeit vernünftig in der DB auf. Das einzige Problem sind dann nur noch die historischen Daten. Die würde ich über einen Button im Config holen und scheiben lassen. Sodass man nach der Installation des Adapters die DB-Konfig für die Historisierung machen kann und dann einmalig auf Button-Klick die historischen Daten reinladen. Eine Automatik halte ich für zu kompliziert. |
|
Ich habe noch was angepasst |
|
<img width="524" alt="Screenshot-3" src="https://user-images.githubusercontent.com/101031627/175293484-93b8520a-87f4-4c07-993f-64c5cb4fe5b6.png">
Guten Morgen,
Ich habe jetzt nochmal eine Frage: Könntest Du den Wert von total_sleep_time unter sleep summary’s wieder auf den Minuten, bzw. Sekunden Wert abändern? Dann wäre nämlich das Logging einfacher und vor allem die Weiterverarbeitung in Grafana.
Weiterhin verstehe ich die Daten noch nicht so ganz. In der App wird mir für die heutige Nacht eine Schlafenszeit von 1 Std. 30 min angezeigt, aber in den Objekten ein Wert von 2Std.30 min
Auch bei den anderen ersten gibt es Abweichungen.
Zur Verdeutlichung habe ich Dir mal einen Screenshot aus der App, sowie von den Datenpunkten angehängt.
Weiterhin ist mir nicht klar wie ich z.B den Wert total_timeinbed umrechnen soll um einen korrekten Minutenwert zu erhalten. Der Wert in den Datenpunkten ist 7980. Laut App war ich genau 2 Std. 13min im Bett - siehe Screenshots.
Dies trifft auch auf einige andere Werte zu.
Generell möchte ich auf jeden Fall folgende Datenpunkte loggen und in Grafana visualisieren - siehe Screenshot 3
Ich hoffe, ich habe mich halbwegs verständlich und nachvollziehbar ausgedrückt.
Am 22. Juni 2022, 18:38 +0200 schrieb TA2k ***@***.***>:
… Ich habe noch was angepasst
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Mir ist gerade aufgefallen das bei Activities 01 und Activities 02 die absolut identischen Daten drinstehen. Gruß Andy |
|
Ich habe keine Ahnung es werden nur die Daten aus der API weitergeleitet. |
|
Hallo zusammen, erstmal danke für den Adapter. Ich habe das Problem, das nach ca. einer Woche meine DB zu viele Datapoints hat und extrem langsam wird. Im Prinzip fängt das ganze System an in die Knie zu gehen. Der Grund ist der sleep-Ordner im Adapter. Die Anzahl der Datenpunkt steigt hier täglich an. Meine Frage wäre, kannst du in den Adapter eine delete-Funktion einbauen? Es würde reichen, wenn ich einstellen kann, jeden Tag 12 Uhr den sleep-Ordner löschen. Aktuell mache ich das per Hand. Grüße Tobi |
|
Kannst du bitte via GitHub installieren und schauen ob damit dein Problem gelöst ist |
Ja mach ich. Ich melde mich dann nochmal. |
Ich hab alles mit der Github-Version laufen lassen. Versionsnummer ist 0.0.10. Ich hatte Initial 2876 Objekte (4 Instanzen) nach einem Tag sind es jetzt 3435. Ich melde mich später nochmal. |
Super ist stabil. Danke dir für den Tipp mit dem Github-Update. |
Had the adapter V0.0.6/V0.0.7 running for four month now with a single Nokia sleep (aka Withings Sleep Analyzer).
In that time the adapter created about 1.200 new objects and states per night.
This resulted in approx 150.000 objects and states as of today.
After deletion of the adapter and cleanup I had only: 19.172 objects and 17.005 states left.
I think the adapter needs a housekeeping routine or a general concept overhaul to avoid that. Especially since not all of these objects are accessable in the object tree.
The text was updated successfully, but these errors were encountered: