Pi 3 als Bluetooth LE Scanner (Beispielscript)

ruhr70

Anbei die Version 0.4.1

327_bluetooth_ble_0.4.1.js

Mit der Version sollte nun das manuelle Löschen eines angelegten Bluetooth Device funktionieren.

Im Zweig Control des Device den Datenpunkt Delete_Device auf true setzen.

Dann wird nach einem Scandurchlauf (im Default 10 Sekunden) das Device mit all seinen Datenpunkten gelöscht.

Der Channel inkl. Name bleibt erhalten. Man erhält so eine Übersicht über die gelöschten Geräte.

Ansonsten kann man nachträglich auch den Channel ohne Gefahr manuell löschen.

Achtung! Wenn ein Gerät zum löschen gekennzeichnet wurde, würde ich den Scandurchlauf abwarten, bis das Gerät gelöscht wurde, bevor das Skript eventuell gestoppt wird.

Das Skript ist dann auch in der Beziehung komplett ohne Eingriff bedienbar.

Soll das Gerät wieder von der Blacklist gelöscht werden, so dass es beim Scan wieder automatisch hinzugefügt werden kann, kann die ID von der Blacklist im Zweig javascript.0.Bluetooth.InfoDevices.Blacklist.Deleted_Devices entfernt werden.

rascal

Danke,

funktioniert so wie von dir beschrieben.

rascal

Ich benutze das Script auf einem Remote Rasp, funktioniert soweit sehr gut.

Das einzige was mir aufgefallen ist, wenn ich am main iobroker stoppe/restarte, dann meldet das Script bei jedem Durchlauf, dass die Bluetooth devices nicht da sind.

Da hilft dann das Script anhalten, ControlScan_ON auf false setzten, bisschen warten, Script starten und variable wieder auf true setzen.

Muss das nächste mal schauen (wenn ich nicht vergesse), ob es hilft, wenn ich das Script vor dem iobroker restart stoppe und danach wieder starte

ruhr70

Ich habe immer noch keine Multihostumgebung aufgebaut. Muss ich wohl mal machen ;-)

Eventuell kann Bluefox was zu den Besonderheiten in der Multihostinstallation sagen.

Bekommst Du in der von Dir beschriebenen Situation dann irgendwelche Logeinträge?

Vielleicht kann man das ja abfangen.

Aus dem Bauch würde ich sagen, dass das nicht passiert, wenn Du vor dem ioBroker Restart das Skript stoppst.

Kamikaze

Ich möchte mich hier einmal einklinken.

Die gesamte Lösung ist äußerst interessant. Da ich zwei Raspberrys habe, eine produktive Umgebung (Raspi 2) und eine Testumgebung (Raspi 3). In der Testumgebung funktioniert alles prima.

Nun meine Frage: Wie bekomme ich noble auf dem Raspi 2 zum Laufen?

Am Raspi 2 habe ich einen LogiLink USB Bluetooth 4.0 Dongle.

Gibt es dafür irgendeine Anleitung, die auch funktioniert?

Ich erhalte bei der direkten Installation Fehlermeldungen.

Macht bitte so weiter, ich lerne inzwischen eine ganze Menge und treibe meine iobroker-Installation voran.
1055_error.txt

ruhr70

Ist denn der Bluetooth Dongle richtig installiert?

Auf gut Glück gegoogelt:

https://klenzel.de/3345

Kamikaze

Hallo,

bei mir ist nicht der Bluetooth-Dongle das Problem,

pi@rasp-ccu:~ $ sudo hcitool lescan

LE Scan …

7C:2F:80:AD:C3:7F (unknown)

7C:2F:80:AD:C3:7F Gigaset G-tag

7C:2F:80:AD:C3:7F (unknown)

7C:2F:80:AD:C3:7F Gigaset G-tag

7C:2F:80:AD:C3:7F (unknown)

sondern die noble installation.

sudo npm install noble --production --prefix "/opt/iobroker/node_modules/iobroker.javascript"

Die Fehlermeldungen sind in meinem vorherige Post enthalten.

Kamikaze

Naja, wenn man es richtig macht, dann funktioniert es auch.

Die Anleitung hatte ich ja schon abgearbeitet, ohne Erfolg. NAchdem ich aber die noble-Installation als root gemacht habe, lief alles durch, ohne Fehlermeldung.

Ich habe zwar derzeit den Überblick verloren, wann ich eine Installation als normaler User machen kann, wann mit sudo und wann als root, aber jetzt funktiniert es.

Danke und einen schönen Abend.

ruhr70

Hattest Du auch mal versucht, noble einfach in der Javascript Instanz einzutragen?

Siehe im ersten Post:

"2.) "noble" in der Javascript Instanz (Config) eintragen (ohne Anführungszeichen)"

Kamikaze

Hallo ruhr70,

das war mein erster Versuch, der natürlich scheiterte. Es gab eine Reihe an Fehlermeldungen im iobroker log und der Scanner brachte auch Fehler.

Erst als ich als root die Installation gemacht habe, war alles in Ordnung.

Jetzt nach längeren Testen, ist mir doch noch eine Sache aufgefallen:

Ich setze ein G-Tag ein und stelle fest, dass sowohl auf der Produktivmaschine als auch auf der Testmaschine der Status häufig kurz wechselt, obwohl sich an dem Standort des G-Tags nicht ändert.

Er liegt ca. 1m von beiden Rechnern entfernt und die Variable lastState ist im Scan meistens true, wie erwartet, springt zwischendurch aber kurz auf false um dann gleich wieder true zu werden.

Hast du dafür eine Idee?

ruhr70

~~@Kamikaze:~~

Ich setze ein G-Tag ein und stelle fest, dass sowohl auf der Produktivmaschine als auch auf der Testmaschine der Status häufig kurz wechselt, obwohl sich an dem Standort des G-Tags nicht ändert.

Er liegt ca. 1m von beiden Rechnern entfernt und die Variable lastState ist im Scan meistens true, wie erwartet, springt zwischendurch aber kurz auf false um dann gleich wieder true zu werden. `

Bei mir läuft der G-Tag sauber durch.

Was bedeutet "gleich wieder auf true"?

Im nächsten Scandurchlauf? Oder "flackert" der Zustand in den Objekten?

lobomau

~~@ruhr70:~~

~~@Kamikaze:~~

Ich setze ein G-Tag ein und stelle fest, dass sowohl auf der Produktivmaschine als auch auf der Testmaschine der Status häufig kurz wechselt, obwohl sich an dem Standort des G-Tags nicht ändert.

Er liegt ca. 1m von beiden Rechnern entfernt und die Variable lastState ist im Scan meistens true, wie erwartet, springt zwischendurch aber kurz auf false um dann gleich wieder true zu werden. `

Bei mir läuft der G-Tag sauber durch.

Was bedeutet "gleich wieder auf true"?

Im nächsten Scandurchlauf? Oder "flackert" der Zustand in den Objekten? `
Bei mir passiert das erst wenn der dongle etwas weiter weg ist. In meinem Fall liegen die dongle in zwei Autos hintereinander geparkt. Das Auto weiter weg wechselt oft von true auf false und wieder zurück. Im Bild ist der X1 näher als der C3. Obwohl beide hin und wieder auf false wechseln, steht beim counter jeweils eine große positive Zahl, die anzeigt seit wievielen Versuchen es auf true steht. Müsste nicht jedes Mal wenn es auf false geht der counter auf Null gesetzt werden?
1146_unbenannt.jpg

ruhr70

~~@lobomau:~~

Bei mir passiert das erst wenn der dongle etwas weiter weg ist. In meinem Fall liegen die dongle in zwei Autos hintereinander geparkt. Das Auto weiter weg wechselt oft von true auf false und wieder zurück. Im Bild ist der X1 näher als der C3. Obwohl beide hin und wieder auf false wechseln, steht beim counter jeweils eine große positive Zahl, die anzeigt seit wievielen Versuchen es auf true steht. Müsste nicht jedes Mal wenn es auf false geht der counter auf Null gesetzt werden? `

Ja, stimmt müsste es. Danke für den Hinweis!

In der Funktion ist ein Fehler. Wenn ein Gerät nicht erreichbar ist, wird nicht auf 0 gesetzt, sondern die vorhandene Zahl um 1 reduziert.

`function nichtErreichbar() {
    for (var i=0; i<bekanntedevicesnichterreichbar.length; i++)/{/var/id="bekannteDevicesNichtErreichbar[i];" if(!inblacklist(id))/setstate(devicepfad/+/".laststate"/,false);/".laststatecount"/,getstate(devicepfad/".laststatecount").val/-/1);/}/}<e=""></bekanntedevicesnichterreichbar.length;>`

Richtig wäre:

`~~[code]~~function nichtErreichbar() {
    for (var i=0; i <bekanntedevicesnichterreichbar.length; i++)/{/var/id="bekannteDevicesNichtErreichbar[i];" if(!inblacklist(id))/setstate(devicepfad/+/".laststate"/,false);/laststatecount="getState(devicePfad" ".laststatecount"/).val;/if(laststatecount="">0) {
                lastStateCount = 0;
            } else {
                lastStateCount = lastStateCount - 1;
            }
            setState(devicePfad + id + ".lastStateCount"   ,lastStateCount);
         }
    }
}</bekanntedevicesnichterreichbar.length;>`

Wenn ein "Flattern" von Geräten ein Problem ist, könnte man noch einbauen, dass sich nach einem Wechsel des Zustands "erreichbar" für drei Zyklen der Zähler sich nicht ändert. 

Ein Indikator für An-und Abwesend wäre dann der Wert in lastStateCount und nicht in lastState.

Wenn es nötig ist, baue ich das gerne noch ein.[/i][/code][/i]

lobomau

~~@ruhr70:~~

Wenn ein "Flattern" von Geräten ein Problem ist, könnte man noch einbauen, dass sich nach einem Wechsel des Zustands "erreichbar" für drei Zyklen der Zähler sich nicht ändert.

Ein Indikator für An-und Abwesend wäre dann der Wert in lastStateCount und nicht in lastState.

Wenn es nötig ist, baue ich das gerne noch ein. `

Das wäre genial!

Kamikaze

Da ich beruflich viel unterwegs bin, kann ich nicht immer so schnell antworten.

Erst einmal super Job ruhr70.

Das "Flattern" ist in den Objekten sichtbar und damit werden auch die Ereignisse ausgelöst. Wenn du die "Stabilitätsroutine" einbauen würdest, wäre das ausgezeichnet.

Grüße aus dem hohen Norden

Kamikaze

Hallo,

ich habe das "Flattern" des G-Tags auf beiden Systemen beseitigen können, vielleicht hilft es auch bei Anderen:

Datei: /etc/init.d/bluetooth

den Eintrag NOPLUGIN_OPTION/in NOPLUGIN_OPTION="–noplugin=sap" ändern.

Danach

sudo service bluetooth restart

sudo service dbus restart

sudo reboot

Grüße

Kamikaze

Ich melde mich noch einmal, da ich noch einige Informationen gesammelt habe:

Der Ansatz, dass das "Flattern" in Abhängigkeit der Empfangsstärke liegt, kann ich bestätigen.

Wie man im Log sieht, ist beim Übergang in den Empfangsbereich ein "Flatter" zu sehen.

Gegen 17:21 Uhr bin ich nach Hause gekommen, gegen 13:22 Uhr habe ich das Haus verlassen.

–---------------------------------------------------------------------------------------------------------------------------------------------------

sayit-0 2016-08-06 17:21:55.131 info saying: Kurt ist anwesend

javascript-0 2016-08-06 17:21:55.099 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt wieder erreichbar 0 0

javascript-0 2016-08-06 17:21:55.098 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt false Neu true

sayit-0 2016-08-06 17:21:45.057 info saying: Kurt ist nicht mehr zu Hause

javascript-0 2016-08-06 17:21:44.978 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt nicht erreichbar -1 1

javascript-0 2016-08-06 17:21:44.978 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt true Neu false

sayit-0 2016-08-06 17:21:32.012 info saying: Kurt ist anwesend

javascript-0 2016-08-06 17:21:30.982 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt wieder erreichbar 0 0

javascript-0 2016-08-06 17:21:30.981 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt false Neu true

sayit-0 2016-08-06 13:23:42.182 info saying: Kurt ist nicht mehr zu Hause

javascript-0 2016-08-06 13:23:42.140 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt nicht erreichbar -1 1

javascript-0 2016-08-06 13:23:42.139 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt true Neu false

sayit-0 2016-08-06 13:23:28.540 info saying: Kurt ist anwesend

javascript-0 2016-08-06 13:23:26.103 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt wieder erreichbar 0 0

javascript-0 2016-08-06 13:23:26.102 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt false Neu true

sayit-0 2016-08-06 13:23:25.535 info saying: Kurt ist nicht mehr zu Hause

javascript-0 2016-08-06 13:23:22.066 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt nicht erreichbar -1 1

javascript-0 2016-08-06 13:23:22.065 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt true Neu false

sayit-0 2016-08-06 13:23:04.014 info saying: Kurt ist anwesend

javascript-0 2016-08-06 13:23:03.990 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt wieder erreichbar 0 0

javascript-0 2016-08-06 13:23:03.988 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt false Neu true

sayit-0 2016-08-06 13:22:53.159 info saying: Kurt ist nicht mehr zu Hause

javascript-0 2016-08-06 13:22:52.046 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt nicht erreichbar -1 1

javascript-0 2016-08-06 13:22:52.044 info script.js.Lokal.BluetoothEreignisse: G-Tag Kurt Ereignis: Alt true Neu false

Gruß

Solear

Ist das ein geiles Script!

Habe jetzt Gigaset Beacons für den Schlüssel gekauft und das Script auf einem Raspi 3 als Multihost (1. Slave) installiert. Jetzt gehen meine Alarmmeldungen per Pushover über Fensteröffnungen nur ein, wenn ich nicht Zuhause bin.

Genial! Danke ruhr70 für das Script und Danke Bluefox für iobroker!! 8-) :mrgreen:

Solear

Die Gigaset G-Tags haben eine ganz miese Eigenschaft :lol:

Sie stoppen die Verbindung zum Raspi-iobroker sobald sie mit dem Handy und der Gigaset G.-Tag App verbunden sind. Hat mich einen halben Tag gekostet das Problem zu finden. Da kommt man ja nicht drauf. Hatte nur 2 von den 3 G-Tags mit dem Handy verbunden, vergessen, und bin beim spielen mit dem Schlüssel/Auto/Empfang fast verrückt geworden.

Wenn ich jetzt Bluetooth am Handy ausschalte oder die App deinstalliere, dann werden alle G-Tags sauber von iobroker angezeigt.

eric2905

Darauf bin ich auch reingefallen :-D Hab auch einen halben Nachmittag damit verbracht.

Ich habe die beiden für die Anwesenheitserkennung einfach nicht an der App angelernt, sondern nur den dritten (aus dem Set) und den in der Tasche versenkt. Anscheinend können die G-Tags nur einen "Empfänger" gleichzeitig (ähnlich wie Pairing).

Was mir aber aufgefallen ist, ist dass das Datum der letzten Statusänderung nicht gesetzt wird. Muss mal in Ruhe schauen, warum das so ist.

Gruß,

Eric

Community Forum

NEWS

Pi 3 als Bluetooth LE Scanner (Beispielscript)

Support us

743

32.4k

81.5k

1.3m