Ankündigung

Einklappen
Keine Ankündigung bisher.

KnxProducer Verschachtelung

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

    KnxProducer Verschachtelung

    Hallo,

    Ist es möglich folgende Verschachtelung aufzubauen?

    Modul
    - Bereich 1..n
    - Funktion 1..n

    Ich habe eine Ebene mit Variabler Anzahl hinbekommen.
    Das habe ich mir bei den Logiken abgeschaut.

    Nun die Frage ob das Grundsätzlich überhaupt geht wenn ja würde ich mich da durch wühlen

    Vielen Dank

    #2
    Kontext ist wahrscheinlich ESP32P4 mit ESP32C6 und Waveshare 10Zoll Display?

    Soll die Anzahl bei beiden gleich sein?​ Und ist das wirklich Funktionalität die in einem Modul zusammengehört? Ich habe das Gefühl, dass es zwischen dem was Du vorhast und Lösungen von mgeramb funktionale Überschneidungen geben könnte. Beschreibe doch mal kurz was Du vorhast, um einen Gesamteindruck zu erhalten (und weitere relevante abschätzen zu können).

    Von Producer-Seite bin ich erst mal optimisch, dass das machbar wäre...

    OpenKNX www.openknx.de | StateEngine: Universelle Zustandsautomaten in KNX | OpenKNX Konfigurationstransfer

    Kommentar


      #3
      Was ich machen möchte wäre:

      Modul
      - Allgemein
      - - Funktion 1: Nacht Modus EIN/AUS
      - - Funktion 2: Außentemperatur Status
      - Küche
      - - Funktion 1: Lampe EIN/AUS
      - - Funktion 2: Temp Status
      - - Funktion 3: Luftfeuchtigkeit Status
      - Bad
      - - Funktion 1: Lampe EIN/AUS
      - - Funktion 2: Temp Status
      - - Funktion 3: Luftfeuchtigkeit Status​​
      - 1:n
      - - Funktion 1..n

      Ich habe das jetzt alles als Liste die halt riesig ist/wird in der ETS

      Modul:
      - Allgemein
      - - Funktion 1: Allgemein Nacht Modus EIN/AUS
      - - Funktion 2: Allgemein Außentemperatur Status
      - - Funktion 3: Küche Lampe EIN/AUS
      - - Funktion 4: Küche Temp Status
      - - Funktion 5: Küche Luftfeuchtigkeit Status
      - - Funktion 6: Bad Lampe EIN/AUS
      - - Funktion 7: Bad Temp Status
      - - Funktion 8: Bad Luftfeuchtigkeit Status​​

      Ich habe mir auch mal als Beispiel in die Prod von der ecowitt geschaut dort gibt es ja auch die Struktur:

      Wetterstationen
      - Wetterstation A: Werkstatt​​​
      - - Temperatur
      - - Luftdruck

      Da ist quasi die 3 ebene fest vorgeben wie bei den Logiken bis auf das manche Ein/Aus geblendet werden aber nicht variabel von der Anzahl.

      Die Performance in der ETS muss man dann mal schauen weil dann glaube ich schon relativ viel generiert wird.
      Wenn nicht muss man die ebenen Anzahl ein wenig begrenzen. z.b. Funktionen 30 und Bereiche 20.

      Hintergrund ist der das ich in mit den Funktionen dann entsprechende ComObjekte anlege.
      Welche ich dann wiederum in meiner Webgui auslesen kann.

      Kommentar


        #4
        Zitat von boonkerz Beitrag anzeigen
        Modul
        - Allgemein
        - - Funktion 1: Nacht Modus EIN/AUS
        - - Funktion 2: Außentemperatur Status
        - Küche
        - - Funktion 1: Lampe EIN/AUS
        - - Funktion 2: Temp Status
        - - Funktion 3: Luftfeuchtigkeit Status
        [...]
        Das ist nun doch eine andere Struktur als erwartet, und zwar eine die sehr schlecht skaliert!

        Der Ressourcenbedarf ist hier deutlich größer als in Deinem Vergleichsbeispiel von ecowitt (und auch anderen mir bekannten Lösungen). Sei
        n = Anzahl der Bereiche
        m = Anzahl der Funktionen je Bereich
        t = Anzahl unterschiedlicher Funktionstypen
        X = mittlerer Ressourcenbedarf je Funktionstyp
        X_max = maximaler Ressourcenbedarf eines Funktionstyps

        Dann hast Du für Deine Idee einen Ressourcenbedarf - ohne Überlappung (wie XML-Elementen) - in der Größenordnung:
        n * m * t * X
        Das Vergleichsbeispiel kommt jedoch aus mit
        n * t * X

        Bei Ressourcen die geteilt werden können (wie Parameter-Speicherplatz):
        n * m * X_max
        und im Vergleich
        n * t * X (<< n * t * X_max bei unterschiedlich komplexen Funktionstypen)

        Zitat von boonkerz Beitrag anzeigen
        Die Performance in der ETS muss man dann mal schauen weil dann glaube ich schon relativ viel generiert wird.
        Was meinst Du mit generiert?

        Zitat von boonkerz Beitrag anzeigen
        Wenn nicht muss man die ebenen Anzahl ein wenig begrenzen. z.b. Funktionen 30 und Bereiche 20.
        Macht dann immer noch einen Faktor von 600 aus, mit dem Du den Ressourcenbedarf pro Funktion multiplizieren musst, selbst wenn Du die Maximalen Dimensionen nie gleichzeitig überall nutzen wirst. Damit kommst Du sehr schnell in Dimensionen die keinen Spaß mehr machen, insbesondere wenn Du die Applikation in einem realen ETS-Projekt verwenden willst. Fazit: Ich rate ausdrücklich zu einem anderen Konzept.

        Zitat von boonkerz Beitrag anzeigen
        Hintergrund ist der das ich in mit den Funktionen dann entsprechende ComObjekte anlege.
        Welche ich dann wiederum in meiner Webgui auslesen kann.
        Wie viele KOs planst Du denn insgesamt?
        OpenKNX www.openknx.de | StateEngine: Universelle Zustandsautomaten in KNX | OpenKNX Konfigurationstransfer

        Kommentar


          #5
          Wenn ich das wie beim MDT Smart mache würde was mir persönlich aus reicht hätten wir 8 Bereiche und pro Bereich 8 Funktionen.
          Ich denke MDT hat das auch begrenzt aus deinen genanten Gründen.
          Wobei dort viel mehr außen rum ist. (Zeitschaltuhr, Standby Elemente, Codeschloss usw.)

          Daher würde ich da evtl. schon mal mit 10 Bereiche und 10 Funktionen testen.
          Man kann dann ja für das Dashboard mit vielen Funktionen 2 Bereiche nutzen. Mache ich jetzt im MDT auch so.

          Kommentar


            #6
            Zitat von boonkerz Beitrag anzeigen
            mit 10 Bereiche und 10 Funktionen testen
            Was sollen die Bereiche denn überhaupt bewirken? Sollen alle Funktionen innerhalb eines Bereichs gemeinsam angezeigt werden?

            Aus dem anderen Thread ist für mich nicht eindeutig, ob Du OpenKNX verwendest oder nur den Producer zusammem mit dem ursprünglichen Stack. Falls OpenKNX und Du den Konfigurationstransfer nutzen willst, dann ist das mit den zwei Dimensionen nicht praktikabel (habe auch keine Pläne die das abdecken würde; mangelt auch so schon nicht an Erweiterungsideen!). Evtl. könnte man allerdings auch eine rein optische Gruppierung von jeweils 3, 9 oder 11 Funktioen (für max 99 Kanäle) realisieren...
            OpenKNX www.openknx.de | StateEngine: Universelle Zustandsautomaten in KNX | OpenKNX Konfigurationstransfer

            Kommentar


              #7
              Die Bereiche sind nur für die Unterteilung in der ETS damit man das sauber strukturieren kann und die Übersicht behält.

              Ich nutze nichts von openknx bisher, nur den Producer für die prod Datei. Ich nutze den im Grunde nur um variable Kommunikationsobjekte zu erstellen.

              für die ganzen Einstellungen und Verknüpfungen ( gruppenadresse zu lvgl Element ) nutze ich eine Web gui.

              Ich kann auch mal ein Teams Meeting anbieten zum besseren Verständnis was ich machen möchte.

              Kommentar


                #8
                Zitat von boonkerz Beitrag anzeigen
                Die Bereiche sind nur für die Unterteilung in der ETS damit man das sauber strukturieren kann und die Übersicht behält.
                Dafür sind die Funktionen und die Geräteansicht dar.

                Mach die Parameterblöcke beschriftbar, dann findet man sich da extrem schnell zurecht.
                Siehe Logikmodul als Beispiel. Das ist trotz der vielen Kanäle super übersichtlich, wenn man alles gut beschriften kann
                OpenKNX www.openknx.de | Kaenx-Creator | Dali-GW

                Kommentar


                  #9
                  Zitat von boonkerz Beitrag anzeigen
                  Modul
                  - Bereich 1..n
                  - Funktion 1..m
                  Das hier bekommt man hin (als n Bereiche und m Funktionen, die aber auf der gleichen Ebene stehen). Da könntest Du Dir das OAM-AccessControl ansehen.

                  Da andere
                  Code:
                  Modul
                  - Bereich 1..n
                  --Funktion 1..n
                  Geschachtelt - n Bereiche und pro Bereich m Funktionen bekommt man nur mit einem Statischen m hin, also n Bereiche und pro Bereich z.B. 10 Funktionen. Bedenke aber, dass die ETS-Applikatin immer die mögliche Maximalgröße hat, egal wie viel davon angezeigt wird.
                  Ein Beispiel hier wäre das OFM-PresenceModule, hier gibt es pro PM-Kanal (bei n Kanälen) immer 4 Tagesphasen (also ein festes m=4).

                  An sich ist die ETS für solch generische Definitionen, wie Du sie vor hast, nicht geeignet.

                  Gruß, Waldemar
                  OpenKNX www.openknx.de

                  Kommentar


                    #10
                    Ich glaube ich werde das wie beim PresenceModule machen.
                    Schaue erstmal wie weit ich komme.

                    Ich möchte auch nochmal Danke sagen das ist schon toll was ihr mit OpenKNX auf die Beine gestellt hat.
                    Mir hilft das sehr.

                    Kommentar


                      #11
                      Also ich weiß noch nicht was du vor hast, aber für ein Touch Display habe ich bereits eine SW die nur noch für den größeren Waveshare angepasst werden muss. Du kannst dort dann eine große Anzahl an Geräten definieren und eine viele Seiten. Eine Seite kann dann entweder nur ein Gerät darstellen oder in Zellen unterteilt werden. Jede Zelle kann ein Gerät bedienen oder als Absprung auf eine andere Seite dienen, damit kann man also auch eine ganze Menüstruktur aufbauen.
                      Wenn du interesse hast, da mitzuwirken anstatt von 0 was neues zu erschaffen, melde dich bitte.

                      Kommentar


                        #12
                        Zitat von mgeramb Beitrag anzeigen
                        Also ich weiß noch nicht was du vor hast, aber für ein Touch Display habe ich bereits eine SW die nur noch für den größeren Waveshare angepasst werden muss. Du kannst dort dann eine große Anzahl an Geräten definieren und eine viele Seiten. Eine Seite kann dann entweder nur ein Gerät darstellen oder in Zellen unterteilt werden. Jede Zelle kann ein Gerät bedienen oder als Absprung auf eine andere Seite dienen, damit kann man also auch eine ganze Menüstruktur aufbauen.
                        Wenn du interesse hast, da mitzuwirken anstatt von 0 was neues zu erschaffen, melde dich bitte.
                        https://knx-user-forum.de/forum/%C3%...10zoll-display

                        Gibt es zu deinem Projekt einen Link oder irgendwo was zu sehen? evtl. passt das ja auch.

                        Ich habe gerade mal geschaut. geht es um das OFM-TouchDisplay und OAM-TouchRound?
                        Zuletzt geändert von boonkerz; 05.02.2026, 18:22.

                        Kommentar


                          #13
                          Zitat von boonkerz Beitrag anzeigen


                          Ich habe gerade mal geschaut. geht es um das OFM-TouchDisplay und OAM-TouchRound?
                          Ha, das TouchDiplay ist für das große Display gedacht. Die SW wird weitgehend zwischen den Projekten geshared werden. Du kann also durchaus die App des TouchRound ansehen. Im wesentlichen wird es nur mehr Optionen für den aufgeteilten Screen geben, weil man da mehr Zellen unterbringen wird können

                          Kommentar


                            #14
                            Zitat von mgeramb Beitrag anzeigen
                            Ha, das TouchDiplay ist für das große Display gedacht. Die SW wird weitgehend zwischen den Projekten geshared werden. Du kann also durchaus die App des TouchRound ansehen. Im wesentlichen wird es nur mehr Optionen für den aufgeteilten Screen geben, weil man da mehr Zellen unterbringen wird können
                            Das mit dem Konzept der Geräte ist natürlich sehr interessant.

                            Ich mache das jetzt manuell derzeit.
                            KO Nummern usw. muss ich nur noch mal planen wobei das für ein privates Projekt ja eigentlich egal ist.

                            image.png image.png

                            Kommentar


                              #15
                              Ganz wichtig bei KO-Nummern: Es werden alle KO - beginnend mit 1 - maxKO. Bei Dir also 10025!!
                              Mach das nicht, das verbrät nur unnütz RAM (pro KO ca. 10 Byte, in Deinem Fall also 100k).

                              Gruß, Waldemar
                              OpenKNX www.openknx.de

                              Kommentar

                              Lädt...
                              X