UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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 …

[mac89muc]

@apollon77

für mich zum Verständnis - polling Intervall bezieht sich ja nur auf das abrufen der Daten von den verbundenen Geräten. Änderungen die ich eintrage wie z.B. die Target Temperature bei meinen Thermostaten, sollten unabhängig vom polling direkt übertragen werden, oder?

Zum Teil stehen bei mir nämlich andere Werte am Thermostat physisch vor Ort als wie im Adapter eingetragen sind..

Wenn ich z.B. um 07:00 Uhr die Heizung auf 21° C stellen möchte und das im entsprechenden Datenpunkt (Target-Temperature) eintrage, bleibt das im Datenpunkt auch drin stehen. Allerdings zeigt mir das Thermostat vor Ort noch den alten Wert von 17° C an auch um 08:00 Uhr - es handelt sich also nicht um einen kleinen zeitlichen Versatz.

Also wurde der Wert zum einen nicht vom Adapter übernommen und zum anderen im Adapter nicht überschrieben mit dem Wert der im Thermostat real als Target Temperature hinterlegt ist.

Sollte das wechselseitig so funktionieren, falls ein Thermostat mal nicht erreicht wird beim senden, dass beim nächsten Abruf dann der tatsächliche Wert vom Thermostat in den Datenpunkt geschrieben wird?

Ansonsten fällt es anhand der Anzeige ja nicht auf, dass der Wert nicht übernommen wurde, nur beim tatsächlichen überprüfen am Thermostat selbst.

Gruß

[apollon77]

@mac89muc Ja Polling bezieht sich auf die Datenabfrage.

Wie setzt du den eine Zieltemperatur? WICHTIG da s ack-Flag (Bestätigt) muss dabei immer false sein!! (Ack=true ist kein Kommando und wird damit nicht umgesetzt).

Sonst gern im Log schauen. Falls ein Wert nicht gesendet werden konnte steht das da an sich drin.

An sich wird nach dem korrekten Setzen eines wertes ein paar Sekunden später dieser Wert gelesen und damit dann nochmal "mit ack flag vom Adapter bestätigt".

Polling überschreibt immer das was im Datenpunkt steht.
Bestätigte Werte zeigt der Admin grün an. Rote Werte sind unbestätigt.

[mac89muc]

@apollon77 - So setze ich die Werte aktuell.
Bedeute aber es kann passieren, dass während eines Pollings der Wert der kurz vorher in den Datenpunkt geschrieben wurde überschrieben wird mit dem aktuellen Wert des Thermostats. Es wird also der ursprünglich im Datenpunkt geänderte Wert dann nicht mehr an das Thermostat übertragen, oder?

Hast Du noch einen Tipp zum Thema Speicher für mich...? So sieht es aktuell bei mir aus - der Adapter braucht ziemlich viel..

Gruß

[apollon77]

@mac89muc Wenn der Wert geschrieben wird, dann wird das ganze gesendet - und auch nach dem Senden und ok vom gerät nochmal vom Gerät 5s später oder so der dann aktuelle Wert gelesen.

Ich könnte mir nicht vorstellen wie sich das mit dem Polling so wie Du sagst Überschneiden kann.

Wenn Du genauer schauen willst starte den Adapter mal mit Loglevel Debug und poste mal das Log.

Zum RAM: Hui das ist viel ... Nein ist der erste Bericht dazu. Ist der die ganze Zeit so hoch oder steigt es über die Zeit an? Wenn es ansteigt dann wäre mal interessant zu sehen wie - am besten nimm mal History oder so und logge die RAM States unter system.adapter.homekit-controller.0 mit ... dann sieht man den zeitverlauf.

[mac89muc]

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

Zum RAM: Hui das ist viel ... Nein ist der erste Bericht dazu. Ist der die ganze Zeit so hoch oder steigt es über die Zeit an? Wenn es ansteigt dann wäre mal interessant zu sehen wie - am besten nimm mal History oder so und logge die RAM States unter system.adapter.homekit-controller.0 mit ... dann sieht man den zeitverlauf.

Ohne es jetzt genau beobachtet zu habe, steigt der m.E. nach an - liegt aktuell bei > 3GB
Habe den Adapter mal auf Info Logstufe umgestellt (lief vorher schon im Debug Modus) und neu gestartet.

Welchen DP soll ich tracken?

Gruß

[apollon77]

@mac89muc memRss und die beiden heap* an sich

[mac89muc]

@apollon77

Hier mal die Infos - lt. Systembericht/Aktivitätsanzeige hat der Adapter wieder >4GB Speicher in der Nutzung gehabt - nach Adapterneustart jetzt bei ca 460 MB.

Gruß