Zeitdifferenz berechnen

haus-automatisierung

@jb_sullivan sagte in Zeitdifferenz berechnen:

Verstehe ich das richtig, das ich nur die Rolle ändern muss?

Theoretisch ja, laut Dokumentation wird die Rolle date für number und string unterstützt: https://www.iobroker.net/#en/documentation/dev/stateroles.md

date (common.type = string - parsable by "new Date(ddd)" string
date (common.type = number - epoch seconds * 1000

Aber ersteres funktioniert im Admin aktuell nicht. Habe einen Issue aufgemacht:

https://github.com/ioBroker/ioBroker.admin/issues/1770

Und: Ich würde davon abraten, die Rollen von Datenpunkten anzupassen, welche man nicht selbst erstellt hat!

Ein Alias wäre hier eine gute Lösung. Type number, role date und beim Lesen einfach die Funktion einfügen: new Date(val).getTime()

{
  "common": {
    "name": "test",
    "desc": "Manuell erzeugt",
    "role": "date",
    "type": "number",
    "read": true,
    "write": true,
    "def": 0,
    "alias": {
      "id": "vw-connect.0.FIN.status.air-conditioning.timers.timeInCar",
      "read": "new Date(val).getTime()"
    }
  },
  "type": "state",
  "native": {},
  "_id": "alias.0.test",
  "acl": {
    "object": 1632,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "from": "system.adapter.admin.0",
  "user": "system.user.admin",
  "ts": 1666775968588
}

Die Frage ist nach wie vor: Was hast Du denn vor? Es ändert sich im Admin ja nur die Anzeige, wenn man die Rolle setzt. Der gespeicherte Wert bleibt genau der gleiche...

klein0r created this issue in ioBroker/ioBroker.admin

closed Role "date" is ignored when common.type is string #1770

JB_Sullivan

@haus-automatisierung sagte in Zeitdifferenz berechnen:

Die Frage ist nach wie vor: Was hast Du denn vor?

Der Adapter liefert die Uhrzeit des Fahrzeugs in UTC und zusätzlich den lokalen (CET) Anpassungsfaktor +2

Das Fahrzeug gibt die Geoposition aus und damit ich in der VIS sehe wie aktuell diese Geoposition ist, blende ich mir den diesen "Zeitstempel" Datenpunkt mit in die VIS ein. Klar kann ICH auch jedesmal im Kopf die 2 Stunden dazu rechnen.

Damit ist aber dem WAF-Faktor leider nicht genüge getan Darum wollte ich den Datenpunkt so umwandeln das ein neuer, zeitlich korrekter DP entsteht, den ich dann in die VIS verknüpfe.

haus-automatisierung

@jb_sullivan sagte in Zeitdifferenz berechnen:

Darum wollte ich den Datenpunkt so umwandeln das ein neuer, zeitlich korrekter DP entsteht

Verstehe. Korrekt sind ja die UTC-Zeitpunkte ja auch

Das ist meiner Meinung nach die Aufgabe des Frontends (also VIS). Es wäre in jedem Fall richtig, den Datenpunkt in UTC zu speichern (als string so wie er aktuell schon da ist oder number, siehe Alias im vorigen Beitrag) und diesen dann im Frontend von VIS auf die lokale Zeitzone umrechnen zu lassen.

Eine Datenbank sollte Zeitstempel immer in UTC speichern (wie das Forum hier z.B. auch). Und dann erst bei der Darstellung den Zeitstempel für den User darstellen.

Dafür gibt es doch z.B. das Widget TimesValue. Da einfach den Datenpunkt mit dem UTC-Zeitstempel wählen und das Format DD.MM.YYYY hh:mm:ss eintragen. Fertig. Keine Scripts, keine neuen Datenpunkte, keine Rechnerei.

JB_Sullivan

@haus-automatisierung VIELEN DANK das wir drüber gesprochen haben

Tja wenn man immer alles wüsste was geht, bräuchte man sich nicht den Kopf zu zerbrechen, wie man dieses oder jenes von"hinten durchs Auge" gelöst bekommt.

Also nochmals vielen Dank für deine Zeit und die Erklärungen

hg6806

Hallo zusammen,

zu dem Thema hätte ich auch eine Frage.
Und zwar habe ich eine Zeitdifferenz berechnet. Die ms stimmen soweit.
16482933ms sind umgerechnet ca. 46h
Mit dem folgenden Blockly bekomme ich aber nur 22:57?

Homoran

@hg6806 sagte in Zeitdifferenz berechnen:

Mit dem folgenden Blockly bekomme ich aber nur 22:57?

das ist nicht vollständig!
wo nommt die Variable her?

Hier wird die SS:mm des errechneten Timestamps ausgegeb3n. Das ist nie > 24h

hg6806

@homoran

Ok, ich hole etwas weiter aus.
Von einem Türsensor bekomme ich ein JSON.
Daraus fische ich den Zeitstempel der letzten Öffnung/Schließung.
Wenn ich den Zeitstempel nach TT.MM.JJJJ dekodiere, stimmt es schon mal.
Die verstrichene Zeit auch (evtl 1h Unterschied wegen Zeitzone).
Doch leider stimmt die letzte Berechnung nicht nach SS:mm

haus-automatisierung

@hg6806 sagte in Zeitdifferenz berechnen:

Doch leider stimmt die letzte Berechnung nicht nach SS:mm

Bitte den Thread nochmal lesen. Wenn Du nach SS:MM wandelst, dann wird die Zeitzone berücksichtigt. Und wenn Du jetzt sagt: Gibt mir 01:20 Uhr UTC mal in meiner Zeitzone, dann ist das etwas anderes als "80 Minuten in SS:MM formatieren bitte".

Um bei dem Beispiel zu bleiben:

new Date(80 * 60 * 1000).toISOString() // "1970-01-01T01:20:00.000Z"
new Date(80 * 60 * 1000).toLocaleString("de-DE", { timeZone: "Europe/Berlin" }) // "1.1.1970, 02:20:00"

Der gleiche Zeitstempel wurde also in verschiedene Zeitzonen umgerechnet. Was (logischerweise) zwei unterschiedliche Ergebnisse gibt.

Du benutzt da keine Funktionen um eine Dauer in einen lesbaren Wert zu wandeln, sondern Du formatierst eine Zeit / einen Timestamp in ein lesbares Format Deiner Zeitzone.

@hg6806 sagte in Zeitdifferenz berechnen:

16482933ms sind umgerechnet ca. 46h Mit dem folgenden Blockly bekomme ich aber nur 22:57?

Das geht daher logischerweise auch nicht. SS bedeutet Stunde. Der Wert geht von 0 bis 23. Genau wie die Minute nur von 0 bis 59 geht. Du bekommst also Tage dazu / das Datum verschiebt sich.

Du formatierst also von dem Zeitstempel 16482933 nur die Stunden und die Minuten. Inzwischen ist aber ein ganzer Tag vergangen. Nach der Logik müsste das heutige Datum mit SS formatiert ja einen extrem hohen Wert ausgeben (vergangene Stunden seit 01.01.1970). Ist aber zum Glück nicht so.

Dazu gibt es auch einen Feature-Request: https://github.com/ioBroker/ioBroker.javascript/issues/1044

Marty56 created this issue in ioBroker/ioBroker.javascript

closed add "format_duration" function #1044

hg6806

@haus-automatisierung

Aber ich nehme zur Berechnung doch gar nicht das TT.MM.JJJJ, sondern die Variable "Zeitdiff_in_ms", die auch kein String sondern eine Zahl sein müsste.
Das oberste "aktualisiere" ist eine eigenständige Berechnung und kann man auch wegdenken.
Das 2. "aktualisiere" stimmt noch, nur das letzte nicht mehr.

haus-automatisierung

@hg6806 sagte in Zeitdifferenz berechnen:

Aber ich nehme zur Berechnung doch gar nicht das TT.MM.JJJJ, sondern die Variable "Zeitdiff_in_ms", die auch kein String sondern eine Zahl sein müsste.

Ja, falsch gelesen. Habe ich editiert und erklärt.

hg6806

@haus-automatisierung

Ich habe es jetzt händisch berechnet, da mich lediglich die Stunden interessieren.

H-a-m-i

Guten morgen zusammen!

Ich komme mit der Berechnung von der Zeitdifferenz, seit der Zeitumstellung heute Nacht, auch nicht mehr zurecht. Hatte bis gestern immer die 3600000 Millisekunden von einer Differenz abziehen lassen und die ausgegebenen SS:mm haben gestimmt. Seit der Zeitumstellung heute Nacht ist es aber wieder eine Stunde mehr, sprich, ich müsste jetzt 7200000 Millisekunden abziehen. Das kann doch nicht sein.

Um das mal am Beispiel von @paul53 "kompensieren-Block" zu zeigen:

Die Zeiten im Raspi stimmen alle:

pi@raspberrypi:~ $ sudo -u iobroker date
[sudo] Passwort für pi:
So 29. Okt 08:51:48 CET 2023
pi@raspberrypi:~ $ date && date -u
So 29. Okt 08:51:52 CET 2023
So 29. Okt 07:51:52 UTC 2023

haus-automatisierung

@h-a-m-i Am besten nicht die Funktionen zweckentfremden. Die sind halt dafür da, um einen UTC Zeitstempel in ein lesbares Format in Deiner Zeitzone zu wandeln. Und nicht um eine Zeitdifferenz zu formatieren.

Steht auf meiner ToDo Liste dafür Funktionen in den Adapter einzubauen

H-a-m-i

Hmm ok. Dann gibt es keine Möglichkeit, in Blockly eine Differenz in SS:mm anzeigen zu lassen, ohne im Sommer 3,6 Mio Millisekunden und im Winter 7,2 Mio Millisekunden abzuziehen?

haus-automatisierung

@h-a-m-i Na doch, könnte man sich mit dem Modulo errechnen. Dann muss man auch nicht mit der Sommerzeit der lokalen Zeitzone kämpfen

H-a-m-i

Ok hab da jetzt mal etwas rumgelesen und mit dem mod rum experimentiert, aber da bekomme ich iwie nur, beim Testen manuell eingegebene, Sekunden bzw. Millisekunden richtig umgerechnet. Sobald ich irgend ein "Zeit-Konvertierungs-Block" mit rein nehme, wie zb den "Aktuelle zeit als Datum-Objekt" Block, den ich oft verwende, kommt wieder eine Stunde mehr raus. Vermutlich wegen der Zeitzonen Berücksichtigung dieser Blöcke... Ist mir wohl zu hoch xD hab einfach zu wenig Ahnung von dem Ganzen...

Ich hab mir jetzt eine, für euch vermutlich umständliche, aber für mich einfachere und schnellere Lösung gebaut xD Ich hab nen DP erstellt, der je nach Sommer- oder Winterzeit entweder die 3600000 oder die 7200000 bekommt und diesen subtrahiere ich dann von meinen Zeitdifferenzen

haus-automatisierung

@h-a-m-i sagte in Zeitdifferenz berechnen:

wie zb den "Aktuelle zeit als Datum-Objekt" Block, den ich oft verwende, kommt wieder eine Stunde mehr raus.

Richtig, das habe ich ja schon 2x oben erklärt. Daher nicht verwenden wenn es darum geht, Zeitdifferenzen zu formatieren. Der ist dafür da, um ein Datum / Zeitstempel zu formatieren. Mehr nicht. Alles andere ist zweckentfremdet und führt zu Seiteneffekten!

Das nächste Problem mit der Lösung ist, dass das Format ja bei 23:59 Uhr endet und dann wieder bei 00:00 Uhr anfängt (das wäre der Folgetag - also der 02.01.1970). Wie gesagt, da wird ein Datum formatiert. Zeitdifferenzen über 24 Stunden sind mit der Funktion also nicht abbildbar!

Das hatte ich mit Beispielen aber schon ausführlicher erklärt.

@h-a-m-i sagte in Zeitdifferenz berechnen:

Ich hab nen DP erstellt, der je nach Sommer- oder Winterzeit entweder die 3600000 oder die 7200000 bekommt

Ich wüsste gar nicht, ob man es noch komplizierter lösen könnte Am Ende reichen die Grundrechenarten, um das vernünftig zu lösen:

Screenshot 2023-10-30 at 12.25.47.png

aber:

Bessere Lösung:

Weil das (eigentlich recht einfache) Thema doch scheinbar so viele bewegt, habe ich gerade einen neue Funktion und einen neuen Blockly-Block in den JavaScript-Adapter gebaut. Kommt dann mit der nächsten Version (> 7.1.6) und sieht dann so aus:

Screenshot 2023-10-30 at 12.16.36.png

Beispiele gibts in der Dokumentation:

const diff = 172800000 + 10800000 + 540000 + 15000; // 2 days, 3 hours, 9 minutes + 15 secoonds
formatTimeDiff(diff); // "51:09:15"
formatTimeDiff(diff, "DD hh:mm"); // "02 03:09"
formatTimeDiff(diff, "D hh:mm"); // "2 03:09"
formatTimeDiff(diff, "hh:mm:ss"); // "51:09:15"
formatTimeDiff(diff, "h:m:s"); // "51:9:15"
formatTimeDiff(diff, "hh:mm"); // "51:09"
formatTimeDiff(diff, "mm:ss"); // "3069:15"
formatTimeDiff(diff, "hh"); // "51"
formatTimeDiff(diff, "mm"); // "3069"

Ich hoffe, damit ist das Thema bald vom Tisch

Ansonsten habe ich das Ganze gerade noch in einem YouTube-Video zusammengefasst. Also Problemstellung und Lösungsweg (inkl. der neuen Blockly-Bausteine): https://www.youtube.com/watch?v=sxkz3O6nfFQ

David G.

@haus-automatisierung

Fein wäre natürlich, wenn man in den neuen Block direkt 2 Daten eintragen könnte anstatt vorher die Differenz berechnen zu müssen.

Kleine Frage:
Rechnet der neue Baustein "einfach" Rückwärts wie auf dem manuellen Weg oder werden auch Schaltjahre oder 29,30,31 Tage bei Monaten berücksichtigt?

Dazu hatte ich hier im Forum schon 1-2 Themen um zB das Alter oder die Zeit bis zu einem Geburtstag zu berechnen. Das ging meistens nur mit einem extra Modul (meine moments) im Js Adapter sauber.

haus-automatisierung

@david-g sagte in Zeitdifferenz berechnen:

Fein wäre natürlich, wenn man in den neuen Block direkt 2 Daten eintragen könnte

Pack die Rechenoperation halt als Block direkt da rein? Musst ja vorher keine Variable erstellen.

@david-g sagte in Zeitdifferenz berechnen:

Rechnet der neue Baustein "einfach" Rückwärts wie auf dem manuellen Weg oder werden auch Schaltjahre oder 29,30,31 Tage bei Monaten berücksichtigt?

Weder noch - es wird einfach auf Basis der Timestamps in Millisekunden gerechnet. Siehst Du ja auch im verlinkten Video. Ist etwas anderes, als wenn man zwei Daten zur Verfügung hat und da erstmal definieren muss in welcher Zeitzone die liegen usw.

David G.

@haus-automatisierung

Das Video hab ich gesehen, noch vor dem Betrag.
Dass das echte Datum außen vor ist, ist mir klar.

Die Frage ist, was ist Zb ein Monat?
Hat ein Monat 30,4 Tage (365/12)?
Geht das Jahr immer von 365 Tagen aus?

Jenachdem was für Zeiträume man berechnet liegt man ja schon (zwangsweise) was daneben.
Zumindest wenn man in den Bereich Monate oder Jahre kommt wo nicht jeder Zeitraum immer genau gleich definiert ist.

NEWS

Zeitdifferenz berechnen

closed Role "date" is ignored when common.type is string #1770

closed add "format_duration" function #1044

Bessere Lösung:

Support us

934
Online

31.7k
Users

79.7k
Topics

1.3m
Posts

NEWS

Zeitdifferenz berechnen

closed Role "date" is ignored when common.type is string #1770

closed add "format_duration" function #1044

Bessere Lösung:

Support us

934Online

31.7kUsers

79.7kTopics

1.3mPosts

934
Online

31.7k
Users

79.7k
Topics

1.3m
Posts