Zeitdifferenz berechnen

paul53

@strobi sagte eine Stunde nach dem Sonnenaufgang müsste 23h rauskommen.

Nein, dann kommt am gleichen Tag ein negativer Wert raus. Teste die Berechnung erst mal mit dem Debug-Block.

Der Datenpunkt scheint keinen Zustand zu haben. Ist es der richtige DP? Das Skript ist aktiv, nicht unter der Gruppe "global" erstellt und der Debug-Modus (rechts oben) ist deaktiviert?

Für positive Werte:

Strobi

@paul53
So geht es - falls es noch jemanden interessiert - Zeitspanne bis zum nächsten Sonnenaufgang

JB_Sullivan

Auch wenn dieser Thread schon "100 Jahre" alt ist, würde ich mich gerne mit meiner Frage hier anschließen, da es sich ebenfalls um eine "Zeit berechnen" Frage handelt.

Konkrete Problemstellung:
Ich habe zwei Datenpunkte - einmal die Zeit als UTC und dann den Lokalen Korrekturfaktor +2 Std. (CET)

Wie kann ich den vorhandenen DP, welcher so aussieht 2022-10-25T13:23:32Z nun um + 2 Stunden hoch addieren?

Das hier funktioniert jedenfalls nicht

haus-automatisierung

@jb_sullivan sagte in Zeitdifferenz berechnen:

Wie kann ich den vorhandenen DP, welcher so aussieht 2022-10-25T13:23:32Z nun um + 2 Stunden hoch addieren?

Du willst nichts addieren. Du willst den Zeitstempel nur anders formatieren (für unsere Zeitzone). Der Zeitpunkt bleibt ja genau der gleiche. Wäre ja falsch, da nun Stunden drauf zu schlagen.

Das "Z" am Ende deiner Zeitangabe steht für "Zulu". Das heißt, das ist UTC. Wenn Du das nun also in die gängigen Datumsfunktionen gibst, dann wissen die schon damit umzugehen. Wenn man den Zeitpunkt nun also formatiert, dann wird die Zeitzone des Betriebssystems berücksichtigt:

Screenshot 2022-10-26 at 10.47.14.png

Ergibt: 25.10.2022. 15:23:32

<xml xmlns="https://developers.google.com/blockly/xml">
  <variables>
    <variable id=",cJDM_Be,aiY)MRh{R/}">timeStamp</variable>
  </variables>
  <block type="variables_set" id="#s#G]QUKK_14+DT$P.$@" x="-587" y="262">
    <field name="VAR" id=",cJDM_Be,aiY)MRh{R/}">timeStamp</field>
    <value name="VALUE">
      <block type="convert_to_date" id="k=w+o:B(w6`jJMabP~b[">
        <value name="VALUE">
          <block type="text" id="r6t?3L$0}/3s`fDw`eh7">
            <field name="TEXT">2022-10-25T13:23:32Z</field>
          </block>
        </value>
      </block>
    </value>
    <next>
      <block type="debug" id="00=-ftF0Y@P^A7$W/(F?">
        <field name="Severity">log</field>
        <value name="TEXT">
          <shadow type="text" id="#=,ZXQ_{QyO-CuYT@KRn">
            <field name="TEXT">test</field>
          </shadow>
          <block type="convert_from_date" id="Ou5k{iL@;t`k5bxyQ^,S">
            <mutation xmlns="http://www.w3.org/1999/xhtml" format="true" language="false"></mutation>
            <field name="OPTION">custom</field>
            <field name="FORMAT">TT.MM.JJJJ. SS:mm:ss</field>
            <value name="VALUE">
              <block type="variables_get" id="=OC%5Yj^4Ki#Oc,(S1m/">
                <field name="VAR" id=",cJDM_Be,aiY)MRh{R/}">timeStamp</field>
              </block>
            </value>
          </block>
        </value>
      </block>
    </next>
  </block>
</xml>

EDIT: So gehts sogar noch einfacher

Screenshot 2022-10-26 at 10.50.22.png

Aber: Wenn Du ein Datum/Zeitpunkt als Wert in einem Datenpunkt speichern möchtest, dann ist UTC dafür ebenfalls korrekt. In dem Fall setzt Du die Rolle auf date und der Admin stellt den Wert dann "richtig" (heißt: in Deiner Zeitzone formatiert) dar:

Screenshot 2022-10-26 at 11.04.06.png

JB_Sullivan

@haus-automatisierung

Naja, den Datenpunkt als UTC gibt es ja. Verstehe ich das richtig, das ich nur die Rolle ändern muss? Also in den Objektdaten von "indicator" in "date", damit nicht UTC sondern die Systemzeit ausgegeben wird?

{
  "type": "state",
  "common": {
    "name": "timeInCar",
    "role": "indicator",
    "type": "string",
    "write": false,
    "read": true
  },
  "native": {},
  "from": "system.adapter.vw-connect.0",
  "user": "system.user.admin",
  "ts": 1665834213369,
  "_id": "vw-connect.0.FIN.status.air-conditioning.timers.timeInCar",
  "acl": {
    "object": 1636,
    "state": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

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

NEWS

Zeitdifferenz berechnen

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

closed add "format_duration" function #1044

Support us

1.1k
Online

30.2k
Users

76.2k
Topics

1.2m
Posts

NEWS

Zeitdifferenz berechnen

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

closed add "format_duration" function #1044

Support us

1.1kOnline

30.2kUsers

76.2kTopics

1.2mPosts

1.1k
Online

30.2k
Users

76.2k
Topics

1.2m
Posts