Test Adapter BLE v0.12.x

[locito09]

@AlCalzone
Bei mir läuft der Adapter

Node.js: v12.19.0
NPM: 6.14.8

Mit Pflanzen sensor
Temp. Sensor

Auf master und Slave

[crunchip]

@AlCalzone sagte in Test Adapter BLE v0.12.x:

Beim Absturz oder Hänger kann dieser einfach neu gestartet werden, ohne den Hauptprozess zu beeinträchtigen.

habe nun auch mal von 0.11.8 auf 0.12.0 gewechselt vor ein paar Tagen, nun ist mir aber aufgefallen, dass vermehrt

ble.0	2020-12-30 01:24:22.064	info	(6936) stopping scan
ble.0	2020-12-30 01:23:52.405	info	(6936) starting scan for services ["fe95"]

im log auftaucht, vor allem, nachdem cron um 0:05, diese Meldungen ziehen sich teilweise dann durch die halbe Nacht

aus dem gestrigen log hab ich dieses noch gefunden

2020-12-29 02:24:10.113 - info: ble.0 (13930) starting scan for services ["fe95"]
2020-12-29 02:24:39.935 - info: ble.0 (13930) stopping scan
2020-12-29 02:24:41.938 - error: ble.0 (13930) EALREADY, Operation already in progress
2020-12-29 02:24:42.006 - info: ble.0 (13930) starting scan for services ["fe95"]

ab da war dann Ruhe für die Nacht/den Tag

Konstellation bei mir

hci0 intern für ble , rssi update intervall 10000ms
hci1 extern für radar

edit:
das heutige log zeigt, das es sich bis 5:06Uhr hingezogen hat

2020-12-30 05:04:52.791 - info: ble.0 (6936) starting scan for services ["fe95"]
2020-12-30 05:05:22.574 - info: ble.0 (6936) stopping scan
2020-12-30 05:05:22.739 - info: ble.0 (6936) starting scan for services ["fe95"]
2020-12-30 05:05:52.593 - info: ble.0 (6936) stopping scan
2020-12-30 05:05:52.748 - info: ble.0 (6936) starting scan for services ["fe95"]
2020-12-30 05:06:22.616 - info: ble.0 (6936) stopping scan
2020-12-30 05:06:52.658 - error: ble.0 (6936) EALREADY, Operation already in progress
2020-12-30 05:06:52.758 - info: ble.0 (6936) starting scan for services ["fe95"]

[AlCalzone]

@crunchip "stopping scan" passiert, wenn der Bluetooth-Stack meldet, dass die Bluetooth-Schnittstelle "poweredOff" ist. "starting scan" kommt, wenn diese bereit ist...
Irgendwas scheint bei dir alle 30 Sekunden den Status der Schnittstelle zu ändern.

[crunchip]

@AlCalzone ok,
hab grad den Zeitstempel angesehen für "driverState", letzte Änderung 12:16Uhr
diese deckt sich mit dem log, stopp/start scan...

@AlCalzone sagte in Test Adapter BLE v0.12.x:

Irgendwas scheint bei dir alle 30 Sekunden den Status der Schnittstelle zu ändern.

Irgend eine Idee Vermutung, was das sein könnte?

[AlCalzone]

@crunchip Leider nein

[crunchip]

@AlCalzone
ich hab jetzt mal etwas getestet, bin wieder auf die 0.11.8 zurück, natürlich keine Besserung.
Nun hab ich mal den radar2 Adapter deaktiviert, ble(driveState) läuft nun sauber, auch nach einem neustart, des ble, bleibt es einmalig bei einem scan Vorgang. Also muss da der radar2 mit reinfunken.

Dementsprechend hab ich ne Vermutung/Frage,
kann es sein, das irgendwo im System was hängen geblieben ist und nicht richtig verarbeitet wurde,
da ich, als ich auf die v0.12 bin, zeitgleich, hci0/1 beider Adapter getauscht hatte. Allerdings waren für die Änderung beide Adapter gestoppt.
Ich beobachte das nun mal, scheinbar stimmt da etwas beim radar2 Adapter nicht. Denn dort habe ich hci1 eingestellt in der Config,
jedoch im log sehe ich

radar2.0	2020-12-30 16:02:18.831	info	(8055) Will try to scan BT devices: hci1 94:E6:F7:B0:5E:22 hci0 00:1A:7D:DA:71:0E

[AlCalzone]

@crunchip sagte in Test Adapter BLE v0.12.x:

Ich beobachte das nun mal, scheinbar stimmt da etwas beim radar2 Adapter nicht. Denn dort habe ich hci1 eingestellt in der Config,
jedoch im log sehe ich

Das sieht ganz so aus als würde der radar2 die Einstellung nicht beachten.

[Holzlenkrad]

@AlCalzone

Hey,
ich hatte es glaube ich schon mal vor 1-2 Jahren gefragt, aber gibt es wirklich keine Möglichkeit die Bluetooth-Schnittstelle eines anderen Hosts zu nutzen? Also z.B. über SSH.

Hintergrund ist, dass bei mir iobroker in einem Docker Container läuft. Und Docker hat leider keinen Zugriff auf die BT-Schnittstelle.

[AlCalzone]

@Holzlenkrad Mir ist keine bekannt. Wenn Google dir was anderes ausspuckt, lass es mich gerne wissen

[Holzlenkrad]

@AlCalzone

Ich weiß leider nicht wie genau dein Adapter funktioniert. Evtl. wäre es möglich, die dafür nötigen Executables per SSH auf einem anderen Host auszuführen.
Meine derzeitige Lösung nutzt einfach bluez zur Kommunikation mit dem BLE Thermometer und das sieht dann so aus:
"ssh root@192.168.0.2 'bluez ...'"

[AlCalzone]

@Holzlenkrad Ich nutze intern die noble Library, da hab ich wenig Einfluss was intern passiert.
Hast du mal über Multihost nachgedacht? Ich hab ioBroker BLE auf nem Pi Zero W laufen, um Empfangsproblemen im Haus entgegen zu wirken.

[Wszene]

Ich habe mal eine Frage

Kann ich diesen Adapter für eine Anwesenheitserkennung mit einem Xiomi Mi Band 5 und einer Apple Watch nutzen

Wenn Ja wie bekomme ich die Beiden Geräte rein?

Danke im Voraus
Gruß
Marcel

[AlCalzone]

@Wszene ble.0.options.allowNewDevices muss dafür auf true stehen (bitte danach wieder ausschalten!)
Vermutlich muss auch diese Option in den Einstellungen gesetzt sein:

[Wszene]

@AlCalzone
Danke genau das habe ich gemacht
Es werden gefühlt 1000 Geräte gefunden
Aber eine Apple Watch ist nicht dabei
Das Mi Band 5 meiner Frau wurde gefunden

Die nächste Frage die ich mir stelle ist wie kann ich dann mit den Datenpunkte sehen wann Jemand da ist oder nicht

[AlCalzone]

@Wszene Such mal im Forum, es gibt Skripte hierfür. Meist wird geschaut, ob RSSI (Signalstärke) länger nicht aktualisiert wurde, dann ist das Gerät abwesend.

[pgBroker]

@alcalzone Keine Ahnung ob das der passende Thread für mein Problem ist, aber da ich den BLE 0.12 nutze schreibe ich es mal hier rein.

Es geht um die runden BLE Thermometer/Hygrometer mit e-Ink Display.

Ich hatte mir vor Weihnachten diese mit HomeKit Unterstützung bestellt:
https://www.amazon.de/gp/product/B08HN15N6J/ref=ppx_yo_dt_b_asin_title_o07_s00?ie=UTF8&psc=1
Werden zwar als Cleargrass beworben, auf den Geräten steht aber Qinping.

Wollte die parallel über ioBroker auslesen für Automatisierungen und Grafana Plots bekomme sie aber nicht über deinen Adater eingebunden:

Hatte dir dazu auch schon mal auf Github was geschrieben.

Habe mir jetzt zum Testen auch einen ohne HomeKit Unterstützung gekauft:
https://www.amazon.de/gp/product/B08L4S5V4Y/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
Heißt wieder Cleargrass, dieses mal M-Version an Stelle von H-Version, auf dem Geräte steht aber wieder Qinping. Es ist in der Tat nicht HomeKit kompatibel und lässt sich anders als die H-Version mit der Xiaomi Home App verbinden und auslesen.

In ioBroker bekomme ich schon mal 2 services fdcd und fe95 angezeigt aber immer noch keine Temperatur und Luftfeuchtigkeit.

Die 58:2D:34 ist ja angeblich ab der 0.7.2 eingetragen, d.h. das Gerät müsste als ein MiTemperature Gerät erkannt werden.

Hast du eine Idee, woran es liegt, dass ich keine Werte angezeigt bekomme?

[Rushmed]

@pgbroker said in Test Adapter BLE v0.12.x:

Unterstützung gekauft:

Hast du das Xiaomi Plugin im Adapter aktiviert?

[pgBroker]

@rushmed Ja, habe ich.

[AlCalzone]

@pgbroker Poste mir bitte mal die vollständigen Werte. Mit halb abgeschnitten Strings in Screenshots kann ich nichts anfangen.

[pgBroker]

@alcalzone Hi. Habe noch ein bischen im Internet recherchiert und folgenden Link gefunden:

https://github.com/alexvenom/XiaomiCleargrassInkDislpay/blob/master/XiaomiClearGrassInk.js

Darin steht, dass alle Informationen im service "FDCD" stehen und auch, was sie bedeuten:

        /* All the information is in this Property called "FDCD" on the advertising data.
           The HEX string is as follows:
           "0807453810342d580104f500da02020145" (quotes included)
           To which:
           0807 or 0801: Ignore, but useful to identify relevant data
           453810342d58: MAC address, INVERTED (58:2d:34:10:38:45)
           0104f500da02: Data for Temperature and Humidity, broken as follows
             - 01: Indicates the Temperature and Humidity events
             - 04: Event data length (4, 2 bytes for Temperature, 2 bytes for Humidity)
             - f500: Temperature data inverted (00f5), which translates to 245, equivalent to 24.5C
             - da02: Humitity data inverted (02da), which translates to 730, equivalent to 73.0%
           020145: Data for Battery, bronek as follows
             - 02: Indicates the Battery events
             - 01: Event data length (1 byte)
             - 45: Battery data, which translates to 69, equivalent to 69%

Habe das eben mal mit meinem Teil nachgerechnet.

Aktueller Wert in fdcd: 8816 790812342d58 01 04 bb00 5e01 020164

Aufgedröselt nach obiger Beschreibung ergibt das:

8816 - Irgend was
790812342d58 - MAC Adresse umgedreht, passt.
01 04 - irgendwelche Events
bb00 - x00bb sind 187 entspricht 18,7°C
5e01 - x015e sind 350 entspricht 35%
020164 - relevant ist nur x64 entspricht 100%

und der Sensor zeigt an: 18,7°C, 35% Luftfeuchtigkeit und volle Batterie.

Ich würde sagen, das passt exakt.

So wie ich das sehe, braucht es zum Auslesen ein eigenes Plugin, denn das Xiaomi Plugin erwartet die Daten im Service "fe95".

Die Daten aus dem Service String rauszuparsen ist eigentlich simpel (s. obigen Link):

        if (JSON.stringify(serviceData[i].uuid).includes('fdcd')){
            stringAdvertise = JSON.stringify(serviceData[i].data.toString('hex'))
            temp = parseInt(stringAdvertise.substring(23, 25) + stringAdvertise.substring(21, 23), 16)
            console.log('Temp: ' + temp/10 + 'ºC')
            humidity = parseInt(stringAdvertise.substring(27, 29) + stringAdvertise.substring(25, 27), 16)
            console.log('Humidity: ' + humidity/10 + '%')
            battery = parseInt(stringAdvertise.substring(33, 35), 16)
            console.log('Battery: ' + battery + '%')
            console.log('')
        }