Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. ioBroker Allgemein
    4. [SOLVED] Frage zum SQL-Adapter

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    [SOLVED] Frage zum SQL-Adapter

    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      diwoma last edited by diwoma

      Hi, ich logge Daten in die Influx-DB und in einen MS-SQL-Server. In den SQL-Server deswegen, weil ich mich mit der SQL-Syntax für Auswertungen besser auskenne als mit der Influx-Syntax.

      Bei der Auswertung der Daten kommen mir vor allem beim Timestamp und beim _from in den Datenpunkten Fragen auf:

      1. Timestamp: Ist das der UTC-Timestamp oder der lokale Timestamp? Ich nehme an, es ist der UTC-Timestamp, aber da die Timezone nicht mit angegeben ist, kann man es (zumindest nicht im MS-SQL-Server) einfach in die lokale Datetime umrechnen, zumal in Europa (noch) durch die Sommerzeit 2 Zeitzonen vorhanden sind. Man müsste bei allen Abfragen, wenn man die Zeit umrechnet eine Abfrage nach den Grenzen der Sommerzeit einfügen, was dann doch belastend für die Abfrage wäre.
      2. im _from ist die Quelle eingetragen, die den Datenpunkt schreibt, ich habe 2 Quellen:
      1	system.adapter.javascript.0
      2	system.adapter.sql.0
      

      Bei mir steht aber immer 1 (javascript) als Quelle, sollte nicht der 'adapter' eingetragen sein, zumal er die Datenpunkte schreibt? Bzw. wann würde der Adapter als Quelle eingetragen sein?

      1. Wenn das mit mit dem Timestamp im MS-SQL-Server so kompliziert wird, macht es Maria-DB da einfacher. Ich habe mit MySql weniger Erfahrung, aber da gibt es eine eingebaute Funktion die einen Timestamp in ein Datetime umwandelt, berücksichtigt diese Funktion eine wechselnde Zeitzone aufgrund des Datums?
      F 1 Reply Last reply Reply Quote 0
      • F
        fastfoot @diwoma last edited by

        @diwoma schau mal hier. Kann es nicht testen aber sieht easy aus

        D 1 Reply Last reply Reply Quote 0
        • D
          diwoma @fastfoot last edited by diwoma

          @fastfoot Ja, schaut einfach aus, hat nur ein Problem:
          Das ist für lokale Zeit nur richtig, wenn der Timestamp auch ein lokaler Timestamp ist. Ist der Timestamp aber ein UTC-Timestamp dann sieht die Umwandlung wie folgt aus:

          MEZ:   dateadd(s, v.ts/1000, '1970-01-01 01:00:00')
          MESZ:  dateadd(s, v.ts/1000, '1970-01-01 02:00:00')
          

          deshalb auch meine Frage, welcher Timestamp in die DB geschrieben ist.

          Ist es UTC-Zeit dann wird es etwas komplizierter:
          Da in den Datapoint's auch keine Zeitzonen-Beschreibung zum Datapoint dazugegeben wurde, muss man erst abfragen ob der Timestamp in die MEZ oder MESZ Zone fällt und dann entsprechend die Umwandlung durchführen:
          Zuerst das Datum ermitteln, dann prüfen ob das Datum größer als MESZ-Startdatum und kleiner als MESZ-Enddatum für das jeweilige Jahr ist und dann 1 Stunde oder 2 Stunden addieren, wobei der Beginn und Ende der MESZ-Zone nicht fix ist sondern vom letzten Wochenende im März und Oktober abhängig ist.

          F 1 Reply Last reply Reply Quote 0
          • F
            fastfoot @diwoma last edited by

            @diwoma ja das ist utc. from_unixtime(ts/1000) in Maria-Db konvertiert das in die lokale Zeit. Du sagtest der sql Server unterstützt die Umwandlung nicht, was halt nur teilweise stimmt. Es fehlt halt die Umwandlung von UTC zu lokaler Zeit

            D 1 Reply Last reply Reply Quote 0
            • D
              diwoma @fastfoot last edited by

              @fastfoot Wenn Du die reine Additon einer Anzahl an Sekunden zu einem 'beliebigen' Datum als Unterstützung meinst, dann hast Du Recht. In meinen Augen ist das nur eine Krücke. Und tatsächlich liegt das Problem wirklich an der fehlenden Erkennung zur Umrechnung in die lokale Zeit

              1 Reply Last reply Reply Quote 0
              • D
                diwoma last edited by

                Ich habe eine Lösung in StackOverflow gefunden:

                /* Aus MySQL ermittelt
                select UNIX_TIMESTAMP('2022-06-06 15:00'); // => 1654520400
                select UNIX_TIMESTAMP('2022-03-03 15:00'); // => 1646316000
                */
                
                SELECT *, DATEADD(SECOND, UnixTimestamp, '1970-01-01') AT TIME ZONE 'UTC' AT TIME ZONE 'Central European Standard Time' AS LocalTime
                FROM (VALUES (1646316000), (1654520400)) AS Tests(UnixTimestamp) 
                
                
                UnixTimestamp	LocalTime
                1646316000	03.03.2022 15:00:00.000 +01:00
                1654520400	06.06.2022 15:00:00.000 +02:00
                

                Und wie man aus der LocalTime sieht, wird die Sommerzeit auch korrekt erkannt. Ist zwar nicht so elegant wie in der MySql aber macht was ich wollte

                F 1 Reply Last reply Reply Quote 0
                • F
                  fastfoot @diwoma last edited by

                  @diwoma nun ja, was heisst elegant, ist doch voll flexibel, in mysql gibt es 'nur' die Umwandlung in die voreingestellte Systemzeit, soweit mir bekannt.

                  D 1 Reply Last reply Reply Quote 0
                  • D
                    diwoma @fastfoot last edited by diwoma

                    @fastfoot Da gebe ich Dir recht.

                    Danke für die Begleitung und Hilfe.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post

                    Support us

                    ioBroker
                    Community Adapters
                    Donate
                    FAQ Cloud / IOT
                    HowTo: Node.js-Update
                    HowTo: Backup/Restore
                    Downloads
                    BLOG

                    707
                    Online

                    31.8k
                    Users

                    79.9k
                    Topics

                    1.3m
                    Posts

                    2
                    8
                    457
                    Loading More Posts
                    • Oldest to Newest
                    • Newest to Oldest
                    • Most Votes
                    Reply
                    • Reply as topic
                    Log in to reply
                    Community
                    Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                    The ioBroker Community 2014-2023
                    logo