Irgendein Bug bekannt beim Adressempfang?

[andi11]

Ich bin gerade bei der Inbetriebnahme meiner Universalaktoren.
Ich habe 2 baugleiche Aktoren. Beide funktionieren beim Empfang auf z.b. Adresse 3/xx/yy (Rollosteuerung)
Bei Adresse 6/1/yy tut sich bei einem Aktor garnichts, obwohl dort definitiv Werte verschickt werden.

Beim "fehlerhaften Aktor" 6/1/130 dpt 9.001 geht nicht, aber 3/1/130 dpt9.001 geht.
Beim funktionierenden geht z.b. 6/1/020
Gibts da irgendeinen bekannanten Bug in den ich reinschlittern könnte?
Ich weis nicht so recht, wie ich da mit der Fehlersuche anfangen soll...
(Geht nicht heist bei mir aktuell, es wird nichtmal die Funktion void knxEvents(byte index) aufgerufen, wenn ein Wert eintrudeln sollte (in der Suite/ Gruppenmonitor taucht er auf)

Sourcecode und XMLs für die Suite im Anang (AK_RHS1 geht, AK_RHS2 nicht)

[tuxedo]

Hatte das mal in einem anderen adressenreich. Eugenius konnte das aber bei sich nicht reproduzieren. Hatte noch nicht Zeit das näher zu debuggen. Wenn du es schaffst das Phänomen auf einen minimalistischen Sketch zu reduzieren, kann man sich das genauer anschauen.

[andi11]

werden die Adressen nach irgendeiner Sortierung abgearbeitet?
=> Stört es Wenn Comobj ID 1 6/1/140 und Comobj ID 3 6/1/120 sind?

[tuxedo]

KONNEKTING sortiert intern die KOs nach der GA um beim Empfang eines Telegramms sehr schnell zu wissen ob die GA des Telegramms in der Liste der KOs verwendet wird. Könnte mir vorstellen dass in diesem Umfeld noch ein Bug ist. Wenn ja, dann haben wir den damals so übernommen. Mit Beta5 muss ich den Abschnitt eh komplett überarbeiten. Dauert aber halt noch ne Weile.

Wenn du das Problem aber auf einen minimalistischen Sketch (der ohne spezielle Hardware läuft) reduzieren kannst wäre das super hilfreich für die Fehlersuche.

[ivande]

Ich hatte auch Probleme mit verpassten Adressen.. nachdem ich in den folgenden Zeilen im File KnxTpUart.cpp (ab Zeile181) die Kommentare entfernt hatte, funktionierte das ganze bisher Problemlos.

   /*
     * 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ß Ivan

[tuxedo]

Leute, wenn ihr ein Problem erkennt, und eine vermeintliche Lösung dafür findet: Wäre es da in einem OpenSource Projekt nicht angebracht das zur Sprache zu bringen, statt einfach irgendwo was zu ändern?

Hatte den Code mit Absicht und mit gutem Grund deaktiviert. Verstehe aber auch noch nicht wie ein Wiedereinschalten bei dem Problem helfen soll. Warum der Code deaktiviert wurde, steht ja im Kommentar darüber.

Fakt ist:

Bitte das Problem auf einen möglichst kurzen, universellen Sketch reduzieren, dann können wir das (gemeinsam?) debuggen. Hab auch einen hardware-Debugger da und kann Code-Zeile für Code-Zeile live ausführen und in alles rein schauen. Damit sollte sich der Fehler finden lassen.

Wer den Fehler suchen will, der müsste hier ansetzen: https://github.com/KONNEKTING/Konnek...pUart.cpp#L551
Da laufen alle eingehenden Telegramme durch und es wird geschaut ob es zu der GA des Telegramms auch ein KO gibt. Gibt es kein KO dazu, wird das Telegramm verworfen. So die Idee dahinter.

Tipp: Zeile 553 und 596 einschalten und die Ausgabe beobachten während ein solches betroffenes Telegramm gesendet wird.

[ivande]

ich hatte bereits versucht das Problem das damals bei mir auftauchte (DMX-Gateway) zur Sprache zu bringen,..
#Gruppenadressen in der Konnekting-Suite #15
ich gebe zu: mein Deutsch, bzw. meine Erläuterung in diesem Post sind unverständlich,... bzw.

widerspricht vom Satzbau und der Wortwahl her jeder Logik.

was ich bei mir damals definitiv feststellen konnte ist, dass die _orderedIndexTable doppelte bzw mehrfach gleiche sich wiederholende Werte(Adressen) in der Tabelle hatte. (hab ich mit dem hardware-Debugger gesehen). Weshalb die zu lauschenden Adressen in dieser Tabelle mehrfach vorhanden waren, kann ich mich leider nicht mehr erinnern.. Die Ursache hierfür, kann auch in einer von mir falsch bearbeiteten XML-Datei liegen,..
Was ich damals noch definitiv mit dem Debugger erkannte, ist, dass bei mehrfach sich wiederholenden Werten in der _orderedIndexTable, der Suchalgorithmus (welcher ja diese Tabelle _orderedIndexTable durchsucht) im KnxTpUart::IsAddressAssigned nicht funktionieren kann..

Jedenfalls waren die doppelten Werte nicht mehr in der _orderedIndexTable, als ich die oben erwähnten Zeilen "// Deduct the duplicate addresses" wieder zum Leben erweckte.


Gruß Ivan

[tuxedo]

Leider bist du damals nach meinem Post nicht mehr drauf eingegangen. Und ich habs dann auch aus den Augen verloren wie der aktuelle Stand bei dir war.

Jedenfalls waren die doppelten Werte nicht mehr in der _orderedIndexTable, als ich die oben erwähnten Zeilen "// Deduct the duplicate addresses" wieder zum Leben erweckte.

Ah, jetzt dämmert's. Vielleicht ging bei dieser Implementierung (die stammt nicht von mir) nur darum, duplikate die beim "sortieren" - wieso auch immer - enstanden sind, wieder zu entfernen, also die Liste zu "reparieren". DAS wäre möglich.
Dann muss man sich den Code zum sortieren der Liste mal anschauen...

[ivande]

genau das war das Problem

Duplikate die beim Sortieren - wieso auch immer - einstanden sind

nicht mehr drauf eingegangen

sorry hierzu.. das DMX-Projekt hatte (und hat immer noch) viele zeitintensive offene Baustellen.. deswegen weiss ich oft selber nicht mehr wo der aktuelle Stand bei mir ist..

Sich als Hobbyprogrammierer in einen bestehenden Code einzuarbeiten ist eh schon nicht so leicht, Probleme dabei noch in deutschen Sätzen zu Papier zu bringen, ist dann der Gipfel der Gefühle

Vielleicht liegt das Problem vom andi11 ja genau auf dieser Wellenlänge..

es wird nichtmal die Funktion void knxEvents(byte index) aufgerufen

dies klingt jedenfalls verdächtig



Ein Aktivieren der Zeilen

 // Deduct the duplicate addresses

im File KnxTpUart.cpp (ab Zeile181) ist sicher einen Versuch wert.


Vielleicht werf ich diese Tage nochmal dem Debugger an, und schaue weshalb die doppelten Einträge überhaupt entstehen.. (Ursache bekämpfen - anstatt den Symptomen)

Gruß Ivan

[tuxedo]

Sich als Hobbyprogrammierer in einen bestehenden Code einzuarbeiten ist eh schon nicht so leicht,

Ich kann dir versichern, das ist als Hauptberuflicher Software-Entwickler auch nicht einfacher. Fremdcode ist immer "anders" :-)

Wenn in knxEvents nichts ankommt, dann liegt das mit ziemlicher Sicherheit an der GA Auswahl-Logik bzw. der internen GA-Liste.

Zeile ab 181 wieder einschalten: Dann bitte schauen dass alle KOs eine zugewiesene GA haben. In-Aktive KOs haben alle 0x0000 als GA und sind damit Duplikate, die dann entsorgt werden, was zu weiteren Fehlern führen kann.

Wenn ich zwischendurch Zeit habe, schaue ich auch mal in den Sortier-Code. Mir ist kein Sortier-Algorithmus bekannt der Duplikate erzeugt...

[andi11]

ich werde versuchen es auf einen kleinen Sketch zu reduzieren. Aber ich habe aktuell noch keinerlei belastbare Infos. Auser das ich es ab und an auch mal bei dem anderen Aktor feststellen kann, ein restart aber hilft... (Gefühlt geht etwas schief wenn die Reihenfolge ist Controller kriegt Spannung => NCN kriegt Spannung vom KNX (arbeite mit zusätzlicher Versorgung))
Dort sollte eigentlich das KNX Init erst garnicht klappen, aber vielleicht passiert da was beim booten. VORSICHT REINE SPEKULATION UND NOCH NICHT BESTÄTIGT


=> Soll ich die Zeilen reinmachen, oder es lieber lassen?

[tuxedo]

Wenn du alle KOs mit GAs versiehst und keine GA doppelt verwendest,, kannst du den Code-Abschnitt wieder einschalten.

Habe mittlerweile die Sortier-Methodik angeschaut... Meine güte, dass mit das nicht schon vorher aufgefallen ist. Die taugt gar nix und hat wenig bis nichts mit modernen Sortier-Algorithmen zu tun.

Werde das reimplementieren, so dass man

a) schneller sortieren kann
b) duplikate keine Rolle spielen

Bis dahin:
Theoretisch sollte das Problem nicht auftreten, wenn alle KOs im System mit einer GA versehen sind und keine GA doppelt verwendet wurde.

[andi11]

Wenn du alle KOs mit GAs versiehst und keine GA doppelt verwendest,, kannst du den Code-Abschnitt wieder einschalten.

Hmmm, das mit "keine GA doppelt verwenden" krieg ich hin. Aber das mit "alle KOs" verwenden schaff ich nicht. Dafür macht der Aktor einfach zuviel, und ich habe 2 davon => ich verliere völlig den Überblick wenn ich die device XML pro Aktor mache (da bei beiden unterschiedliche KOs belegt sind) Es ist eh das Konnekting Gerät bei mir, dass mit Abstand am meisten KOs und Parameter hat.

[tuxedo]

Ich meinte jetzt eher testweise, nicht auf dauer.

Bin nebenbei schon dran den Sortier-Algo mal isoliert zu betrachten und umzustellen. So richtig schlau werde ich aktuell noch nicht.

Ich stecke folgendes in den bestehenden Algorithmus rein:

[0] = 0x0001
[1] = 0x0004
[2] = 0x0003
[3] = 0x0002
[4] = 0x0005

und bekomme folgende sortierung raus:

[0] = 0x0000
[1] = 0x0003
[2] = 0x0002
[3] = 0x0001
[4] = 0x0004

--> Das ist Müll. Entweder ich habe beim isolieren des Algos in eine kleine C-Konsolenanwendung was falsch gemacht, oder der Algo ist tatsächlicher Blödsinn.

[andi11]

Ich meinte jetzt eher testweise, nicht auf dauer.

Das hatte ich auch so verstanden, aber es wäre eben bei dem Aktor ne verdammt große Änderung, so dass es eben nicht wirklich was hilft, um den Fehler einzugrenzen.
Die Sortierung ist richtig. Sie liefert aber den Index zurück, nicht den Wert!