Balkendiagramm fehlerhaft

[Norb1204]

Ich habe noch folgende Fehler entdeckt:

1. Fehler in der Zeitachse (siehe Grafik, Datum vom 31.07.2023, Hover-Details zeigt 22.08.2023 an, grafischer Balken falsch platziert)
2. Monat fängt mit 0 an und geht nur bis 11 (siehe Grafik)
3. Zoom funktioniert nicht
4. links und rechts verschieben funktioniert nicht

Grüße

[SilasMueller]

Ich glaube ich habe ein ähnliches Problem wie in 1. beschrieben bloß mit Tagen anstatt Monaten:

Die gespeicherten Daten zu meinem Datenpunkt sehen so aus:

Wenn ich das per ECharts als Balkendiagramm darstellen lassen will sieht das Ergebnis so aus:

Wie man sieht passen die Daten nicht ganz mit den Timestamps zusammen. Die Daten im Diagramm fangen am 21.11. an und hören am 25.11. auf. Also genau um einen Tag nach hinten verschoben.

Da die Timestamps auf 23:58:00 Uhr liegen hatte ich den Verdacht, dass sie deswegen schon zum Folgetag gerechnet werden. Ich habe sie testweise mal auf 12:00:00 Uhr und auf 00:00:30 Uhr gesetzt. Das hat beides nicht geholfen.

[Erwin40]

Auch dieser Fehler ist schon seit über einem halben Jahr existent.
Wenn die Bar-Charts nur Quark darstellen, sollten die eingentlich im Adapter deaktiviert werden.
Lieber garkeine Chart Statistik, als eine falsche ;-)

[Norb1204]

gibt es mittlerweile einen Lösungsansatz bzw. ist das Problem überhaupt erkannt worden?

[bu-na]

Hier mal ein möglicher Workaround:

[Erwin40]

Super, aber dann stimmt das Datum vom Tooltip nicht mehr mit der Zeitleiste überein. ;-(
Das kann also wirklich nicht die Lösung sein.

[Norb1204]

Das Problem liegt an der Berechnung der Monate, diese werden immer mit 30 Tagen berechnet. Der Entwickler hat dies bereits im Script angemerkt, wurde aber bis dato nicht umgesetzt. Ich denke hier sollte angesetzt werden.
Der Workaround funktioniert so nicht. Bedingt durch die Reichweite (z.B. 6 Monate, 1 Jahr, 2 Jahre) kommen immer wieder Fehler in der Balkendiagrammanzeige. Entweder fehlt ein Monat komplett oder ist verschoben.
Wie im ersten Eintrag vom 24.11.2023 beschrieben, fangen die Monate auch mit 0 an anstatt mit 1.

[Erwin40]

Der Fehler is nicht nur bei Monate.
Auch wenn ich nur die letzten 14 Tage anzeigen lasse, sind alle Werte um 1 Tag noch vorn versetzt.
Außerdem werden nicht 14, sondern 16 Tage angezeigt.
Nebenbei bemerkt funktioniert auch die Bereichs-Definition nicht, so, dass die Balken zu hoch sind und die Werte nicht lesbar sind.
Und wenn ich oben unten einstelle ist es schlecht lesbar.

[GermanBluefox]

Vielleicht kann mir jemand mal helfen? Ich kümmere mich um ca 80 adapter...:

• admin
• javascript
• cameras
• backitup
• echarts
• iot
• cloud
• vis-2
• material
• modbus
• und blablablabl

[Erwin40]

Bitte?
Ach herrje...
Und dann komm ich auch noch blöd. Sorry.
Also das mit dem letzten Punkt, bezüglich "Bereichs-Definition" hat sich erledigt.
Ich habe heute neue Parmeter Min und Max unter DATENQUELLEN gefunden.
Wenn ich dort die richtgen Werte eintrage, funktioniert die Skala links wie gewünscht und alles rutscht ein wenig tiefer.
Jetzt kann ich wieder die Legende und Beschriftung aktivieren. 👍

Ok, zum Bereichsfehler:
Es werden Daten vom 18.09.2024 00:00:00 für den 19. angezeigt. Und das kann, wie man sieht, nicht sein.
Denn gestern war ja der 18. ;-)
Und so pflanzt sich das fort. Daten vom 17. sind angeblich vom 18. usw.
Ich nutze übrigens eine MySQL (MariaDB) und den SQL-Adapter.

Brauchst du Testdaten, oder wie kann ich weiterhelfen?
Brauchst du

[GermanBluefox]

Brauchst du Testdaten, oder wie kann ich weiterhelfen?

Ich sehe, dass du JSON da verwendest. Es währe toll diese Daten zu haben, damit ich am einfachsten den Fehler reproduzieren könnte

[Erwin40]

Leider nein.
Ich nutze übrigens eine MySQL (MariaDB) und den SQL-Adapter.
Ich könnte aber die betreffenden Daten versuchen zu exportieren.
In welchem Format soll ich die ausgeben?

Ich glaub SQL INSERTs macht am meisten Sinn.
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1723500000000, '4672', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1723586400000, '4271', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1723672800000, '4322', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1723759200000, '4559', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1723845600000, '4227', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1723932000000, '808', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724018400000, '2451', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724104800000, '1502', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724191200000, '4360', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724277600000, '5029', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724364000000, '4794', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724450400000, '4925', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724536800000, '3190', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724623200000, '3356', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724709600000, '5068', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724796000000, '5011', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724882400000, '4708', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1724968800000, '4452', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725055200000, '4642', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725141600000, '4271', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725228000000, '2285', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725314400000, '3564', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725400800000, '3084', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725487200000, '4157', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725573600000, '3335', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725660000000, '4994', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725746400000, '1727', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725832800000, '1692', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1725919200000, '2061', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726005600000, '701', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726092000000, '2394', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726178400000, '2658', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726264800000, '1929', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726351200000, '3162', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726437600000, '590', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726524000001, '1190', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726610400000, '4240', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726696800000, '4530', 0, 7, 0);
INSERT INTO ts_string (id, ts, val, ack, _from, q) VALUES (108, 1726783200000, '60', 0, 7, 0);

[Norb1204]

Gibt es noch Lichtblicke, dass der Bug irgendwann behoben wird :-)

[Erwin40]

Ich persöhnlich glaube nicht. Ist ja leider nicht der einzige Bug...
Passieren tut hier kaum noch was, was wirklich schade ist.
Ich vermute das der Entwickler mit der Komplexität von eChart hoffnunglos überfordert ist.
Was ich absolut nachvollziehen kann. Habe selten ein so kompliziertes Framework gesehen.
Und ja, so ist das eben wenn eine Software kostenlos und in der Freizeit entwickelt wird.
Da hat man auch keinen Anspruch.
Hmmm, Corona war da halt doch ganz geschickt 😁 Da hatten viele Entwickler hier, deutlich mehr Zeit für so was ;-)