motiviert ^^ und es ist schön, nach dieser „langen“ Abwesenheit wieder zu programmieren.
Also, es funktioniert auch für die „Fläche“-Kurven. Es ist nur so, dass ich mehrere Kurven hatte und es nicht funktioniert. Soweit ich auf GitHub sehe und verstehe, funktioniert der CSV-Export bei mehreren Kurven nur, wenn die Zeitwerte unterschiedlich sind. Ich nehme also an, dass es funktionieren sollte, wenn die Werte ein identisches ‹ created_at › haben… ich werde es irgendwann testen.
In der Zwischenzeit werde ich nach einer Methode suchen, um zumindest die zu exportierende Kurve auszuwählen…
Sehr cool, all diese Untersuchungen. Es wäre wirklich schön, die bereits in Gladys vorhandenen Daten weiter zu erkunden!
Allerdings bin ich nicht unbedingt für ein separates Tab, das letztendlich genau das Gleiche wie das Dashboard ist. Stattdessen sollte man das, was du gemacht hast, lieber in das bereits bestehende Dashboard integrieren.
Ich bevorzuge, dass du die andere Funktion beibehältst, die eine präzise Funktion ist.
Ich denke, ich werde dieses Thema in « Entwicklung » als Diskussion umwandeln und den Funktionswunsch « Diagramme verbessern » schließen, da die ursprüngliche Anfrage von @Hizo bereits umgesetzt wurde (benutzerdefinierte Farben in den Diagrammen haben).
Ich habe die Absicht, auf DuckDB umzusteigen, sobald es 1.0 erreicht (voraussichtlich Ende Q1 2024), ich hatte darüber in einem anderen Thema gesprochen, ich weiß nicht, ob du es gesehen hast.
Das würde die Abfrageleistung drastisch verbessern, selbst wenn man auf die Rohdaten zugreift.
Man muss sehen, ob diese Entwicklung vor oder nach diesem Wechsel gemacht werden soll. Tatsächlich können wir in der Zwischenzeit die aggregierten Daten aufrufen, sobald die ausgewählte Dauer eine bestimmte Zeitspanne überschreitet.
Ich will dir nicht den Spaß am Entwickeln verderben, aber denk daran, das, was du machst, gut zu strukturieren, um nicht in deine alten Gewohnheiten zurückzufallen: riesige PRs
Ich denke, dass du, wenn du willst, dass diese Entwicklung in Gladys landet, dich wieder auf die Grundfunktionen konzentrieren musst: die saubere Integration mit Gladys (welchen Bedarf es deckt und wo es in Gladys platziert wird), und im Moment nicht zu sehr in alle Richtungen laufen, um eine saubere PR zu haben
Danach können wir ohne Probleme wie bei Netatmo iterieren!
Zuerst einmal danke für die Aufräumarbeit im Thema. Du hast recht. Entschuldige für das Chaos.
Ist deine Meinung dazu endgültig oder können wir die Community dazu befragen?
Ehrlich gesagt sehe ich bei mir zum Beispiel einen Nutzen, da das Dashboard eher ein schneller Zugriff auf Befehle und eine schnelle Übersicht über die Zustände ist, habe ich bereits eine Menge davon:
Für mich geht es mehr um die Analyse und gehört nicht ins Dashboard, ich werde es regelmäßig erstellen/löschen. Und ehrlich gesagt würde es mich erheblich stören, 10 zusätzliche Kurvenansichten in meinen Dashboards zu haben, auch wenn ich sie natürlich trotzdem nutzen würde.
Aber vielleicht gibt es auch andere Lösungen ^^ Wenn ich jetzt einen PR erstelle, kannst du dann Vorschläge machen?
Und die einzige Spalte ist für diese Entwicklung unerlässlich.
Ja, wir haben uns darüber persönlich unterhalten und ich habe es gut im Kopf. Deshalb habe ich diese Lösung vorgeschlagen, ob sie vorübergehend ist oder nicht, denn ich habe keine Ahnung, wann du auf DuckDB umsteigst und ob die Tests über ein Jahr erfolgreich sein werden. Ungeduld ^^
Keine Chance ^^ Ich habe verstanden, keine Sorge. In diesem Fall:
Ich brauche trotzdem einen umfassenderen Überblick, auch wenn mein PR später aufgeteilt wird!!
Fast keine Serverseite betroffen/beeinflusst (ein Dutzend Zeilen)
Hauptsächlich Änderungen auf der Frontend-Seite… und deshalb momentan Warten auf deine Entscheidung bezüglich neuem Reiter oder nicht ^^
Wenn du das sagst, meinst du den Teil der Feature-Auswahl, der sich von dem aktuellen unterscheidet, oder zum Beispiel den Export-Teil? Denn letzterer ist wirklich nicht aufwendig!
Man muss sehen, wofür die Funktion am Ende genutzt wird, und ob es eher Sinn macht, das im Dashboard zu haben, zum Beispiel über einen Button, der es ermöglicht, die grafische Ansicht eines Sensors zu „erweitern“, wie man es zum Beispiel bei Kameras macht (mit dem Button „Vollbild öffnen“), oder ob man wirklich ein Tab wirklich nur für die Analyse will.
Falls man ein Tab für die Analyse will, warum nicht, aber dann muss man etwas wirklich anderes als das Dashboard machen!
ja, ich auch nicht, keine Ahnung, wann das bei denen fertig sein wird, also lieber nicht warten und dann anpassen, wenn wir zu DuckDB wechseln
Das liegt bei dir, aber wie immer muss man knapp bleiben und sich auf eine Hauptfunktion konzentrieren, ohne zu viel zu verändern, denn so ist es einfacher zu überprüfen, und es verursacht keine Instabilitäten an anderen Stellen
Ich arbeite gerade daran, den Code zu bereinigen, um ihn auf das absolute Minimum zu reduzieren. Ich habe den PR erstellt: Add charts-history feature and related components and styles. Sobald es fertig ist, erstelle ich ein Bild. Wenn es Tester gibt, die ihre Produktionsdatenbank kopieren und testen können, um Feedback zu geben, insbesondere zu dem von @pierre-gilles erwähnten Punkt, um eine Meinung zu äußern über:
die Nutzung der aktuellen Kurven im Dashboard mit einer Öffnung für solche Dinge
oder eine dedizierte Seite, auf der man dedizierte Historienansichten erstellen kann.
Und natürlich funktioniert der Export mit der angezeigten Kurve. Mir bleibt nur noch, die Pfeile links und rechts zu beenden, um den Schritt in Abhängigkeit von der Anzeige und nicht des Intervalls hinzuzufügen, und dann sind wir bereit für die Tests. Ich denke, dass die 3/4 der ursprünglichen Funktionen (die in den verschiedenen Themen aufgelistet sind) vorhanden sind:
Präzise historische Ansicht in Groß (noch zu klären, ob man über bestehende Kurven vom Dashboard oder eine eigene Ansicht für die Konsultation gehen muss)
Für mich eine SEHR nützliche Entwicklung, da ich meinen Stromverbrauch / meine Stromerzeugung zu Hause verfolge!!
Nochmals vielen Dank @Terdious, und auch wenn ich mir vorstellen kann, dass es erst Debatten, dann Codierung, dann Tests geben wird… ich freue mich darauf, dass es in Gladys integriert wird !!
Bild wird gerade gebaut docker pull terdious/gladys:add-view-charts. Ich werde es morgen testen und euch sagen, ob es funktioniert ^^
In jedem Fall hoffe ich, dass das Thema damit gestartet wird ^^ Und ja, wie du sagst, möglicherweise wird es Debatten geben ^^ Im Moment ist es nur meine Vision davon ^^
Ich habe versucht, ein Testimage zu erstellen, aber sowohl bei der PR als auch beim Image-Build auf der Seite von GitHub Actions bricht es bei der Version linux/amd64 in « Docker Magic! » ab. Ich verstehe nicht, warum. @pierre-gilles, hast du eine Idee?
Ich habe ein Image für arm V8 (linux/arm64) erstellt: docker pull terdious/gladys:add-view-charts (falls jemand das testen kann, interessiert mich, ob die Leistung besser ist als bei v7 ^^)
Und eines für linux/arm/v7: docker pull terdious/gladys:add-view-charts-armv7
EDIT2: Funktioniert bei armV7 für alle, die es testen möchten.
Meine bisherigen Notizen und eine Ansicht:
Historique et courbe : Seite Historische Daten und Kurven leer: Der "Neu"-Button hat keinen Text, nur ein "+" zu überprüfen.
Dashboard : Die Höhe der Grafiken auf der Dashboard-Seite überprüfen (wieder wie ursprünglich einstellen)
Bearbeiten Historische Daten und Kurven : Die Namen der angezeigten Dienste in der Bearbeitung überprüfen (nicht alle haben einen Titel??). Schauen, was anderswo gemacht wird (Liste der Dienste im Integrationsmenü).
Bearbeiten Historische Daten und Kurven : Langsam beim Anzeigen (lange Abfrage der Dienste/Geräte/Merkmale?)
Bearbeiten Historische Daten und Kurven : Wenn kein Kurventyp ausgewählt ist => Fehler beim Anzeigen der Ansicht, da es bei 'lowerCase' in den Apex-Typen abstürzt.
Fehler behandeln und verhindern, dass die Bearbeitungsansicht (mit Fehler) gespeichert wird
Export XLSX : Versuchen, den Aufbau der Daten in strukturierte Tabellen hinzuzufügen (ermöglicht einfacheres Filtern von Anfang an)
Export XLSX : Erstes Spalte als Datum und zweite Spalte als Zeit formatieren
EDIT: @pierre-gilles, ich habe angenommen, dass es an der Installation der neuen Pakete xlsx-js-style und sweetalert2 lag, aber offensichtlich sind sie mit amd64 kompatibel. xlsx-js-style verwendet xlsx (SheetJs), das bereits auf der Serverseite als Abhängigkeit anderer Pakete verwendet wird.
Und das läuft auch auf mobilen Geräten (ein paar Korrekturen sind noch nötig ^^). Sehr reaktiv in 6 Tagen. Die Zoom-Tasten sind sehr praktisch, ebenso wie die Pfeile links/rechts (danke @guim31, dass du daran von Anfang an gedacht hast ^^)
Ah super! Genau das dachte ich mir schon, als ich mir die Build-Historie angesehen habe ^^ Du beruhigst mich ^^
Es sei denn, ein Beta-Tester benötigt das Image in amd64 (gebt mir Bescheid ^^), ich bleibe so, bis du den Merge durchführst. Letztendlich kann ich den Test auch in arm64 durchführen.
Nur zur Info: Ich werde einen Zweig erstellen, in dem ich deine Idee mit der Option einer direkten Großansicht im Dashboard hinzufüge… denn schließlich schließt das eine das andere nicht aus, und es wird einfach sein, die Arbeit wieder aufzunehmen, falls wir uns am Ende nur für diese zweite Option entscheiden.
Damit können wir direkt die beiden Möglichkeiten testen.
Ich habe die Vorschläge für die Vollbildanzeige durch direkte Auswahl aus einer Kurve im Dashboard abgeschlossen … aber ich stecke so tief in Schwierigkeiten mit dem Design und dem CSS … ich kämpfe stundenlang, und egal wie sehr ich die Dokumentation lese, ich komme nicht weiter (und die KI auch nicht, leider ^^).
Beispiel: Ich versuche, das Kreuz zum Schließen anzupassen … eine Katastrophe ^^
Funktional ist es eigentlich schon, wir können das Design später überarbeiten. Wenn du testen möchtest/kannst (also die beiden Versionen, die auf demselben Bild zu sehen sein werden), wäre das wirklich toll. Für alle, die testen und Feedback geben möchten, wird das Bild morgen früh verfügbar sein …
Sagen wir mal, wenn du in der Realität testen willst, ist es besser, Daten zu haben (insbesondere, um die Leistung über einen längeren Zeitraum zu testen, es könnte notwendig sein, in andere Periodizitäten aufzuteilen… insbesondere für die Architekturen armv6/v7)
Ich liebe es! Mindestens 2 Phasen gleichzeitig über 7 Tage visualisieren zu können und zusätzlich alles direkt nach Excel exportieren zu können… Das ist wirklich super!
Und mit den Pfeilen links/rechts, die dasselbe Maßstab beibehalten, kann man schnell die Unterschiede erkennen und es ist viel einfacher, meiner Meinung nach, die Phasendifferenzen festzustellen.
Es wäre gut, eine temporäre Visualisierungsfunktion direkt hinzufügen zu können (ein Refresh würde sie entfernen). In meinem Fall würde das ermöglichen, Geräte zu finden, die gleichzeitig starten (man könnte einfach eine binäre Kurve unten hinzufügen mit den verdächtigen Geräten, wie Sie sagen ^^
!!
