UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Strobi]

@paul53
Guten Abend,
leider funktioniert die Zeitberechnung so leider nicht.
Ich würde gerne immer die Zeitdifferenz bis zum nächsten Sonnenaufgang berechnen.
Also 1h vor dem Sonnenaufgang müsste 1h rauskommen, eine Stunde nach dem Sonnenaufgang müsste 23h rauskommen.

Mit folgendem Blockly kommt aber leider gar nichts raus:

Hat vielleicht jemand eine Idee, wie ich das hinbekommen könnte?

Besten Dank!

[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:

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

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:

[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...

[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

[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?