HomeKit Brücke für KNX

[brutella]

Wäre mir auch neu, dass für Tunnelling Multicast benutzt wird

Tunneling selbst verwendet kein Multicast, aber bei Auto-Discovery werden die KNXnet/IP Search Requests über Multicast versendet.

[McEgg]

Eine Frage. Du schreibst „Gratis während der Betaphase“.
es ist ja wirklich löblich, dass gerade hier so viele ihre „Programme“ kostenlos zur Verfügung stellen.
Bei deiner Software wäre es gut zu wissen, ob du planst diese kostenpflichtig zu machen.
Ich persönlich hätte jetzt wenig Lust, alles zu konfigurieren und mich damit zu beschäftigen und wenn dann alles läuft kommen Kosten auf mich zu, mit denen vorher nicht zu rechnen war.
Ist natürlich völlig legitim etwas für eine Software zu verlangen. Dann sollte es aber auch angekündigt werden. Vor allem, wie das Kosten-/Lizenzmodell dann in etwa aussehen soll.
Ansonsten... sehr interessantes Projekt. Ich verfolge es auf jeden Fall mal.

[derPaul]

Tunneling selbst verwendet kein Multicast, aber bei Auto-Discovery werden die KNXnet/IP Search Requests über Multicast versendet.

Das killt zumindest den Docker Container bislang hehe, fairerweise muss ich sagen war der auch nur fix mit der heissen Nadel zusammen gekloppt


BTW : Wäre cool wenn die Json mit entsprechenden umbrüchen gespeichert werden würde, dann kann man zu debugging zwecken sich die besser anschauen :-)

[brutella]

Eine Frage. Du schreibst „Gratis während der Betaphase“.
es ist ja wirklich löblich, dass gerade hier so viele ihre „Programme“ kostenlos zur Verfügung stellen.
Bei deiner Software wäre es gut zu wissen, ob du planst diese kostenpflichtig zu machen.
Ich persönlich hätte jetzt wenig Lust, alles zu konfigurieren und mich damit zu beschäftigen und wenn dann alles läuft kommen Kosten auf mich zu, mit denen vorher nicht zu rechnen war.
Ist natürlich völlig legitim etwas für eine Software zu verlangen. Dann sollte es aber auch angekündigt werden. Vor allem, wie das Kosten-/Lizenzmodell dann in etwa aussehen soll.

Das Lizenzmodell ist noch nicht geklärt und daher auch der Vermerk, dass es zurzeit kostenlos ist.
Ich habe schon gute Erfahrungen mit Open-Source gemacht – viele meiner Projekte sind auf GitHub verfügbar.
Trotzdem muss man viel Zeit dafür aufwenden um das Ganze am Laufen zu halten. Letztendlich ist es immer eine Sache des Geldes, den von den Likes auf GitHub kann man keine Familie ernähren. Ich bin selbständiger Softwareentwickler und habe nebenbei keinen anderen Job.

Das heißt jetzt nicht, dass die Software am Ende des Tages € 200 kosten wird. Ich muss nur einen Weg finden meinen Zeitaufwand betriebswirtschaftlich rechtfertigen zu können. Wenn sich da keine Lösung findet, macht das Projekt auf lange Sicht (bei der jeder Freude an der Programmierung) keinen Sinn.
(Bis jetzt hab ich ~300h an dem Projekt gearbeitet.)

Daher ist es für mich erstmal wichtig Feedback zu bekommen. Wenn die Software gut ankommt, werde ich das Projekt weiterführen.

[McEgg]

Danke für die Antwort. Ist denke ich für alle wichtig zu wissen. Und für gute Software kann man auch gern ein paar Taler zahlen.

[brutella]

Hm? Tunneling braucht Multicast? Ich dachte, das würde nur für Routing gelten.

Hab einen Fehler in der Implementierung entdeckt. Multicast wird (fälschlicherweise) verwendet auch wenn die IP Adresse des Gateway angegeben wurde.
Wird im nächsten Update gefixt.

[AndreasK]

ja aber wieso sollte ich ein funktionierenden dienst ersetzen wollen?

iobroker nutz ich nicht

Es hat niemand geschrieben, dass du von deinem bestehenden, funktionierenden System wechseln sollst.
Dir hat die Konfiguration per Browser gefallen und du hast die Frage gestellt, ob eine Echo Integration vorhanden ist.
Beides bietet ioBroker.
Es ist keine umständliche und nicht immer einfache Konfiguration über eine *.json notwendig.
Du kannst Echo sogar so stark integrieren, dass du den Notification Leuchtring aktivieren und als Anzeige nutzen kannst, oder Sprachausgabe auf Echo durchführen und noch viel mehr.

Das ist alles, was ich mit meinem Beitrag schreiben wollte

[jentz1986]

Wenn ihr mir jetzt noch in einem anderen Thread (weit weg von diesem) erklärt, was Alexa mit Homekit zu tun hat, werde ich total glücklich. Ja man kanns verbinden - toll.

Homekit mit KNX - dafür wurde das hier beschriebene Produkt geschaffen. Die Unterschiede zu anderen bestehende Produkten abzufragen ist wichtig für die Positionierung des Produkts. Aber ob du nun diese oder jene Leuchte im Haus hast (Echos Leuchtring) ist dafür irrelevant.

[charlez]

will there be a x64 version also in the future?

[brutella]

Yes, what OS are you using?

[charlez]

Debian 10

[brutella]

s01iD Die neue Version sollte das Verbindungsproblem (mittels IP Adresse) beheben.
Außerdem gibt es jetzt auch eine 32-Bit Version für Linux.

Hier gehts zum Download: https://github.com/brutella/hkknx-pu...ases/tag/0.0.9

(Der Download über die Weboberfläche wird freigeschaltet, sobald niemand einen groben Fehler entdeckt.)

Download ist jetzt auch bequem über die Weboberfläche möglich.

[brutella]

Einige User haben berichtet, dass eine Verbindung mit dem IP Gateway bei der Angabe einer fixen IP Adresse nicht funktioniert.
Jetzt steh ich vor einem Problem, wo ich nicht ganz weiter weiß – vielleicht kennt sich da jemand besser aus als ich.

Das Problem ist, dass beim Aufbau einer KNXnet/IP Tunnelling Verbindung der sogenannte Control und Data Endpoint des Gateways bekannt sein muss.
(Ein Endpoint gibt die IP Adresse und den Port der Verbindung an.)

Im Normalfall bekommt man diese Endpoints über eine Multicast Suchanfrage. Wenn aber nun Multicast nicht möglich ist (weil im Netzwerk nicht erlaubt) sollte es möglich sein, dass der User die IP Adresse des Gateway angibt. Problem ist nur, dass wenn ich eine Suchanfrage direkt an die IP Adresse des Gateways sende, ich keine Antwort bekomme – möglicherweise wird das ignoriert?

Jetzt meine Frage, ist es überhaupt vorgesehen eine KNXnet/IP Tunnelling Verbindung aufzubauen, wenn Multicast Requests nicht möglich sind?
Dazu müsste man ja nicht nur die IP Adresse, sondern auch den Port wissen – der Port ist aber in meinem Fall, bei einem MDT IP Interface, nicht bekannt.

[s01iD]

Gegenfrage: warum lässt Du nicht einfach den Port vom Nutzer eintragen, so wie es alle anderen Tools (inkl. der ETS, siehe Screenshot) auch machen?

[meti]

Das Problem ist, dass beim Aufbau einer KNXnet/IP Tunnelling Verbindung der sogenannte Control und Data Endpoint des Gateways bekannt sein muss.

Beim Aufbau der Verbindung muss nur der Control Endpoint bekannt sein. Den Data Endpoint bekommst du dann in der CONNECT_RESPONSE und kann auch der mit dem Control Endpoint ident sein. Der übliche Port ist 3671 - kann aber glaub ich auch umgestellt werden - sollte also konfigurierbar sein.

FYI: SEARCH_RESPONSE ist im Gegensatz zu SEARCH_REQUEST Unicast. Wenn du also Multicastpackets senden, aber nicht empfangen kannst macht das nichts.