Ankündigung

Einklappen
Keine Ankündigung bisher.

BUS-Kommunikation in Datenbank (Neo4j / MongoDB) ablegen/schreiben

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

    BUS-Kommunikation in Datenbank (Neo4j / MongoDB) ablegen/schreiben

    Hallo zusammen,

    auch wenn das Jahr jetzt schon wieder "alt" ist, trotzdem nochmal ein FROHES NEUES an Alle und ..... viel Gesundheit!

    Vielleicht ist die Frage hier schon mal gestellt worden aber so richtig gefunden habe ich nichts dazu über die Suche.

    Ich möchte die gesamte Buskommunikation tracken und in einer DB ablegen. Als DB soll entweder eine Neo4j oder MongoDB genutzt werden. Diesbzgl. werde ich noch etwas testen, was sinnvoller ist. Tendenz geht zwar in Richtung MongoDB aber wie gesagt, noch nicht entschieden.
    Ich stelle mir eigentlich eine Komponente in Form eines "Listeners" vor, der am KNX-BUS hängt und die Kommunikation real-time mitliest und in die DB schreibt.

    Hat jemand schon mal etwas in der Art gemacht? Oder vielleicht eine Idee, mit welchen Komponenten so etwas umsetzbar wäre? Bin für alle Tipps dankbar.

    Ciao
    Der DJ


    Darf man fremden Leuten eigentlich Fragen stellen, nachdem sie im Bus telefoniert haben und einem noch etwas unklar ist?
    Projects: Sonos Gateway (Musterprojekt) - KNX-MonAMI - Nutzer-Profile

    #2
    Wofür willst dieses Protokoll dann benutzen, welche Daten sollen da gespeichert werden? Wenn es in realtime ist würde sich auch influxdb anbieten - dazu findet man Lösungen für jedes erdenkliche System hier.
    Zuletzt geändert von meti; 11.01.2021, 17:29.

    Kommentar


      #3
      Ich möchte einfach alle Daten speichern bzw. eigentlich handelt es sich bei den Daten ja um Befehle, unabhängig davon wie sie jetzt ausfallen.
      Die Daten sollen gespeichert werden und im Nachgang dann als "Pool" genutzt werden. influxdb kenne ich noch nicht, wenn ich mir die Infos kurz auf der Herstellerseite ansehe, dann könnte dies auch eine Alternative sein. Wichtig ist, dass die Speicherung schnell durchführbar ist, aber auch die Abfrage der gespeicherten Werte im Nachgang dann auch schnell und in real-time durchgeführt werden soll.

      Einzig nur, meine API besteht nicht nur aus "Sensor1 / Wert" sondern es müssen parallel zu den Daten noch eine ganze Reihe weiterer Parameter getrackt werden.

      Unabhängig davon geht es aktuell primär um die Möglichkeiten, die KNX-Daten vom BUS zu bekommen und sie zum Speichern an eine DB zu übergeben.
      Darf man fremden Leuten eigentlich Fragen stellen, nachdem sie im Bus telefoniert haben und einem noch etwas unklar ist?
      Projects: Sonos Gateway (Musterprojekt) - KNX-MonAMI - Nutzer-Profile

      Kommentar


        #4
        Ich habe mal einige Monate!! KNXD vbusmonitorX laufen gehabt und die Ausgabe einfach Shell Umleitung in eine Datei geleitet. Das ging ganz hervorragend. Die typischen Shell Befehle (z.B. grep) zum Auswerten auch von vielen Tausenden Datensätzen lief ohne Probleme. Insbesondere wenn du aktuell noch keine brauchbare Lösung hast, ist das eine schnelle Option die Daten schonmal zu sammeln und ggf. auch erst später in eine DB zu überführen.

        Was bitte ist real-time? Und wofür ist das wichtig?

        Kommentar


          #5
          tobiasr Ich habe mir überlegt, ob es nicht möglich wäre auf Basis von ML bzw. eigentlich wäre es AL (Active Learning) eine neue Art von SmartHome-Server aufzusetzen.
          Grundlage wären die bestehenden Daten, die erst einmal getrackt und klassifiziert würden und im Nachgang müsste die AL-Komponente dann "lernen" in welchen Situationen und Bedingungen das Haus wie zu steuern wäre. Natürlich über alle Gewerke wie Licht (Beleuchtungsszenen unterschiedlichster Art), Heizung, Jalousie, Lüftung, Klima usw. usw. Natürlich alles auf Tages-, Uhrzeit-, Jahreszeit-, Wetter-, Anwesenheits-Ebene usw.
          Auf deutsch gesagt, ein SmartHome mit KI / AI ausstatten. Sollte aus meiner Sicht kein Problem sein, ganz im Gegenteil sogar ... und sollte genauso bzw. sogar besser funktionieren als jeder Homeserver.

          Vorausgesetzt natürlich, man entwickelt ein entsprechendes Konzept und nutzt die entsprechenden Tools.
          Weitere Voraussetzung wäre, die Informationen, die gelesen werden bzw. ausgewertet werden müssen, werden in Echtzeit verarbeitet .... denn wenn irgendwo bsp. ein Präsenmelder oder Sensor oder was auch immer "anspringt", dann muss natürlich das Haus (sofort/unverzüglich) wissen:
          - es muss eine bestimmte Beleuchtungs-Szene aufrufen
          - oder es muss ggf. Musik anmachen
          - oder es muss ein Alarm erzeugen
          - oder einen Verbraucher steuern
          - oder, oder, oder


          Darf man fremden Leuten eigentlich Fragen stellen, nachdem sie im Bus telefoniert haben und einem noch etwas unklar ist?
          Projects: Sonos Gateway (Musterprojekt) - KNX-MonAMI - Nutzer-Profile

          Kommentar


            #6
            Wenn ich nochmal Echtzeit lese... Nehmen wir die kleinste Zeitbasis eines normalen PCs. Dieser ist idr. bis ca. 3GHz getacket. Heißt also der macht 3.000.0000.0000 Berechnungen je Sekunde. Echtzeit ist, wenn zwei Prozessoren mit den gleichen Daten hantieren und dabei in 1/3.000.000.000s die SELBE Information abzapfen. Das geht nicht. Und so schnell kann auch kein System (was nicht der super CPU nahe Speicher ist) auf Datenanfragen reagieren.

            Du möchtest also einfach nur, dass die Daten ohne für einen Menschen merkbare Verögerungen (wir reden hier von etwa unter ca. 80ms) ankommen? Also ist dir obendrein das logging in diesem Kontext egal. Dafür sieh dir die ETS Tunneling Standards an und öffne einen Socket auf den KNXD oder normalen IP Router. In der Programmiersprache deiner Wahl. Sinnigerweise C oder C++, denn alles andere ist viel zu langsam für "Echtzeit".

            Um ehrlich zu sein, frage ich mich wie jemand, der nicht mal die Basic schafft (Doku der KNX Schnittstelle lesen), komplexe Datenbanken und dann künstliche Intelligenz Logiken entwerfen will. Das schaffen selbst große Unternehmen noch nicht mit vertretbarem Aufwand.

            Selbst wenn du die Datenbasis aus dem KNX hast, die alle AUTOMATISCH zu verknüpfen ist ein riesen Komplex und müsste insbesondere in der Anfangsphase stark händisch beeinflusst werden. Du benötigst imho mindestens einen komplette Jahresdurchlauf um halbwegs verwertbare Dinge zu bekommen. Zudem reichen KNX Daten nicht. Bewegungsprofile (bin ich Einkaufen, Arbeiten, etc.), habe ich Besuch, bin überhaupt "ich" zuhause, etc. muss alles Berücksichtigt werden. Ich fürchte wenn ich arbeiten gehe und habe Besuch, der dreht durch, wenn die Wohnung alles nach meinen Bedürfnissen versucht automatisch zu regeln.

            Das Leben hat soviele unvorhersehbare Eigenschaften, spätestens wenn man nicht alleine lebt. Wer bewegt sich, wohin, was hat er vor?

            Was du da bisher aufgezählt hast, sind noch relativ simple normale Szenenabläufe. Dafür brauche ich keine KI.

            Kommentar


              #7
              Du solltest Dich nicht so an den Definitionen der Begriffe festklammern. Es ist auch OK, wenn Du es "ohne merkbare Verzögerung" nennst. Sorry, wenn ich Begriffe genutzt habe, die eher zur Verwirrung beigetragen haben.
              Zitat von tobiasr Beitrag anzeigen
              Dafür sieh dir die ETS Tunneling Standards an und öffne einen Socket auf den KNXD oder normalen IP Router.
              Werde ich machen, zumindest schon mal besten Dank für die Info.

              Zitat von tobiasr Beitrag anzeigen
              Um ehrlich zu sein, frage ich mich wie jemand, der nicht mal die Basic schafft (Doku der KNX Schnittstelle lesen), komplexe Datenbanken und dann künstliche Intelligenz Logiken entwerfen will. Das schaffen selbst große Unternehmen noch nicht mit vertretbarem Aufwand.
              Die Frage ist berechtigt ... Antwort ist: Aktuell keine Zeit gehabt ... und um das Thema komplexe Datenbanken und Logiken mache ich mir keinen Kopf, das bekomme ich hin! Soll nicht heißen, dass es einfach wird, aber machbar! Das Problem ist eher zeitlicher Art (zuviele andere Projekte!).

              Zitat von tobiasr Beitrag anzeigen
              Selbst wenn du die Datenbasis aus .....
              Das geht schon in die Richtung, vor allem im Bereich der Profile aber trotzdem schon ein wenig zu kompliziert gedacht.
              Es ist aber klar, dass auch manuell eingegriffen werden muss an der ein oder anderen Stelle, ist aber auch gewollt, dies zu tun.

              Zitat von tobiasr Beitrag anzeigen
              Das Leben hat soviele unvorhersehbare Eigenschaften, spätestens wenn man nicht alleine lebt. Wer bewegt sich, wohin, was hat er vor?
              Das glaubt man nur, wenn man sich noch nicht mit derartigen Profilen und den daraus entstehenden bzw. notwendigen Daten beschäftigt hat. Es wird immer viel zu kompliziert gesehen, vor allem viele Techniker haben diese Sichtweise. Bin selber Techniker, kann ein Lied davon singen: Immer erst die Probleme sehen und darstellen, warum irgendetwas nicht geht. Die Lösung wird selten gesehen!
              Jedoch sind viele Dinge sehr viel einfacher als man denkt, vor allem aber auch "technisch abbildbar".

              Zitat von tobiasr Beitrag anzeigen
              Dafür brauche ich keine KI.
              Ich habe auch nicht gesagt, dass man das braucht . Ich brauche auch kein Kurvenlicht im Auto, keinen Regensensor, kein automatisches Abblendlicht und Fernlicht. Ich habs aber trotzdem!
              Darf man fremden Leuten eigentlich Fragen stellen, nachdem sie im Bus telefoniert haben und einem noch etwas unklar ist?
              Projects: Sonos Gateway (Musterprojekt) - KNX-MonAMI - Nutzer-Profile

              Kommentar


                #8
                This is easily achievable with just a tiny bit of code.
                ​Just pick a scripting language, which has available libraries for KNX and your chosen database engine. My personal choice would be Python with xknx library.
                The script would be fairly simple:
                * Init knx library * Connect to KNX IP interface or router and set up for bus monitor mode
                * Repeat forever
                ** Receive KNX frame from bus
                ** Write KNX frame in the database

                You can deploy that pretty much anywhere (PC, high end linux based router, Raspberry Pi) because performance would not be an issue due to very low bandwidth of KNX bus.

                The big question is what are you going to do with that data. Data mining is generally the easy part. Transforming the data into something useful and making decisions based on it is where all the complexity lies.
                Zuletzt geändert von Jeecha; 12.01.2021, 00:52.

                Kommentar


                  #9
                  Ich würde die Logs entweder in eine Timestamp-basierte DB schreiben oder - um weniger Stress mit DB zu haben einfach per Logrotation in einen Logfile-Format deiner Wahl schreiben ... CSV, JSON, etc.

                  Ob du Python, bash oder sonst was nimmst spielt keine Rolle. So viel Buskommunikation, dass man da in Performanceprobleme läuft, hat man in einem EFH wahrscheinlich nie.

                  Kommentar


                    #10
                    Zitat von DJ.Picasso Beitrag anzeigen
                    Ich habe mir überlegt, ob es nicht möglich wäre auf Basis von ML bzw. eigentlich wäre es AL (Active Learning) eine neue Art von SmartHome-Server aufzusetzen...
                    Das steht auch auf meinem Plan für später im Jahr :-) Mein Vorgehen wäre, openHAB als Basis zu verwenden. Telegram-Aufzeichnung ist damit einfach, auch mit Daten aus anderen Welten. Aus den per machine learning gefundenen Dingen würde ich dann openHAB Regeln generieren.

                    Kommentar


                      #11
                      Zitat von cobrito Beitrag anzeigen
                      Mein Vorgehen wäre, openHAB als Basis zu verwenden.
                      Ich kenne openHAB jetzt nicht im Detail, ist schon etwas her bei mir. Hatte das mal evaluiert aber bin dann bei nodeRED hängen geblieben. Meiner Meinung nach hat sich MQTT als "generische" Middleware / Austauschschicht im Hausautomatisierungsbereich bewährt. Nahezu jedes Framework ist kompatibel und für jede erdenkliche Hardware gibt es ein MQTT Stack. Daher würde ich nicht auf ein proprietäres System aufbauen, sondern den gesamten Traffic in Richtung MQTT schieben. Dort kann man problemlos loggen und entwickeln (übrigens auch mit einem Adapter / Mock vom "virtuellen Haus"). Die Aufgabe des Algorithmus wäre es dann letztlich nur noch, zur richtigen Zeit die richtigen Steuerbefehle über MQTT zu senden. Eine echte "Logikfunktion" in Syntax ergibt sich hieraus eigentlich nicht, das wäre schon eher eine "Auto-Code-Generation" für openHAB. Das einzige, was dieses Framework dann an eine spezifische Installation bindet, ist ein Gateway, in deinem Fall dann KNX <=> MQTT. Ich komme natürlich aus meiner Welt, aber ich würde den knxd in nodeRED nutzen und dort entweder Log-Files schreiben oder eine DB nutzen. Auf Basis der Files kann man dann "trainieren" und das Modell als JS Funktion in einen nodeRED Block einbauen ... als Rapid-Prototyping Umgebung ... Produktiv müsste man überlegen, in welche Architektur man das ganze überführt, aber das ist Schritt 2.

                      Kommentar


                        #12
                        Home assistant hätte ein data science portal. Vielleicht könnte das etwas Arbeit abnehmen. https://data.home-assistant.io

                        Kommentar


                          #13
                          Zitat von tobiasr Beitrag anzeigen
                          Wenn ich nochmal Echtzeit lese... Nehmen wir die kleinste Zeitbasis eines normalen PCs. Dieser ist idr. bis ca. 3GHz getacket. Heißt also der macht 3.000.0000.0000 Berechnungen je Sekunde. Echtzeit ist, wenn zwei Prozessoren mit den gleichen Daten hantieren und dabei in 1/3.000.000.000s die SELBE Information abzapfen. Das geht nicht. Und so schnell kann auch kein System (was nicht der super CPU nahe Speicher ist) auf Datenanfragen reagieren.

                          Du möchtest also einfach nur, dass die Daten ohne für einen Menschen merkbare Verögerungen (wir reden hier von etwa unter ca. 80ms) ankommen?
                          Echtzeitanforderungen setzen "nur" die Einhaltung von garantierten (und das ist das Schwierige, zumindest bei harten Echtzeitbedingungen) Zeitobergrenzen voraus. Je nach Anwendungsfall können die auch größer ausfallen als das was die meisten Menschen beim Begriff "Echtzeit" erwarten. Hier wären wir also für das später gewünschte fertige System bei maximal 80ms. Das Thema dürfte aber auch frühestens im zweiten (eher dritten) Schritt relevant werden, weil wir vorher erst überhaupt irgendein Modell brauchen das zuverlässig eine sinnvolle Aktion auslösen kann.

                          Zitat von DJ.Picasso Beitrag anzeigen
                          Aktuell keine Zeit gehabt ... und um das Thema komplexe Datenbanken und Logiken mache ich mir keinen Kopf, das bekomme ich hin! Soll nicht heißen, dass es einfach wird, aber machbar! Das Problem ist eher zeitlicher Art (zuviele andere Projekte!). […]

                          Das glaubt man nur, wenn man sich noch nicht mit derartigen Profilen und den daraus entstehenden bzw. notwendigen Daten beschäftigt hat. Es wird immer viel zu kompliziert gesehen, vor allem viele Techniker haben diese Sichtweise. Bin selber Techniker, kann ein Lied davon singen: Immer erst die Probleme sehen und darstellen, warum irgendetwas nicht geht. Die Lösung wird selten gesehen!
                          Jedoch sind viele Dinge sehr viel einfacher als man denkt, vor allem aber auch "technisch abbildbar".
                          Maschine Learning und Data Science gehören eher nicht zu den Themen die einfacher sind als "man" denkt, das hält die Leute aber nicht davon ab das das trotzdem zu glauben und Wunder zu erwarten. Da gibt es dann Tutorials die an einfachen (und gut geeigneten) Beispielen zeigen wie einfach das sein kann. Die Probleme die bei realen Anwendungen zu erwarten sind fehlen aber. Und eine seriöse Evaluation des entstandenen Modells fehlt auch oft (und dann würde das Ergebnis wesentlich schlechter aussehen). Selbst wenn Du auf den ersten Blick vielen Daten hast, dann wirst Du bei genauerem Hinsehen feststellen dass die Fälle die Du automatisieren willst nur vergleichsweise selten auftritt. Was ein 3-Jähriger zum nach 3 Durchläufen verstanden hat, wird i.d.R. auch mit 100 Beispiel mit einem ML-Modell nicht vernünftig funktionieren. Selbst wenn Du sowas einfaches wie das Einschalten vom Licht nur mit dem Signal vom BWM und der gemessenen Helligkeit (die nicht exakt vorliegt sondern mit größerer Ungenauigkeit irgendwo in der Historie liegt) trainieren willst wirst Du dafür erst mal eine ganze Menge Zeit investieren müssen, u.A. zur Behandlung von Sonderfällen wie dem Einschalten bei Tag zum Putzen (was vielleicht eine Hand voll Male im Jahr passiert).

                          Ich finde das Thema auch sehr Spannend, aber man darf da den dafür nötigen Aufwand und das nötige Datenvolumen keinesfalls unterschätzen.

                          Kommentar


                            #14
                            ich würd zum daten abgreifen nen kleines nodejs script nehmen und mit forever / pm2 laufen lassen.

                            sind ne hand voll zeilen code...

                            Kommentar

                            Lädt...
                            X