eibd(war bcusdk) Fork -> knxd

[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

[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

[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

[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.

[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]

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.

[makki]

Timo spricht mir in allen Punkten aus der Seele

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]

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

[Tru]

knxd auf OpenWrt

Also, ich wäre brutal dankbar wenn sich jemand darum kümmert und die "Show-stopper" meldet (bzw. fixed) - nicht per Patch sondern lieber im source..

Makki, ich habe es unterdessen geschafft, dass die Pakete pthsem und knxd (inklusive knxd-tools) auf github.com/openwrt/packages aufgenommen worden sind, ebenso libesmtp und linknx. Diese werden nun jeweils im Trunk automatisch erstellt. Ich bin jetzt am Finetuning und nehme Anregungen gerne entgegen.

knxd muss noch ohne USB-Support gebaut werden, weil OpenWrt bei libusb-1.0 auf Version 1.0.9 steht und der Maintainer keine Veranlassung sieht auf Version 1.0.19 zu gehen. Ich glaube er stört sich an der Abhängigkeit von udev, aber da blicke ich nicht durch.

Gruss, Othmar

[christianwicke]

Pull Request für USB-Timeout-Problematik

Hallo Michael, ich habe den Patch von damals (BCU SDK with eibd / Mailing Lists) überarbeitet und als Pull-Request bereit gestellt. In dem Original-Patch war eine Variable nicht initialisiert, dass ist nun gefixt.
Mit dem Patch wird der USB-Timeout nun richtig behandelt. Bisher wurde nach 30 Sekunden ohne Telegramm (Timeout) anschließend das erste Telegramm nicht erkannt.
Ich bin noch git-Anfänger. Falls ich den den Pull-Request nicht richtig erstellt habe, melde dich bitte noch mal.

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

[makki]

Ich hab gerade ein Gentoo Linux ebuild für eibd fertiggestellt als ich auf den thread hier stieß - Jetzt wird daraus wohl ein knxd ebuild , wenn Interesse besteht würde ich das gerne zur Verfügung stellen.

Danke, #17 ist bereits gemerged

Ich hab eine Gira USB Schnittstelle, d.h. damit könnte ich euch testend zur Seite stehen.

Gerne!
Für einen stabilen Betrieb empfehle ich aber weiterhin (USB) TP-UART oder KNXnet/IP..

Wegen pthsem austauschen (falls das noch der plan ist), würde ich C++11 threading als Ziel nehmen. Mag sein, dass man da jetzt aktuelle compiler für braucht, aber bis der code umgebaut ist sind die compiler auch schon wieder weiter verfügbar. Und die threading libs im C++ standard werden wohl sehr lange überleben bzw. gewartet.

Sehe ich im Prinzip zwar genauso (wobei ich eher pthread präferiere) aber wiegesagt: das halte ich eher für ein Ziel einer Version 1.1+ - es sollen "alte" (OpenWRT z.B.) die einfach nen ganz anderen Zyklus haben keinesfalls ausgeschlossen werden.
-> Also wenn vorerst eine parallele Branch.

Zumindest nicht ohne Not, denn es funktioniert mit pthsem ja 24x7x365 (x8 Jahre); ich hasse "Update-Zwang".
"Bezahlen" muss man das damit, das es so nicht in Debian kann, aber damit leben wir jetzt auch schon seit ewig..

Makki

[kfed]

Ich hab gerade ein Gentoo Linux ebuild für eibd fertiggestellt als ich auf den thread hier stieß - Jetzt wird daraus wohl ein knxd ebuild , wenn Interesse besteht würde ich das gerne zur Verfügung stellen.

Ich hab eine Gira USB Schnittstelle, d.h. damit könnte ich euch testend zur Seite stehen. Ich hätte zwar vor demnächst auf ein usb-tp-uart oder knx/ip umzustellen, weil auch der gira homeserver ist nicht stabil mit dem usb-hid dings... Aber das heißt ja nicht, dass ich die gira Schnittstelle wegwerfe. Möchte alles auf opensource umstellen, dass mein Haus auch in 20 Jahren noch sicher von aussen Steuerbar ist, d.h. ich werde die nächste Zeit mit coding rund um das Thema verbringen.

Wegen pthsem austauschen (falls das noch der plan ist), würde ich C++11 threading als Ziel nehmen. Mag sein, dass man da jetzt aktuelle compiler für braucht, aber bis der code umgebaut ist sind die compiler auch schon wieder weiter verfügbar. Und die threading libs im C++ standard werden wohl sehr lange überleben bzw. gewartet.

[makki]

Ich hab es eben mal auf die Schnelle unte OSX probiert die Quellen zu übersetzen. Das funktioniert soweit mit folgenden Ergänzungen zur Anleitung auf GitHUB:

Es wäre toll - damit das nicht untergeht(!!), wenn du das ins Github-Wiki schreiben würdest - oder in ein README.osx o.ä.
Mir einfach den github-Namen mitteilen, wenn das zu unübersichtlich erscheint (was ich durchaus verstehen würde..) bitte kurze Info, dann versuche ich es die Tage einzupflegen.

Kannst Du noch etwas mehr Details liefern, lässt sich das Problem reproduzieren, falls ja wie genau?

@makki, kannst mir den Issue sonst mal zuteilen.

Patrik hat das sehr detailiert dokumentiert (nicht von WG irritieren lassen, es geht rein um eibd/knx; ich selbst habe auch eibd aufm WG gepflegt..)
Ich habs an den Issue https://github.com/Makki1/knxd/issues/16 angehängt, sachdienliche Hinweise sind gerne willkommen

Makki

[mjoe]

Wenn du die Sache mal untersuchen möchtest kann ich dir das PDF mal zukommen lassen.

Ja schick mir doch mal das pdf per pn oder an 'dev at mjoe dot org', danke