Gruppenadressen in der Konnekting-Suite

[tuxedo]

23 Hauptgruppen? Oh, erhelle uns doch bitte mit deiner Projektstruktur. Das klingt interessant.

Ich komme aktuell mit 5 oder 6 Hauptgruppen aus und hab in Summe rund 400 Gruppenadressen. Also kein Kleinst-Projekt, aber auch kein Riesen-Projekt.

[Ing-Dom]

Raum/Gewerk/Funktion

z.B. 7/3/33

Büro / Fenster / Abs. Lammelenposition 2. Fenster

[tuxedo]

Interessanter Ansatz. Meine Hauptgruppe orientiert sich am Gewerk. Also System, Licht, Sonnenschutz, Heizung/Klima, ... Damit komme ich auf aktuell 6 Hauptgruppen.
Mittelgruppe ist dann das Gewerk weiter in Funktionen aufgedröselt. z.b. Sonnenschutz -> Bewegen, Schritt/Sperren, ...
Und erst im letzten Abschnitt habe ich dann die einzelnen Endpunkte bzw. Räume

Also Gewerk/Funktion/Raum bzw Endpunkt.

Hast du Linienkoppler im Einsatz? Wusstest du vorher von der "Empfehlung" im Rahmen von 15 Gruppenadressen zu bleiben?

[Ing-Dom]

nein, wusste es nicht. Habe keine Linienkoppler.
Alle "echten" KNX-Geräte haben keine Probleme gemacht.
Nur das Garagentorantrieb-Teil von Budde hat ein Update der Parametrisierungs-Software (ähnlich Suite) gebraucht.

[Ing-Dom]

Wie ist den der Status von issue #35?
Im Bugtracker finde ich keine Refernez auf einen commit - ist das in der Suite schon drin?

Dann würde ich mir eine Spezialversion der Suite bauen.

Hintergrund:
ich möchte gerne meinen Dimmer in (Test)Betrieb nehmen, ohne meine GA-Struktur umzuschmeißen..

Oder gibts einen Hack, wie ich die BETA4 dazu bringen kann HG >15 zu nehmen?

[Ing-Dom]

Ich beantworte die Frage mal selbst:

durch manuellen Eingriff in die xml lassen sich auch größere GAs schreiben.

[keil]

Hallo zusammen,

auch ich nutze alle 31 möglichen Adressen der Hauptgruppe (bei mir hat jeder Raum eine eigene Adresse, wobei auch die Fassade, Garage, Terasse usw. „Räume“ sind) und würde mich über eine direkte Unterstützung freuen.


Viele Grüße,
Michael

[tuxedo]

Das kommt. Versprochen. Ob ich das als zwischen Version bringe muss ich noch schauen.

[Bernator]

Allerdings ist es auch doof "irgendwo in der Mitte" eine unbenutzbare GA (weil Prog GA) zu haben...

Warum ist die Prog GA eigentlich unbenutzbar, soll das ohne Programmier Taste immer funktionieren? Ansonsten könnte man die GA ja nur dann "umleiten" wenn im Prog Mode und ansonsten normal verwenden......nur ein schneller Gedanke, kann auch Käse sein

[tuxedo]

Wenn wir nicht sicherstellen dass wir die GA exklusiv benutzen, dann werden früher oder später andere KNX Geräte auf dieser GA Telegramme "zwischenschießen" die die Kommunikation aus dem Tritt bringen.

Wir haben zwar zwei Bytes am Anfang des Telegramms die unser Protokoll als unseres definieren, aber es ist dennoch nicht ausgeschlossen dass nicht zufällig ein anderes Telegramm die gleichen Anfangsbytes hat.
Man kann das natürlich mit Prüfsummen und allerhand anderem kram "absichern", aber es ändert nichts an der Sache, dass andere Telegramme das ganze Prozedere stören.
Deshalb haben wir die sich "eigentlich am Ende befindliche GA" 15/7/255 als "dedizierte KONNEKTING ProgGA" deklariert. Und das "Ende" war bis vor kurzem noch dadurch definiert, dass GAs jenseits von 15/7/255 eigentlich nicht wirklich "empfohlen" werden. Eben wegen etwaigen Adressgrenzen von Linienkopplern und Co.

Ich habs nicht gezählt, aber 9 von 10 Usern (oder mehr) werden hier sicherlich die Grenze von 15/7/255 nicht sprengen, eben weil eine andere GA Aufteilung genutzt wird. D.h. die betroffene Zielgruppe wo 15/7/255 "irgendwo in der Mitte liegt" ist sicher recht klein.

Worüber man ggf. nachdenken kann ist, ob man das nicht einstellbar macht. D.h. in der Suite zwischen dem "einen Ende" und "dem anderen Ende" den User wählen lassen.
Würde allerdings voraussetzen, dass die Firmware auf dem Gerät das vorher weiß, d.h. entsprechend kompiliert ist. Ich würde aber dennoch vom Standardfall 15/7/255 ausgehen. Und wer davon abweicht, müsste in der Firmware und der Suite dann aktiv werden.

Wenn hier tatsächlich bedarf besteht: Ticket in Github aufmachen ... Dann schauen wir uns das für beta5 noch an.

[Ing-Dom]

Erstmal klingt das toll, die Prog-GA festzulegen. Sollte ja programmiertechnisch kein großes Aufwand sein.
Dann kann jeder die GA in seine GA-Struktur packen, wo sie am besten hinpasst.

ABER: wir wollen ja das ein Konnekting-Ökosystem entsteht, wollen ja auch die FW andere User nutzen, oder fertig aufgebaute Geräte.
An der Stelle würde ich also die zentrale Festlegung auf eine GA bevorzugen. Ich als einer der HG >15 nutzt, habe damit auch kein Problem.

Klar, eigentlich ist 15/7 für was anderes vorgesehen, aber mei... die eine GA.

Warum habt ihr euch eigentlich gegen eine Programmierung per Prop Read/Write entschieden?

[tuxedo]

Ja, das würde definitiv die Community fragmentieren. Es wäre eine Entscheidung ala 2- oder 3-stellige GA Form. Das lässt sich auch nur schwer mixen.
Für die Firmware wäre das allerdings dann kein großes Thema. umstellen eines "#define ..." und fertig. Würde aber gerade bei Neulingen wieder zur Verwirrung führen: "Welche FW Variante nehm ich jetzt?"

Von daher wäre nach wie vor der Vorschlag: Alles beim alten belassen, und die wenigen die es betrifft beißen mit der einen GA eben in den sauren Apfel.

Prop Read/Write hatte ich vor Jahren schon mit der KnxTpUart Lib probiert. Damals gab es massive Timingprobleme. Das ganze war sehr unzuverlässig. Woran es lag hab eich auch nach onaten nicht rausgefunden.
Als ich dann auf Franck Marini's Lib gestoßen bin (dank @Masifi) und gesehen habe, dass dort schon eine erste grundlegende Programmierung implementiert wurde (auf Basis von GA), hab ich mir das angeschaut und weiter getestet und dann ausgebaut: Das ganze lief einfach ohne die Lib für PropRead/Write umzustrukturieren.

Unter'm Strich würde mir die Verwendung von ProRead/Write auch gefallen. Aber die Lib würde größer und auch ein Stückchen komplexer werden (zwei Mechanismen...), und der Code auf Desktop-Seite wird auch aufwendiger (Calimero halt ...).

Es war unter'm Strich einfacher eine GA dafür zu opfern (der eigentlich einzige Nachteil) als die Baustelle auf beiden Seiten (Arduino/Desktop) nochmal komplett aufzureißen und ein erstes Release um weitere Monate zu verzögern.