Ankündigung

Einklappen
Keine Ankündigung bisher.

(SUCHE) ich benötige einen Denkansatz für eine universelle Zeitschaltuhr

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

    (SUCHE) ich benötige einen Denkansatz für eine universelle Zeitschaltuhr

    Hallo,

    leider gibt's kein Zeitschaltuhr Binding, daher muss man sich das per Rules und Cron selber bauen.

    Das sieht im einfachst Fall so aus:

    rule "06:45" // Montag bis Freitag
    when
    Time cron "0 45 6 ? * MON,TUE,WED,THU,FRI"
    then
    sendCommand(Rollo_OG_Bad, 0)
    sendCommand(Rollo_OG_Buero1, 0)
    end

    Wenn man das allerdings per GUI Konfigurieren möchte funktioniert dieser Ansatz nicht.

    Daher würde ich eine RULE erstellen, die alle 5 Minuten aufgerufen wird. (oder sogar jede Minute)

    Für jedes Gerät oder Gerätegruppe die ich per Zeitschaltuhr steuern möchte benötige ich eine eigene RULE?
    In jeder Gruppe möchte ich 10 Kanäle die ich per Wochentag und Zeit steuern kann.

    Nun kommt mein eigentliches Problem.

    1) welche der Persistence ist hier am idealsten geeignet? Ich möchte kein Monster wie MariaDB
    2) Benötige ich für jedes Gerät/Gerätegruppe folgende Switche-/Nummern- ITEMS ?
    - 1x Zeitschaltuhr ein/aus
    - 10x7 Wochentag (Montag, ..., Sonntag)
    - 10x Stunden
    - 10x Minuten
    3) kann man in einer RULE auch ITEMS und Persistence anlegen/erzeugen? (glaube das geht nicht)

    Oder gibt's bessere Ansätze?

    Gruß
    Lothar


    --
    Gruß
    Lothar

    #2
    Hi,

    es gibt ja diverse Wecker-Beispiele, auch solche, die per GUI eingestellt werden können.
    Du wirst sicher pro Schaltzeit eine Rule benötigen, eben wie bei einer Zeitschaltuhr unterschiedliche Programme.

    gruss,
    Jörg

    Kommentar


      #3
      Zitat von lo4dro Beitrag anzeigen
      Oder gibt's bessere Ansätze?
      Ich weiß nicht ob es bessere gibt, es gibt aber andere:

      Für dein obiges Problem mit dem Öffnen und Schließen von Rollos kann man z.B. das Astro Binding nutzen, dieses gibt dir bei Sonnenauf- und/oder -untergang einen Trigger (ggf. auch mit einem Offset und einem earliest/latest Zeitpunkt). Das ist deutlich komfortabler als mit einer Zeituhr.

      Ich habe auch schon oft vielfältige Begründungen gelesen, die von der Nutzung von Zeitschaltuhren in Automationslösungen abraten, da ereignisorientierte Trigger deutlich komfortabler sind.
      Zuletzt geändert von sihui; 04.09.2017, 06:31.

      Kommentar


        #4
        Ansonsten, wenn man doch von außen eingreifen können will:
        Man sollte nicht versuchen, krampfhaft alles in einer Oberfläche zu halten. Man kann z.B. Google Calendar nutzen (gcal Binding) oder auch (nicht ganz so flexibel) das caldav Binding, welches dafür z.B. auch mit owncloud funktoiniert.

        Das MariaDB ein Monster sei, finde ich ehrlich gesagt nicht gerechtfertigt. Es ist eine komplette Datenbankengine, mit der man auch große Datenmengen beherrschen kann, wenn man nur wenige Daten verarbeitet, wird das meiste davon brach liegen, aber das ist mit Word auch nicht anders. Wer nutzt mehr als 2% der Word Funktionen (das ist alles zum Schreiben von Text inklusive Formatierungen)?
        Wenn es partout weniger mächtig sein soll, kannst Du mit SQLite eine Nummer kleiner fahren, oder mit db4o fünf Nummern kleiner.

        Kommentar


          #5
          Danke,
          an die sqlite habe ich auch schon gedacht, ich bin halt überrascht das es so viele Persistence Module gibt und mir nicht immer klar ist für was die benötigt werden. Es gibt sogar Leute die in der rrd4 Werte dauerhaft speichern.
          Ist die SQLite-DB auch im Backup, wenn man sein Backup wie hier beschrieben durchführt?

          Ich habe mir das Astro Binding angesehen, es hat ein paar interessante Möglichkeiten mit diesen Chanel im Thing. Ein Teil der Rollostteuerung kann man so lösen.
          Allerdings habe ich auch einige Geräte für die eine klassische Zeitschaltuhr mit GU sehr praktisch ist.
          Zuletzt geändert von lo4dro; 05.09.2017, 07:19.
          --
          Gruß
          Lothar

          Kommentar


            #6
            Also, das ist recht einfach erklärt. Zum einen gibt es unterschiedliche Vor- und Nachteile der verschiedenen Datenbanken:

            mapdb:
            • + :total einfach
            • + :schnell
            • + :wächst nicht an
            • + :speichert alle Items
            • - :speichert nur einen Wert

            rrd4j:
            • + :wächst nicht an
            • + :als Grundlage für Diagramme (default)
            • + :unkompliziert
            • - :kann nicht mit allen Datentypen umgehen
            • - :Ist nicht uneingeschränkt für restoreOnStartup geeignet
            • - :Je länger die Erfassung zurück liegt, desto ungenauer werden die Werte (zeitliche Auflösung sinkt; nur noch Durchschnittswerte)

            influxdb:
            • + :räumt sich selbständig auf (wenn man es so einrichtet)
            • + :mächtige Analysefunktionen und tolle Diagramme (z.B. grafana)
            • + :schnell (sehr)
            • - :aufwändig aufzusetzen

            jdbc:
            • + : (fast) alles (aber zumindest die wichtigsten Vertreter) was SQL spricht, wird über einen Service angesprochen
            • + :uneingeschränke Speichereigenschaften
            • + :mächtige Analysetools
            • + :Einsatz der gewohnten db
            • - :nur eine Datenbank möglich
            • - :je nach DB Engine komplex aufzusetzen, falls man noch keine DB Engine einsetzt

            gcal:
            • + :erzeugt im Zusammenspiel mit dem gcal Binding auf Wunsch mit minimalem Aufwand eine automatische Event-Wiederholung (Anwesenheitssimulation)
            • + :Events können über die Kalenderoberfläche nachvollzogen werden
            • - : Daten in der Cloud
            • - :In der Einrichtung gab es verschiedentlich Probleme mit oauth (meines Wissens aber aktuell alle in Ordnung)

            db4o:
            • + :bei OH1 mitgeliefert und schon eingerichtet
            • - :bei OH2 nur manuell zu installieren
            • - : Daten können nur mit Aufwand extern weiter verarbeitet werden

            logging:
            • + :Klartext Ausgabe
            • - :nicht für lesenden Zugriff aus openHAB geeignet, also kein restoreOnStartup, keine historicStates


            zum Anderen gibt es (vor allem in Bezug auf jdbc) draußen viele verschiedene Datenbanken. Ich finde es toll, dass ich nicht auf eine bestimme Datenbank Engine festgelegt bin, sondern mir aussuchen kann, wo ich meine Daten speichere. Gerade bei SQL gibt es ja auch jede Menge Tools, um den Datenabfall extern aufzubereiten, also externe Berichterstellung. Dafür bietet openHAB nur sehr eingeschränkte Möglichkeiten, und im Grunde gibt es dafür auch genügend Software, die darauf spezialisiert ist.

            Was das Backup betrifft, muss man halt dafür sorgen, dass die Datenbank mit gesichert wird. Im Fall von db4o und rrd4j passiert das automatisch, weil die Datenbank im userdata Verzeichnis liegt, wenn man "externe" Datenbanken nutzt, muss man dann die entsprechenden Pfade mit einbeziehen (ein Datenbankbackup macht man aber auch besser mit spezialisierten Tools wie z.B. rdiff-backup.

            Ich habe hier einen Mischbetrieb von Astro-gestützten Schaltereignissen und solchen, die rein zeitgesteuert sind. Da ich aber ohnehin der Einzige bin, der hier Einstellungen vornimmt (meine Frau sagt mir, was sie will und die Kinder haben noch nichts zu melden ) mache ich das tatsächlich ganz gerne über die Rules, weil ich dort maximale Freiheit habe, z.B.:
            Fahre die Rollläden um 8:31 Uhr in Beschattung, aber nur von April bis September, und nur, falls die Wettervorhersage mehr als 24°C für den aktuellen Tag ankündigt. Könnte man die Zeitschaltuhr noch relativ leicht um ein Monatsfeld ergänzen, wird es mit Bedingungen, die zusätzlich erfüllt sein müssen schon extrem aufwändig.
            Das Haus soll halt simple Entscheidungen selbst fällen.
            Unsere Rollläden fahren zu bestimmten Zeiten auf und zu, das geht zum einen über die Zeit und den Wochentag (zusätzlich zum Sonnenstand), zum anderen werden aber auch Feiertage berücksichtigt, ebenso wie die Schulferien. Da es leider bisher koch kein entsprechendes Binding gibt, muss ich die Ferientermine noch von Hand einpflegen (ein Script ähnlich dem für Feiertage) aber da wird schon noch was kommen...

            Kommentar


              #7
              Danke udo1toni
              --
              Gruß
              Lothar

              Kommentar

              Lädt...
              X