Ankündigung

Einklappen
Keine Ankündigung bisher.

- √ - Asynchron - Raspberry time und Openhab time

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    - √ - Asynchron - Raspberry time und Openhab time

    Hallo zusammen,

    ich habe eine Asynchronität bei OH mit der Userzeit und dem was in den logs passiert.

    Bsp:

    root@raspberrypi:/opt/openhab/logs# date
    Fri Nov 15 16:53:54 CET 2013

    während geichzeitig im Logfile folgendes ausgegeben wird:
    2013-11-15 15:52:59 - Weather_Temperature state updated to 2
    2013-11-15 15:53:04 - strSunset state updated to 16:42:00
    2013-11-15 15:53:09 - w state updated to partlycloudy

    da laufen mein Cron rules leider nicht zur rechten Zeit.

    Hat mir irgendjemand einen Tip?

    Danke
    Karsten

    #2
    Vermutlich musst Du auf dem RasPi (außerhalb von openHAB) noch einen NTP-Client einrichten. Alternativ hast Du im NTP-Client des RasPi eine andere Zeitzone angegeben, als in openHAB.

    Kommentar


      #3
      Du siehst mich Stirn runzeln.

      Wo stelle ich im OH eine NTP Zeitzone ein? Im ntp binding finde ich nur eine Server. Dort habe ich nichts veränder (oh.cfg

      # the hostname of the timeserver
      ntp:hostname=ptbtime1.ptb.de

      im PI habe ich folgende einstellungen:

      Current default time zone: 'Europe/Berlin'
      Local time is now: Fri Nov 15 17:09:36 CET 2013.
      Universal Time is now: Fri Nov 15 16:09:36 UTC 2013.

      mir scheint OH läuft auf UTC. Den Efekt habe ich im übrigen nur wenn ich OH automatisch beim booten starte.

      Wenn ich OH über die Komandozeile starte habe ich diesen Effekt nicht - dann läuft - obwohl der gleiche user - das in der richtigen Zeit. Kann ich im Startskript eine time setzen?

      Danke

      Kommentar


        #4
        Ah. Stimmt, in openHAB bezieht sich die Konfiguration auf die Ausgabe, wird also beim item mit übergeben.

        Weil es mit manuellem Start klappt, mit dem automatischen aber nicht, tippe ich auf falsch (bzw. nicht) gesetzte locales. war bei mir auch so, als ich den Startprozess automatisiert habe. die Locales beziehen sich ja auf die Konsole, in der sie gesetzt werden, hat bei mir dazu geführt, dass die Wochentage im Datum englisch waren, bis ich die default locales auf deutsch eingestellt habe. Ich meine /etc/default/locale oder so, bin aber nicht zuhause, so dass das nachschauen etwas umständlich ist.

        Kommentar


          #5
          Super danke das wars - habe in rasp-config die locales nochmal gesetzt und rebootet - jetz ttuts.

          Kommentar


            #6
            ich sitze gerade an der selben Geschichte.

            cat /etc/default/locale gibt mir die erwartete Ausgabe:
            LANG=de_DE.UTF-8

            aber die OpenHab time ist leider immer noch auf GMT und nicht auf CET

            Gibt es noch eine Einstellung, die gemacht werden muss?

            [EDIT]: Habe es herausgefunden: wenn man in den Server Start-parametern noch das entsprechende Dvalue setzt: -Duser.timezone="Europe/Berlin"

            Kommentar


              #7
              hatte vor einiger zeit exakt die gleiche problematik auf meinem qnap in verbindung mit der eigenen java applikation
              kanns jetzt nicht 100% erklären, ist länger her, liegt aber wohl an der TimeZone

              versuche mal folgendes (was bei mir geholfen hat):
              Code:
              mv /etc/localtime /etc/localtime.bak
              ln -s /usr/share/zoneinfo/Europe/Berlin /etc/localtime

              Kommentar


                #8
                Zitat von Tulamidan Beitrag anzeigen
                ich sitze gerade an der selben Geschichte.

                cat /etc/default/locale gibt mir die erwartete Ausgabe:
                LANG=de_DE.UTF-8

                aber die OpenHab time ist leider immer noch auf GMT und nicht auf CET

                Gibt es noch eine Einstellung, die gemacht werden muss?

                [EDIT]: Habe es herausgefunden: wenn man in den Server Start-parametern noch das entsprechende Dvalue setzt: -Duser.timezone="Europe/Berlin"


                Hi,

                bei mir motzt er dann die doppelten "" an. kannst du die komplette Zeile

                DAEMON_ARGS="-Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShutdown=true -Djetty.port=$HTTPPORT -Djetty.port.ssl=$HTTPSPORT -Djetty.home=$ECLIPSEHOME/etc/login.conf -Dorg.quartz.properties=$ECLIPSEHOME/etc/quartz.properties -Djava.awt.headless=true -jar $cp -console ${TELNETPORT} -Duser.timezone=Europe/Berlin"

                mal posten bitte und ggfls anpassen im WiKi ... neuinstallation und ich weiss nicht mehr wie es damals geklappt hat.

                [UPDATE] Selbst gefunden - die UTC LOcale UK war noch aktiviert - und da ich nicht bis zum e runter gescrollt bin hat er diese weiterhin verwendet.

                danke
                Karsten

                Kommentar


                  #9
                  Mir ist dabei noch etwas seltsames aufgefallen:

                  Wenn ich einen timer neu setze

                  timer = createTimer(now.plusMinutes(5))

                  Dann wird er in 5 Min ab jetzt ausgelöst.

                  Wenn ich aber einen existierenden Timer neu setzen möchte:

                  timer.reschedule(now.plusMinutes(5)) dann löst er nicht (oder in 2h und 5min aus?)

                  now.toString gibt folgendes aus: 2014-04-11T13:40:22.000+02:00

                  Somit wird irgendwie die Uhrzeit versucht zu korrigieren. Beim Initialen setzen des Timers scheint dies aber keine Auswirkung zu haben:

                  Ein Test:
                  Ich lasse meinen Rolladen nach Sonnenaufganszeit nach oben fahren, um 0:00 wird die Sonnenaufganszeit ermittelt und ein Timer gesetzt

                  00:07:03.952 INFO o.openhab.model.script.Sunset[:53]- Timer tSunrise created for bathroom shutter: 2014-04-11T04:43:12.000+02:00

                  04:43:12.163 INFO o.openhab.model.script.Sunrise[:53]- Timer tSunrise executed

                  Den Test für das reschedule muss ich leider schuldig bleiben... ich finde gerade keinen Logeintrag dazu.

                  Kommentar

                  Lädt...
                  X