Ankündigung

Einklappen
Keine Ankündigung bisher.

Wie zwingt man linknx den Wert vom Bus zu lesen?

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

    Wie zwingt man linknx den Wert vom Bus zu lesen?

    Hallo,
    (Kurzfassung: ) gibt es einen Trick linknx zu zwingen beim Objektwertauslese den Wert vom Bus zu lesen/zu aktualisieren (statt gebufferten Wert auszugeben)?
    Update: Für die Lösung schauen Sie Antwort #6 unten.

    (Langfassung: ) Ich möchte mit linknx (in meinem Fall v.0.0.1.33) einen Wert vom KNX Bus, z.B. einen Helligkeitswert vom Sensor, auslesen.
    Das klappt auch soweit, nur triggert die linknx Objektauslese keine Aktivität beim KNX-Bus, sondern es wird nur der letzte am Bus gemeldete Wert zurückgegeben.

    In linknx Konfiguration habe ich stehen:
    Code:
    <object type="9.004" id="WZ_Helligkeit" gad="0/7/5" flags="cwtus">WZ_Helligkeit</object>
    Wenn ich mit Telnet
    Code:
    <read><object id="WZ_Helligkeit" /></read>
    abfrage sehe ich im (ETS) Gruppenmonitor dass einmalig der Wert vom Bus abgefragt wurde (linknx -> knxd -> KNXNet/IP Router -> KNX Bus).
    Beim weiteren Leseversuchen sehe ich auf dem Bus keine weitere Leseaktivität, d.h. die Antwort bleibt gleich, wie hier am Beispiel:
    Code:
    <read status='success'>172</read>
    <read status='success'>172</read>
    <read status='success'>172</read>
    Wenn ich den Gruppenadresse, z.B. mit ETS Gruppenmonitor, händisch auslese und danach mit linknx den Wert neu auslese, gibt linknx den neuen aktualisierten Wert aus:
    Code:
    <read status='success'>165</read>
    Log in Debug-Modi gibt folgendes aus (erste Teil ist vom erste Abfrage, zweite Teil vom zweite Abfrage mit ausbleibenden Buskommunikation):
    Code:
    DEBUG ClientConnection : PROCESSING MESSAGE:
    DEBUG ClientConnection : <?xml version="1.0" encoding="utf-8"?><read><objects><object id="WZ_Helligkeit"/></objects></read>
    DEBUG ClientConnection : END OF MESSAGE
     INFO KnxConnection    : write(gad=0/7/5, buf, len=2)
    DEBUG KnxConnection    : Write request sent
    DEBUG KnxConnection    : Response from 1.1.3 to 0/7/5: 1d fa
    DEBUG Object           : Object (id=WZ_Helligkeit): get
     INFO Object           : New value 122.4 for object WZ_Helligkeit (type: 9.004)
    DEBUG Object           : Calling onChange on listener for WZ_Helligkeit
     INFO Rule             : Evaluate rule read-in-values
     INFO Condition        : ObjectCondition (id='WZ_Helligkeit') evaluated as '1'
     INFO Rule             : Rule read-in-values evaluated as 1, prev value was 1
    DEBUG Object           : Object (id=WZ_Helligkeit): get
    
    DEBUG ClientConnection : PROCESSING MESSAGE:
    DEBUG ClientConnection : <?xml version="1.0" encoding="utf-8"?><read><objects><object id="WZ_Helligkeit"/></objects></read>
    DEBUG ClientConnection : END OF MESSAGE
    DEBUG Object           : Object (id=WZ_Helligkeit): get
    Wie zwingt man linknx bei jedem Objektlesen den Wert vom Bus auszulesen? Ich habe verstanden die "s" Flagge sei dafür da, nur wie es aussieht, habe ich es nicht richtig verstanden.
    Update: die "s"-Flagge wird in linknx (mindestens bis v0.0.1.33) nur bei ausgehenden Datenwrites ausgewertet, beim einkommenden Datenreads/-requests nicht (Info bestätigt von linknx Entwickler).

    Auch folgende Regel bringt nicht das gewünschte Ergebnis:
    Code:
    <rule id="read-in-values">
       <condition type="object" id="WZ_Helligkeit" trigger="true" />
       <actionlist>
          <action type="send-read-request" id="WZ_Helligkeit" />
       </actionlist>
    </rule>
    Für jede Hilfe bin ich sehr dankbar!

    Gruss,
    xrk

    P.S. Im Forum hier könnte ich einen ähnlichen Problemfall von 2010 finden, als Lösung gab meiner Meinung nach weniger elegante externe Bus-Auslese-Trigger mit eibd/knxd groupread, der allerdings auch nur einmalig den Busauslese auslöst:
    https://knx-user-forum.de/forum/%C3%...rung-erstellen
    Zuletzt geändert von xrk; 11.08.2016, 15:08.
    Winston Churchill hat mal gesagt: "Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

    #2
    Sollte wie folgt funktionieren, der Wert wird alle 30 Sek. gelesen und aktualisiert.
    Code:
    <rule id="read-in-values">
       <condition type="timer" trigger="true">
          <every>30</every>
       </condition>
       <actionlist>
          <action type="send-read-request" id="WZ_Helligkeit" />
       </actionlist>
    </rule>

    Kommentar


      #3
      Hallo Michixx,
      danke für dein Beitrag!

      Die vorgeschlagene Methode produziert allerdings Buslast, auch wenn der Wert von linknx nicht abgefragt wird. Genau dies wollte ich vermeiden (statt Polling, Event-basierte Abfrage).
      Wie wäre die richtige Konfiguration um dies mit linknx zu erreichen?
      Winston Churchill hat mal gesagt: "Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

      Kommentar


        #4
        Wieso produziert das Buslast, auch wenn linknx den Wert nicht abfragt?
        Was meinst du mit Ereignis basierte Abfrage, wenn sich der Helligkeitswert ändert?
        Ich verstehe auch gerade nicht was du so recht vorhast, erkläre das bitte mal.

        Kommentar


          #5
          Hallo Michixx,
          ich möchte linknx als Mittelsmann zwischen knxd und pyKNX verwenden.

          Die von Dir vorgeschlagene linknx Regel mit Timer, feuert jede x Zeit (im Beispiel oben x=30 Sekunden), unabhängig wie oft oder selten der linknx-Client (in meinem Fall pyKNX) am Ende den Wert tatsächlich benötigt. Jede von diesem Zeitintervallen produziert auf dem Bus einen GroupValueRead und einen GroupValueResponse Nachricht, wie man mit Bus- oder Gruppenmonitor in ETS beobachten kann.

          "Ereignis-basiert" wäre wenn der Wert vom Bus erst abgefragt wird, wenn ein linknx-Client (pyKNX) es abfragt. Wenn dies unregelmäßig stattfindet (z.B. manchmal mit 10 Sekundenintervall, manchmal aber erst nach 3 Tagen), dann müsste man den Pollingintervall kleinstmöglich wählen, um aktuelle Daten zu erhalten. Bei dem 3 Tage Beispiel-Fall würde dies viel unnötige Buslast bedeuten, da der linknx trotzdem jede 10 Sekunden den Sensor am KNX-Bus abfragen würde, um auch den kleinsten Intervall-Fall abzudecken.
          Zuletzt geändert von xrk; 09.08.2016, 13:18.
          Winston Churchill hat mal gesagt: "Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

          Kommentar


            #6
            Nach Kommunikation mit linknx Entwickler Cyrille Defranoux, bietet im Moment die aktuellste Version (v.0.0.1.33) nicht die Möglichkeit direkt vom KNX-Bus auszulesen, sondern es kann nur gebufferte Werte liefern.

            Um die von mir gewünschte Funktionalität zu erreichen, habe ich den Quellcode dann selber gepatcht. Ggf. interessiert sich jemand noch für dies, daher schreibe ich hier die Änderungen die ich gemacht habe.

            Im Anhang für sofortige verwendung 3 gepatchte Dateien für linknx v.0.0.1.33 die Objektwertauslese abhänging von in linknx.conf definierten Objektflagge "s" für Stateless nachliefern. Ist die "s"-Flagge für ein linknx Lese-Objekt gesetzt, wird es jedes mal neu vom KNX-Bus ausgelesen, ist es nicht gesetzt (=nicht vorhanden), wird stattdessen von linknx gebufferter Wert ausgegeben (=Standardverhalten von linknx).

            Zur Anwendung alle drei angehängten C++ Dateien in /src überschreiben und linknx neu übersetzen (make & sudo make install).

            Im Detail habe ich in objectcontroller.h|cpp eine Funktion reset_init_m_if_stateless() addiert, die linknx internen Objektwertinitflagge init_m zurücksetzt, das linknx den Wert neu vom Bus einmal holen zwingt:
            Code:
            void Object::reset_init_m_if_stateless()
            {
               if (flags_m & Stateless)
                  init_m = false;
            }
            Diese Rücksetzungsfunktion wird beim XML Eingangsparsen von Tags "read" + "object" in xmlserver.cpp in Funktion ClientConnection::Run an zwei Stellen vor Wertrückgabe ( obj->getValue() ) aufgerufen.
            Am einfachsten schaut man den Diff zwischen Original v0.0.1.33 und den Anhangsdateien an. Inkl. geschweifte Klammern handelt es dabei um nur 9 Zeilen Codeaddition verteilt über 3 Dateien.

            Schöne Grüße,
            Risto
            Angehängte Dateien
            Zuletzt geändert von xrk; 13.08.2016, 19:49.
            Winston Churchill hat mal gesagt: "Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

            Kommentar


              #7
              Vielen Dank dafür.

              Kommentar


                #8
                Kommt das auch im "offiziellen" Code? Macht ja wirklich Sinn!

                Kommentar


                  #9
                  Ich habe die Modifikationen an Cyrille weitergeleitet, mal sehen ob er es in die nächste Version aufnehmen möchte.
                  Winston Churchill hat mal gesagt: "Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

                  Kommentar


                    #10
                    Zitat von xrk Beitrag anzeigen
                    Ich habe die Modifikationen an Cyrille weitergeleitet, mal sehen ob er es in die nächste Version aufnehmen möchte.
                    Setz doch gleich einen Pull Request auf https://github.com/linknx/linknx dafür.

                    Gruss, Othmar
                    EIB/KNX, VISU mit knxd + linknx + knxweb, Steuerbefehle via SMS und Email mit postfix + procmail

                    Kommentar


                      #11
                      Setz doch gleich einen Pull Request auf https://github.com/linknx/linknx dafür.
                      Gute Idee! Hab gerade den Request mit den Änderungen für master-branch hochgeladen.

                      Gruss,
                      Risto
                      Winston Churchill hat mal gesagt: "Ein kluger Mann macht nicht alle Fehler selbst. Er gibt auch anderen eine Chance.“

                      Kommentar

                      Lädt...
                      X