Test Adapter BLE v0.12.x

[Thomas Braun]

@AlCalzone
Unauffällig im positiven Sinne. Installation lief sauber durch und meine beiden Xiaomi BT Thermometer wurden wie zuvor gefunden und liefern Werte.
node 14.15.0
npm 6.14.8

[Siegfried]

@AlCalzone

Läuft hab aber auch nur 2 Xiaomi Thermometer
Node.js v12.19.0
NPM 6.14.8

[m0rph]

@AlCalzone
Also bei mir bleibt der Adapter gelb beim zurückweseln funktioniert er wieder, ist allerdings nicht alles up to date
node 8.17
npm 6.13.4
js-controller 2.1.1

[Thomas Braun]

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

ist allerdings nicht alles up to date

Das ist mal eine herbe Untertreibung.
Das ist so alt, das riecht schon nicht mehr.

[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