Docker Container für Alexa mit habridge

[MiniMaxV2]

Klingt als wenn Alexa zwingend HTTPS vorraussetzt zur Bridge :/

[Robert_Mini]

Also doch das nächstd Abenteuer mit ha-bridge und proxy?
Sollte ja gl. wie bei der CV gehen mit Netzwerk bridge und portmapping? Oder muss man dazu im Container was ändern?
Robert

[MiniMaxV2]

Probiers aus - wenn es ja schon ging unter macvlan sollte es im Proxy weniger Provleme geben (vermute ich mal

[Chris M.]

Aber das Telegramm kommt nun nicht am KNX an

Ich habe port 80:80 gemappt und publish all exposed ports aktiviert.

Braucht der knxd eine Authentifizierung über https oder was in der Art?

Der knxd hat mit HTTP nichts zu tun - der redet KNX IP Tunnel oder KNX IP Router nach außen und was eigenes nach innen. Das innen ist das was die CGI-BIN Programme auch reden und über den Web-Server als GET bereit stellen.

Wenn es nun nicht geht, dann ist ganz einfach der knxd nicht korrekt konfiguriert. Vgl. https://www.cometvisu.org/CometVisu/de/ ... bwrite-cgi wie das geht.
Da Du eine andere Installation machen willst als die die beschrieben ist, musst Du hier wohl entsprechend anpassen.

Hinzugefügt nach 7 Minuten 58 Sekunden:

Das der jetzt nicht zum Wolf kommt, klingt ja wieder nach dem Problem vom anfang - nur eben nicht zwischen CV und HaBridge sondern zwischen EibD und TW .. Kann da irgendwas mit der Firewall im Wolf sein ?
@ Chris M. - wie läuft das eigentlich ab? Die CV sendet ana Backend. Dort von PHP auf den EibD und dann über Netzwerl an den Wolf? Wo stellt man die Adresse ein? War das die Variable KNX Interface in der Base? Wenn ja dann steht da ja nun localhost, der Container ist aber ja nicht mehr local zum Wolf ? (Also im Test von oben)

Die CometVisu braucht kein PHP, das geht alles ohne. PHP ist nur für optionale Komfort-Features wie den Manager oder Editor oder manche Plugins.

Bei einem Lesen (r) oder Schreiben (w) über die Visu auf den KNX läuft das so: Browser -> GET Request an Web-Server -> der reicht das durch über die CGI-Schnittstelle an das entsprechende CGI-BIN-Programm -> das greift über den Socket des knxd auf diesen zu -> der knxd geht über die dort konfigurierte Schnittstelle (z.B. IP Tunnel) auf ein KNX Interface zu -> das KNX Interface redet mit dem KNX Bus.

=> Das entscheidende ist, dass der knxd des CometVisu Containers auf eine entsprechende KNX Schnittstelle zugreifen kann. Das kann ein IP Tunnel sein, den der Timberwolf bereits stellt, das kann ein IP Router sein, vermutlich geht auch ein durchgereichtes TP-UART

Die Konfiguration des knxd geht über die Umgebungsvariablen des Containers, vgl. https://www.cometvisu.org/CometVisu/de/ ... nvironment

[MiniMaxV2]

@Chris M. danke für die kurze Skizzierung. Dann kann es ja nur an den Env Vars des knxd liegen
P.S. Das Zertifikat von Cometvisu.org ist heute abgelaufen und wird mir als unsicher markiert.

[Chris M.]

P.S. Das Zertifikat von Cometvisu.org ist heute abgelaufen und wird mir als unsicher markiert.

Ich weiß. Und kann nichts dagegen machen
Die Seite wird von GitHub gehostet, die besorgen sich das Zertifikat selber und machen alles selbständig.

Bleibt also nur hoffen, dass das bald gelöst ist.

[Robert_Mini]

Hallo zusammen!

Kurzer Zwischenstand:
Die Meldung "This ha-bridge instance is not secured", bezog sich darauf, dass das WebInterface nicht geschützt ist. Man kann user + pwd anlegen, dann erscheint dort ein Anmeldedialog => die Bridge braucht kein https, so wie ich auch zahlreiche Postings im Internet verstehe.

Hauptproblem, war der nicht freigegebene Port 50000 für UDP.

Damit sehe ich nun unter "Manage Links" die Alexa in ha-bridge als auch eine "test-ha-bridge", welche zum Testen der Devices (aus dem ha-bridge interface) verwendet wird.

Jetzt die schlechten Nachrichten:
- Nach mehreren Versuchen wird zwar auf amazon alexa eine Philips Lampe Arbeitszimmer angezeigt, beim Sprachbefehl anwortet Alexa: "Gerät nicht erreichbar, prüfen sie ihre Netzwerkverbindung..." => also wieder ein Zugriffsproblem, obwohl es vom Webinterface funktioniert.
- "Schalte Licht Esszimmer ein" => kann kein Gerät mit dem Namen Esszimmer finden, d.h. Bestätigung, dass Arbeitszimmer soweit richtig von Alexa behandelt wird.
- Wenn ich mehrere Lampen anlegen, werden diesen nicht erkannt, auch das Löschen aller Devices und suchen hilft da nicht.
- Interessanterweise findet amazon beim neu anlegen eine Lampe "Esszimmer" in der ha-bridge (vorher alle löschen) wird weiterhin eine Lampe "Arbeitszimmer gefunden"
- Mehrere angelegte Lampen wurden bisher nicht gefunden.

Fazit: Ganz habe ich noch nicht aufgeben, aber wie sich das im Moment darstellt, ist das ganze leider weder stabil noch massentauglich. Ich poste das ganze auch mal auf github, vielleicht geht's ja doch noch ein Stück weiter.

lg
Robert

[MiniMaxV2]

@Chris M. Seid gestern hab ich auch noch ein paar andere Seiten (nicht meine), die auch kein neues Cert bisher haben :/
@Robert_Mini Das ganze klingt ja bisher nicht sooo schlecht -du bist ja schon weit gekommen. Warum der jetzt nicht ganz durch geht, aber ein Gerät erkennt, ist merkwürdig. Kann man in der HA Bridge auch Geräte ohne "URL" hinterlegen? Sonst könnte ich das morgen mal testen in einem Container

[Robert_Mini]

@Robert_Mini Das ganze klingt ja bisher nicht sooo schlecht -du bist ja schon weit gekommen. Warum der jetzt nicht ganz durch geht, aber ein Gerät erkennt, ist merkwürdig. Kann man in der HA Bridge auch Geräte ohne "URL" hinterlegen? Sonst könnte ich das morgen mal testen in einem Container

Die HA Bridge kann so ziemlich alles anlegen, was über http bedienbar ist, das ist ja das coole (Harmony, etc.). Screenshot anbei.
Man kann auch ein skript oder exe ausführen...
Ich sag jetzt mal (egoistisch), das zahlt sich aus , zumal das Dockerfile von für x86, x86-64 und ARM fertig ist (ein paar Seiten runter scrollen: => https://github.com/bwssytems/ha-bridge)

Danke und lg
Robert

[MiniMaxV2]

Ich schau mal wann ich heute oder morgen dazu komme

@Dennis Warum kann man das Bild eigentlich nicht vergrößern mit einem Klick drauf? Über Rechts->Grafik Anzeigen gehts