Hallo @pierre-gilles, ich wäre sehr erfreut, wenn wir uns heute Nachmittag trotzdem über die Daten austauschen könnten. Sag mir Bescheid.
Tatsächlich erscheint mir der erste Punkt zwingend, aber wir können es uns nicht leisten, bewusst Instanzen laufen zu lassen, auch wenn das nicht die Mehrheit der Zeit sein wird (heute zum Beispiel kein Problem, ich habe nur etwa 50 Zustände pro Feature). Deshalb habe ich eine Logik implementiert, aber ich würde lieber direkt mit dir darüber sprechen.
Insbesondere für eine Speichermethode für Binärdateien (und andere, falls gewünscht), aber das können wir später besprechen.
Nach weiteren Tests stelle ich fest, dass:
- das Abrufen von 3000 Zuständen jeweils für 7 nicht-binäre Features (3 Box-Charts) praktisch sofort angezeigt wird
- aber das Abrufen von 500 Zuständen jeweils für 3 binäre Features (1 Box) stark ruckelt.
Ich vermute also, dass die starke Komprimierung der binären Werte die Leistung beim Dekomprimieren beeinträchtigt?
Ich möchte daher (zum Testen) eine Vervollständigung der Kurve ab 300 Werten mit einem „Pufferbereich“ implementieren, der die fehlenden Daten angibt, um einen Zoom anzuwenden, um diese Zeitlinie zu visualisieren, und der die anderen Features der Box, die weniger Daten enthalten, nicht daran hindert, angezeigt zu werden:
Dafür muss ich jedoch am Zoom arbeiten.
Ich kann vor dem Call pushen, wenn du möchtest.
PS HS: Mit all diesen Tests denke ich auch, dass es schade ist, diese Ansicht zu haben, wenn es keinen neuen Zustand gab, obwohl man eigentlich in einem Zustand ist, solange man nicht sicher ist, dass es kein Verbindungsproblem ist:
Ich denke, hier sollten wir den letzten empfangenen Wert anzeigen, eventuell mit einer Unsicherheitsmeldung, falls nötig (last_value_changed < Intervall = Nachricht)
PS HS2: Auf dem obigen Bild müssen wir die Warnung der Nachricht ändern, die nicht mehr relevant ist, da es keine Aggregation mehr gibt.
