KnxProducer Verschachtelung

[boonkerz]

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

[coko]

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...

[boonkerz]

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.

[coko]

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)

Die Performance in der ETS muss man dann mal schauen weil dann glaube ich schon relativ viel generiert wird.

Was meinst Du mit generiert?

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.

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?

[boonkerz]

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.

[coko]

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...

[boonkerz]

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.