Ankündigung

Einklappen
Keine Ankündigung bisher.

Anwesenheitssimulation Logik

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

    Anwesenheitssimulation Logik

    Hallo zusammen,

    ich habe derzeit eine einfache Anwesendheitssimulation, die zu bestimmten Zeiten mehr als rudimentär einige Lichter mit Timer schaltet.
    Dies wollte ich nun optimieren, indem ich die Ereignisse vergangener Tage "abspule"

    Meine derzeitige Regel lautet (Als Ausschnitt)
    Code:
    rule PresenceSimulator
    when
     Time cron "0 31 22 ? * MON" or
     Time cron "0 34 22 ? * TUE" or
     Time cron "0 02 23 ? * WED" or
     Time cron "0 17 22 ? * THU" or
     Time cron "0 58 22 ? * FRI" or
     Time cron "0 27 23 ? * SAT" or
     Time cron "0 09 22 ? * SUN"
    then
     if (Absence.state == ON){
      var int Wochentag = now.getDayOfWeek
      pushNotification("Info", "Anwesenheitssimulation Tag: " + Wochentag)
      switch (Wochentag) {
       case (1): {
        pushNotification("Info", "Monday Anwesenheitssimulation !!")
    
        Lampe_OG.sendCommand(ON)
        timer1 = createTimer(now.plusSeconds(24)) [|
         Steckd_EG_Flur.sendCommand(OFF)
         Lampe_EG_Deko.sendCommand(OFF)
         timer2 = createTimer(now.plusSeconds(17)) [|
          Lampe_OG.sendCommand(OFF)
         ]
         Lampe_Haustuere.sendCommand(OFF)
        ]
       }
       case (2): {
        pushNotification("Info", "Tuesday Anwesenheitssimulation !!")
        ........
    Dies funktioniert, finde ich aber umständlich.

    Frage: Wie bekomme ich denn in einer Rule hin, dass zu bestimmten Zeiten die unterschiedlichen Aktionen gefahren werden.

    z.B.
    Code:
    rule PresenceSimulator
    when
    Absence.state == ON
    then
      var int Wochentag = now.getDayOfWeek
      pushNotification("Info", "Anwesenheitssimulation Tag: " + Wochentag)
      switch (Wochentag) {
       case (1): {
        pushNotification("Info", "Monday Anwesenheitssimulation !!")
    
       IF timeCron (xyz) then  Lampe_OG.sendCommand(ON)
       If timeCron(dfv) then Steckd_EG_Flur.sendCommand(OFF)
       If timeCron(dfv) then Lampe_OG.sendCommand(OFF)
    
    usw
    
       case (2): {
        pushNotification("Info", "Tuesday Anwesenheitssimulation !!")
        ........
    Aber, dass geht so natürlich nicht :-(

    VG
    Jörg

    #2
    Rules brauchen einen Trigger, da führt kein Weg vorbei. Ein Ansatz wäre, die Rule immer zur gleichen Zeit zu triggern, dann aber wochentagsabhängig einen Timer zu starten, der die eigentlichen Schaltungen entsprechend verzögert, also z.B. so:
    Code:
    rule "Präsenz Simulation"
    when
        Time cron "0 0 22 * * ?"
    then
        if(Absence.state == ON) {
        switch(now.getDayOfWeek) {
            case 1: {
               timer0 = createTimer(now.plusMinutes(31),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(24),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
            case 2:{
               timer0 = createTimer(now.plusMinutes(34),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(29),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
            case 3:{
               timer0 = createTimer(now.plusMinutes(62),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(27),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
            case 4:{
               timer0 = createTimer(now.plusMinutes(17),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(31),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
            case 5:{
               timer0 = createTimer(now.plusMinutes(58),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(39),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
            case 6:{
               timer0 = createTimer(now.plusMinutes(87),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(48),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
            case 7:{
               timer0 = createTimer(now.plusMinutes(9),[|
                   item1.sendCommand(ON)
                   timer1 = createTimer(now.plusSeconds(32),[|
                       item1.sendCommand(OFF)
                   ])
               ])
            }
        }
    }
    end
    Aber das ist natürlich genauso wenig elegant.

    Wesentlich eleganter ist dieser Ansatz: https://community.openhab.org/t/anti...mulation/22129
    (Code vom Link kopiert)
    Code:
    rule "Periodically check auto lights"
    when
        Time cron "0 */10 * * * ?"
    then
        logInfo("LightsAuto", "Auto Light Check")
        // If nobody is home and lights away mode is auto or if mode is on
        if( (Presence.state == OFF && Lights_away_auto.state == "Auto" ) || (Lights_away_auto.state == "On") ){
            gLights_auto.members.forEach[lamp|
                lamp.sendCommand(lamp.historicState(now.minusDays(7)).state)
            ]
        }
    end
    Die Rule wird alle 10 Minuten aufgerufen, dann wird, falls Abwesenheit aktiv ist, für eine Gruppe Items, die automatisch geschaltet werden sollen, nachgeschaut, welchen Status sie vor einer Woche hatten, dieser wird dann wiederhergestellt. Voraussetzung ist, dass diese Items persistiert werden, natürlich mit einem Persistence Service, der sowohl Number als auch Switch verarbeiten kann.
    Natürlich kann man darüber nachdenken, die Rule eher jede Minute aufzurufen, um auch kurze Schaltänderungen zu simulieren. Außerdem könnte man noch eine gewisse Zufälligkeit mit einbauen, also sowas wie
    Code:
    var Integer RandomInterval = ((Math::random() * 61).doubleValue).intValue
    als Zufallsgenerator, und das dann zusätzlich zum Schaltzeitpunkt dazu rechnen, entweder per createTimer, oder indem man es im historicState verwendet. Dann ginge das Licht nicht immer zur vollen Minute an oder aus.

    Kommentar


      #3
      Zitat von udo1toni Beitrag anzeigen
      Wesentlich eleganter ist dieser Ansatz: https://community.openhab.org/t/anti...mulation/22129
      Da stimmt wohl <= Was alles mit guten Programmierkenntnissen machbar ist

      Zitat von udo1toni Beitrag anzeigen
      Voraussetzung ist, dass diese Items persistiert werden, natürlich mit einem Persistence Service, der sowohl Number als auch Switch verarbeiten kann.
      Bevor ich an die Kür gehe und Deinen Erweiterungvorschlag einbaue, müsste ich natürlich persistieren. Hast Du denn noch einen Tipp, wie ich bei Varianten persistiere?? Derzeit nutze ich die ja nur für den letzten Status, zum wiederherstellen nach einem Reboot.

      VG
      Jörg

      Kommentar


        #4
        Ich habe ja eine MapDB zum persistieren des letzten Status. Kann ich diese evtl. auch nutzen um die letzten 14 Tage zu sichern?? Es braucht ja nicht Wochen zurück gehen
        Und wie könnte ich mir den Inhalte der MapDB anzeigen lassen

        Kommentar


          #5
          Nein, MapDB speichert per Definition exakt den letzten Zustand.

          Kommentar


            #6
            Zitat von udo1toni Beitrag anzeigen
            Nein, MapDB speichert per Definition exakt den letzten Zustand.
            Mist

            Dann werde ich mal schauen, ob es eine Anleitung zur Installation von influxdb für Windows gibt. Derzeit habe ich nur was für dieses Linux gefunden

            VG
            Jörg

            Kommentar


              #7
              influxdb: aktuell https://dl.influxdata.com/influxdb/r...dows_amd64.zip runterladen und installieren... zu finden direkt bei https://www.influxdata.com/
              Du kannst auch SQLite für Windows installieren, das sollte mit openHAB auch zusammen spielen.

              Kommentar


                #8
                Zitat von udo1toni Beitrag anzeigen
                influxdb: aktuell https://dl.influxdata.com/influxdb/r...dows_amd64.zip runterladen und installieren... zu finden direkt bei https://www.influxdata.com/
                Du kannst auch SQLite für Windows installieren, das sollte mit openHAB auch zusammen spielen.
                Die Anleitungen sind leider alle für Linux und ich habe immer noch Probleme, dies unter Windows zu installieren :-/
                Ist denn SQLite gesichert oder nur eine Vermutung??

                LG
                Joerg

                Kommentar


                  #9
                  influxdb wird unter windows nicht "installiert". Du lädst die Datei runter, packst sie in ein Verzeichnis aus und startest influxd.exe. Anschließend kannst Du Dich mit dem Start von influx.exe mit der Datenbank verbinden, um User und Datenbanken anzulegen. Die Anleitungen der Linux-Installation kannst Du quasi eins zu eins verwenden.

                  Alternativ sqlite: http://johnatten.com/2014/12/07/inst...te-on-windows/ ist zwar in englisch, sollte aber grundsätzlich verständlich geschrieben sein.

                  Kommentar


                    #10
                    So,
                    leere DB ist mit SQlite erstellt, da FluxDB wohl nur unter 64bit läuft.
                    Den Code habe ich schon angefangen einzubauen, nun kommt das persistieren :-/
                    Muss ich die DB noch irgendwo bekannt geben, oder reicht es eine .persist anzulegen??

                    VG Joerg

                    Kommentar


                      #11
                      Du musst den jeweiligen Persistence Service konfigurieren, im Fall von SQLite eben JDBC. Siehe hier: http://docs.openhab.org/addons/persi...bc/readme.html
                      Achte besonders auf http://docs.openhab.org/addons/persi...-configuration, sprich, in der jdbc.cfg müssen nicht alle Einstellungen getätigt werden, es reicht, die Verbindung zu SQLite einzutragen, damit openHAB den Zugriff auf die Datenbank erhält.

                      Falls noch keine Datenbank vorhanden ist, wird openHAB diese automatisch erstellen. Dazu muss der verwendete Datenbank-User natürlich berechtigt sein.

                      Zum eigentlichen persistieren brauchst Du dann noch die jdbc.persist mit den passenden Einträgen, aber auch das ist in der Doku eigentlich gut beschrieben.

                      Kommentar


                        #12
                        Zitat von udo1toni Beitrag anzeigen
                        Dazu muss der verwendete Datenbank-User natürlich berechtigt sein.
                        SQlite kennt doch gar kein User/Passwort Konzept??

                        Kommentar


                          #13
                          So, Dank udo1toni habe ich nun den Service installiert, konfiguriert und up and running

                          Aber: Es geht natürlich noch nicht :-(

                          Ich habe folgende Items angelegt
                          Code:
                          Switch Lampe_EG_Deko_Wand  "Schrankleuchten"     (EG_Wohnen, EG_Essen, Lampen) { knx="5/5/1" }
                          Switch Lampe_EG_Deko_Decke  "Deckenspots"      (gLights_auto, EG_Wohnen, EG_Essen, Lampen) { knx="5/5/2" }
                          In der jdbc.persist habe ich diese wie folgt persistiert
                          Code:
                          Strategies {
                           everyHour  : "0 0 * * * ?"
                           everyDay  : "0 0 0 * * ?"
                          
                           // if no strategy is specified for an item entry below, the default list will be used
                           default = everyChange
                          }
                          
                          Items {
                           Lampe_EG_Deko_Wand : strategy = everyChange,restoreOnStartup
                           Lampe_EG_Deko_Decke : strategy = everyChange,restoreOnStartup
                          }
                          Nachdem die Items geändert wurden, hat sich die DB auch gefüllt.

                          Ich habe den Code noch ein wenig abgestripped um erst einmal zu testen
                          Code:
                          rule "Presence Simulator"
                          when
                            Time cron "0 */5 * * * ?"
                          then
                            println("-> Auto Light Check <-")
                            logInfo("LightsAuto", "Auto Light Check")
                            if (Absence.state == ON) {
                              gLights_auto.members.forEach[lamp|
                              lamp.sendCommand(lamp.historicState(now.minusDays(7)).state)
                            ]
                           }
                          end
                          Absence ist ON und im Log erscheint die Info => OK Rule wird abgearbeitet
                          Aber es gibt auch einen Fehler:
                          Code:
                          19:45:00.008 [ERROR] [ntime.internal.engine.ExecuteRuleJob] - Error during the execution of rule Presence Simulator: An error occurred during the script execution: The name 'gLights_auto' cannot be resolved to an item or type.
                          Ich vermute mal, ich muss noch ein Group Item anlegen?? Kann ich in diesem dann Dimmer und Switche mischen, oder benötigt dies 2 Items??

                          VG
                          Jörg

                          Kommentar


                            #14
                            Im items-Auszug sehe ich keine Gruppe gLights_auto, nur, dass Du Bezug darauf nimmst. Gruppen müssen aber definiert werden wie jedes andere Item auch:
                            Code:
                            Group:Switch gLights_auto
                            Dann reicht in der jdbc.persist auch ein
                            Code:
                            Items {
                                gLights_auto* : strategy = everyChange,restoreOnStartup
                            }
                            um alle Member der Gruppe gLights_auto - aber nicht das Gruppenitem selbst(!) - zu persistieren.
                            Wichtig ist, den Itemtyp mit anzugeben, sonst kann die Gruppe nicht als Trigger verwendet werden.
                            Zur Gruppe gehörende Dimmer Items werden von der Gruppe selbst natürlich nur as ON/OFF betrachtet, auf den persistierten Zustand hat das aber keinen Einfluss, auch wenn man nur die Gruppe mit * im persist-file angibt.

                            Unter OH2 wird der Befehl println vermutlich nicht funktionieren, jedenfalls wurde das im englischen Forum erwähnt.

                            Kommentar


                              #15
                              Zitat von udo1toni Beitrag anzeigen
                              Unter OH2 wird der Befehl println vermutlich nicht funktionieren, jedenfalls wurde das im englischen Forum erwähnt.
                              Bei mir funktioniert dies bisher, Häher nutze ich dies gerne bei der Implemenitierung neuer Funktionen ;-) vor allem, weil der Eintrag in weiß (alles andere eher grau) dargestellt ist. So fällt der direkt auf.

                              Werde mich dann mal dran geben, das Group Item anzulegen.

                              Kommentar

                              Lädt...
                              X