eibd(war bcusdk) Fork -> knxd

[swiss]

Naja um das Echo zu erkennen kann man bei identischen Paketen auch den Routingzähler vergleichen... Kommt das gleiche Telegramm innerhalb einer gewissen Zeit mit identischem Routingzähler wie vom TPUART gesendet wurde, ist etwas falsch. Da alle Telegramme von TLN mit 6 Starten und beim passieren der Koppler um 1 reduziert werden...

Wenn also von oben (IP) ein Telegram mit z.B. Routingzäler 5 kommt und der TPUART das Telegramm mit Routingzähler 4 sendet, kann das gleiche Telegramm mit ebenfalls Routingzähler 4 nicht von einem Teilnehmer sein.

Wobei mir gerade einfällt dass bei einem Echo eigentlich als Absender die PA des TPUART im Adressfeld stehen müsste. Also wäre es auch möglich die Telegramme von der PA des TPUART auszufiltern.

Irgend wie muss es ja eine Lösung für das Problem geben denn mit dem gleichen Phänomen müssen ja auch echte IP Router fertig werden (und werden sie auch...). Gibt es da keine Vorgaben wie das nach KNX Standard zu lösen ist?

[timowi]

Ich habe das bereits so implementiert, das der header verglichen wird und dann das packet ignoriert wird. Das muss jetzt halt getestet werden. Für Verbesserungsvorschläge bin ich natürlich offen.

Wobei mir gerade einfällt dass bei einem Echo eigentlich als Absender die PA des TPUART im Adressfeld stehen müsste. Also wäre es auch möglich die Telegramme von der PA des TPUART auszufiltern.

Wie kommst du da drauf? Es kommt genau so zurück wie es dem tpuart übergeben wurde bzw wie es auf den bus gesendet wird. Erstellen der packete macht nicht der tpuart.

Irgend wie muss es ja eine Lösung für das Problem geben denn mit dem gleichen Phänomen müssen ja auch echte IP Router fertig werden (und werden sie auch...).

Müssen sie nur wenn ein tpuart verbaut ist. Dann muss die kommunikation mit den tpuart halt entsprechend umgesetzt werden.

Routing ist glaub ich noch gar nicht richtig implementiert. Es wird einfach alles weitergeleitet. Ich denke da sollte auch gefiltert werden, von wo nach wo eigentlich weitergeleitet wird.

[do13]

Kannst du den selben Versuch noch mal mit dem branch https://github.com/Makki1/knxd/tree/...art-duplicates durchführen?

Bin noch kurz zu einem Test gekommen:

Layer 0(02501640,54B00F57) Recv(018): 06 10 05 30 00 12 29 00 BC E0 11 00 67 07 02 00 80 00
Layer 1(02501640,54B00F57) Recv(012): 29 00 BC E0 11 00 67 07 02 00 80 00
Layer 8(02501160,54B00F57) Recv_Route L_Data low from 1.1.0 to 12/7/7 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 3(024E03D0,54B00F57) Send L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 2(024CFC00,54B00F57) Send L_Data low from 1.1.0 to 12/7/7 hops: 05 T_DATA_XXX_REQ A_GroupValue_Write 00
Layer 0(024CFC00,54B00F57) Write(020): 80 BC 81 11 82 00 83 67 84 07 85 D2 86 00 87 80 88 00 49 60
Layer 0(024CFC00,54B00F57) Recv(001): BC
Layer 0(024CFC00,54B00F57) Recv(001): 11
Layer 0(024CFC00,54B00F57) Recv(001): 00
Layer 0(024CFC00,54B00F57) Recv(001): 67
Layer 0(024CFC00,54B00F57) Recv(001): 07
Layer 0(024CFC00,54B00F57) Recv(001): D2
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 00
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 80
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 00
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 60
Layer 0(024CFC00,54B00F57) ignoring this telegram. we send it.
Layer 0(024CFC00,54B00F57) Recv(001): 8B
Layer 0(024CFC00,54B00F59) Recv(001): BC
Layer 0(024CFC00,54B00F59) Recv(001): 15
Layer 0(024CFC00,54B00F59) Recv(001): 06
Layer 0(024CFC00,54B00F59) Recv(001): 29
Layer 0(024CFC00,54B00F59) Recv(001): 6B
Layer 0(024CFC00,54B00F59) Recv(001): C3
Layer 0(024CFC00,54B00F59) SendAck 10
Layer 0(024CFC00,54B00F59) Recv(001): 00
Layer 0(024CFC00,54B00F59) Recv(001): 80
Layer 0(024CFC00,54B00F59) Recv(001): 01
Layer 0(024CFC00,54B00F59) Recv(001): 2C
Layer 0(024CFC00,54B00F59) Recv(001): 7C
Layer 1(024CFC00,54B00F59) Recv(011): BC 15 06 29 6B C3 00 80 01 2C 7C
Layer 2(024CFC00,54B00F59) Recv L_Data low from 1.5.6 to 5/1/107 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 01 2C
Layer 3(024E03D0,54B00F59) Recv L_Data low from 1.5.6 to 5/1/107 hops: 04 T_DATA_XXX_REQ A_GroupValue_Write 01 2C
Layer 8(02501160,54B00F59) Send_Route L_Data low from 1.5.6 to 5/1/107 hops: 03 T_DATA_XXX_REQ A_GroupValue_Write 01 2C
Layer 1(02501640,54B00F59) Send(013): 29 00 BC B0 15 06 29 6B 03 00 80 01 2C
Layer 0(02501640,54B00F59) Send(019): 06 10 05 30 00 13 29 00 BC B0 15 06 29 6B 03 00 80 01 2C

Damit bekommen wir das Problem in den Griff. Ob es noch irgendwelche Nebenwirkungen hat müssten jetzt weitere Tests zeigen.

Dirk

[saft6luck]

An diesem Punkt bin ich nicht einig. Der TPUART speichert den Frame mindestens teilweise zwischen, siehe Timing-Diagramm. Wenn der TPUART den Frame nicht sofort senden kann, speichert er ihn erst mal zwischen und wiederholt ihn ggf. bis zu drei Mal (lässt sich konfigurieren).

Thema zeitgleiches Senden, genau. Dann habe ich aber nicht den gleichen Frame empfangen, also Fall 2.

Laut Diagramm empfängt der TPUART das zu sendende Telegramm zeitgleich wieder und überträgt es mit der Sendebestätigung (oder einem Fehlercode) an den Host. So kann man schon unterscheiden, ob es das eigene Telegramm war, dass man jetzt empfangen hat.

Für den 1. Schuß würde ich die Sendebestätigung prüfen und gut ist.

Es ist also nicht gesagt, dass der erste empfangene Frame nach dem Schreiben eines Frames in den TPUART das zugehörige Echo ist.
Einen Fehler meldet der TPUART nur dann, wenn du einen zweiten Frame senden willst, bevor der erste komplett gesendet wurde - jedenfalls lese ich so das Datenblatt.

Der zu sendende Frame bleibt also weiterhin im Host Puffer und wird beim nächsten Telegramm verglichen.

Natürlich kann man auch darauf verzichten das Echo zu prüfen, es würde sich aber anbieten, denn eine Checksumme kann die Übertragung nicht vollständig absichern.

[saft6luck]

Ich habe das bereits so implementiert, das der header verglichen wird und dann das packet ignoriert wird. Das muss jetzt halt getestet werden. Für Verbesserungsvorschläge bin ich natürlich offen.

Wenn du nur das darauffolgende Telegramm vergleichst, könnte gleichzeitiges Senden (insbesondere hohe Buslast) das Problem wieder zeigen.

[makki]

Bei KNX kann immer nur einer senden und die anderen müssen in der Zeit still sein und lauschen bis die Leitung wieder frei ist...

Leider ist es etwas komplizierter, aber ich habe seit Jahren das erste mal das Gefühl, das wir uns in der Sache einer wirklichen Lösung nähern.
Das Problem ansich ist mir ja seit langem bekannt! Das Verhalten des eibd ist da nicht richtig, aber wie bereits von vorpostern angemerkt, ist eine Telegramm-Wiederholung (hier) unnötig&lästig, sollte aber nicht zu einem echten Problem führen,
-> weil das kann & darf (im Einzelfall) immer mal vorkommen.
Will ich für mitleser nur dazusagen

Ja. Das schlimmste wäre ein knxd den zufällig nach zu 40 Tagen Telegramme verliert... Das ist fast unmöglich zu testen und zu Debuggen.

Jep, das wäre fatal und geht garnicht. Genau deswegen wird das auch seit Jahren immer - teils wochenlang! - live getestet, weil nur so bekommt man das mit (Licht geht an Tag 39 im Bad nicht an..)

Ich finde mit der momentanen Situation ist es sehr schwer zu verfolgen, ob jemand ein commit in die wichtigen Dateien gemacht hat.

Ich bin eigentlich eher angenehm überrascht, ich habs mir schlimmer vorgestellt

Also dann folgendermaßen?:
Alles was in die Verzeichnisse
backend common libserver server usb
geht nur per branch mit review. Alles direkten commits werden ohne Rechtfertigung rückgängig gemacht. Bitte auch bei reinen Kommentaren und Umbenennungen. Ich habe es leider schone erlebt das bei so "einfachen" Änderungen irgendwo eine Klammer verschoben wurde, ein break, continue oder ähnliches irgendwo aufgetaucht ist.

Sowas in der Art, ich würde es aber nicht ganz so "hart" sehen.
Also Änderungen, wo "nebenbei" 400 Tabs oder spaces befummelt werden gehen natürlich garnicht;
kleine Aufräumarbeiten (Comments, Idents) in hübsch segmentierten commits schon.
Für grobe Änderungen eine branch, wenn keiner Widerspricht kanns derjenige dann mergen.
Post-1.0 wirds dann eh "master"(bezeichne ich als "trunk", da darf man durchaus dann auch mal "fummeln") und release-x.y geben..

(kein Kommentar meinerseits zu manchem ist übrigens bitte keineswegs als abwertend oder Missbilligung zu sehen, sondern eher als stumme Zustimmung!)

Planung 1.0: ist hier Anfangs bereits beschreiben und in dem Milestone auch: 100% eibd 0.0.5 mit dringend notwendigen fixes;
danach: ist Diskussions-Sache, in Issues oder Milestone reinschreiben(?)

Ich weiß das es nervig ist Änderungen kompakt zu halten und code reviews sind auch langweilig. Leider ist es aber viel zu einfach Fehler einzufügen.

100% Ack: Das hat schon seine Richtigkeit, ob nervig oder nicht! Ich habe selbst schon 99x zuviel irgendeinen "Quickfix" gemacht.. (die letzten 4J u.a. mit patches am eibd..)

Auch sollten wir uns mal Gedanken machen, wie wir das planen und koordinieren. Wenn jeder einfach irgendwo "hackt" wird das eher nichts. Ich würde gerne einige Teile (z.B. das cemi/emi... handling) kapseln (einiges scheint eher aus einem C Projekt) und dann auch Tests für schreiben.

Planen/Koordinieren: momentan finde ich passt das mit Issues bei Github (kann man ja auch nen Assignee eintragen, Milestones), Diskussion dort oder eben hier (und das ganz bewusst öffentlich, da jeder - auch stille Mitleser daran teilhaben sollen!)
Mittelfristig sollte es aber auch wieder eine Mailing-Liste o.ä. geben, weil halt nicht jeder deutsch spricht.. Die bcusdk-devel tuts aber da für den Moment denke ich..

Es gibt auch das Angebot seitens der Admins dafür hier ein Unterforum einzurichten, nur sehe ich den Bedarf noch(?) nicht, bisher ist die Diskussion hier in diesem Thread (konzentriert!) und auf github IMHO sehr zielgerichtet und auch zielführend, oder?
(Die zig PN's und emails zum Thema "makki, sag mal, wie starte ich eibd auf meinem Raspi" streiche ich jetzt mal aus dieser Betrachtung Das machen wir wenn 1.0 steht&geht)

Makki

P.S.: ich freue mich übrigens echt über die rege Beteiligung! Und nochmal: Kein Kommentar zu etwas bedeutet im Regelfall schlicht Zustimmung.

[Tru]

Githup Änderungsprozess

Sowas in der Art, ich würde es aber nicht ganz so "hart" sehen.

Obwohl ich bei der Entwicklung kaum viel beitragen kann und meine Meinung deshalb nicht besonders relevant ist, möchte ich sie trotzdem kurz äussern, zumal ich jetzt auch meine ersten Erfahrungen mit Github gemacht habe:

• Jede Änderung soll in einem spezifischen Branch im eigenen Fork gemacht und verifiziert werden.
• Der Merge soll mit einem Pull Request beantragt werden. Mindestens eine weitere Person muss es gutheissen. Bekanntlich übersieht man seine eigenen Fehler sehr leicht. Da macht es Sinn dass es eine, noch besser mehrere Personen anschauen oder sogar prüfen.
• Wenn eine Zustimmung vorliegt, kann jeder mit Schreibrecht den Merge durchführen. Im Trivialfall kann der Zustimmende den Merge ja gleich machen. So geschieht jede Änderung im Master im Mehraugenprinzip
• Der spezifische Branch im eigenen Repository kann zum Schluss wieder gelöscht werden, damit es übersichtlich bleibt.

Ich finde der Master Branch in Makki's Repository sollte nach Möglichkeit dauernd auf Produktivlevel gehalten werden.


Gruss, Othmar

[timowi]

Jep, das wäre fatal und geht garnicht. Genau deswegen wird das auch seit Jahren immer - teils wochenlang! - live getestet, weil nur so bekommt man das mit (Licht geht an Tag 39 im Bad nicht an..)

na, dann sind es halt 160Tage (auch nicht viel besser). Vielleicht auch nur in einer Konstellation die nicht geststet wird... Daher min Fazit: Praktisch nicht testbar.

Sowas in der Art, ich würde es aber nicht ganz so "hart" sehen.
Also Änderungen, wo "nebenbei" 400 Tabs oder spaces befummelt werden gehen natürlich garnicht;
kleine Aufräumarbeiten (Comments, Idents) in hübsch segmentierten commits schon.

Das sehe ich schon so "hart". Gerade auch "einfache" commits sollten erst in in branch und dann mergen nach review. Da habe ich einfach zu viel schlechte Erfahrungen. In whitespace changes und auch reinem dokumentieren verstecken sich zu leicht Änderungen, die man übersieht. Sei es mangels disziplin (ach das muss eh gemacht werden und ist ja einfach...), weil man im editor versehentlich was löscht/einfügt/verschiebt/dupliziert oder weil man nicht auf einen sauberen branch arbeitet (Mal was getestet und und dann vergessen). Und schon hat man eine Änderung sehr gut versteckt. Fürs review sollten dann tools ingesetzt werden. Sonst übersieht man das in vielen Zeilen einfach.

Für grobe Änderungen eine branch, wenn keiner Widerspricht kanns derjenige dann mergen.
Post-1.0 wirds dann eh "master"(bezeichne ich als "trunk", da darf man durchaus dann auch mal "fummeln") und release-x.y geben..

Ich finde man kann ruhig auf positive Rückmeldung warten. Sonst weiß man nicht ob stillschweigende Zustimmung ist, oder bloß niemand Zeit hatte...
Auch nach dem Release sollte nicht gefummelt werden. Wir sollten da schon mehr auf Entwicklungprozesse setzten als haufenweise gebastel am code. Knxd hat ein Haufen Zustandsautomaten und viele unterschiedliche Codezweige. Da wird viel zu einfach was kaputt gemacht. Und "vor dem nächsten release finden wir alle Fehler und dann wird das schon" funktioniert einfach nicht.


100% Ack: Das hat schon seine Richtigkeit, ob nervig oder nicht! Ich habe selbst schon 99x zuviel irgendeinen "Quickfix" gemacht.. (die letzten 4J u.a. mit patches am eibd..)

Obwohl ich bei der Entwicklung kaum viel beitragen kann und meine Meinung deshalb nicht besonders relevant ist, möchte ich sie trotzdem kurz äussern, zumal ich jetzt auch meine ersten Erfahrungen mit Github gemacht habe:
[LIST][*]Jede Änderung soll in einem spezifischen Branch im eigenen Fork gemacht und verifiziert werden.
...
Ich finde der Master Branch in Makki's Repository sollte nach Möglichkeit dauernd auf Produktivlevel gehalten werden.

Genau so sollte es sein (Meiner Meinung nach). Branching und Merging ist sehr schnell und leicht mit git. Das sollte ausgiebig genutzt werden. Die Verzögerung dadurch spielt eigentlich keine Rolle. Wenn jeder einfach in master committed wird es schnell unübersichtlich. Diskussionen über Änderungen werden sehr schwierig. Dann wird es sehr schnell eher ein Gebastel als eine Zielgerichtete Entwicklung. Für die Client programm mag das nicht so schlimm sein, für den Kern halte ich das aber für den falschen weg.

[lustigerpinguin]

Hallo Zusammen,

vorweg: ich kann nicht programmieren

Bei meinem Arbeitgeber arbeiten wir mit gitlab für die Versionsverwaltung.
Die Daten aus dem Git gehen dann zum Bauen direkt an unseren internen Jenkins (z.B. würde das verm. auch hier gehen: https://www.cloudbees.com/resources/...rogram-details).
Alternativ auch noch hier mit: https://travis-ci.org

Was testen angeht: mit einer Anleitung/makefile bekomme ich auch den Sourcecode gebaut (den Dreisatz ./configure && ./make && ./make install schaffe ich normalerweise auch )

Testen geht bedingt, mir fehlt die KNX - Hardware; die kann ich evtl. noch auf der Arbeit testen; tcpdump würde aber z.B. gehen, solange keine Rückmeldung kommen muss.

Ich hoffe die Info hilft etwas.

Gruß

lustigerpinguin

[makki]

na, dann sind es halt 160Tage (auch nicht viel besser). Vielleicht auch nur in einer Konstellation die nicht geststet wird... Daher min Fazit: Praktisch nicht testbar.

Klar, es ist niemals alles testbar - selbst in so einer banalen Umgebung wie KNX

Aber für banale Dinge/Fehler wären automatische Tests schon hilfreich..

Das sehe ich schon so "hart". Gerade auch "einfache" commits sollten erst in in branch und dann mergen nach review. Da habe ich einfach zu viel schlechte Erfahrungen. ..

So soll es denn wegen mir auch sein.

Wenn genug beisammen sind, klappt das vermutlich auch (wenn ich am Anfang allerdings auf eine dritte Meinung zu den auto*-changes von dir gewartet hätte, naja, dann würden wir vermutlich immernoch dastehen und warten ..)
Also es sollte den Entwicklungsprozess halt nicht behindern, ohne das die Qualität auf der Strecke bleibt.
Gratwanderung nennt man das glaube ich..

Makki

[JNK]

Ich bin gerne bereit den ein oder anderen Commit zu reviewen.

[ctr]

Wir haben jetzt übrigens hier zwei Projekte, die sich knxd nennen. Das könnte zu Verwirrungen führen...
Siehe: https://knx-user-forum.de/forum/supp...wiregate/26135

Teil 1- knxd:

Der knxd ist ein abgespeckter WiregateDaemon. Dieser wurde von sämtlichen Abhängigkeiten zum originalen wiregated.pl befreit und konfigurierbar gemacht. Dadurch kann dieser auch auf dem original WireGate neben dem wiregated.pl eingesetzt werden.

[makki]

Wir haben jetzt übrigens hier zwei Projekte, die sich knxd nennen. Das könnte zu Verwirrungen führen...
Siehe: https://knx-user-forum.de/forum/supp...wiregate/26135

Das war mir bewusst - und ich hatte seinerzeit schon darauf hingewiesen, das ich die Namensgebung vom ebus-knxd als fork vom wiregated nicht für sehr sinnvoll halte (der auf den eibd zugreift).

Nachdem ich ersteren geschrieben und zweiteren geforked habe, sehe ich das ziemlich entspannt:
Mal sehen, was sich unter der Bezeichnung "knxd" durchsetzt

Makki

P.S.: Soll heissen: der wiregated.pl-Fork muss einfach umbenannt werden

[Elwedritsche]

Kleiner Tipp: 1) Das "Echo" vom TP-UART ist die Basis für die L_Data.conf, also die Information darüber, was aus einem L_Data.req am Ende auf dem Bus geworden ist (abweichende Definition der Crtl Field (1/2) Flags für L_Data.conf im Gegensatz zu L_Data.req beachten). 2) Das Tunneling Interface eines Routers sitzt topologisch auf der Sublinie. Das heißt, dass a) der HopCount beim Schreiben auf die Linie nicht dekrementiert wird und b) Telegramm, die "nach oben" geroutet würden (auch an den Router selbst adressierte), dennoch erst einmal auf die Sublinie geschrieben und "selbst bestätigt" werden. Gruß, Jan.

[saft6luck]

2) Das Tunneling Interface eines Routers sitzt topologisch auf der Sublinie. Das heißt, dass a) der HopCount beim Schreiben auf die Linie nicht dekrementiert wird und b) Telegramm, die "nach oben" geroutet würden (auch an den Router selbst adressierte), dennoch erst einmal auf die Sublinie geschrieben und "selbst bestätigt" werden.

Klar.

Kannst du noch bei folgendem Problem helfen?
Wenn der Router die 0.0.0 hat, auf welche Linie geht dann ein Tunnel, welches Medium hat dann die Linie und welches die übergeordnete Linie?