Ankündigung

Einklappen
Keine Ankündigung bisher.

smarthomeNG über ETS konfigurieren

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

    #46
    Der knxd ist richtig konfiguriert, wenn du ihn mit ETS als Router findest, und auch die Telegramme im Gruppenmonitor siehst, wenn du dich über Routing mit knxd verbindest.

    Logging sollte direkt in der Console sichtbar sein. Du müsstest also shng mit -d oder -i oder so starten.

    Mal eine blöde Frage: Den Button zum aktivieren des Programmiermodus auf dem Webinterface hast du gefunden?

    Kommentar


      #47
      Danke für deine Antwort. Ja den Button hab ich gefunden hab Suchmaschinen testweise den Progmode fest im Plugin aktiviert
      Schaue mir später mal die Logs an

      Kommentar


        #48
        Also hab das nochmal versucht.
        snhg mit -d gestartet. Aber eigtl keine Meldungen vom knx_ets Plugin
        im knxtool vbusmonitor folgendes:
        on: BC 11 79 19 19 E3 00 80 25 B6 DB :L_Data low from 1.1.121 to 3/1/25 hops: 06 T_Data_Group A_GroupValue_Write 25 B6
        L_Busmon: BC 11 79 19 19 E3 00 80 25 A3 CE :L_Data low from 1.1.121 to 3/1/25 hops: 06 T_Data_Group A_GroupValue_Write 25 A3
        L_Busmon: B0 11 7B 00 00 E1 01 00 C5 :L_Data system from 1.1.123 to 0/0/0 hops: 06 T_Data_Broadcast A_IndividualAddress_Read
        L_Busmon: B0 11 7B 00 00 E1 01 00 C5 :L_Data system from 1.1.123 to 0/0/0 hops: 06 T_Data_Broadcast A_IndividualAddress_Read
        L_Busmon: B0 11 7B 00 00 E1 01 00 C5 :L_Data system from 1.1.123 to 0/0/0 hops: 06 T_Data_Broadcast A_IndividualAddress_Read
        L_Busmon: BC 11 79 19 19 E3 00 80 25 AA C7 :L_Data low from 1.1.121 to 3/1/25 hops: 06 T_Data_Group A_GroupValue_Write 25 AA
        L_Busmon: BC 11 79 19 19 E3 00 80 25 9D F0 :L_Data low from 1.1.121 to 3/1/25 hops: 06 T_Data_Group A_GroupValue_Write 25 9D
        L_Busmon: BC 11 79 19 19 E3 00 80 25 BC D1 :L_Data low from 1.1.121 to 3/1/25 hops: 06 T_Data_Group A_GroupValue_Write 25 BC
        L_Busmon: B0 11 7B 00 00 E1 01 00 C5 :L_Data system from 1.1.123 to 0/0/0 hops: 06 T_Data_Broadcast A_IndividualAddress_Read
        L_Busmon: B0 11 7B 00 00 E1 01 00 C5 :L_Data system from 1.1.123 to 0/0/0 hops: 06 T_Data_Broadcast A_IndividualAddress_Read
        L_Busmon: B0 11 7B 00 00 E1 01 00 C5 :L_Data system from 1.1.123 to 0/0/0 hops: 06 T_Data_Broadcast A_IndividualAddress_Read
        L_Busmon: BC 11 79 19 19 E3 00 80 25 9D F0 :L_Data low from 1.1.121 to 3/1/25 hops: 06 T_Data_Group A_GroupValue_Write 25 9D

        während Programmierversuch. Gibts iregndeine Möglichkeit festzustellen ob die Pakete überhaupt zum knxPython Stack durchkommen bzw vom Stack zurück zum knxd gehen ?

        Ich hab im ETS als Schnittstelle natürlich den knxd benutzt, Habs aber auch mit meinem MDT IP Interface versucht.
        Hast Du da noch eine Idee ?

        Was mich ich für Parameter bei knx.Prepare() mitgeben , wenn ich das ganze mal ausserhalb dem Plugin testen möchte ?


        Kommentar


          #49
          Bei knx.Prepare gibt man einfach die argumente von shng mit. Dadurch kann das über ets neu gestartet werden. (wenn z.B. die PA geändert wurde.)

          Der Code liegt unter https://github.com/thelsing/knx/tree...ples/knxPython

          Du kannst auch das Linux-Beispiel des Stacks ohne python testen: https://github.com/thelsing/knx/tree...ples/knx-linux

          Zusätzliches logging kannst du https://github.com/thelsing/knx/tree...ples/knx-linux und https://github.com/thelsing/knx/blob...tform.cpp#L261 aktivieren.

          Zusätzlich gibt es noch auskommentierte Consolenausgaben im network-layer, datalink-layer usw. Aber in der Linux-platform siehst du ob überhaubt was ankommt.
          Dein Router/Switch darf übrigens nicht IGMP blocken.

          Viel Erfolg,
          Thomas

          Kommentar


            #50
            Super Danke werd mir das mal in einer ruhigen Stunde genauer anschauen.

            Kommentar


              #51
              So hab das Ganze mal etwas getestet und einen Teilerfolg gehabt.
              So wie es ausschaut kommen die Antworten vom Plugin nicht zurück über den KNXD.
              Icst das ein Bug im Knxd dass lokale Anfragen an localhost nicht geroutet werden ?
              Irgendwie steig ich bei dem Thema Routing/Tunneling Multicasts nicht komplett durch.

              Hab jetzt meinen 2. Raspi als IP Router konfiguriert und dessen IP Adresse als Host in /etc/Plgun.yaml eingetragen.


              Ich kann jetzt Programmieren.
              Allerdings gehts nur wenn SHNG knxprod als TP generiert wird wird. Wenn ich es als IP mache und es einer IP Linie zufügen will kommt folgender Fehler im ETS:
              System.Collections.Generic.KeyNotFoundException: Der angegebene Schlüssel war nicht im Wörterbuch angegeben.
              bei System.Collections.Generic.Dictionary`2.get_Item(T Key key)
              bei Knx.Ets.ObjectModel.Caching.ObjectCacheBase`2.Look up(TId id)
              bei Knx.Ets.ObjectModel.Project.Device.EnsureCalculato rExistsAndIsValid()
              bei Knx.Ets.ObjectModel.Project.Device.CreateCalculato rKeepAliveScope()
              bei Knx.Ets.ObjectModel.Project.Device.EnsureParameter InstancesAndCalculatorExist()
              bei Knx.Ets.ObjectModel.Project.Device.EnsureCalculato rExistsAndIsValid() ..........

              Kommentar


                #52
                Der Bug mit den lokalen Verbindungen liegt bei mir. Ich muss die Multicastpacket auch lokal verarbeiten lassen. Das mache ich bisher nicht, da ich die sonst auch selbst kriege und das Echo entsprechend handhaben muss. Da muss ich da Data-Link-Layer wohl nochmal refactoren.

                Der Fehler von ETS kommt bestimmt daher, dass du das Gerät schon als TP drin hast oder hattest. Probier mal das Gerät komplett aus dem Projekt zu nehmen und danach das Projekt zu verkleinern. (In der Projektübersicht "jetzt komprimieren" oder so). Vielleicht hilft das.

                Einen Host brauchst du für das knx_ets-Plugin eigentlich nicht einstellen.

                Zu Routing/Tunnelling:

                Bei Tunnelling mach 1 Prozess eine TCP-Verbindung zum IP-Interface auf. Über diese Verbindung werden die Telegramme ausgetauscht.

                Routing erfolgt über Multicast. Also 1-zu-Viele Kommunikation. Jedes Gerät schickt sein Telegramm an eine spezielle Multicast-IP-Adresse. Jeder der mag (und das dem Switch gesagt hat) bekommt das Telegramm. Eins der Geräte ist (rein zufällig) der knx-Router. Der schaut ggf. in seine Filtertabelle und schickt die Telegramme auch auf die TP-Linie. Bei Telegrammen von TP schaut er auch in seine Filtertabelle und schickt das Telegramm wieder an die spezielle Multicast-IP-Adresse. Hierdurch erhalten es alle Geräte die das wollen. Die UDP-Pakete können leider verloren gehen. Bei der Spezifikation von knx-IP hat wahrscheinlich noch niemand an IP-only Geräte gedacht.

                Kommentar


                  #53
                  Danke für den Tip. Also ich hab das ganze jetzt ins ETS importieren können. Hab das knxprod nochmal neu erstellt.
                  Das mit dem Multicast hab ich jetzt auch kapiert. Denk ich zumindestens
                  Werd mich die nächsten Tage mal ich deinen KNX stack einarbeiten und mal schauen wie das ganze genau funktioniert.
                  Möchte iegtnlich schon alles auf einen PI mit knxd usw laufen lassen können. Die andere Konfig ist mir zu unübersichtlich wenn mal was nicht geht.

                  Kommentar


                    #54
                    Moin thesing , ist der Stand in Deinem Github Repo noch aktuell?

                    Kommentar


                      #55
                      Hallo,

                      mich reizt das Plugin nachwievor...
                      Was mich bisher abhielt (abgesehen vom Aufwand des Umstieg):
                      Aktuell ist meine lib auf 255 KOs beschränkt. Bei mir reicht es noch. Wenn jemand mehr braucht kann ich das auch relativ einfach auf 65K aufbohren. Wenn neue Items hinzkommen, muss man derzeit das alte Gerät aus ETS entfernen, das neue hinzufügen und dann wieder die ganzen KOs zu den GAs verbinden. Das dauert leider etwas. Die generierten knxprods sieht ETS als unregistriert an. Daher kann man nicht einfach das Applikationsprogramm updaten. Ich muss mal sehen ob man das noch besser machen kann.

                      Nach der ganzen Arbeit hab ich dann festgestellt, dass knxd (zumindest bei mir) nicht von IP zu TP routet. Andersrum funktioniert es super. Das schein an der Absende-Adresse zu liegen
                      Besteht die Beschränkung auf 255 noch? Und hast du das KNXd Problem ohne Calimero gelöst?

                      Items löschen und hinzufügen inkl Applikationsupdate ohne neuverknupfen geht ja jetzt, oder?
                      Nur muss shng per ETS dann neu programmiert werden, richtig?

                      Nutzt du es weiterhin produktiv?
                      Wie sind deine Erfahrungen?

                      Gruß,
                      Hendrik

                      Kommentar


                        #56
                        Ich habe gerade nochmal den letzten Stand gepusht. Das plugin ist bei mir sein einigen Jahren ohne Probleme im Einsatz. Update in ETS funktioniert auch. Wenn man Items entfernt, bleiben die KOs trotzdem in ETS drin. An eine Beschränkung auf 255 KO oder Probleme mit knxd kann ich mich gar nicht mehr erinnern...
                        Der knx-Stack kann auf jeden Fall 2^16 KOs und ich benutze inzwischen einen "richtigen" IP-Router.

                        Ich arbeite aber auf einer älteren smarthomeNG-Version, da bei den aktuellen keine rekursiven Structs möglich sind, und mein Patch der das möglich gemacht hat bei der aktuelle nicht mehr funktioniert. (Issue #318)

                        Die initiale Einrichtung ist ein bisschen hakelig (die Python-lib erstellen, im Webinterface die xml erzeugen, mit CreateKnxProd eine knxprod aus der xml erzeugen, ...), aber wenn es einmal läuft, funktioniert es problemlos.

                        Die Programmierung der über ETS startet übrigens smarthomeNG neu (ggf. mehrfach).

                        Kommentar


                          #57
                          Hallo,

                          thesing
                          seit ich das Plugin aktiviert habe, habe ich dies im Log:
                          Code:
                          2023-01-16  19:13:26 WARNING  lib.item.items      Plugins 'knx' and 'knx_ets' define the same item-attribute 'knx_dpt'
                          2023-01-16  19:13:29 WARNING  lib.metadata        Item 'og.Lina.Szene', attribute 'knx_dpt': Invalid value '18.001' for attribute 'knx_dpt' -> using '1' instead (defined in Licht.yaml)
                          ​
                          Und die Szenen funktionieren nicht mehr.
                          In der dpts.py finde ich auch keinen DPT18.

                          Du hattest mal geschrieben, dass man beide Plugins parallel nutzen kann. Das sollte eigentlich weiterhin so sein, oder?

                          Gruß,
                          Hendrik

                          Kommentar


                            #58
                            Es sollte nur eins gleichzeitig aktiv sein denke ich. Den DPT18 kannst du sicherlich beim orginal knx plugin klauen und bei mir einfügen. Wenn du die wirklich parallel haben willst, solltest du in meinem Plugin ein anderes attribut als statt knx_dpt nehmen dann hast du je nach Attribut den Zugriff auf den Bus über ein anderes Plugin.

                            Kommentar

                            Lädt...
                            X