Ankündigung

Einklappen
Keine Ankündigung bisher.

Das nächste Release

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

    #61
    Hast Du beim knxd den Cache aktiviert?

    Ansonsten ist mir noch nicht ganz klar was Du wie machsts und was wie funktioniert und was nicht.

    Wen der write funktioniert, *sollte* der read auch funktionieren (Annahme: Cache ist aktiv). Wobei der write einfacher ist, da dort nur einmalig etwas gesendet werden muss, bei dem read dagegen muss nach dem ersten Request auch noch das COMET funktionieren.
    TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

    Kommentar


      #62
      Chris M. hab ich ...
      Ich hab auch schon das Problem gefunden.
      Mein Fehler. Kein Programm Fehler. Vielleicht aber doch, weil ich eben nicht damit gerechnet haber, dass folgendes passieren kann.

      In meiner Produktivumgebung (RPI, eibd...) läuft Linknx. Linknx liefert den Status einiger GAs, die als Objekte in der Cometvisu abgefragt werden. Stoppen ich komplett die Produktivumgebung läuft natürlich Linknx auch nicht.

      Den Rest kannst Du Dir denken. Auf der Testumgebung (Knxd, CometVisu) versucht die Cometvisu u.A. diese GAs auszulesen. Bekommt aber keine Antwort. Das führt dazu, dass alle Statie angezeigt werden. Schmeiße ich alle "GA-Leichen" aus der visu_config.xml raus KOMMEN ALLE STATIE.

      Was bedeutet das nun? Wenn ich einen defekten Aktor habe blockiert er die gesamte Statie des Projektes? Könnte ich natürlich morgen ausprobieren wenn alle aus dem Haus sind :-)

      Kommentar


        #63
        Wie der linknx hier interagiert kann ich nicht beurteilen.

        In einem "reinen" KNX Projekt, wo alle Teilnehmer am grünen Kabel hängen und auf dem Server nur der eibd/knxd + eibread-cgi läuft, passiert folgendes:
        • eibd/knxd wird mit aktivierten Cache gestartet und hört am Bus mit
        • KNX Pakete auf dem Bus werden im Cache mit gespeichert
        • Visu wird gestartet => eibread-cgi wird mit neben den interessanten GAs mit dem Parameter t=0 gestartet
        • Alles abgerufenen(!) GAs die im Cache sind werden an die Visu übermittelt, für alle anderen wird ein Lese-Telegramm auf dem Bus abgesetzt. Mit der Antwort kommt ein Index im Cache.
        • Die Visu zeigt die Rückmeldung an und schickt sofort einen neuen Request an den eibread-cgi, nur jetzt mit i=<Index>
        • Eibread-cgi blockiert die Antwort so lange, bis ein Paket vor irgend einer der interessanten GAs vorbei kommt - das wird dann sofort an die Visu übergeben. (Sollte bereits in der Zwischenzeit in Paket gekommen sein - was durch den Index leicht herausfindbar ist - gibt's das natürlich sofort als Antwort)


        Von daher sollte es auch kein Problem mit "GA Leichen" geben. (Ich teste das immer mit der Demo-Config - die hat keine GAs die bei mir am Bus real existieren).
        Wenn nun aber der Linknx auf eine "besondere"(?) Art mit dem eibd/knxd spricht, könnte ich mir ein Blockieren durchaus vorstellen, schließlich ist der eibd/knxd kein richtiges Multithreading-Programm was folglich leicht blockieren könnte.
        TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!

        Kommentar


          #64

          Mit neuerem knxd eibread-cgi gibt es eine Änderung was den GA-Abruf bei Start angeht, siehe
          https://github.com/knxd/knxd/commit/...6f6bcc2e9fdb3d
          https://github.com/knxd/knxd/commit/...6f6bcc2e9fdb3d
          für eine zeitlang war es komplett raus, jetzt in abgespeckter Form wieder drin. Das ist imho auch ok so, das alte Verhalten war ein Overkill.

          Kommentar

          Lädt...
          X