Test Adapter BLE v0.12.x

[m0rph]

@Thomas-Braun Ja das stimmt, sollange es funtkionert bis dahin ist das auch kein Thema, sind extra Raspberries die nur BT Beacons scannen

[Thomas Braun]

@m0rph Mit dem Werkzeug machen aber Tests keinen Sinn.
Das neuer Code da nicht drauf läuft ist ja keine Überraschung.

[m0rph]

@Thomas-Braun Habe auch nichts anderes behauptet

[AlCalzone]

@m0rph Was steht denn im Zustand info.driverState? Findest du was auffälliges im Log?

Ich wüsste jetzt ad hoc nicht, warum das nicht auch auf Node 8 laufen sollte.

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