Test Alpha Homekit-Controller 0.0.x

[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

[mac89muc]

@apollon77

Habe jetzt seit zwei Monaten meine Eve Thermos über den Adapter eingebunden. In dieser Zeit war ja nicht gerade die große Heizperiode mit viel "Arbeit" für die Thermostate bei den Aussentemperaturen.
Dennoch sind die Akkus sehr schnell leer - bei direkter Einbindung in HomeKit halten die länger.
Kann das am Pollinginterval liegen, oder hast Du sonst einen Tipp?

Viele Grüße

[apollon77]

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

Kann das am Pollinginterval liegen, oder hast Du sonst einen Tipp?

Wäre auch meine Vermutung ... Homekit pollt halt nicht sondern fragt nur dann ab wenn Du es in der App abfragst ...

[mac89muc]

@apollon77
Danke für die schnelle Rückinfo.

Für mich zum Verständnis nach der Adapterinfo auf Git s.u. - es gibt zwar keine Realtime Updates aber die Werte werden unabhängig vom Polling Intervall automatisiert getriggert und aktualisiert bei Änderungen die am Thermostat selbst gemacht werden (Aus- Einschalten, Temperatur ändern....) und wenn ich Änderungen über iobroker ans Thermostat schicke, werden die ja auch geupdatet. Worauf bezieht sich dann das Polling Intervall bzw. für welche Werte ist das dann noch nötig (Batteriestand?) - was wäre eine sinnvolle Zeitspanne?

"Because of the limitations of Bluetooth devices no "real-time updates" of state changes are available. The devices will report "important state changes" (e.g. the "On" state changes) by special packages that will trigger an immediate data refresh. Additionally, data are refreshed in the defined data polling intervals. Do not set them too short!"

[apollon77]

@mac89muc bei wlan/ip Geräten brauchen wir kein polling im Normalfall weil dort das subscriben auf Änderungen tut und Änderungen gemeldet werden. Deswegen kann man da selten Pollen.

Bei Bluetooth ist es so das solche subscriptions nur für ca 30-60 Sekunden gelten und dann ist die Connection weg. Bzw auch generell hab ich das (mit den zwei Bluetooth Geräten dienlich nur hab) nie sinnvoll hinbekommen. Daher aktualisierten sich Bluetooth Geräten nur per polling. Außer einige „Haupt States“ der Geräte kommen teilweise als announcements - dann pollt der a dapper auch. Das sind aber nie Temperaturänderungen oder so. Daher auch das eigene polling Intervall.

Sinnvoller polling interval musst du sagen … wie „aktuell“ willst du die werte im iobroker haben?

[mac89muc]

@apollon77
Habe mal etwas mit dem polling Intervall rumgespielt - leider keine wesentliche Änderungen. Auch die Batterielaufzeit wird mir bei den Thermostaten nicht zuverlässig aktualisiert - auf einmal sind die Batterien leer. Hatte mir vorher eigentlich ein Script mit Warnung über pushover erstellt, hilft aber wie gesagt nichts.

Gibts evtl. eine Chance die Eve Thermostate irgendwann evtl. mit Matter in den iobroker zu bekommen - was meinst Du? Ansonsten ist der Umweg über Regeln in HomeKit recht aufwändig und unpraktikabel um die Zustände und Temperaturen der Thermostate mit persönlichen Automationen und simpleAPI in iobroker zu bekommen.

Wäre daher am einfachsten wenn Matter die Möglichkeit irgendwie aufbohrt über einen Adapter direkt mit den Eve Thermostate in iobroker kommunizieren zu können.

Gruß

[apollon77]

@mac89muc naja matter ist erstmal ne ganz andere nimmermüde ja wird garantiert kommen. Aber erstmal müssen das die Geräte können und so …