NEWS
[gelöst] Export Verlaufsdaten
-
@thomas-braun
es ist schade, dass man sich nicht darauf verlassen kann, die Daten so wie in der Anzeige exportiert zu bekommen. Wenn es schon den Export nach csv gibt, dann bitte ohne Veränderung der Daten(anzeige). Selbst, wenn es im Hintergrund anders aussieht.
Es ist auch nur durch die Umwandlung von °C "19.3" in Datum "19.Mrz" aufgefallen. Das Zeitproblem wäre wahrscheinlich bei größeren Datenmengen untergegangen und somit wäre die weitere Datenauswertung falsch gewesen.
Es muss also erst wieder umständlich nachgearbeitet werden. Eine genereller Temperaturwert mit zwei Nachkommastellen (Komma als Komma und nicht als Punkt) würde zumindest das eine Problem lösen. Ob die Bedeutung des "Z" am Ende jedem klar wäre ist auch fraglich. Ohne Vergleich mit den Ausgangsdaten hätte ich diese Werte für korrekt angesehen.Trotzdem Danke für die Aufklärung.
Das Zeitproblem wäre wahrscheinlich bei größeren Datenmengen untergegangen und somit wäre die weitere Datenauswertung falsch gewesen.
Deswegen steht halt das Z im Datensatz drin...
Die Logik ist halt eine andere. Zeiten werden in der EDV (und beim Militär, in der Luftfahrt usw.) immer als Z-Zeit verarbeitet und erst in der Darstellung an die Lokale Zeitzone angepasst.
Den Datenexport könntest du auch an einen New Yorker weitergeben, der könnte dann damit die Darstellung an seine lokale Zeit anpassen.Und das Datum wird von dem superschlauen Excel umgefummelt. Das musst du für das Datenfeld/die Zelle einstellen. Es ist ja nun auch eine Tabellenkalkulation und keine Datenbank.
-
Das Zeitproblem wäre wahrscheinlich bei größeren Datenmengen untergegangen und somit wäre die weitere Datenauswertung falsch gewesen.
Deswegen steht halt das Z im Datensatz drin...
Die Logik ist halt eine andere. Zeiten werden in der EDV (und beim Militär, in der Luftfahrt usw.) immer als Z-Zeit verarbeitet und erst in der Darstellung an die Lokale Zeitzone angepasst.
Den Datenexport könntest du auch an einen New Yorker weitergeben, der könnte dann damit die Darstellung an seine lokale Zeit anpassen.Und das Datum wird von dem superschlauen Excel umgefummelt. Das musst du für das Datenfeld/die Zelle einstellen. Es ist ja nun auch eine Tabellenkalkulation und keine Datenbank.
@thomas-braun
"Den Datenexport könntest du auch an einen New Yorker weitergeben,..." - ich denke mal, sowas kommt sehr selten vor. Eher erwartet jeder User, dass die Daten so rüberkommen, wie angezeigt (beim Export könnte ein New Yorker die Daten dann auch noch an seine Zeit anpassen). Es war wohl für den Programmierer einfacher, auf die Grunddaten beim Export zuzugreifen, als auf die für die Anzeige schon umgewandelten Datums-/Zeitangaben.
Dass Excel aus 19.3 ein Datum macht ist nicht verwunderlich und fällt auch sofort auf. Vielleicht ist es auch zu schwierig die Gradangaben generell mit zwei Nachkommastellen anzulegen ? -
@thomas-braun
"Den Datenexport könntest du auch an einen New Yorker weitergeben,..." - ich denke mal, sowas kommt sehr selten vor. Eher erwartet jeder User, dass die Daten so rüberkommen, wie angezeigt (beim Export könnte ein New Yorker die Daten dann auch noch an seine Zeit anpassen). Es war wohl für den Programmierer einfacher, auf die Grunddaten beim Export zuzugreifen, als auf die für die Anzeige schon umgewandelten Datums-/Zeitangaben.
Dass Excel aus 19.3 ein Datum macht ist nicht verwunderlich und fällt auch sofort auf. Vielleicht ist es auch zu schwierig die Gradangaben generell mit zwei Nachkommastellen anzulegen ?@dgr sagte in Export Verlaufsdaten:
"Den Datenexport könntest du auch an einen New Yorker weitergeben,..." - ich denke mal, sowas kommt sehr selten vor.
In der Netzwerktechnik kommt das milliardenfach in der Sekunde vor.
Pakete aus der 'Zukunft' würden da z. B. auch verworfen. Deswegen muss ein Zeitpunkt genau festgelegt sein, ohne Einflüsse von Zeitzonen. Deswegen halt intern die Z-Zeit, da spielt es keine Rolle in welcher Zeitzone du gerade bist.Es war wohl für den Programmierer einfacher, auf die Grunddaten beim Export zuzugreifen
Natürlich, der müsste ja sonst jeden Datensatz in die Zeitzone des Systems konvertieren und wieder zurück. Das funktioniert so nicht. Bzw. wäre unnötig aufwändig, wenn es schon einen Standard für Zeitstempel gibt.
-
@dgr sagte in Export Verlaufsdaten:
"Den Datenexport könntest du auch an einen New Yorker weitergeben,..." - ich denke mal, sowas kommt sehr selten vor.
In der Netzwerktechnik kommt das milliardenfach in der Sekunde vor.
Pakete aus der 'Zukunft' würden da z. B. auch verworfen. Deswegen muss ein Zeitpunkt genau festgelegt sein, ohne Einflüsse von Zeitzonen. Deswegen halt intern die Z-Zeit, da spielt es keine Rolle in welcher Zeitzone du gerade bist.Es war wohl für den Programmierer einfacher, auf die Grunddaten beim Export zuzugreifen
Natürlich, der müsste ja sonst jeden Datensatz in die Zeitzone des Systems konvertieren und wieder zurück. Das funktioniert so nicht. Bzw. wäre unnötig aufwändig, wenn es schon einen Standard für Zeitstempel gibt.
@thomas-braun
es ergibt für mich keinen Sinn, wenn z.B. ein New Yorker sich die Temperaturangaben aus Berlin um dort 8 Uhr Berliner Zeit auf die New Yorker Zeit 2 Uhr anzeigen läßt.
Die Daten wurden ja schon in die Zeitzone des Systems konvertiert, sonst könnten sie ja nicht im ioBroker korrekt angezeigt werden. Warum also nicht diese Daten exportieren ? -
@thomas-braun
es ergibt für mich keinen Sinn, wenn z.B. ein New Yorker sich die Temperaturangaben aus Berlin um dort 8 Uhr Berliner Zeit auf die New Yorker Zeit 2 Uhr anzeigen läßt.
Die Daten wurden ja schon in die Zeitzone des Systems konvertiert, sonst könnten sie ja nicht im ioBroker korrekt angezeigt werden. Warum also nicht diese Daten exportieren ? -
@thomas-braun
es ergibt für mich keinen Sinn, wenn z.B. ein New Yorker sich die Temperaturangaben aus Berlin um dort 8 Uhr Berliner Zeit auf die New Yorker Zeit 2 Uhr anzeigen läßt.
Die Daten wurden ja schon in die Zeitzone des Systems konvertiert, sonst könnten sie ja nicht im ioBroker korrekt angezeigt werden. Warum also nicht diese Daten exportieren ?Über die 'Zeitproblematik' haben sich schon ganz andere Leute den Kopf zerbrochen. Man ist dann zu dem Ergebnis gekommen, dass man Zeitstempel immer in Relation zur Null-Zeit angibt, weil das einfach am einfachsten, klarsten und problemlosesten funktioniert und dann nur die Darstellung basierend auf den lokalen Zeitzonen verändert wird.
Das ist jedenfalls sinnvoller als Zeitpunkte immer noch mit der lokalen Zeitzone zu versehen. In deinem Beispiel müsste dann statt Z da CEST stehen, zur Winterzeit dann CET und der iobroker user in Portugal hätte dann wieder ein anderes Kürzel dabei, weil der ja in einer anderen Zeitzone lebt. Macht keinen Sinn.Im Excel gibt es mit Sicherheit eine Funktion, die die Zeitkonvertierung vornehmen kann.
Das ganze ist also kein Bug, sondern 'du machst was falsch' bzw. machst was notwendiges nicht.
Eine ähnliche Diskussion zu 'time stamps' gab es übrigens ganz aktuell hier:
https://forum.iobroker.net/topic/56186/shelly-adapter-6-0-0-uptime?_=1657373231029
-
Über die 'Zeitproblematik' haben sich schon ganz andere Leute den Kopf zerbrochen. Man ist dann zu dem Ergebnis gekommen, dass man Zeitstempel immer in Relation zur Null-Zeit angibt, weil das einfach am einfachsten, klarsten und problemlosesten funktioniert und dann nur die Darstellung basierend auf den lokalen Zeitzonen verändert wird.
Das ist jedenfalls sinnvoller als Zeitpunkte immer noch mit der lokalen Zeitzone zu versehen. In deinem Beispiel müsste dann statt Z da CEST stehen, zur Winterzeit dann CET und der iobroker user in Portugal hätte dann wieder ein anderes Kürzel dabei, weil der ja in einer anderen Zeitzone lebt. Macht keinen Sinn.Im Excel gibt es mit Sicherheit eine Funktion, die die Zeitkonvertierung vornehmen kann.
Das ganze ist also kein Bug, sondern 'du machst was falsch' bzw. machst was notwendiges nicht.
Eine ähnliche Diskussion zu 'time stamps' gab es übrigens ganz aktuell hier:
https://forum.iobroker.net/topic/56186/shelly-adapter-6-0-0-uptime?_=1657373231029
@thomas-braun
Die Grunddaten können doch so bleiben. Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt. Also ist es offenbar möglich und diese umgewandelten Daten könnten exportiert werden. -
@thomas-braun
Die Grunddaten können doch so bleiben. Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt. Also ist es offenbar möglich und diese umgewandelten Daten könnten exportiert werden.Zeitstempel werden grundsätzlich in Z-Zeit angegeben. Gründe dafür hatte ich ja schon genannt.
Verarbeite die Daten halt zum gewünschten Format weiter, deswegen heißt das ja auch EDV.Kannst ja froh sein, dass überhaupt ein menschenlesbares Format rüberkommt. Man hätte es auch noch komplett anders ausgeben können. So macht es dmesg z. B. :
[148554.091265] CIFS: Attempting to mount \\192.168.178.1\fritz.nas [179577.387458] CIFS: Attempting to mount \\192.168.178.1\fritz.nasÜbersetzt:
[Fri Jul 8 19:05:17 2022] CIFS: Attempting to mount \\192.168.178.1\fritz.nas [Sat Jul 9 03:42:20 2022] CIFS: Attempting to mount \\192.168.178.1\fritz.nas -
Zeitstempel werden grundsätzlich in Z-Zeit angegeben. Gründe dafür hatte ich ja schon genannt.
Verarbeite die Daten halt zum gewünschten Format weiter, deswegen heißt das ja auch EDV.Kannst ja froh sein, dass überhaupt ein menschenlesbares Format rüberkommt. Man hätte es auch noch komplett anders ausgeben können. So macht es dmesg z. B. :
[148554.091265] CIFS: Attempting to mount \\192.168.178.1\fritz.nas [179577.387458] CIFS: Attempting to mount \\192.168.178.1\fritz.nasÜbersetzt:
[Fri Jul 8 19:05:17 2022] CIFS: Attempting to mount \\192.168.178.1\fritz.nas [Sat Jul 9 03:42:20 2022] CIFS: Attempting to mount \\192.168.178.1\fritz.nas@thomas-braun
Zeitstempel können von mir aus auch weiter in Z-Zeit angegeben werden. Das habe ich schon gesagt (Grunddaten). Aber wenn die Angaben schon mal "lesbar" umgewandelt wurden, warum dann nicht so exportieren ?Verstehe schon, dass wir hier offenbar nicht weiterkommen.
Danke. Muss man wohl mit dem Vorhandenen auskommen. -
@thomas-braun
Zeitstempel können von mir aus auch weiter in Z-Zeit angegeben werden. Das habe ich schon gesagt (Grunddaten). Aber wenn die Angaben schon mal "lesbar" umgewandelt wurden, warum dann nicht so exportieren ?Verstehe schon, dass wir hier offenbar nicht weiterkommen.
Danke. Muss man wohl mit dem Vorhandenen auskommen.@dgr sagte in Export Verlaufsdaten:
Muss man wohl mit dem Vorhandenen auskommen.
Ja, du musst die vorhandenen Daten weiterverarbeiten und in das von dir bevorzugte Format bringen.
Die Amis schreiben ja auch z. B. Tagesdatum und Monat 'verkehrt' herum. Wie soll da also ein auf lokalen Vorlieben basierender Export aussehen? Das muss immer eine standardisierte Ausgabe sein. -
@dgr sagte in Export Verlaufsdaten:
Muss man wohl mit dem Vorhandenen auskommen.
Ja, du musst die vorhandenen Daten weiterverarbeiten und in das von dir bevorzugte Format bringen.
Die Amis schreiben ja auch z. B. Tagesdatum und Monat 'verkehrt' herum. Wie soll da also ein auf lokalen Vorlieben basierender Export aussehen? Das muss immer eine standardisierte Ausgabe sein.@thomas-braun
noch einmal: die Daten wurden für die Anzeige schon aufbereitet (Bild).
Das wird wahrscheinlich für jede Zeitzone und jedes Grundformat gemacht. Wahrscheinlich statt in °C auch in °F.
Es geht doch nur darum, diese einmal aufbereiteten Daten auch so zu exportieren. Das wäre wirklich anwenderfreundlich. Statt dessen programmtechnisch einfach machen und die Grunddaten exportieren (oder wenigstens wahlweise). Soll sich der User doch damit rumschlagen und was draus machen. -
@thomas-braun
noch einmal: die Daten wurden für die Anzeige schon aufbereitet (Bild). Das wird wahrscheinlich für jede Zeitzone und jedes Grundformat gemacht. Wahrscheinlich statt in °C auch in °F.
Es geht doch nur darum, diese einmal aufbereiteten Daten auch so zu exportieren. Das wäre wirklich anwenderfreundlich. Statt dessen programmtechnisch einfach machen und die Grunddaten exportieren (oder wenigstens wahlweise). Soll sich der User doch damit rumschlagen und was draus machen.@dgr sagte in Export Verlaufsdaten:
noch einmal: die Daten wurden für die Anzeige schon aufbereitet
Das weiß ich... Das wird vom Admin basierend auf den Rohdaten und der hinterlegten Zeitzone jeweils umgerechnet. Das ist deutlich effizienter als jeden Datensatz beim Export schon zu konvertieren.
Soll sich der User doch damit rumschlagen und was draus machen.
Genau das ist ja der Ansatz. Es werden Daten roh angeliefert und jeder hat die Möglichkeit die flugs auf das gewünschte Format umzurechnen. Kann dann auch der Maya-Mondkalender oder das dyskordische Zeitformat sein.
In einer Visualisierung willst du auch nicht vorgegeben bekommen, das die Schriftfarbe gelb ist und kursiv gesetzt. Die Formatierung der Daten musst/darfst du selber machen.
-
@dgr sagte in Export Verlaufsdaten:
noch einmal: die Daten wurden für die Anzeige schon aufbereitet
Das weiß ich... Das wird vom Admin basierend auf den Rohdaten und der hinterlegten Zeitzone jeweils umgerechnet. Das ist deutlich effizienter als jeden Datensatz beim Export schon zu konvertieren.
Soll sich der User doch damit rumschlagen und was draus machen.
Genau das ist ja der Ansatz. Es werden Daten roh angeliefert und jeder hat die Möglichkeit die flugs auf das gewünschte Format umzurechnen. Kann dann auch der Maya-Mondkalender oder das dyskordische Zeitformat sein.
In einer Visualisierung willst du auch nicht vorgegeben bekommen, das die Schriftfarbe gelb ist und kursiv gesetzt. Die Formatierung der Daten musst/darfst du selber machen.
@thomas-braun said in Export Verlaufsdaten:
Das wird vom Admin basierend auf den Rohdaten und der hinterlegten Zeitzone jeweils umgerechnet. Das ist deutlich effizienter als jeden Datensatz beim Export schon zu konvertieren.
Muss ich erstmal so hinnehme, obwohl ich die Logik dahinter nicht verstehe. Wenn man die Rohdaten in Bezug zur jeweils hinterlegten Zeitzone und den anderen Daten (°C/°F) umrechnen kann, wo ist dann das Problem, das auch beim Export zu machen ?
Das müsste man vermutlich eher den Programmierer fragen. Kann ja sein, dass es da unüberwindbare Hürden gibt.
"... jeder hat die Möglichkeit die flugs auf das gewünschte Format umzurechnen." - das kann jeder auch machen, wenn er die Daten wie angezeigt exportiert bekommt.
-
@thomas-braun said in Export Verlaufsdaten:
Das wird vom Admin basierend auf den Rohdaten und der hinterlegten Zeitzone jeweils umgerechnet. Das ist deutlich effizienter als jeden Datensatz beim Export schon zu konvertieren.
Muss ich erstmal so hinnehme, obwohl ich die Logik dahinter nicht verstehe. Wenn man die Rohdaten in Bezug zur jeweils hinterlegten Zeitzone und den anderen Daten (°C/°F) umrechnen kann, wo ist dann das Problem, das auch beim Export zu machen ?
Das müsste man vermutlich eher den Programmierer fragen. Kann ja sein, dass es da unüberwindbare Hürden gibt.
"... jeder hat die Möglichkeit die flugs auf das gewünschte Format umzurechnen." - das kann jeder auch machen, wenn er die Daten wie angezeigt exportiert bekommt.
@dgr sagte in Export Verlaufsdaten:
wo ist dann das Problem, das auch beim Export zu machen ?
Es ist technisch keins, aber warum sollte man den Aufwand in seinem Programm oder Adapter haben, wenn die grundlegende Funktion in jedem System schon viel besser vorhanden ist? Und sei es nur durch gesetzte $LOCALES auf einem Multiuser-System wie es Unix eins ist. Es widerspricht auch den 'Best practises'.
das kann jeder auch machen, wenn er die Daten wie angezeigt exportiert bekommt.
Dann muss er es aber zweimal umrechnen. Von der falschen Zeitzone auf Z und dann wieder auf seine richtige. Macht man halt nicht, zu viel Aufwand und zu Fehler anfällig.
-
@thomas-braun
Die Grunddaten können doch so bleiben. Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt. Also ist es offenbar möglich und diese umgewandelten Daten könnten exportiert werden.@dgr sagte in Export Verlaufsdaten:
Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt.
nein, nicht u
@dgr sagte in Export Verlaufsdaten:
die Daten wurden für die Anzeige schon aufbereitet (Bild).
eben nicht!
sie liegen nach wie vir in Zulu-Zeit vor.
Nur der Admin zeigt sie anders an.das ist genauso wie eine Werteliste, in der die Daten 1,2,3,... gespeichert sind (und bleiben), im Admin aber gesclossen, gekippt, offen,.... angezeigt wird.
Ist müssig zu diskutieren, wenn man von unterschiedlichen Voraussetzungen ausgeht.
Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen
BTW EXCEL sollte die Zuluzeit als solche erkennen
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@dgr sagte in Export Verlaufsdaten:
Sie wurden doch für die Darstellung schon in die lokale Zeitzone umgewandelt.
nein, nicht u
@dgr sagte in Export Verlaufsdaten:
die Daten wurden für die Anzeige schon aufbereitet (Bild).
eben nicht!
sie liegen nach wie vir in Zulu-Zeit vor.
Nur der Admin zeigt sie anders an.das ist genauso wie eine Werteliste, in der die Daten 1,2,3,... gespeichert sind (und bleiben), im Admin aber gesclossen, gekippt, offen,.... angezeigt wird.
Ist müssig zu diskutieren, wenn man von unterschiedlichen Voraussetzungen ausgeht.
Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen
BTW EXCEL sollte die Zuluzeit als solche erkennen
@homoran sagte in Export Verlaufsdaten:
Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen
Dann will ich aber auch den jüdischen, den muslimischen, den Maya-Mondkalender, die dyskordische Zeit und meinen persönlichen Biorhythmus für den Export auswählen können!
Die hunderttausend verschiedenen Möglichkeiten ein Zeitformat darzustellen sind natürlich auch berücksichtigt, ist ja klar. -
@homoran sagte in Export Verlaufsdaten:
Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen
Dann will ich aber auch den jüdischen, den muslimischen, den Maya-Mondkalender, die dyskordische Zeit und meinen persönlichen Biorhythmus für den Export auswählen können!
Die hunderttausend verschiedenen Möglichkeiten ein Zeitformat darzustellen sind natürlich auch berücksichtigt, ist ja klar.@thomas-braun sagte in Export Verlaufsdaten:
@homoran sagte in Export Verlaufsdaten:
Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen
Dann will ich aber auch den jüdischen, den muslimischen, den Maya-Mondkalender, die dyskordische Zeit und meinen persönlichen Biorhythmus für den Export auswählen können!
dann sollte das gewünschte Format auch in dem aktiven Frontend, auf dem der Export durchgeführt wird, im System e7ngestellt und abfragbar sein.
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@thomas-braun sagte in Export Verlaufsdaten:
@homoran sagte in Export Verlaufsdaten:
Mach bitte ein Issue auf, ob es möglich sei die Daten beim Export umzurechnen
Dann will ich aber auch den jüdischen, den muslimischen, den Maya-Mondkalender, die dyskordische Zeit und meinen persönlichen Biorhythmus für den Export auswählen können!
dann sollte das gewünschte Format auch in dem aktiven Frontend, auf dem der Export durchgeführt wird, im System e7ngestellt und abfragbar sein.
-
Wer da was eigenes möchte, kann doch auch einfach selbst einen CSV-Export bauen - z.B. mit dem JavaScript-Adapter und sendTo / getHistory. Dann mit
formatDateins Wunschformat bringen und fertig. -
@dgr sagte in Export Verlaufsdaten:
wo ist dann das Problem, das auch beim Export zu machen ?
Es ist technisch keins, aber warum sollte man den Aufwand in seinem Programm oder Adapter haben, wenn die grundlegende Funktion in jedem System schon viel besser vorhanden ist? Und sei es nur durch gesetzte $LOCALES auf einem Multiuser-System wie es Unix eins ist. Es widerspricht auch den 'Best practises'.
das kann jeder auch machen, wenn er die Daten wie angezeigt exportiert bekommt.
Dann muss er es aber zweimal umrechnen. Von der falschen Zeitzone auf Z und dann wieder auf seine richtige. Macht man halt nicht, zu viel Aufwand und zu Fehler anfällig.
@thomas-braun
"warum sollte man den Aufwand in seinem Programm oder Adapter haben, wenn die grundlegende Funktion in jedem System schon viel besser vorhanden ist?"- weil es benutzerfreundlich ist.
"Dann muss er es aber zweimal umrechnen."
- man braucht es m.E. nur einmal umrechnen, von der einen Zeitzone in die gewünschte, falls sowas überhaupt sinnvoll ist bei Temperaturangaben.
Was nützt einem New Yorker, wenn er nach seiner Zeit eine Temperaturangabe aus Berlin bekommt ? In Berlin war es um 14 Uhr 28°C. Er rechnet die Zeit um und weiß dann, dass es nach seiner Zeit 8 Uhr in Berlin 28°C (oder etwas in °F) war. Das würde bedeuten, dass es aus seiner Sicht in Berlin schon früh sehr heiß war.
292
Online32.7k
Benutzer82.4k
Themen1.3m
Beiträge