eibd(war bcusdk) Fork -> knxd

[makki]

Hallo Michael, ich habe den Patch von damals (BCU SDK with eibd / Mailing Lists) überarbeitet und als Pull-Request bereit gestellt.

Danke! ist schon gemerged.
(und Schreibzugriff, den jeder bekommt der brauchbaren Code abliefert)

Was anderes: Git es eine Übersicht, welche Threads es in knxd gibt und auf welche Semaphoren sie benutzen und mit wem sie Daten austauschen? Wenn es noch gar gar nichts gibt, mache ich mich bei Gelegenheit mal daran.

Christian

Nein, gibt es m.W. nicht und es ist auch - gelinde ausgedrückt - etwas unübersichtlich, weswegen ich da auch nur äußerst behutsam rangehe..

Makki, ich habe es unterdessen geschafft, dass die Pakete pthsem und knxd (inklusive knxd-tools) auf github.com/openwrt/packages aufgenommen worden sind,

Sehr schön, da hattest du mehr Erfolg als ich seinerzeit
Eine Sache finde ich nervt bei OpenWRT: das der daemon nicht per Default nach der Installation "enabled" und gestartet wird.. (das dürfte allerdings eine politische Diskussion sein/werden)
Ich hab mein altes ja auch mal hochgeschoben: https://github.com/Makki1/knxd/tree/...y-eibd/openwrt
Sieht jedenfalls ganz fein aus, im Sinne des latent ultra-knappen Flash auf OpenWRT macht evtl. mittelfristig eine weitere Aufteilung der Tools in Sub-Pakete Sinn (siehe mein Packerl) aber das überlasse ich gerne dir.

Makki

[timowi]

Routing Bug:
Wenn das pdf stimmt (geh ich mal von aus) ist das wirklich ein Fehler. Ich konnte es aber mit einem FT12 Interface nicht reproduzieren. Ich vermute ein Fehler im tpuart backend. Meine TPUart kann ich aber gerade nicht finden. Ich würde mir das mal genauer ansehen, da müsste aber jemand mitmachen der das Problem reproduzieren kann.

Threads:
Ich denke C++11 ist keine option. Ist zwar schön portabel, leider aber nicht auf allen Plattformen verfügbar. Das wird sich auch nicht ändern. Für viele embedded Systeme wird es einfach keine updates geben. Daher wird es wohl eher pthreads werden.
Allerdings wird das die Server Komponente komplett ändern. Daher erst später sinnvoll.
Zu eine liste der Semaphoren und ähnliches: Wäre schön, ist aber beim umstieg auf echtes threading wieder hinfällig...


Es ist jetzt wichtig zu planen wie es weiter gehen soll. Meiner Meinung nach sollte niemand einfach Änderungen am Server Code machen. Die Gefahr von Instabilitäten ist immer groß und es gibt keine einfachen Änderungen. Daher würde ich vorschlagen das immer über braches und ein review von min 2 Entwicklern vor dem Merge. Alleine eine Diskussion und Begründung von Änderungen ist hilfreich. Alleine ist viel zu schnell mal was übersehen.
Ich bin dafür für Version 1.0 sogar gar keine Änderungen am Server Code zu machen. Dann wäre die 1.0 eine kompatible Version die genauso stabil sein sollte wie die letzte bcusdk/eibd Version.
Vor umfangreichen Änderungen sollte der Code erstmal Dokumentiert werden.
Die Client Programme sind wesentlich unkritischer, da dort auf Fehler viel einfacher zu Testen ist.

[makki]

Timo spricht mir in allen Punkten aus der Seele

Makki

[timowi]

Wie machen wir das mit der Planung und einem Entwicklungsprozess? Ich finde das wird langsam etwas unübersichtlich. Wenn dann Änderungen einfach im master landen, lässt sich das alles schwer überprüfen.

Ich würde gerne alles was in die Kernkomponenten geht ausführlich überprüfen. Auch wenn es nur "einfache" Änderungen sind. Ich hab es leider schon sehr oft erlebt das dabei schwer zu findende Bugs eingefügt werden. So passiert es schon mal das bei einfügen von Kommentaren versehentlich eine Zeile gelöscht wird. Daher sollte auch sehr einfache Commits geprüft werden.

Daher meine Bitte: Alle Änderungen in eigene Branches. Dieses möglichst einfach halten. Und mergen erst nach Diskussion.

[swiss]

Noch eine kurze Anmerkung meinerseits zu dem Routing Problem...

Ich denke timo hat recht mit dem TPUART als Ursache. Denn ich betreibe mein Wiregate seit bald 3 Jahren nur im IP Routing modus ohne TPUART und habe so auch keine doppelten Telegramme... Erst als mich Tomas auf das Problem angesprochen und ich es nach einem ganzen Tag (und bis spät in die Nacht) auf den eibd eingrenzen konnte, wollte ich das bei mir zuhause noch einmal sauber reproduzieren. Damals habe ich mein produktives Wiregate aus dem Rack genommen und erste Versuche angestellt und konnte das Verhalten reproduzieren. Als das Thema letztens wieder aufgekommen ist habe ich den Versuchsaufbau nochmal so gut wie möglich aufgestellt und versucht zu dokumentieren und das Verhalten wurde mit einem komplet neuen Wiregate dass vorher noch nie in Betrieb war (also nicht von mir dur Bastelein negativ beeinflusst werden konnte) zu 100% reproduziert werden.

Ich denke dass lässt sich auch andererorts mit einem TPUAR und KNXIP Routing reproduzieren. Also hoffe ich dass es da beim BUG fixen weiter geht denn so kann der eibd / knxd nicht sinnvoll als IPRouter verwendet werden da das Programmieren massiv erschwert wird.

Aber vielen Dank an timowi dass du dir das Problem mal näher angesehen hast Das lässt mich wieder hoffen

EDIT: Und was noch schlimmer ist... In meinem Testaufbau hatte ich den Enertex IPRouter auf der Gegenlinie... Wenn ich an der Enertex Linie ein Telegramm erzeugte und diese über IP Routing an den eibd des Wiregate gesendet wurde, kam das Telegramm "geklont" aber mit um 2 reduziertem Routingzähler zurück was nach dem ersten Telegramm zum Absturz des Enertex IPR führte (aus dem Grund ist da in der Aufzeichnung auch nur 1 Telegramm dabei).

Mir ist klar dass der Enertex IPR nicht wegen einem solchen Telegramm abstürzen sollte aber Fakt ist dass er es tut wesshalb diese Kombination momentan garnicht lauffähig ist.

[timowi]

Kann jemand die zweite Situation aus dem pdf noch mal nachbauen? Das Verhalten sollte identisch sein auch wenn gar kein Aktor am Bus angeschlossen ist. Wäre praktisch wenn dann jemand ein log vom knxd aufzeichnen könnte.

Wenn jemand das Problem reproduzieren kann und einen neuen knxd aus den sourcen erstellen kann, sollten wir das schnell gefixt bekommen.

[makki]

Wie machen wir das mit der Planung und einem Entwicklungsprozess?

Ich bin für jegliche Vorschläge offen..
Milestones, Issues auf Github, was sonst?
(Den kompletten, internen rename eibnet->KNXnet/IP habe ich eher für post 1.0 vorgesehen.. aber je früher desto weniger arbeit..)
Das sollte dann IMHO allerdings multilingual (sprich Englisch) sein.
Ich brauch ne git-Schulung zu branches und tags

Noch eine kurze Anmerkung meinerseits zu dem Routing Problem...

Ich habe das bewusst auf "Milestone 1.0" gesetzt, da ich es auch für erheblich halte, fast so wichtig wie den "ETS5-Issue"

EDIT: Und was noch schlimmer ist... In meinem Testaufbau hatte ich den Enertex IPRouter auf der Gegenlinie... Wenn ich an der Enertex Linie ein Telegramm erzeugte und diese über IP Routing an den eibd des Wiregate gesendet wurde, kam das Telegramm "geklont" aber mit um 2 reduziertem Routingzähler zurück was nach dem ersten Telegramm zum Absturz des Enertex IPR führte (aus dem Grund ist da in der Aufzeichnung auch nur 1 Telegramm dabei).

Das ist AFAIK seitens Enertex behoben (erschwert aber die Diagnose der Ursache .. grmpf..)
Das schlimme an IT ist, das es meist nicht eine Ursache, sondern mindestens zwei gibt, die miteinander interagieren.
Werden wir trotzdem finden..

Makki

[Tru]

knxd auf OpenWrt

Sehr schön, da hattest du mehr Erfolg als ich seinerzeit

Von mir hängen auch schon seit zwei Jahren zwei Patch-Vorschläge im Ticket-System. Seit kurzem haben sie aber die Entwicklung der Firmware und den Unterhalt von Software-Paketen getrennt. Nun ist es viel einfacher Updates für normale Packages auf github.com via Pull Request zu beantragen. Dort mache ich jetzt auch meine ersten Schritte.

Eine Sache finde ich nervt bei OpenWRT: das der daemon nicht per Default nach der Installation "enabled" und gestartet wird.. (das dürfte allerdings eine politische Diskussion sein/werden)

Das liegt ja in der Hand des Package Maintainer. Ich habe jetzt die Configfiles und das Init-Script im Paket integriert. Das enable und start könnte mit postinst Anweisungen erledigt werden. Ich habe jedoch davon abgesehen, denn nach der Erstinstallation muss ja sowieso die Konfig angepasst werden und bei einem Upgrade ist es auch nicht mehr nötig.

Ich hab mein altes ja auch mal hochgeschoben: https://github.com/Makki1/knxd/tree/...y-eibd/openwrt
Sieht jedenfalls ganz fein aus, im Sinne des latent ultra-knappen Flash auf OpenWRT macht evtl. mittelfristig eine weitere Aufteilung der Tools in Sub-Pakete Sinn (siehe mein Packerl) aber das überlasse ich gerne dir.

Ja, das hab ich gesehen. Es gibt sicher gute Gründe das knxd-tools Paket zu überarbeiten (Namespace, überflüssige Tools), da warte ich gerne ab, was in deinem knxd Projekt weiter passiert. Die Tools auf mehrere Pakete aufzuteilen halte ich bei einer Grösse von weniger als 35kBytes aber eigentlich nicht für nötig.

Gruss, Othmar

[do13]

Ich denke timo hat recht mit dem TPUART als Ursache.

Ich würde auch auf den TPUART tippen.
Im Datenblatt auf Seite 15 ist der Sendevorgang (TP-UART-IC sending telegram) erklärt. Der TPUART schickt den zu versendenden Frame als Echo wieder zum Host zurück (während er auf den Bus sendet). Der wird dann neu empfangen und per Routing ins Netz geschickt.
Ist nur eine Vermutung, aber das sollte sich mit einem knxd-log belegen lassen.

Dirk

[timowi]

Der TPUART schickt den zu versendenden Frame als Echo wieder zum Host zurück (während er auf den Bus sendet). Der wird dann neu empfangen und per Routing ins Netz geschickt.

Ja, das ist wohl das Problem. Ich hab mal versucht das zu ändern: https://github.com/Makki1/knxd/tree/...art-duplicates Wenn jemand das Problem hat kann er gerne mal testen.

[swiss]

Ich kann den fix leider selber nicht testen da ich 0,0 Ahnung habe wie ich das irgend wo instaliert bekommen würde. Zumal ich momentan nur 2 WG in Betrieb habe und ich dan mächtig Ärger bekommen könnte durch Abhängigkeiten im WG bzw bei Updates usw...

Also kann ich da leider momentan nicht helfen...

[l0wside]

Ich würde auch auf den TPUART tippen.
Im Datenblatt auf Seite 15 ist der Sendevorgang (TP-UART-IC sending telegram) erklärt. Der TPUART schickt den zu versendenden Frame als Echo wieder zum Host zurück (während er auf den Bus sendet). Der wird dann neu empfangen und per Routing ins Netz geschickt.

Ich verfolge eure Arbeit nur lesend, aber mit großem Interesse. Von mir jedenfalls:
Das Echo-Problem kenne ich aus meiner eigenen Stack-Entwicklung (ob die dortige Lösung toll ist, bezweifle ich gerade, deswegen spare ich mir erst mal die Beschreibung).

Was ich nicht verstehe: warum sollte der eibd ein empfangenes Telegramm gleich noch mal rausschicken? Vor allem: wenn er das tut, müsste sich der Vorgang beim Senden des Echos doch wiederholen, d.h. ein unendlich oft wiederholtes Echo produzieren, oder?

Gruß,

Max

[Jockel]

Es wäre toll - damit das nicht untergeht(!!), wenn du das ins Github-Wiki schreiben würdest - oder in ein README.osx o.ä.

Sorry, hab das erst heute gelesen, liege schon seit Tagen flach! Sobald ich wieder auf den Beinen bin und etwas Zeit habe mache ich das gerne, in den nächsten Tagen wird das aber leider nichts. Hab es mir aber in den Kalender geschrieben, damit es nicht vergessen wird!

[timowi]

Was ich nicht verstehe: warum sollte der eibd ein empfangenes Telegramm gleich noch mal rausschicken? Vor allem: wenn er das tut, müsste sich der Vorgang beim Senden des Echos doch wiederholen, d.h. ein unendlich oft wiederholtes Echo produzieren, oder?

Das hast du falsch verstanden. Das Problem tritt auf wenn knxd als router konfiguriert ist. KNXNET/IP <-> KNX TP
Das Packet kommt von knxnet/ip (routingzähler 6) -> wird per tpuart auf den Bus gesendet (routingzähler 5) -> Das Echo wird als eingehendes Packet vom Bus behandelt und wieder über knxnet/ip gesendet (routingzähler 4)

[makki]

.
Das liegt ja in der Hand des Package Maintainer. Ich habe jetzt die Configfiles und das Init-Script im Paket integriert. Das enable und start könnte mit postinst Anweisungen erledigt werden. Ich habe jedoch davon abgesehen, denn nach der Erstinstallation muss ja sowieso die Konfig angepasst werden und bei einem Upgrade ist es auch nicht mehr nötig.

zumindest KNXnet/IP, USB, USB-TPUART kann man problemlos & automatisch im init-script erkennen und dem User damit das unverständliche, lästige konfigurieren+aktivieren ersparen, oder ?
Computer sollen dem Menschen dienen, nicht umgekehrt, so sehe ich das..

Das "Telegrammwiederholungs-Problem" dürfte Dank Timo&Co mit https://github.com/Makki1/knxd/tree/...art-duplicates gefixed sein, ich teste noch.. (ja, nur zur Info: das dauert mal 6-8h sowas..)

Makki