Ankündigung

Einklappen
Keine Ankündigung bisher.

Openhab: Performance bei Rules

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

    Openhab: Performance bei Rules

    Moin.

    Ich habe gerade ein Problem mit der Performance von Rules. Vorab: Openhab läuft bei mir auf einem Raspberyy Pi 2 und diese Tweaks habe ich bereits durchgeführt: https://github.com/openhab/openhab/wiki/Hardware-FAQ

    Ich möchte LEDs mittels DMX relativ schnell Dimmen, sodass ich unter anderem einen schönen On/Off-Fade hinbekomme. Dazu habe ich mir eine Rule erstellt, mit der ich das testen möchte. Leider finde ich die Zeit, die Openhab für bestimmte Dinge benötigt, sehr hoch.

    Beispiel:
    Code:
            while(actualState < 100) {
                actualState = actualState + 1
                logInfo("bla", now.toString())
            }
    Zwischen den einzelnen Durchgängen liegen 5-6 Millisekunden.

    Code:
            while(actualState < 100) {
                actualState = actualState + 1
                Thread::sleep(1)
                logInfo("bla", now.toString())
            }
    Zwischen den einzelnen Durchgängen liegen 7-8 Millisekunden.

    Code:
            while(actualState < 100) {
                actualState = actualState + 1
                sendCommand(Licht_W, actualState)
                Thread::sleep(1)
                logInfo("bla", now.toString())
            }
    Zwischen den einzelnen Durchgängen liegen 11-12 Millisekunden.

    Jede Aktion verlängert den Durchlauf relativ stark. Mit Timern sieht es übrigens sehr änlich aus. Eigentlich würde ich gerne eine relativ komplexe Logik in meine Rule schreiben. Ich vermute aber, dass ich dann am Ende bei 50-100 ms pro Durchgang liege. Wenn ich einen schönen Dimmer haben möchte, darf die Zeit aber bei maximal 5-10 ms liegen. Hat jemand vielleicht eine Idee, was ich hier machen könnte? Ich bin momentan ziemlich ratlos.

    Gruß,
    Pasqual

    #2
    Wau. 100 State-Änderungen auf den Eventbus zu schmeißen ist schon ne Hausnummer. Jedes Holpern im Threading wird man als "Ruckler" sehen können. Warum nimmst du nicht Olad, bzw. das DMX-Plugin ? Ich hab einfach entsprechende Fades konfiguriert und erfreu mich sanftes Ein- und Ausfaden ohne CPU-Last...

    Gruß
    Christoph

    Kommentar


      #3
      Hmmmm, ich verstehe nicht so recht, was du meinst... Ich schicke keine einzige State-Änderung auf den Event-Bus (falls du den KNX-Bus meinst). Ich nutze sehr wohl das DMX-Plugin mittels ArtNet.
      Was ist Olad? Und kannst du mir genau erklären, wie du dimmst? Vielleicht mache ich ja auch nur irgendwas falsch.

      Kommentar


        #4
        Also wenn du bereits das DMX Plugin nutzt, dann kannst du doch in der item-Konfig angeben, wie er bei einem ON bzw. OFF faden soll. Wenn ich mich recht erinnere, gibt man jeweils die Start- und Ziel-Werte für mehrere DMX-Adressen an und wieviele ms das ganze dauern soll. Ergebnis ist ein schöner Übergang wenn man von OFF auf ON schaltet und umgekehrt. Funktioniert bei mir per Artnet perfekt.
        Olad ist nur der Server, der bei mir Artnet auf richtigem DMX umsetzt.

        Kommentar


          #5
          Und ganz vergessen...

          Mit Event-Bus meinte ich den Openhab-Event-Bus. Der scheint zwar recht flott implementiert, aber ich glaube nicht, dass der für so viele Events ausgelegt ist.

          Kommentar


            #6
            Hmmm... Mit dem Openhab-Event-Bus magst du Recht haben. Das Fading über die Konfig wollte ich eigentlich nicht machen, da mir ein komplexeres Regelwerk vorschwebt.
            Beispiel: Wenn ich einen Dimm-Wert mittels Dimm-Funktion eingestellt habe, dann soll dieser nach einem Aus- und Anschaltvorgang wieder eingestellt werden. Beim Fade über das Item kann ich nur einen Festen Wert bestimmen, welcher beim Einschalten wiederhergestellt wird. Bei weißen Lichtern würde ich das vielleicht noch akzeptieren, nicht aber bei RGB-Werten. Deswegen brauche ich eigentlich ein komplexes Regelwerk. Und deswegen suche ich nach einer Möglichkeit, das Ganze zu beschleunigen.

            Nebenfrage: Was genau macht denn der Olad eigentlich?

            Kommentar


              #7
              Du kannst doch die ganzen (Zwischen)Werte erst einmal alle berechnen und in einem Array ablegen. Danach beginnst du mit dem Fading, da musst du dann nur noch die einzelnen Werte verschicken. Die Zeit dafür ist klein und vor allem konstant.

              Kommentar


                #8
                Hmmm... die Werteberechnung ist nicht das Problem. Ich erhöhe ja in meinem Beispiel nur jeweils um 1 und trotzdem habe ich schon relativ hohe Zeiten. Ich führe ja keine komplexen Berechnungen durch.

                Kommentar


                  #9
                  Ich dachte du suchst einen Weg alle 5-10ms einen Wert an den Dimmer schicken zu können. Den habe ich beschrieben. Falls das nicht dein Problem ist, dann solltest du vermutlich noch einmal beschreiben was genau eigentlich das Problem das es zu lösen gilt

                  Kommentar


                    #10
                    Ja, im Prinzip ist es das, was ich suche... Aber entweder ich verstehe nicht so recht, was du meinst, oder ich glaube nicht, dass es so funktioniert.

                    Wenn ich dich richtig verstehe, dann sagst du, es wäre wesentlich schneller, Daten aus einem Array abzurufen, als zu berechnen "actualState = actualState + 1". Mehr berechne ich ja im obrigen Beispiel gar nicht. Ich kann mir nicht vorstellen, dass die Array-Methode wesentlich schneller ist... Oder verstehe ich es falsch?

                    Kommentar


                      #11
                      Natürlich ist Daten aus einem Array abrufen nicht schneller als "actualState = actualState + 1". Beides wird auf ähnlichem Niveau liegen (5ms pro Wert). Du hast oben aber geschrieben:

                      Zitat von turboPasqual Beitrag anzeigen
                      Eigentlich würde ich gerne eine relativ komplexe Logik in meine Rule schreiben. Ich vermute aber, dass ich dann am Ende bei 50-100 ms pro Durchgang liege.
                      Heißt: On the fly berechnen 50-100ms pro Wert, Lookup aus dem Array bleibt konstant bei 5ms pro Wert. Natürlich musst du das Array vorher befüllen, das wird genauso lange dauern wie die on the fly Berechnung, die Zeit dafür ist aber egal, da man die ja nicht sieht. Dir geht es ja nur darum, dass der Fade perfekt ist, also alle 5ms ein neuer Wert beim Dimmer ankommt. Korrekt?

                      Kommentar


                        #12
                        Hmmm.... Könnte grundsätzlich funktionieren. Ich werde am WE noch mal etwas mit der Idee spielen. Ich habe nur dir Befürchtung, dass das vielleicht nur mit einer oder 2 Rules funktioniert. Sobald aber ein paar mehr (gleichzeitig) laufen, komme ich vermutlich wieder in Zeitprobleme. Aber ich werde es mal testen.

                        Ich denke gerade schon darüber nach, ob ich mir das DMX-Bindung anpasse. Aber das ist dann schon viel Arbeit, die ich mir eigentlich sparen möchte.

                        Kommentar

                        Lädt...
                        X