Ich habe heute testweise mein IPS 3.4 auf 4.0 migriert und mir die geloggten Daten angeschaut. Ich habe mir die Daten mit AC_GetLoggedValues ausgeben lassen, jeweils für einen Kalendertag.
Dabei ist mir aufgefallen, dass offensichtlich nur ein Teil der Rohdaten migriert werden (bei einer Stichprobe fehlten ca. 500 Datensätze [von ca.1400] , bei einer 2. Stichprobe fehlten 2200 Datensätze [von ca. 2800]).
Weiterhin ist mir aufgefallen, dass in den CSV’s scheinbar nur 2 Nachkommastellen gespeichert werden (evtl. sogar gerundet?!). Auch das ist aus meiner Sicht nicht ok.
Sieht ja fast so aus, als wenn erst gerundet wird und die dadurch entstandenen ‚Duplikate‘ entfernt wurden, weil ja nur Änderungen geloggt werden.
Michael
Werde mir das Morgen ansehen, wodurch das Runden verursacht wird. Normalerweise sollten alle Nachkommastellen exportiert werden.
Duplikate werden dann natürlich, wie Michael sagte, gefiltert.
Ich hab mir die Daten nach dem gestrigen Update heute nochmal angeschaut (Timestamps und Aggregation hab ich zunächst ausgeblendet, da der Punkt noch offen ist).
Ich vermute, Ihr habt vergessen zu erwähnen, dass in IPS 4.0 die Float-Werte nicht mehr mit 8bit (=15stellig Nachkomma), sondern nur mit 4bit (=6stellig Nachkomma) verarbeitet.
M.E. sollte das nochmal überdacht/überarbeitet werden, da dies in bestimmten Fällen durchaus eine Rolle spielen kann. Zumindest habe ich so einen „Medienbruch“ beim Wechsel aus der alten Datenwelt (IPS <= 3.4) zur neuen Datenwelt (IPS >= 4.0).
Ich werde das hier noch einmal diskutieren. Hast du aber ein praktisches Beispiel, wo du oder jemand anders wirklich mehr als 6 Nachkommastellen benötigen würden?
primär geht es mir darum, dass die Struktur der Daten nicht einfach so umgestellt werden sollte (und nicht kommuniziert wird). Man kann nie wissen, welche Auswirkungen das bei den Usern hat (und das ist stark davon abhängig, wie sie ihre Daten verwenden).
Dazu kommt der ‚Medienbruch‘ mit dem Release-Wechsel.
Als spontanes Beispiel habe ich die Messung der UV-Einstrahlung. Aktuell (heute, ca. 16:30 Uhr) Werte um 2-5 mW, Auflösung 3 Stellen hinter dem Komma. Diese Strahlungsleistung aggregiere ich zur Strahlungsmenge auf, allerdings in Wh. Das ganze über Tage, Wochen, Monate, Jahre. Und hier werden die Stellen hinter dem Komma interessant.
Könnte man das nicht mit einer „Experten-Einstellung“ lösen?
So wie man die Thread-Anzahl einstellen kann?
Ich bräuchte diese Anzahl an Nachkommastellen z.B nicht, kann das Problem aber verstehen.
Würde es für die Allgemeinheit bei weniger Stellen ( Standart ) belassen und die die mehr benötigen, können das Einstellen, die wissen dann auch, das es mehr Speicher und Performance benötigt!
Gruß,
Peter
Ich habe die Thematik noch einmal besprochen und wir werden die Genauigkeit im Installer nicht erhöhen. Die Datenmenge steigt durch zusätzlichen Nachkommastellen erheblich, was für die wenigsten Kunden von Interesse ist. Ich werde jedoch im Laufe der nächsten Woche ein Tool bereitstellen, welches die Datenbank „offline“, ohne Installer, mit einer beliebigen Genauigkeit konvertiert.
Somit wird der Wunsch nach einer höheren Genauigkeit beim Exportieren auch berücksichtigt und alle die nach z.B. Linux wechseln möchten, können die Datenbank in Ruhe ohne eine vorherige IPS4 Installation konvertieren.
@BerndJ: Hast du alle Ordner korrekt durchsucht? @Raketenschnecke: Anbei wie versprochen das Tool, welches die Datenbank ohne das Setup konvertieren kann und dabei alle 15 Stellen ausgibt. Ein entsprechender Hinweis kommt zum nächsten Update der Webseite auch in die Migrationsanleitung: https://www.symcon.de/files/service/DBConvertTool.zip
Nach dem Konvertieren sollte die logging.db von euch irgendwo archiviert werden, damit der Installer nicht erneut versucht diese zu konvertieren.
