Test Alpha Homekit-Controller 0.0.x

[apollon77]

@mac89muc Die nanoleafs sind aber hier "anders" weil die schon auf die erste Pair-Setup Nachricht M1 einfach nicht antworten. Musst Du da ggf einen pairing Mode aktivieren? Aber sonst ja ... Strange.

Bei Nano-Leaf könnte es vllt sein das irgendwas "zu schnell" geht, aber am Ende komisch so oder so

Kannst du mal schauen wie lange es nach so einem fehlgeschlagenen Pait braucht bis Du wieder "identify" machen kannst erfolgreich?

[apollon77]

@mac89muc So, für Nuki wissen wirds schonmal:

We can’t & won’t go into any details because of confidentiality restrictions, but what i can tell you is that in step M3 Apples authentication coprocessor comes into play.

Da gibt es scheinbar eine Spezifikationserweiterung die aber nicht Public ist Damit fällt Nuki wohl aktuell aus

For comercial HomeKit solutions your company will need to register as a Hardware Developer with the MFi Program. (Free membership) The MFi Program is Apple’s Hardware Development Program, they help HW Developers integrate Apple technology. (CarPlay, AirPlay, HomeKit...) Any non Apple Product that integrates Apple technology will need to authenticate itself with an iOS device in order to ensure seemless and secure communication. MFi Hardware developers have two options for Authentication, when integrating HomeKit. This can be done through HW or SW. HW authentication means your product will need to embed an MFi Chip on its PCB and SW Authentication means you can use a software based solution (provided by Apple) the option is yours to choose. Neither of them is costly it all depends of what suits you best. All info, tech specs and support is available through the MFi Program

Wenn die ggf Hardware drin haben von Apple dann sind wir eh raus Bei Software gehts vllt?

[mac89muc]

@apollon77

Danke für die Info. Eine Frage dazu noch -

For comercial HomeKit solutions your company will need to register as a Hardware Developer with the MFi Program. (Free membership) The MFi Program is Apple’s Hardware Development Program, they help HW Developers integrate Apple technology. (CarPlay, AirPlay, HomeKit...) Any non Apple Product that integrates Apple technology will need to authenticate itself with an iOS device in order to ensure seemless and secure communication. MFi Hardware developers have two options for Authentication, when integrating HomeKit. This can be done through HW or SW. HW authentication means your product will need to embed an MFi Chip on its PCB and SW Authentication means you can use a software based solution (provided by Apple) the option is yours to choose. Neither of them is costly it all depends of what suits you best. All info, tech specs and support is available through the MFi Program

Wenn die ggf Hardware drin haben von Apple dann sind wir eh raus Bei Software gehts vllt?

Kann ich hier noch was checken, ob "nur" softwareseitig etwas verbaut ist, oder war's das erstmal, weil selbst bei softwareseitiger Lösung ein MFI Account/Lösung nötig wäre für den ioBroker?

Gruß

[apollon77]

@mac89muc Gut Frage, keine Antwort. Da die Nuki Leute vom Coprozessor gesprochen haben, denke ich das die MFi Hardware nutzen.

Und naja das Nanoleaf ist irgendwie andere Baustelle weil das antwortet ja gleich gar nicht ... aber vllt ist das auch was

Am Ende ist die "Open Source Version der Homekit Protokoll Specs" von Apple von 2019 ... seitdem keine Updates mehr. Ich fürchte wir müssen erstmal damit leben

[pql]

@apollon77
Ich habe ja auch Probleme meinen Eve Energy zu verbinden, da Connections gerne direkt disconnected werden.
Wenn ich den pairing-mode fix auf PairSetup stelle, scheint zumindest M1 durchzugehen.

Ich habe dazu ein anderes Projekt einmal getestet, damit war das Pairing mit dem Eve Energy ohne Probleme möglich, konnte aber noch nicht ermitteln was da anders läuft. Zumindest wird in M1 definitiv ein anderes Packet gesendet (und nicht nur die Transaction id)

Gerne sonst einfach mal die Nanoleafs hier gegen testen: https://github.com/jlusiardi/homekit_python
Ist leider nur kein Javascript sondern Python und daher nicht mit node testbar.

[apollon77]

@pql Also Eve Energy (also so ne Steckdose) hab ich hier und die tut ... bräuchte ich auch gern volles log. müsste man mal schauen das manLogs bekommt und dann gegeneinanderhalten. Ich habe leider kein solches gerät

[pql]

@apollon77 das mit den logs (zumindest gegen deinen hap-controller) haben wir hier im thread schon durch

Die logging Ausgaben hab ich schon angefangen zu vergleichen, ist nur teilweise nicht so einfach, da der hap-controller in M1 das komplette TLV packet loggt und die python library nur Tag 1 und Tag 0.

Auch bin ich mir nicht so ganz sicher ob das nicht ein generelles Problem im hap-controller-node ist.
Ich hab mir aus dem hap-controller-node soweit das ble example pair-setup.js zurechtgebaut um damit zu testen.
Ich komme einfach gar nicht zur M1 wenn

const pairMethod = await discovery.getPairMethod(service);

drin ist und ich die pairMethod nicht manuell setze.

Dann passiert nämlich so ein Blödsinn:

Found device: Eve Energy EA06: Available for pairing: true
  hap-controller:gatt-connection connect peripheral +0ms
  hap-controller:gatt-connection c77fc41c4890/c7:7f:c4:1c:48:90 Write for characteristic 0000004f0000100080000026bb765291 0003001100 +766ms
  hap-controller:gatt-connection c77fc41c4890/c7:7f:c4:1c:48:90 Received data for characteristic 0000004f0000100080000026bb765291 0200000300010102 +74ms
  hap-controller:gatt-connection disconnect peripheral +1ms
  hap-controller:gatt-connection Peripheral disconnected +15ms
  hap-controller:gatt-connection connect peripheral +3ms
  hap-controller:gatt-connection Peripheral disconnected +283ms
Eve Energy EA06: Disconnected

Der 2. connect wird immer direkt ein Disconnect.

Lass ich mir das nicht discovern und setze direkt PairSetup komme ich beim M1 so weit:

Found device: Eve Energy EA06: Available for pairing: true
  hap-controller:gatt-connection connect peripheral +0ms
  hap-controller:tlv Add 1 bytes for tag 6: 01 +0ms
  hap-controller:tlv Add 1 bytes for tag 0: 00 +1ms
  hap-controller:tlv Add 6 bytes for tag 1: 060101000100 +2ms
  hap-controller:tlv Add 1 bytes for tag 9: 01 +1ms
  hap-controller:gatt-connection c77fc41c4890/c7:7f:c4:1c:48:90 Write for characteristic 0000004c0000100080000026bb765291 0002000f000b000106060101000100090101 +805ms
  hap-controller:gatt-connection c77fc41c4890/c7:7f:c4:1c:48:90 Received data for characteristic 0000004c0000100080000026bb765291 0200009d0101ff06010203ffde456388650a5e355dac3cda87031c7837931aa955868eba69f7819c7bf9f7154566df1798c359194b3d2324b20d6beaeae171dac5d339bfb3536594e155d96f744b236dbee213227f73513b0d2e94e1536769fc5a2fe02bd2773f32968d52a4f41dc8df1ea4f472a85dc3481e7e28c0749f2b48742aad14c3f64d7addfa3e4434becbc5274ae6e7c27270b57d4305fc0f9defa21f7aa2d3bb0cf5ddb41f2b480d758fa3f1481edddc0d35a7d50f8ab93654fa330b999e8b3c0140803df31f798b79fc0f7b05e143fc4506c00ccaaafb57800909fcfffa182e00d005f24b758975b53a65e9c25560e074535c86e318a9835c48 +551ms
  hap-controller:gatt-connection Peripheral disconnected +103ms
Eve Energy EA06: Disconnected

[apollon77]

@pql Vllt braucht man ein Dela zwischen dem Discovery und dem anderen? kannst mal versuchen zb 100ms zu warten? Vllt sind es einfach "zwei zu schnelle Disconnect/connects?

[pql]

@apollon77 bringt leider auch gar nichts, selbst 5 Sekunden Timeout zwischen den Steps sorgen für das gleiche Ergebnis

[apollon77]

@pql Was haste denn als pairMethod bekommen? Falls 0 probier mal pair mit 1, oder anders rum

[pql]

@apollon77 bekomme 0, hab auch schon beides probiert für M1, gleiches Ergebnis.
Die Python Library bekommt auch 0 und pair't damit; alles auf der gleichen Hardware.

[apollon77]

@pql Ok dann ist das Discobery ja schonmal richtig ... jetzt muss man nur den unterschied zwischen pythiong lib und nodejs lib (mit noble) rausfiunden

EDIT: Die vollständige rausgesendete nachricht vom Pythin siehst Du nicht?

[pql]

@apollon77

2022-06-07 14:53:52,256 __init__.py:0111 DEBUG #1 ios -> accessory: send SRP start request
2022-06-07 14:53:52,257 __init__.py:0647 DEBUG entering write function [
  <6, b'\x01'>,
  <0, b'\x00'>,
]
2022-06-07 14:53:52,257 __init__.py:0658 DEBUG sent 00020a0f000b000901010106060101000100
2022-06-07 14:53:53,259 __init__.py:0667 DEBUG reading characteristic
2022-06-07 14:53:53,807 __init__.py:0675 DEBUG control field: 2, tid: a, status: 0, length: 413
2022-06-07 14:53:53,807 __init__.py:0683 DEBUG received 020a009d0101ff06010203ff3e47781039678a527b74c8ec43fcedb2d8e8966401b004e67dd03e7d4814327b328cabfd6e61ea921d29183b5c386558624969886aa6c1ad7c8b98d9a1069256600d2d95f90e81d1bd9aaeb67e477332a0f4917788b4a251a70513320f99fa62465800b3acd1d0e6dc61b603a5283ac35efd474f45f93a827e9f68b5d71f53b2fc2c0eef5d45846cb809eaf266b49b5cd277011bab941ebd9c23aa61be97498842119af78b7f72a8e114c24d96bc6f19ed8a63b3f8073248faf30ab013a11d2440d0dbf5e2a5efb682f4ddf3f82335fd1e655850114b5fbb3d64c3f8d378954aff6bd4e53facb000038fc886f3398f2678163003442023308f6e019a788507e3b0038140cef6d797cf7e5e4e1b9d735fdc5ac72cf20e46108dee7550ee642ca4d3581f3971aa75a8ebbce127a0657617362e39f55f10a91f353fcbac2b4c1f82a1d9448845b07419264a5e15e953097f0a4f1e8136a4ca33feb1939e9886c51b97a716d3cf7e7a7d1b256d3d82054c13680ebb858549c373d93d87712284f0cf35c005730210d06ce1ea376ec83f9dda8a2542a6fee6

[apollon77]

@pql sagte in Test Alpha Homekit-Controller 0.0.x:

tid: a

Das ist faktisch der Unterschied, die trx id bei uns ist 00 bei ihm 0a ... und da wir zwei CLients nutzen ist die trx Id immer 00 beim erste call... vllt ist das der grund das Discover mit 00 und ddirekt danach erster Pair Request mit 00 ...

willst mal was versuchen?

In deiner node-hap-controller lib hast du ein lib/transport/ble/gatt-client.js und dort in Zeile 60 ein

this.tid = -1;

Ersetz das mal durch

this.tid = Math.floor(Math.random() * 254);

Und dann neu versuchen

[pql]

@apollon77 leider gleiches Verhalten obwohl transaction id unterschiedlich.

[apollon77]

@pql Wäre ja auch zu einfach gewesen

Und mit der "random trx id" geht auch das pairing nicht wenn du den ersten Call weglässt und die Pair-Methode direkt mitgibst??

Auf was für eine rHardware-Platform machst Du es eigentlich? Vllt spielt sowas ja auch eine Rolle bzw in demm auch wie es unter der haube geht ... bei Node.js ist der BLE Stack halt "Noble"

[pql]

@apollon77 ja genau, hab discovery mal weggelassen um direkt zu pairen, aber neee.

das ganze läuft auf einem RPI 4B mit 4GB RAM und on Board Bluetooth. Mit einem BLE Stick hats aber auch genauso wenig funktioniert.
Node ist Version 16.15

[mac89muc]

@pql

Keine Ahnung ob das was zur Sache tut - hatte Ubuntu als VM auf meinem Macmini installiert und dort ioBroker inkl. HomeKit Controller laufen lassen + BLE Stick da der interne Apple BLE Adapter nicht weitergereicht wurde in der VM.

Mit der Konfiguration konnte ich keines meiner Eve Geräte anlernen.

Im jetzigen Setup mit ioBroker direkt auf dem Macmini (macOS) ohne VM mit Nutzung des direkten Apple BLE Adapters funktioniert das einbinden der Eve Geräte ohne Probleme.

Bin jetzt nicht wirklich vom Fach - aber ich habe das Gefühl unter Linux läuft das Bluetooth Thema nicht ganz so unkompliziert und verlässlich...

Gruß

[pql]

@mac89muc nachdem ich nun etwas damit gekämpft hab den hap-controller auf meinem Macbook zu installieren (zu viel Müll durch diverse XCode Versionen usw) konnte ich auf tatsächlich den Eve Energy ohne Probleme auch dort koppeln.

Also; was passiert da anders auf dem RPI 4, sodass es mit node nicht funktioniert aber mit python -_-

[apollon77]

@pql sagte in Test Alpha Homekit-Controller 0.0.x:

was passiert da anders auf dem RPI 4

Dann sind wir fürchte ich jetzt auf Firmware Ebene .... ppuuhh