[Frage] Diskussion/Fragen zum Wiregate Plugin Container

[tger977]

ok, ich habe nun was am Laufen.

Ich habe nun wirklich nochmal eine neue vclient Version compiliert und damit geht es nun! Warum es da aber immer zu einer Fehlermeldung zu einer nicht auffindbaren Datei kam?!

Vielen Dank nochmal, Jens!

[tger977]

So, es ist nun nach fast 2 Jahren geschafft! Das Wiregate ist arbeitslos

Ich habe nun einen knxd Docker Container erstellt und den als KNX TCP/IP Tunnelserver konfiguriert ist. Diesen habe ich nun für alle meine Container erstmal als IP Schnittstelle angegeben incl. des Wiregate Containers. Damit wird der einzige beim TW2400 verfügbare Tunnel nun für den KNXD Container verwendet und alle anderen Container und auch die ETS laufen nun über den KNXD.

Jetzt schalte ich heute abend nach nun über 5 Jahren das Wiregate das erste mal ab...

[tger977]

tja, da hat mich das log doch etwas zu früh freuen lassen. Alles geht nur der wiregate Container nicht mehr... Es tauchen nur Leseanfragen im Log auf, sobald was geschrieben werden soll passiert im log nichts mehr.

Ich hatte gehofft wie bei den anderen Containern daß man einfach die IP und den port per ENV Variable auf den KNXD umstellen kann. Geht aber wohl nicht. Und dann wären wir wieder am Anfang: Man kann in dem Container einfach nichts verändern. Warum klappt das nicht? der eibd ist doch nur als listener konfiguriert?

kann es noch an der leider fest im start_services.sh programmierten PA 0.0.0 liegen (die ENV Variable läuft da leider wohl ins leere)?

[tger977]

so nun der Abschluss meiner (Erfolgs-)Story auch hier:

Ich habe das eben nochmal angesehen, es war gestern wohl zu spät, da ich noch eine Kleinigkeit übersehen hatte.

Jetzt läuft an meinem TW2400 mit original Wiregate USB Hutschienen TPUart:
- EDOMI in eigenem macvclan Container mit KNX Zugriff
- Der KNXD Container per macvlan (und damit quasi als virtueller IP-Tunnel Server/Schnittstelle)
- der wiregate plugin Container mit KNX Zugriff (und dort nun auch erfolgreich der vclient der Viessmann Heizung wie im Wiregate damals auch)
- diverse weitere Container ohne KNX Zugriff
und ich kann (eben getestet!) auch parallel noch mit der ETS Geräte programmieren! Und das funktioniert mit dem KNXD sogar besser als mit dem eibd des wiregate, da es beim wiregate dann immer zu Verbindungsabbrüchen des EDOMI Containers kam und man dann immer nach programmieren eines devices EDOMI neu starten musste

Also der Beweis ist erbracht: das theoretisch öfter schon geschriebene funktioniert: Einen eigenen KNXD Container auf den TPUart ansetzen, alle weiteren Container dann die KNX Verbindung über den KNXD aufbauen lassen. Ergebnis: es läuft alles über die eine in der ETS konfigurierte Tunnelverbindung (damit auch alles über diesselbe PA, sprich per PA lässt sich nicht herausfinden von wo der KNX traffic tatsächlich herkam)!

für heute bin ich im 7ten Himmel und mach jetzt mal ein kühles Bier auf zur Feier des Tages!

[gbglace]

Im November hab ich nochmal 3Wochen Urlaub und werde den am CU im Keller verbringen. Im Anschluss werde ich dann bestimmt viele Fragen zum Viessmann Containerpackage haben.
Aber Glückwunsch das Du das so ans laufen bekommen hast. Zeigt ja auch das der TWS ne sehr mächtige Box ist. Und auch ohne Root an der Basis er einen enorme Freiheitsgrade ermöglicht.

[Robosoc]

nach nun erster erfolgreicher Anmeldung im Container und nach reinkopieren der plugins+confs+eibga.conf bekomme ich beim Ausführen des Status plugin folgende Fehlermeldung (wie oben von Auweia ja auch schon gemeldet):



was fehlt da und wie kann ich das beheben?

Nach langer Abstinenz im Forum melde ich mich mal wieder und bin heute die Plugin-Geschichte angegangen. Mit der KB bin ich bis zu dem Punkt gekommen, dass ich beim Status_Plugin diverse Fehlermeldungen sehe, die alle so hier auch schon mal gemeldet wurden. Aber irgendwie habe ich nicht verstanden ob und wie Ihr das Problem mit den folgenden Fehlern gelöst habt?

Use of uninitialized value in localtime at ./app/plugin_status.pl line 35.
Use of uninitialized value in sprintf at ./app/plugin_status.pl line 35.

Die Fehler

Logikprozessor.pl 6057 2019-08-27 21:21:06 Can't locate URI/Escape.pm in @INC (you may need to install the URI::Escape module) (@INC contains: /usr/share/bcusdk /app /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at (eval 573) line 1677.
BEGIN failed--compilation aborted at (eval 573) line 1677.

und

Logikprozessor.pl 6057 2019-08-27 21:21:06 Can't locate URI/Escape.pm in @INC (you may need to install the URI::Escape module) (@INC contains: /usr/share/bcusdk /app /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/arm-linux-gnueabihf/perl5/5.24 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/arm-linux-gnueabihf/perl-base) at (eval 573) line 1677.
BEGIN failed--compilation aborted at (eval 573) line 1677.

habe ich mir erstmal weggesprengt, indem ich die folgenden Zeilen in der .pl-Datei mit der Raute unwirksam gemacht habe:

# use LWP::UserAgent;
# use URI::Escape;

Das führt mit Sicherheit früher oder später zu Ausführungsproblemen meiner Logiken, aber zumindest bei dem Thema UserAgent habe ich eine Idee, wann auf dieses Subroutinen zugeriffen werden und deaktivere entsprechend die Logiken, die das Triggern.

Jemand eine Idee, wann URI::Escape benötigt wird?

[Robosoc]

Aber schon mal eine Mega-Erfolg: Das Plugin Scenencontroller.pl und der Logikprozesser (ohne UserAgent und Escape, siehe vorheriger Threat) funktionieren auf Anhieb einwandfrei bei meinen ersten Tests!!!

[tger977]

Die Fehler habe ich mir erstmal weggesprengt, indem ich die folgenden Zeilen in der .pl-Datei mit der Raute unwirksam gemacht habe:

# use LWP::UserAgent;
# use URI::Escape;

Das führt mit Sicherheit früher oder später zu Ausführungsproblemen meiner Logiken, aber zumindest bei dem Thema UserAgent habe ich eine Idee, wann auf dieses Subroutinen zugeriffen werden und deaktivere entsprechend die Logiken, die das Triggern.

Jemand eine Idee, wann URI::Escape benötigt wird?

Also bei mir waren diese Zeilen nur im Logikprozessor in der subroutine für das prowl/NMA Modul drin und auch nur dafür nötig. Da ich beides nicht nutze passiert da bei mir sonst gar nichts und sollte damit für alle anderen Logiken unkritisch sein!

[tger977]

Mit der KB bin ich bis zu dem Punkt gekommen, dass ich beim Status_Plugin diverse Fehlermeldungen sehe, die alle so hier auch schon mal gemeldet wurden. Aber irgendwie habe ich nicht verstanden ob und wie Ihr das Problem mit den folgenden Fehlern gelöst habt?

Use of uninitialized value in localtime at ./app/plugin_status.pl line 35.
Use of uninitialized value in sprintf at ./app/plugin_status.pl line 35.

das ist wohl ein Fehler im Perl Skript zur Statusanzeige. Ist aber nicht schlimm, braucht man eigentlich nicht wirklich und im Hintergrund läuft der Container einwandfrei. Und über das Log des Containers kann man das alles viel besser kontrollieren. Daher sollten wir die kostbare ElabNet Kapa lieber an anderen Dingen im TW weiterentwickeln lassen

Also hier wirklich nochmal großen Dank ans ElabNet Entwicklungsteam für die tolle Arbeit, jetzt sollten dann vermutlich einige weitere alte wiregates bei euch aufschlagen

[tger977]

Im November hab ich nochmal 3Wochen Urlaub und werde den am CU im Keller verbringen. Im Anschluss werde ich dann bestimmt viele Fragen zum Viessmann Containerpackage haben.

Also meine Erfahrung:
Ich habe den vcontrold mittels Container von @murelli146 am laufen, jedoch ohne den MQTT part zum Auslesen per vclient
Dann habe ich den vclient im Plugincontainer installiert und den bisherigen per crontab gelösten regelmäßigen Aufruf des vclient einfach im Logikprozessor integriert.
Sobald MQTT im TW ootb funktioniert werde ich dann den vclient und die Aufruflogik im wiregate Container ersetzen

Aber Glückwunsch das Du das so ans laufen bekommen hast. Zeigt ja auch das der TWS ne sehr mächtige Box ist. Und auch ohne Root an der Basis er einen enorme Freiheitsgrade ermöglicht.

Danke, ich habe wieder viel neues über Dockercontainer gelernt... So langsam kapiere ich diese Technologie besser und wird mir immer sympathischer Da hat Elabnet denke ich schon die richtige Entscheidung getroffen.