HomeKit Brücke für KNX

[mgf722]

Das Projektfile habe ich. Auch schon hochladen können. Somit an der Stelle kein Problem.

Mein Problem ist, dass ich bei der „automatischen Suche“ nach dem Gateway nix finde.

Daher meine Vermutung, dass das Z41 kein Gateway sein kann, obwohl der Elektriker mir das damals so erzählt hat bzw. ich das so verstanden habe.
Weiter habe ich das Problem, dass ich bei mir im Router schon gar keine Option für Multicast finde noch eine Möglichkeit mir angeboten wird, eine Adresse mit 224... und den Ports einzugeben.

Ich war mir nicht sicher, da Matthias auf seiner Seite folgendes schreibt:

Netzwerkanforderungen

Damit die HomeKit Brücke eine Verbindung mit HomeKit aufbauen kann, muss Multicast (für mDNS) im Netzwerk erlaubt sein. Verwendet werden dafür die Multicast Adressen 224.0.0.251 (IPv4) und ff02::fb (IPv6), sowie Port 5353.

Multicast wird außerdem noch für die Automatische Suche des KNX IP Gateways benötigt. Dafür wird die Multicast Adresse 224.0.23.12 und Port 3671 verwendet.

Zitat ENDE


Somit kann ich jetzt festhalten, mir fehlt der Gateway (ich habe nur eine USB-Schnittstelle und das Z41 neben den Aktoren).
Du meinst, Multicast wäre weniger das Problem, also kann ich den Router lassen?
Ist die Integration eines IP-Gateways ein großer Aufwand?

Gruß

[chef76]

Hallo zusammen, erstmal ein gutes neues Jahr!

Vorneweg, ich bin alles andere als ein Profi in der KNX-Thematik. Haus gekauft, und der Bauherr hat KNX für Heizung und Jalousien eingebaut.

Lese hier schon paar Tage mit, habe die Installation auf der PI durchgeführt, das Projekt geladen...aber weiter komme ich nicht.
Vermutlich habe ich zwei Baustellen, könnt ihr mir vielleicht dies bestätigen, dann weiß ich, wo ich weitermachen muss.

1) Router: ein O2 6641 (also zyxel)
—> entweder bin ich zu doof oder finde die Stelle nicht, um die Multicast-Ports freizuschalten. Kann das der Router gar nicht? Ich finde auch nix im Netz...

2) Gateway: Ich dachte, das Zennio Z41 pro ist das Gateway, aber das kann vermutlich kein Tunneling. Weiß das vielleicht jemand, ob ich hier zusätzlich noch ein IP-Gateway benötige?

Besten Dank und Grüße
Franz

Vielleicht schilderst Du mal Deine Probleme, dann können wir Dir vielleicht helfen.

1) Ich denke nicht dass Multicast Dein Problem ist

2) das Z41 ist ein Touchpanel. Laut Beschreibung hat es den LAN Anschluß zur Netzwerkanbindung um eine App-Anbindung zu realisieren. Ich glaub nicht, dass das als Gateway funktioniert. Such mal in Deinen Verteilern, ob du ein KNX Gerät mit Netzwerkanschluß findest. (z.B. sowas hier)

Dein größtes Problem dürfte aber darin bestehen, wenn Du das ETS Projektfile nicht hast. Dann braucht man schon viel Erfahrung und v.a. Die ETS Software um das hinzukriegen.

[mgf722]

Hallo zusammen, erstmal ein gutes neues Jahr!

Vorneweg, ich bin alles andere als ein Profi in der KNX-Thematik. Haus gekauft, und der Bauherr hat KNX für Heizung und Jalousien eingebaut.

Lese hier schon paar Tage mit, habe die Installation auf der PI durchgeführt, das Projekt geladen...aber weiter komme ich nicht.
Vermutlich habe ich zwei Baustellen, könnt ihr mir vielleicht dies bestätigen, dann weiß ich, wo ich weitermachen muss.

1) Router: ein O2 6641 (also zyxel)
—> entweder bin ich zu doof oder finde die Stelle nicht, um die Multicast-Ports freizuschalten. Kann das der Router gar nicht? Ich finde auch nix im Netz...

2) Gateway: Ich dachte, das Zennio Z41 pro ist das Gateway, aber das kann vermutlich kein Tunneling. Weiß das vielleicht jemand, ob ich hier zusätzlich noch ein IP-Gateway benötige?

Besten Dank und Grüße
Franz

[traxanos]

Müsste das nicht per Trick17 doch gehen. Man legt sich einen virtuellen Schalter an und verknüpft in HomeKit den Brandalarm mit dem Schalter. Oder habe ich was falsch verstanden?

[brutella]

Wäre es mit der Brücke auch möglich, die EVE Brandmelder in KNX einzubinden d.h. in die QC Visu? Also der umgekehrte Weg?

Nein, das ist nicht möglich.

[max999]

Wäre es mit der Brücke auch möglich, die EVE Brandmelder in KNX einzubinden d.h. in die QC Visu? Also der umgekehrte Weg?

[chef76]

Das kann ich bestätigen. Liegt daran, dass die Lamellen nach einer Auf-Fahrt über HomeKit auf 0% stehen und dafür muss die Jalousie wieder ein Stück zurück fahren. Vielleicht kann Brutella das so einrichten, dass bei einer Auf-Fahrt die Lamellen automatisch auf 100% (90°) gehen, dann sollte das behoben sein?!

O.k., das würde auch nichts bringen. Das Einzige was hier Abhilfe schaffen würde, wäre, dass bei einem Druck auf die HomeKit-Taste ein Auf- oder Ab-Befehl gesendet würde (je nach aktueller Position). Das Thema hatten wir aber schon. HomeKit kann nur über Positionen steuern, wenn ich mich richtig erinnere. Wenn der Tastendruck allerdings ein eigenes Kommando wäre, müsste hierfür eine zusätzliche GA verknüpfbar sein.

[dornadeluxe]

So ich habe jetzt auch mein komplettes EFH soweit eingerichtet. Eigentlich läuft alles bestens bis auf ein Thema: Wenn ich meine Jalousien (mit MDT Jalousieaktoren) hoch oder runter fahren möchte, so tun sie das auch, allerdings fahren Sie nach erreichen der Endposition die Lamellen etwas auf, was dann dazu führt dass sie mit ca. 3% offen in Home angezeigt werden. Ich kann sie dann auch nur ganz schließen indem ich die Lamellenposition in Home manuell anpasse. Gibt es hier eine Lösung bzw. hat jemand ein ähnliches Problem?

[charlez]

Vielleicht kann die Konfigurator-App das deaktivieren, wenn sie in den richtigen Raum verschoben wird?

Ich habe auch einige andere Vorschläge zu verbessern.
Wenn Sie die Schreibadresse (als erste) eingeben, berücksichtigen dies die Vorschläge der anderen Felder. Derzeit schlagen sie etwas vor, das auf dem ausgewählten Raum basiert, denke ich.

Entschuldigung, wenn nicht klar

[Grafe]

@charlez: Ja, das ist wirklich nervend. Und dass die Aufnahme in den Staus defaultmäßig „an“ ist, stört auch. Dürfte aber ein iOS-„Feature“ sein, dafür kann die Brücke nichts.

[charlez]

Ist es beim Hinzufügen von Geräten möglich, diese nicht standardmäßig zu Favoriten hinzuzufügen?

[brutella]

brutella
Gibt es von deiner Seite einen Plan wie du an dem Thema Homekit-Brücke weiterarbeitest?
Wann werden die Bugs gefixed und wann ggf. neue Features implementiert?

Einige Bugs sind in Version 1.1.2 schon gefixt – diese Version werde ich wohl in den nächsten Tagen releasen.
An neuen Features werde ich arbeiten, wenn das Update für Home+ fertig ist – das dauert leider viel länger als ursprünglich geplant.

[blane]

brutella
Gibt es von deiner Seite einen Plan wie du an dem Thema Homekit-Brücke weiterarbeitest?
Wann werden die Bugs gefixed und wann ggf. neue Features implementiert?

[McEgg]

brutella
Wie z.B. hier beschrieben, müssen in einigen Feldern die gleichen GAs eingetragen werden. Das ist eigentlich bei so ziemlich allen Geräten der Fall.
In meinen Augen ist da die Fehleranfälligkeit relativ hoch, wenn man sich nicht sicher ist und dann unterschiedliche GAs einträgt.

Im o.g. Beispiel sieht man, dass die gleiche GA an vier Stellen eingetragen werden muss:

1. Jalousie-Ist Position LESEN
2. Jalousie-Ist Position INITIALISIEREN
3. Jalousie-Soll Position LESEN
4. Jalousie-Soll Position INITIALISIEREN

Wäre es nicht geschickter nur ein Feld zu haben.... Oder wenn du die Felder so behalten möchtest, dass du die Felder 2-4 sperrst (grau hinterlegt) und die in 1. angegebene GA automatisch in die Felder 2-4 kopierst? Und das eben in allen Geräten an den Stellen, an denen die jeweils gleiche GA rein muss...
Das hätte zum einen den Vorteil, dass der Benutzer nicht 4x die gleiche GA eintragen muss und zum anderen, dass der Benutzer nicht fälschlicherweise eine andere GA einträgt und somit Probleme bekommt.

Wenn es Gründe gibt, dass doch mal eine andere GA rein soll, gäbe es ja auch die Möglichkeit im Gerät unter "Status" noch eine Checkbox "Autofill" zu erstellen, die standardmäßig angehakt ist. Damit sind die jeweiligen LESE und INIT Felder ausgegraut und die entsprechende GA wird kopiert.
Ist die Checkbox nicht angehakt, sind die Felder 2-4 offen und die GA in 1 wird nicht kopiert. So kann der Bentuzer dann selbst was anderes eintragen.

brutella
Ich glaube ich habe gerade noch einen Bug entdeckt.
Bereits angelegte Geräte haben nicht die gleichen Einstellmöglichkeiten, wie neue Geräte, wenn mit späteren Releases neue Funktionen für ein Gerät hinzukamen.
Beispiel:
Ich habe in der Vergangenheit "Kontaktsensoren" angelegt. Diese frühen angelegten Kontaktsensoren haben als Eigenschaft nur "Kontakt erkannt". Lege ich mit der aktuellen Version einen neuen Kontaktsensor an, habe ich die Eigenschaften "Kontakt erkannt", "Störung erkannt", Batteriestatus" und "Sperren".
Möchte ich die Einstellungen auch in alten Geräten haben, muss ich diese löschen und neu anlegen.
Ohne es geprüft zu haben... ich vermute dass das auch bei anderen Geräten und nicht nur bei "Kontaktsensoren" so ist....
Ich denke neue Einstellmöglichkeiten sollten auch für bereits angelegt Geräte verfügbar sein und nicht nur für neue Geräte...

brutella
Habe leider noch keine Antwort bekommen.
Die Rollladen Konfiguration auf deiner Seite ist auch anders als das was hier empfohlen wird und auch funktioniert. Nämlich 4x die gleiche GA einzutragen.

[wwfr]

Ich habe mir gerade mal die Applikationen von einigen Reglern angeschaut (MDT, Gira/Jung, Hager/Berker, Theben, Zennio) und alle benutzen DPT 20.102 für die Umschaltung und Status des Betriebsmodus. Es gibt auch noch eine 1-Bit Option wenn man Schalter hat. Also es scheint standardisiert zu sein? Man könnte also ein Umschalten 1-byte und ein Status 1-byte benutzen und dann wie in Post #402 mit Schaltern in Homekit umsetzen?

Nur MDT hat noch eine weitere zusätzliche Option "HVAC Status" bzw RHCC Status: aber das scheint eher für ungewöhnliche Anwendungsfälle zu sein? Evtl. weiß da jemand mehr als ich...

Oder von welchen unterschiedlichen Anforderungen sprichst du konkret? Wäre gern behilflich...

Ich war längere Zeit abwesend - evtl. hast du diesen Post übersehen oder ich deine Antwort (wenn ja, bitte entschuldigt diesen Post).

brutella Könntest du nochmal erläutern was du mit unterschiedlichen Anforderungen an die RTR meinst? (#906)

Für mich wäre eine Ansteuerung der Betriebsmodi über HK ein Killerfeature, da mit HK-Logik und Geolocation (ganze Familie ist mit Apple unterwegs) das Thema Heizung/Klimaanlage äußerst elegant lösen würde.