HomeKit Brücke für KNX

[psi]

Hat jemand schon mal beobachtet dass der Temperaturregler auf dem Bus krumme Werte sendet ???

Sobald ich die Temperatur auf z.B. 21°C Stelle bekomme ich auf meiner X1 Visu 21,1 °C angezeigt.

Hallo soeben getestet und kann ich nicht nachvollziehen, bei mir sendet er exakt die Werte.

[Sral1987]

Aktuell habe ich ein Iphone5s also auch kein iOS 13. Evtl liegt da der Hund begraben. Die Rückmeldung wenn die Temperatur am X1 oder RTR geändert wird funktioniert ohne Probleme.

Gerade nochmal mit der Home APP auf 22,5°C geschraubt und auf dem Gruppenmonitor der ETS kamen 22,7°C an. Sehr strange dass ganze.

[KNXFan1970]

Interessant, unter welchen Umständen werden Schalt-GAs gesendet?
Es kann natürlich sein, dass HomeKit automatisch eine Lampe ausschaltet, wenn man die Helligkeit auf 0% reduziert.
Die HomeKit Brücke selbst beinhaltet keine Logik um Werte an Schalt-GAs zu senden. Es wird "nur" alles von HomeKit an KNX weitergeleitet.

Bei mir werden beim Dimmen über die Home-App auch Schalt-GA neben den Dimm-GA gesendet - auch, wenn der Dimmbereich nicht 0% oder 100% erreicht. Dies führt dann mitunter dazu, dass über die Home-App nichts mehr steuerbar ist. Allerdings wird der Status weiterhin korrekt angezeigt, wenn über KNX gesteuert wird.
Wird Siri zum Einstellen des Dimmwertes verwendet, dann wird bei mir nur die Schalt-GA gesendet und das Steuern über die Home-App ist sofort nicht mehr möglich.

[MatthiasS]

Das Rundungsthema ist ein bekanntes KNX-Thema. Ignorieren.

[nowi87]

Alsoooo,

Als erstes habe ich in dem Log FritzBox keine Multicast Fehlermeldungen finden können.
Multicast ist auf der FritzBox und dem Ubiquiti AC Pro jetzt auch aktiviert und brachte auch erstmal keine Abhilfe.

Danach habe ich dann im hkknx die IP des Gateway fest vergeben und den Raspberry neu gestartet.
Das ganze lief den ganzen Abend auch ca. 2-3 Stunden und heute geht leider wieder nichts mehr.

Laut Busmonitor kommen auch keine Befehle von der HomeKit Brücke an, trotz bestehender UDP Verbindung am MTD Gateway.

Also müsste ja auf der Strecke von dem iPad Pro zum Raspberry/hkknx das Problem irgendwo sein.

Hier einmal das Ergebnis von netstat -s auf dem Raspberry:

Im Abschnitt UDP gibt einige Pakete mit Fehlern:
17416 packet receive errors
17416 receive buffer errors

[B]pi@raspberrypi[/B]:[B]~ $[/B] netstat -s

Ip:

Forwarding: 2

32306 total packets received

1 with invalid addresses

0 forwarded

0 incoming packets discarded

32277 incoming packets delivered

22437 requests sent out

40 dropped because of missing route

Icmp:

340 ICMP messages received

5 input ICMP message failed

ICMP-Eingabehistogramm:

destination unreachable: 340

342 ICMP messages sent

0 ICMP messages failed

ICMP-Ausgabehistogramm:

destination unreachable: 342

IcmpMsg:

InType3: 340

OutType3: 342

Tcp:

1 active connection openings

89 passive connection openings

0 failed connection attempts

62 connection resets received

2 connections established

5059 segments received

5430 segments sent out

483 segments retransmitted

0 bad segments received

466 resets sent

Udp:

37699 packets received

2 packets to unknown port received

17416 packet receive errors

16550 packets sent

17416 receive buffer errors

0 send buffer errors

IgnoredMulti: 6905

UdpLite:

TcpExt:

29 ICMP packets dropped because they were out-of-window

5 TCP sockets finished time wait in fast timer

5 packetes rejected in established connections because of timestamp

17 delayed acks sent

Quick ack mode was activated 8 times

166 packet headers predicted

3060 acknowledgments not containing data payload received

148 predicted acknowledgments

TCPSackRecovery: 4

TCPDSACKUndo: 2

8 congestion windows recovered without slow start after partial ack

TCPLostRetransmit: 353

4 fast retransmits

TCPTimeouts: 406

TCPLossProbes: 85

TCPLossProbeRecovery: 6

TCPDSACKOldSent: 8

TCPDSACKRecv: 44

61 connections aborted due to timeout

TCPDSACKIgnoredNoUndo: 2

TCPSackShiftFallback: 7

TCPRcvCoalesce: 9

TCPSpuriousRtxHostQueues: 8

TCPAutoCorking: 17

TCPOrigDataSent: 2335

TCPHystartTrainDetect: 10

TCPHystartTrainCwnd: 170

TCPACKSkippedPAWS: 2

TCPACKSkippedSeq: 11

TCPKeepAlive: 2180

TCPDelivered: 2330

IpExt:

InMcastPkts: 18118

OutMcastPkts: 9818

InBcastPkts: 6909

InOctets: 6541942

OutOctets: 5001186

InMcastOctets: 4583959

OutMcastOctets: 2189027

InBcastOctets: 1289965

InNoECTPkts: 31778

InECT0Pkts: 532

[brutella]

Hast du evtl. eine Dokumentaion der Kommunikationswege (incl. Ports, UDP/TCP Traffic, etc.),das würde das Troubleshooting vereinfachen?

Hab die Readme auf der Projektseite mit Infos über die Multicast Adressen aktualisiert.

[brutella]

RGB LEDs
Ich habe für meine Dali RGB Stripes jeweils für jede Farbe ein Objekt für den Wert und eine Rückmeldung. Ebenfalls noch für ein/aus ein Schaltobjekt. Ich kann das hier nicht abbilden, gibt es da eine Lösung?

Zurzeit noch nicht. Ich schau mir das noch an.

Passwort
Wir es noch ein Passwortschutz für das WebInterface geben?

Ist geplant. #22

Musik
Ist eine intgeration z.B. von Sonos möglich und angedacht?

In HomeKit gibt es da noch keine gute Lösung.
Welche Integration wäre für dich dahingehend wichtig?

Kameras
Ist eine Einbindung von Kameras angedacht?

Aktuell hat das keine große Priorität, aber es wäre möglich.
Welches Kommunikationsprotokoll wird von deiner Kamera unterstützt? RTSP?

Mit meinem Open-Source Projekt hkcam kannst eine eigene HomeKit-kompatible Kamera basteln.

[MatthiasS]

Sehr interessantes Projekt. Ich denke, ich werde mich am Wochenende auch mal damit beschäftigen.

Weil wir gerade bei der Musik sind, Logitech Media-Server ist mein Favorit

[brutella]

Bei mir werden beim Dimmen über die Home-App auch Schalt-GA neben den Dimm-GA gesendet - auch, wenn der Dimmbereich nicht 0% oder 100% erreicht. Dies führt dann mitunter dazu, dass über die Home-App nichts mehr steuerbar ist. Allerdings wird der Status weiterhin korrekt angezeigt, wenn über KNX gesteuert wird.
Wird Siri zum Einstellen des Dimmwertes verwendet, dann wird bei mir nur die Schalt-GA gesendet und das Steuern über die Home-App ist sofort nicht mehr möglich.

Bitte starte die Brücke mit der -verbose Option und überprüfe welche Werte von HomeKit gesendet werden.
Zum Beispiel, wenn du einen Schalter einschaltest, taucht folgende Ausgabe auf

[...] 192.168.0.44:49420 PUT /characteristics
[...] {"characteristics":[{"aid":2,"iid":9,"value":1}]}

192.168.0.44:49420 ist die Adresse des HomeKit Clients (zB iPhone)
"value":1 ist der Wert der an die Brücke gesendet wird – zB Einschalten.

Wenn dieser Wert an die Brücke gesendet werden, obwohl du nur die Helligkeit änderst, dann liegt das Problem wohl an der Apple Home App.

[brutella]

Ich habe eine Frage bzgl. KNX Alarmanlagen.

Nehmen wir mal an eine Alarmanlage kann nicht über KNX scharf/unscharf gestellt werden.
Wie bekomme ich über den KNX Bus mit, dass die KNX Alarmanlage jetzt scharf gestellt wird?
Wird der Status der Alarmanlage über eine Gruppenadresse mitgeteilt?

Falls ein Alarm ausgelöst wird, wie bekomme ich mit, dass der Alarm jetzt wieder deaktiviert wurde?
Wird in dem Fall eine "0" an die Alarm-Gruppenadresse gesendet?

Danke für die Hilfe.

[SeatSLF]

Bei z.b. meiner Telenot ist 1=scharf 0=unscharf, Alarm = 1 wenn kein Alarm dann 0
Im Grunde läuft es genauso wie du vermutest.

[SeatSLF]

Bei mir läuft es wohl ab und zu verkehrt.

Telegramme wie Statuse die vom KNX kommen
im Homekit an, ABER wenn ich irgend etwas
schalten möchte, passiert nichts.
Schalte oder dimme ich direkt vom Taster oder
aus Edomi (Visu/Logik) wird der Status in Homekit richtig „angenommen“

Die Software läuft in einer VM unter einem Raspberry Image und hängt direkt am Switch.
Es gibt keine VLANs oder dergleichen die intern
dazwischen kommen könnten.

[brutella]

Telegramme wie Statuse die vom KNX kommen
im Homekit an, ABER wenn ich irgend etwas
schalten möchte, passiert nichts.

Kommen die Anfragen von HomeKit richtig an der Brücke an?
Wenn du die Option -verbose verwendest solltest du PUT Requests in den Logs sehen – so wie oben an einem Beispiel gezeigt.

[woerdi2000]

Das Problem mit dem Dimmen kann ich bestätigen.
Bei mir verhält es sich wie folgt:

- stelle ich in HK einen %-Wert ein, wird von der Brücke erst der "ein" Befehl gesendet und hinter der eingestellte "%" Wert.
- schalte ich die Lampe nur "ein", wird der "ein" Befehl und 100% als absoluter Wert hinterher gesendet.
Somit wird die Memory-Funktion des Dimmaktors nicht genutzt.

Es dürfte also beim einschalten kein absoluter Dimmwert nach dem "ein" gesendet werden.
Kannst du das unterdrücken?

[brutella]

Bei mir verhält es sich wie folgt:

- stelle ich in HK einen %-Wert ein, wird von der Brücke erst der "ein" Befehl gesendet und hinter der eingestellte "%" Wert.
- schalte ich die Lampe nur "ein", wird der "ein" Befehl und 100% als absoluter Wert hinterher gesendet.
Somit wird die Memory-Funktion des Dimmaktors nicht genutzt.

Welche iOS Version verwendest du? Unter iOS 13 tritt das bei mir nicht auf.