Gruppenadressen in der Konnekting-Suite

[Ing-Dom]

ich darf GAs nur bis 15/7/255 eingeben.

KNX Gruppenadressen gehen aber von [0-31]/[0-7]/[0-255]. (5bit, 3bit, 8 bit) = 2Byte

Ist das gewollt oder ein Käferchen?

[Masifi]

Technisch dann ja, aber KNX hat eben nur 15/7/255 festgesetzt

[tuxedo]

Wobei 15/7/255 ... das muss ich noch entfernen. Das kollidiert mit der KONNEKTING-GA die für die ganze Programmierung und Co. genutzt wird.

[Ing-Dom]

Nö. Das gilt für PAs, aber nicht für GAs.

größte PA: 15.15.255
größte GA: 31/7/255

[tuxedo]

Du machst mich fertig... Wenn ich das so auf die schnelle rictig sehe, dann nutzen wir seit rund 2 jahren für GA und IA die jeweils falschen byte-macros für die Umrechnung...

*facepalm* Wie konnte sowas passieren?

Ich werde mir das für beta5 nochmal genauer ansehen und ggf. korrigieren.

Damit "könnte" es sein, dass ich auch die Programmier-GA auf 31/7/255 ändere... mal schauen.

[tuxedo]

Siehe auch:
https://github.com/KONNEKTING/KonnektingSuite/issues/35

[Ing-Dom]

Du machst mich fertig...

sorry

aber sonst sehr gelungen, die SW.. ging recht flüssig von der Hand.

Wenn ich da an selfbus denke.. extrem hohe Einstiegshürde!

[Masifi]

Jetzt mal langsam. ich habe noch nie eine GA gesehen die größer ist als 15/7/255. (habe aber auch noch kein Haus :-) )

Aber hier steht: https://www.knx.org/media/docs/downl...delines_de.pdf

Die Zentral-Gruppenadressen werden in der Regel mit der Hauptgruppe 0 bzw. 14 oder 15 versehen. Total können bis 32 Hauptgruppen (0–31) vergeben werden. Eventuelle Einschränkungen bei Linienkoppler, Bereichskoppler, PlugIns, Visualisierungen und Gateways sind zu berücksichtigen.

Man muss aber wohl aufpassen.

[tuxedo]

Fakt ist: SirSydom hat recht. Habs eben in der ETS auch mal praktisch ausprobiert...

GA's kannst du ohne weiteres bis 31/7/255 anlegen...

Wenn man einen LK hat der das nicht mitmacht: Dann ist das nicht das Problem von KONNEKTING, sondern von dem, der seine GAs nicht passend zu seinem Equipment vergibt.

[Masifi]

Hm ich würde es vielleicht doch lassen, da es dann absolut sicher ist. Jemand der mehr braucht, darf die >15 gerne nutzen.

Da sich bis jetzt erst einer gemeldet hat *g* ist das wohl nicht geläufig und ich muss gestehen, ich wusste das auch nicht :-) bei den Beispielen im Internet findet man eigentlich nur Hauptgruppe 15max als Wert.

Bei den zweifach gegliederten GA gibt es auch nur 15 Hauptgruppen oder ?

[tuxedo]

Also den Support für 32 Hauptgruppen sollten wir reinnehmen... ob ich die Prog-GA ändere... weiß ich noch nicht. Ich werde da mal schauen wie das mit LKs ist... Wenn wir nämlich nicht mehr über einen LK hinweg programmieren können, weil die Prog GA auf der Hauptgruppe 31 sitzt wäre das in der Tat doof.

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

[ivande]

sollten die GA ohne Adress-Zuweisung in der Suite nicht als aktive=false gekennzeichnet werden? Oder muss ich dies in der xml von Hand machen,.. bei mir sind alle aktive=true,..

            <CommObjectConfiguration Id="21" GroupAddress="2/2/13" active="true"/>
            <CommObjectConfiguration Id="22" GroupAddress="6/2/13" active="true"/>
            <CommObjectConfiguration Id="23" active="true"/>
            <CommObjectConfiguration Id="24" GroupAddress="2/2/11" active="true"/>
            <CommObjectConfiguration Id="25" GroupAddress="2/2/12" active="true"/>
            <CommObjectConfiguration Id="26" active="true"/>
            <CommObjectConfiguration Id="27" GroupAddress="6/2/14" active="true"/>
            <CommObjectConfiguration Id="28" active="true"/>
            <CommObjectConfiguration Id="29" active="true"/>
            <CommObjectConfiguration Id="30" active="true"/>

irgendwie kommt bei mir der Sortier- und Suchalgoritmus im KnxTpUart.cpp durcheinander, sodass ich nicht auf allen benützen CommObjecten
ein knxEvents() bekomme.. je nachdem ob ich ein paar Adress-Zuweisungen in der Suite dazu oder wegnehme werden bestimme Adressen nicht von KnxTpUart::IsAddressAssigned gefunden..

in der _orderedIndexTable sind alle CommObjecten wiederholt d.h. Doppelt-und Dreifach vorhanden,.. und so kommt die Suche oft zu keinen Ergenis:



Zykluszeit vom Loop (ohne Event) liegt derzeit bei ca. 30-40µs (SAMD21-Controller)

244CommObjekte davon derzeit nur 68 mit Zugewiesener Adresse.. alle 244 CommObjekte sind in der xml aber als aktive=true!

Gruß Ivan

[tuxedo]

Grundsätzlich: Finger weg von der XML. Es gibt, außer du bist KONNEKTING-Entwickler und probierst was neues, keinen Grund in der XML von Hand etwas einzutragen oder umzustellen. Wenn etwas nicht so funktioniert wie es vllt. sein soll, dann ist es allem anschein nach ein Bug.

Mir ist aktuell kein Szenario bekannt, wo _alle_ mit einem active=true versehen sind, ohne dass es eine passende GA dazu gibt. Hab eben den Code dazu nochmal durchgeschaut... Kein anderweitiges Szenario gefunden.

Ich weiß nicht ob du da schon selbst am Werk warst, aber ausschließen kann ich es nicht. Vor allem nicht, da du an der XML ja offenbar selbst Hand anlegen möchtest.

Am besten du fängst mit einer ".kdevice.xml" (die hat keinen Konfigurationsabschnitt) von vorne an und beobachtest das ganze.

Zu deinem zweiten Problem:
Ist das eher generell so, oder ist das ein vermeintlicher Folgefehler? Wenn der Arduino ein KO als Aktiv genannt bekommt, aber keine vernünftige GA dafür hat, dann kann da schon einiges schief gehen.

Notiz an mich selbst:
Ich werde wohl noch eine Prüfsumme oder dergleichen in die XML einbauen müssen, damit die Suite dem Anwender "Abweichungen" die nicht Suite-verursacht sind gleich melden kann.

P.S.
244KOs... das ist immens viel. Bedenke dass wir noch im Beta-Stadium sind es noch nicht ausdiskutiert ist, wie weiter mit (vielen) KOs verfahren wird.

[tuxedo]

[update]

Hab mich etwas zu sehr von der Config verleiten lassen. Da ist das active/inaktiv Flag etwas anders in der Semantik als beim tatsächlichen Programmieren. Dort zählt nämlich ob eine GA überhaupt gesetzt ist.

Lass mir doch mal ein Log zukommen in dem du das Gerät programmierst. Am besten in der Debug-Variante.

[ivande]

natürlich habe ich auch in der XML "gebastelt", ich sehe darin auch den Sinn einer XML?

244KOs... das ist immens viel.

ich benötige bei weitem nicht alle davon..

für jeden Raum welche das Gateway beleuchten können soll, benötige ich derzeit min 6KO's - bei 15 Räumen macht das 90KO's aus, wobei die 6KO für alle Räume gleich sind.
Die KO sind pro Raum gleich, wiederholen sich also nur 15mal (mit unterschiedlichen GA natürlich) im XML mit unterschiedlichen Namen und ID.
Damit ich beim späteren Einfügen von KO's für eine der 15 Gruppen nicht die ganze ID's ändern / verschieben bzw neu eintippen muss, habe ich für jeden Raum "ein paar" unbenützte Reserve KO's dazwischen vergeben, um eine gleichbleibende sich wiederholende Struktur in die CommObj-Liste zu bekommen,.. 6 benötigt + 9 Reserve = 15KO/je Raum
Zuzüglich ein paar KO's für Zentrale-Bedinung,. so komme ich derzeit eben auf 244KO wovon derzeit 68KO auch eine gültige GA zugewiesen haben.

zum eigentlichen Problem:

die _orderedIndexTable im KnxTpUart.cpp hat nach dem Sortieren 244 Index-Einträge, obwohl nur 68KO eine GA haben, also ist jede ID 3 mal in der _orderedIndexTable vorhanden.

Der Suchalgorithmus im KnxTpUart::IsAddressAssigned findet daraufhin einiger der Adressen in der Tabelle nicht, obwohl diese in der Tabelle sind. Ich vermute es hängt mit den auskommentierten Zeilen zusammen, kann es aber erst am Abend testen..

    /*
     * Removed duplicate check: GAs are initialized as "active=false", so they are not used.
     * As soon as an address is set (only done on startup when reading user-settings from eeprom)
     * the flag is set to "active=true" and ComObj is able to communicate.
     * 
     * If device starts with factory settings, all ComObjs have *no* GA, which leads to "duplicates"
     * if this check is enabled.
     * 
     * Also it makes no sense to check for duplicates, as it is quite a use-case to have 
     * multiple ComObjs with same GA
     */
    // Deduct the duplicate addresses
//    for (byte i = 0; i < listSize; i++) {
//        if (!IS_COM(i)) continue;
//        for (byte j = 0; j < listSize; j++) {
//            if ((i != j) && (ADDR(j) == ADDR(i)) && (IS_COM(j))) { // duplicate address found
//                if (j < i) break; // duplicate address already treated
//                else {
//                    _assignedComObjectsNb--;
//                    DEBUG_PRINTLN(F("AttachComObjectsList : warning : duplicate address found! i=%d:0x%04x j=%d:0x%04x"), i, j, ADDR(i), ADDR(j));
//                }
//            }
//        }
//    }

Gruß