Download: http://service.knx-user-forum.de/?co...nload&id=12740
EDIT:
So jetzt mit ein bisschen Zeit erklärt.
Der Baustein legt einen statisch kompilierten knxd unter /usr/local/knxd/knxd ab, der im Logikbaustein gezipped enthalten ist.
Ich habe versucht die Konfiguration gegen Fehlkonfiguration größtenteils abzusichern.
Was geht ... und was geht nicht.
Als KNX Schnittstellen ist standardmäßig ip: (also KNX Router über Multicast eingestellt)
Es ist aber auch möglich über ipt:10.10.0.1 (eine KNX IP Schnittstelle im Tunnelmode zu verwenden)
Nicht getestet aber auch möglich:
ft12:/dev/ttyS0 (FT1.2 Schnittstelle am Homeserver / diese kann dann aber nicht im Homeserver verwendet werden / dazu später mehr)
tpuparts:/dev/ttyS0 (TPUART Schnittstelle, die der Homeserver so sowieso nicht benutzen könnte)
Was nicht geht.
USB - alle USB Schnittstellen funktionieren NICHT mit dem knxd. Was aber nicht heißt das diese nicht für die Busanbindung des Homeservers genutzt werden können
Man kann also z.B. wenn man eine USB Schnittstelle hat und noch eine alte FT1.2 oder TPUART, diese zusätzlich am Homeserver für den knxd nutzen um z.B. KNX Tunnelserver oder aber auch IP Router zu aktivieren für die ETS
Wenn man auf den EIBSCAN des Homeservers verzichten kann (z.B. wenn man das Abfragen über Sequenzen löst), dann kann man auch die Schnittstelle des Homeservers auf IP Router stellen und die FT1.2 oder TPUART Schnittstelle dem knxd überlassen und den Homeserver über den knxd auf dem HS an den Bus anbinden.
Da die Logiken jedoch nach dem SCAN erst starten, geht es halt nicht mit SCAN
Es werden noch diverse Optionen als auch Informationen des knxd an die Baustein IO gelegt.
Ihr solltet aber dennoch aufpassen, da evtl. bei alten HS2 evtl auch HS3 der Speicher eng werden kann, denn es werden ca. 3-5MB RAM genutzt. Sollte es daher Problem bei der Installation des Binary geben und der Speicher zu einem Kernel Problem führen, wäre eine Wiederherstellung des HS nur mit seriellem Kabel möglich.
Der eigentliche Start des knxd erfolgt über EN[1] = 1, den man am besten zum Testen verzögert zum Systemstart auslöst.
Auch ein beenden des Prozesses ist mit EN[1] = 0 möglich.
Viel Spaß
Dank an Smurf für den knxd, evtl könnt ihr ihm ja mal was Gutes zukommen lassen ( https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen?p=1050001#post1050001)
Wen es interessiert. Der static Build des knxd
OLD:
Schnell mal für euch zum testen eingeworfen.
Bei mir läuft der Tunnelserver.
ABER ACHTUNG ... nicht ohne Serielles Kabel in Reichweite testen.
Am besten Triggert ihr EN[1] über KO solange nicht ausgibig getestet
Viel Spaß ..
EDIT:
So jetzt mit ein bisschen Zeit erklärt.
Der Baustein legt einen statisch kompilierten knxd unter /usr/local/knxd/knxd ab, der im Logikbaustein gezipped enthalten ist.
Ich habe versucht die Konfiguration gegen Fehlkonfiguration größtenteils abzusichern.
Was geht ... und was geht nicht.
Als KNX Schnittstellen ist standardmäßig ip: (also KNX Router über Multicast eingestellt)
Es ist aber auch möglich über ipt:10.10.0.1 (eine KNX IP Schnittstelle im Tunnelmode zu verwenden)
Nicht getestet aber auch möglich:
ft12:/dev/ttyS0 (FT1.2 Schnittstelle am Homeserver / diese kann dann aber nicht im Homeserver verwendet werden / dazu später mehr)
tpuparts:/dev/ttyS0 (TPUART Schnittstelle, die der Homeserver so sowieso nicht benutzen könnte)
Was nicht geht.
USB - alle USB Schnittstellen funktionieren NICHT mit dem knxd. Was aber nicht heißt das diese nicht für die Busanbindung des Homeservers genutzt werden können
Man kann also z.B. wenn man eine USB Schnittstelle hat und noch eine alte FT1.2 oder TPUART, diese zusätzlich am Homeserver für den knxd nutzen um z.B. KNX Tunnelserver oder aber auch IP Router zu aktivieren für die ETS
Wenn man auf den EIBSCAN des Homeservers verzichten kann (z.B. wenn man das Abfragen über Sequenzen löst), dann kann man auch die Schnittstelle des Homeservers auf IP Router stellen und die FT1.2 oder TPUART Schnittstelle dem knxd überlassen und den Homeserver über den knxd auf dem HS an den Bus anbinden.
Da die Logiken jedoch nach dem SCAN erst starten, geht es halt nicht mit SCAN
Es werden noch diverse Optionen als auch Informationen des knxd an die Baustein IO gelegt.
Ihr solltet aber dennoch aufpassen, da evtl. bei alten HS2 evtl auch HS3 der Speicher eng werden kann, denn es werden ca. 3-5MB RAM genutzt. Sollte es daher Problem bei der Installation des Binary geben und der Speicher zu einem Kernel Problem führen, wäre eine Wiederherstellung des HS nur mit seriellem Kabel möglich.
Der eigentliche Start des knxd erfolgt über EN[1] = 1, den man am besten zum Testen verzögert zum Systemstart auslöst.
Auch ein beenden des Prozesses ist mit EN[1] = 0 möglich.
Viel Spaß
Dank an Smurf für den knxd, evtl könnt ihr ihm ja mal was Gutes zukommen lassen ( https://knx-user-forum.de/forum/projektforen/knxd/1049547-grundlagen-zum-knxd-mit-installationsanleitung-vor-dem-schreiben-lesen?p=1050001#post1050001)
Wen es interessiert. Der static Build des knxd
Code:
export CPPFLAGS="-static-libstdc++ -static-libgcc -L. -static /usr/libi/i386-linux.gnu/libev.a"" export LDFLAGS="-static-libstdc++ -static-libgcc -L. -static /usr/libi/i386-linux.gnu/libev.a"" ./configure --prefix=/usr/local/knxd \ --enable-static --disable-shared \ --disable-systemd --disable-usb \ --enable-ft12 --enable-tpuarts \ --enable-eibnetip --enable-eibnetserver \ --enable-eibnettunnel --enable-eibnetipserver \ --enable-groupcache --enable-ncn5120 \ --enable-busmonitor --disable-java \ --enable-management sed -i 's/-lev//g' src/server/Makefile make strip --strip-all src/server/knxd
Schnell mal für euch zum testen eingeworfen.
Bei mir läuft der Tunnelserver.
ABER ACHTUNG ... nicht ohne Serielles Kabel in Reichweite testen.
Am besten Triggert ihr EN[1] über KO solange nicht ausgibig getestet
Viel Spaß ..
Kommentar