BLOCKLY Zeit nach UTC konvertieren.
-
@paul53 Naja ich habe die Zulu Zeit am Objekt. Die ist immer gleich - ob Sommer oder Winter. Ich möchte prüfen ob die Zeitdifferenz die mir als Zulu-Zeit vorliegt sich um mehr als 30 Minuten von der aktuellen Zeit, die ich als CET habe abweicht. Hard-Coden macht keinen Sinn wegen der Sommer-Winterzeit-Geschichte...
Deine Idee mit den ms versteh ich nicht.
-
@cyrano330
Wandle den DP-Wert in ms und subtrahiere ihn von der aktuellen Zeit in ms.
Das Datum-Objekt enthält immer die ms seit 1.1.1970 0:00 Uhr UTC.
-
@cyrano330 man braucht keine Uhrzeit zur Überwachung. Die Teile melden sich innerhalb von 2 Stunden mind. einmal. Starte einfach einen Timer, wenn er sich gemeldet hat und gib Alarm aus, wenn er sich nicht innerhalb von 2 Std. gemeldet hat. Dazu brauche ich keine Uhrzeiten.
-
@paul53 Ich hab nen Knoten im Kopf... Wenn ich das so mache hab ich einen negativen Wert.... Als imm kleiner als die 180000....
-
@mickym Sind die 2h sicher?
-
@cyrano330 sagte: hab ich einen negativen Wert..
Das wundert mich. Ist der String im Datenpunkt nicht JS-konform? Die Wandlungsfunktion sollte am "Z" erkennen, dass es sich um die UTC-Zeit handelt.
-
Logfile: script.js.Skript_1: Differenz aktuelle Zeit - Datenpunkt -2782300 Messpunkt: 1675002562301 aktuelle Zeit: 1674999780001
-
@cyrano330
Der Wert liegt in der Zukunft. Poste bitte mal den Datenpunktwert, da ich solche Datenpunkte nicht habe.EDIT: Habe mal mit einem String "2023-01-29T14:00:24.000Z" (= heute 15:00:24 MEZ) getestet: Bei mir funktioniert die Konvertierung richtig.
-
@cyrano330 sagte in BLOCKLY Zeit nach UTC konvertieren.:
@mickym Sind die 2h sicher?
Bei mir funktioniert das nun seit 2 Jahren so.
Wenn sich die Temperatur ändert dann sogar um so häufiger. Hier meine 3 AQURAs aus der Küche.
2 überwachen den Kühlschrank. Da ist sogar Kurve mit dabei. Ich lass mir immer ausgeben von wann der Wert war.
- Aber das mache ich wie bei den zigbee Teilen generell. Das heißt wenn sich irgendein Gerät meldet, dann ermittle ich nur die Differenz. Ich speichere das aber selbst. Mach das auch nicht mit Blockly.
-
Hi,
angelockt vom Titel des Threads über die Suche, hab ich's mit der hier vorgeschlagenen Lösung versucht, allerdings vergeblich. Ich bekam immer nur eine Differenz von einer Stunde heraus, nie die korrekte von 2 Stunden (wir haben gerade Sommerzeit). Was mir dabei auffiel: Die alten Beispiele oben, zumindest deren Postings, fanden i.d.R. zur Winterzeit statt.Deshalb hier eine kleine, 3-Zeiler-Lösung für Blockly, die immer korrekt das Ergebnis als Differenz zur aktuellen Systemzeit liefert. JS selbst hat da den passenden Befehl, den man per Blockly-Funktion fix einbinden kann:
Inhalt der Funktion (Klick auf die 3 Punkte rechts):
....und hier die Einbindung:
Um wie bei mir gewollt aus UTC die lokale Zeit zu bilden, werden lediglich die Offset-Minuten als Millisekunden (* 60 * 1000) addiert. Umgekehrt geht's natürlich genauso mit anderem Vorzeichen.Anwendung bei mir ist übrigens eine Ansage eines Zeitabstandes (nebst berechneter absoluter Zielzeit) zum gelieferten Prognoseergebnis einer Trendanalyse, also wann bei gleichbleibendem Trend ein Grenzwert erreicht würde. Diese habe ich, ausgehend von den SQL-Historien im Broker auf dem ohnehin dafür genutztem SQL-Server ermitteln lassen (kleiner IBM-NUC). Die Zeiten dort kommen aber wg. Modularität stets als UTC. Diese waren dann in Abfrage- oder Alarmansagen (gebildet in Blockly) in lokalTZ zu wandeln.
(Off topic, aber vielleicht für einige interessant?)
Das ganze ist übrigens komplett modular (liefernder Datenpunkt + "projektabhängig" Limits bzw. Ergebnis-Schweregrad-Klassen als Parameter), in konkreter Anwendung bisher bei mir im Einsatz für-
Diabtetes-Wert (Adapter: libre.; Sorry, die internen "Trends" dort sind keine bzw. sinnlos weil nicht look-ahead. Z.B. zum Wecken bei Unterzuckerung absolut ungeeignet). Warum Trend? Sorry, ich esse stochastische Kohlehydratmengen in stochastischen Zeitabständen, nebst stochastischer körperlicher Betätigung
-
Ermittlung Sturm-/Starkwind-Ende für Dachfenster, Stoff-Markiesen usw. (Einfahren bei Boe über Limit ist easy, aber eine Böenpause ist noch kein Indiz fürs Wieder-Ausfahren, obwohl Schatten-Bedarf noch besteht. Hier hilft ein Trend sehr! 2 Adapter: WU (WeatherUnderground) und Netatmo
-
Regenwasser-Zisternen für Gartenbewässerung, Füllstand rechtzeitig evtl. umschalten auf Frischwasser, BEVOR neuer Zyklus beginnt (oder wenn manuell umschalten: VOR dem Urlaub, Dienstreise usw.). Hardware: LevelJet von ProJet (Ultraschall-Sensor), angebunden per USB an Raspi (zzgl. 2 systemeigener Funkstrecken auf dem Weg dahin: Zisterne->Controller und von dort USB->Funk->USB->Raspi). Trend hier besser, da Bewässerung selbst (und damit Mengenentnahme) stochastisch (überhaupt? Zeitdauer?) aus Verdunstungsberechnung zzgl. aktueller Regenereignissen, -mengen, -zeitabständen usw. Kein Adapter, empfangener Raspi triggert kleines Script für Werteaktualisierung
-
Wasserdruck Heizungsanlage, Rohrsystem aus den 1960ern mit leichten Verlusten (diese aber Nutzungs- bzw. letztlich Umgebungs-Temperatur-abhängig -> Trendanalyse nötig), das ganze in Pflegewohnung >100km entfernt, natürlich "unter Limit" (Gefahr der Abschaltung -> Wasser nachfüllen) nach Monaten, immer genau dann, wenn man gerade zu Besuch war, auf Dienstreise ist oder Glatteissturm usw. herrscht... Adapter: Vaillant, Absolute Werte (immer der aktuelle) als Limit nützt leider wenig, weil die Heizungsanlage selbst mit ihrer bedarfsweisen Zykluspumpe Werte dann im gesamten Min-Max-Bereich) nochmal für Stochastik im System sorgt. -> Trendanalyse über Tage hilft.
Völlig unterschiedliche Anwendungen, Einheiten, Zeitabstände, Ergebnisbehandlung, aber alle nutzen gleiches Modul zur Berechnung, bei Ansagen, Alarmauskopplungen usw.
Vielleicht veröffentliche ich hier mal im Forum den ganzen Kram, so Interesse besteht. An der Doku als Lehrmaterial arbeite ich bereits.
Gruß bb61 (=GW in den Release-Kommentaren)
-
-
@bb61 sagte: Ich bekam immer nur eine Differenz von einer Stunde heraus
Bezug ist der 1.1.1970, also keine Sommerzeit.
-
@paul53
klar. DAS Datum ist stabil. Aber auch immer =0, Sommers wie winters.Aber es geht hier ja nun nicht um diesen fixen Ursprung (1.1.70 00:00:00) in der gesuchten Zeitkoordinate, sondern um dessen Differenz zum anderen Ende des Zeitstrahls, also um den "Nutz-Zeitwert" aus der realen Welt. Und der "floatet" natürlich durch das reale Jahr, je nach Anwendungsfall.
Entstammend aus realen Eventzeitpunkt in lokaler oder Systemzeit (also "anderes Zeit-Koordinatensystem"), liegt dieser dann aber sehr wohl ursprünglich in Sommer- oder Winterzeit, bevor der dann in die "Sommerzeitumschaltungslose" UTC umgerechnet wird. Also mal mit und mal ohne SZ-Zeitverschiebung, je nach Event-Zeit.
Genau das berücksichtig aber zum Glück der JS Befehl in der genannten Function.. Ohne dem muss man das aber selber nachbilden. Oder es funktioniert dann eben nur ...ähm... zeitweise.
Egal, Zeitberechnungen haben so manch lustige Effekte, wenn man mal mehr ins Detail schaut. Das hier ist noch einer der einfachsten.
