Ankündigung

Einklappen
Keine Ankündigung bisher.

Umfrage zur Nutzung der time-series Datenbank InfluxDB

Einklappen
Das ist ein wichtiges Thema.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    Klempner?
    Countermode?

    Kommentar


      #17
      Ich fänds genial, wenn's in das database Plugin implementiert werden könnte. Teste gerne.

      Kommentar


        #18
        Countermode = Der Graph kann mit Zählern umgehen. Beispiel: Stromzähler, steigende Werte. Graph macht daraus zum Beispiel einen schönen Verbrauch pro Tag. Bei RRD steht: COUNTER is for continuous incrementing counters like the ifInOctets counter in a router. The COUNTER data source assumes that the counter never decreases, except when a counter overflows. The update function takes the overflow into account. The counter is stored as a per-second rate. Der Klempner kommt mit so einer einfachen HTML Seite, wie drraw.pl sie erzeugen konnte prima klar, um sich mal die Parameter des Kessels anzuschauen
        Die influxdb habe ich ihm noch nicht zugetraut. Ich vermute, es gibt auch einen "simple view"...
        Derzeit zwischen Kistenauspacken und Garten anlegen.
        Baublog im Profil.

        Kommentar


          #19
          Das wird nicht ganz so einfach sein denn RDD bezieht sich IMHO auf normierte Zeiteinheiten, das Datenbankplugin aber schreibt die Daten dann wenn sie kommen in die Datenbank rein.
          Es müßte als zunächst eine Abfrage alle Datensätze für den in Frage kommenden Zeitraum abrufen, dann müssen die Werte in Zeitabschnitte aufgeteilt werden. Dabei wird sicher selten der Zeitpunkt eines Datensatzes mit dem Zeitabschnitt überein passen.
          Die Frage wäre, wo diese Funktionalität eingebaut werden sollte, ins Datenbank Plugin oder ins Websocket plugin?

          Kommentar


            #20
            Zitat von bmx Beitrag anzeigen
            Die Frage wäre, wo diese Funktionalität eingebaut werden sollte, ins Datenbank Plugin oder ins Websocket plugin?
            Eindeutig ins Database. Websocket reicht ja einfach die Anfrage per item.series() an das Database-Plugin weiter.

            Ich würde auch nicht versuchen, Influx im (SQL-basierten) Database-Plugin zu integrieren. Die Technologien sind einfach zu verschieden.
            Aber es sollte ein einziges Influx-Plugin sein, welches dann auch item.series() implementiert und damit ohne weitere Anpassungen an Websocket oder Visu für die Visu genutzt werden kann.

            Kommentar


              #21
              influx kann Countermode, insofern bin ich einfach pro Influx
              Derzeit zwischen Kistenauspacken und Garten anlegen.
              Baublog im Profil.

              Kommentar


                #22
                Ich habe mir die drei Plugins mal angeschaut und in den Readmes einen wichtigen Hinweis gefunden:

                Bei influxdata steht:
                Thanks to SgtSeppel for the initial plugin which can be found here: https://github.com/SgtSeppel/influxdb I'd choose to implement UDP over the initial implementation because I run my InfluxData server in the cloud over VPN. This setup has some latency and the original plugin blocked my whole smarthome.py including logics not executed.
                Und bei influxdb:
                This started as a fork of the plugin influxdata with the following enhancements:
                • proper naming
                • specify a name for the measurement instead of falling back to the item's ID
                • specify additional tags or fields globally (plugin.yaml) and/or on per-item basis

                The special smarthomeNG attributes caller, source and dest are always logged as tags.
                Anscheinend gab es also eine Evolution und das influxdb aus dem SmartHomeNG-Repo ist das am weitesten entwickelte. Eine kurze Analyse des Codes bestätigt dies auch.
                Meines Erachtens könnte also influxdata entfernt werden, Benutzer davon können ohne Änderungen auf influxdb umsteigen. Einzig die plugin.yaml muss natürlich angepasst werden (neben dem class_name und class_path muss aus den Parametern influx_host und influx_port das 'influx_' entfernt werden).

                Die ursprüngliche Version von SgtSeppel nutzt HTTP durch den InfluxDB Python Client. Wenn ich mich nicht irre ist aber der geloggte Inhalt ebenfalls kompatibel mit den anderen beiden.


                Nun zu der teilweise bereits diskutierten Weiterentwicklung:
                1. Eine Implementierung von HTTP fände ich sinnvoll.
                  Per Parameter könnte eingestellt werden, dass auch Itemdaten per HTTP geschrieben werden. Damit könnte das Plugin von SgtSeppel ebenfalls vollständig abgelöst werden. HTTP ist von der Performance her zwar minim schlechter, dafür funktioniert es in der Standardinstallation und ist bei Remote-Datenbanken allenfalls einfacher.
                  heckmannju magst du deinen Code teilen?
                  .
                2. Für die Performance wäre es sicher besser, wenn nicht für jeden Schreibvorgang ein neuer Socket geöffnet, sondern dieser offen gehalten (und nach einem Verbindungsverlust wieder geöffnet) wird. So macht es meines Wissens auch das database-Plugin.
                  War ein Irrtum - es geht ja um UDP, da gibt es keine Connection. Aber das Socket-Objekt könnte allenfalls behalten werden, damit der Garbage Collector weniger zu tun hat.
                  .
                3. Dann würde ich wie erwähnt versuchen item.series() zu implementieren, damit die Influx-Daten auch per Visu-Websocket abgefragt werden können.
                  .
                4. Unterstützung für Strings zulassen. Influx unterstützt dies entgegen den Gerüchten hier im Forum grundsätzlich. Strings müssen aber korrekt escaped werden und wenn ich das hier richtig verstehe, müssen sie in ein separates Value-Feld.
                  .
                5. Alle drei Plugins kennen einen Parameter influx_keyword in der plugin.yaml, über welchen man das Keyword zur Aktivierung in Items übersteuern kann.
                  Das ist zwar praktisch, weil man so ohne Anpassung der Items z.B. vom sqlite oder database-Plugin zu Influx wechseln kann. ich bin mir aber nicht sicher, ob das wirklich sinnvoll und vom Core-Team so erwünscht ist. IMHO sollten die Namen der Item-Attribute möglichst eindeutig einem Plugin zugeordnet werden können.

                Also lange Rede kurzer Sinn:
                Ich würde influxdata entfernen und influxdb weiterentwickeln und dabei in erster Priorität HTTP implementieren, damit auch das Plugin von SgtSeppel abgelöst werden kann.
                Zuletzt geändert von smai; 08.08.2018, 09:41. Grund: Punkt 2 gestrichen, Punkt 4 eingefügt

                Kommentar


                  #23
                  Hallo smai , vielen Dank für die ausführliche Analyse. Den Punkt 5 muss ich mir mal näher anschauen. Das klingt erstmal nach einer Systematik die ich so nicht gut finde.
                  Viele Grüße
                  Martin

                  There is no cloud. It's only someone else's computer.

                  Kommentar


                    #24
                    Kurze Info von mir: ich bin derzeit auch auf http angewiesen, da die Docker Images die ich ausprobiert habe, UDP nicht von Haus aus aktiviert hatten... Aus meiner Sicht auch der sinnvollere Weg!

                    Kommentar


                      #25
                      Beim influxdb gibts wohl Problemebei ner verlorenen Verbindung. Außerdem ein Problem mit Leerzeichen beim Caller. Siehe https://knx-user-forum.de/forum/supp...50#post1248550

                      Kommentar


                        #26
                        Das mit der Verbindung würde mich sehr überraschen. Jedes Pakete wird per UDP über einen neuen Socket gesendet, ohne eine Verbindung offen zu halten.
                        Es kann höchstens sein, dass sich irgendwie das ganze Plugin aufhängt.

                        Das mit dem Leerzeichen hingegen macht Sinn. In der Doku habe ich gelesen, dass diese und ein paar anderen Zeichen mit \ escaped werden müssen.

                        Kommentar


                          #27
                          Hallo,

                          @smai: ich teile deine Analyse.
                          HTTP würde ich aufgrund Docker auch bevorzugen.

                          Gruß,
                          Hendrik

                          Kommentar


                            #28
                            Ich bin mit den Erweiterungen gut vorangekommen. Diese umfassen:
                            1. Konfigurierbar Schreiben per HTTP inkl. Buffering, um die Transfers zu reduzieren.
                            2. Wiederverwenden des Sockets.
                            3. Implementieren von item.series() und item.single().
                            4. Unterstützung für Strings.
                            5. Korrektes Escape von Leerzeichen, Komma und = (das sind alle zu escapenden Zeichen).
                            Einige Details sind noch offen und ich muss noch ausführlich testen, aber ich bin zuversichtlich, dass dies alles gelingt.


                            Wünschbar wäre wohl noch die Möglichkei für Multiinstanz.
                            Zuletzt geändert von smai; 11.08.2018, 23:35.

                            Kommentar


                              #29
                              smai spricht noch etwas gegen einen Pull Request ?

                              Kommentar


                                #30
                                Ich ktiege es nicht hin, dass ich annähernd dieselben aggregierten Werte kriege wie im database-Plugin.
                                Unterdessen bin ich mir aber auch nicht mehr so sicher, ob ich das überhaupt will bzw. die Werte im db-Plugin zwingend sinnvoll sind.
                                Ich werde den Code wohl in Kürze mal zeigen, damit andere prüfen, ob das Ergebnis brauchbar ist.

                                Kommentar

                                Lädt...
                                X