Habe es nicht im Detail durchgelsen aber im Wesentlichen MQTT. Ich verwende die EDOMI Remote API statt MQTT.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Tutorial Anwesenheitsstatus
Einklappen
X
-
Ja . Aber eigentlich gleiche Funktionalität.
Hast du ne Idee wie ich den radius der BT Erkennung minimieren könnte ?
Laut den BT class'es fängt die Reichweite bei 1m an und geht in der nächst höheren class schon auf 10m
Um eine raumbezogene Erkennung zu schaffen ist 1m zu wenig und 10m zu viel
Als kleine ergänzung zu den Link vorher.
https://github.com/andrewjfreyer/monitor
So wie ich es verstehe kann ich über RSSI die detection beinflussen.
PREF_RSSI_CHANGE_THRESHOLD -20 If a beacon's rssi changes by at least this value, then the beacon will be reported again via mqtt. PREF_RSSI_IGNORE_BELOW -75 If an anonymous advertisement is "farther" away (lower RSSI), ignore the advertisement
Muss damit mal spielen. hatte schonmal einen versuch. Der war aber umgekeht.
Sendendes beacon mit App auf Smartphone (RSSI Radius detection und Tasker).
LG
Zuletzt geändert von trollmar; 21.03.2019, 12:34.Jean-Luc Picard: "Things are only impossible until they are not."
Kommentar
-
Zitat von trollmar Beitrag anzeigenJa . Aber eigentlich gleiche Funktionalität.
Hast du ne Idee wie ich den radius der BT Erkennung minimieren könnte ?
Laut den BT class'es fängt die Reichweite bei 1m an und geht in der nächst höheren class schon auf 10m
Um eine raumbezogene Erkennung zu schaffen ist 1m zu wenig und 10m zu viel
Und auch wenn die MQTT-Variante im Ergebnis das gleiche macht....wieso eine zusätzliche Fehlerquelle einbauen, wenn direkt edomi bedient werden kann ;-)
Kommentar
-
Zitat von McEgg Beitrag anzeigenHab mir die Gigaset Keeper mal bestellt...Ciao Jochen
Kommentar
-
Vielleicht hast du aus Versehen den Knopf länger als 5 Sekunden gedrückt, dann gibts quasi nen Reset, der bestimmt auch ins Timeout läuft.
Ich würde zunächst mal probieren den Knopf länger als 5 Sekunden zu drücken und sehen, ob die LED dann leuchtet. Wenn das der Fall ist, dann wieder über die App anlernen und danach die APP wieder deinstallieren und wieder mit dem RPI nutzen.
Kommentar
-
Ne, das wars nicht. Irgendwie hab ich gerade ein größeres Problem hier. Ich verliere jetzt immer beide Tags. Wenn ich das Skript starte, werden die Tags gefunden. Aber es wird nicht "weitergescannt". Eigentlich müsste das Skript ja weiterlaufen und jeden "Fund" der Tags aufführen. Es passiert aber nichts mehr. Ich hab alles komplett neu Installiert. Anscheinend gabs auch ne Änderung am Skript. Aber kann ja daran nicht liegen, wenn es bei allen anderen funktioniert.
Hast du eine Idee?
Nach 2 Minuten werden die Tags dann als inactive angezeigt. Starte ich das Skript neu, werden die Tags sofort wieder gefunden.
Code:root@ubuntupc:/usr/local/Bluetooth-scanner# php BTdaemon.php start There is no BLE.py process to kill There is no BTdaemon.php process to kill Starting Bluetooth Daemon Check config file exists Load config file Adapter: hci0 EDOMI base url: http://192.168.XX.XX/remote/?login=remote&pass=XXX&koid= logs: 1 Amount of BT tags: 2 Check Bluetooth Software & Hardware Found hciconfig: /bin/hciconfig Found hcitool: /usr/bin/hcitool Found python-bluez Bluetooth adapter found Bluetooth adapter UP & RUNNING children php BT scanner - 7601 children python BLE scanner - 7602 Start python BLE scanner root@ubuntupc:/usr/local/Bluetooth-scanner# Start as: sudo python BLE.py 0 root BTdaemon.php $1 [\"7C:2F:80:F5:XX:X1\",\"7C:2F:80:F5:XX:X2\"] 2019-04-05 11:29:04,662 - Will Use hci adapter hci0 2019-04-05 11:29:04,663 - Will use root as process User 2019-04-05 11:29:04,663 - Will use BTdaemon.php as php script callback 2019-04-05 11:29:04,663 - Will scan 2 tag(s) with bdaddr ["7C:2F:80:F5:XX:X1","7C:2F:80:F5:XX:X2"] 2019-04-05 11:29:04,663 - Connected to bluetooth adapter hci0 2019-04-05 11:29:05,311 - Tag 7C:2F:80:F5:XX:X1 seen @ 1554456545 2019-04-05 11:29:05,516 - Tag 7C:2F:80:F5:XX:X2 seen @ 1554456545 URL call ERROR: OK;291;1; Active Tag found: 7C:2F:80:F5:XX:X1 URL call ERROR: OK;292;1; Active Tag found: 7C:2F:80:F5:XX:X2 2019-04-05 11:29:08,331 - Tag 7C:2F:80:F5:XX:X1 seen @ 1554456548 2019-04-05 11:29:08,526 - Tag 7C:2F:80:F5:XX:X2 seen @ 1554456548
Edit:
Nach zig mal starten und stoppen läuft es jetzt gerade wieder. Ka, warum das auf einmal so unzuverlässig ist. Vielleicht mal was anderes als Ubuntu versuchen??Zuletzt geändert von McEgg; 05.04.2019, 10:50.Ciao Jochen
Kommentar
-
McEgg Ich habe ein ähnliches Problem mit einem RPi zero in meiner Zweitwohnung. Das lief auch monatelange problemlos und jetzt stoppt die Funktion nach einiger Zeit und es hilft offensichtlich nur ein Reboot. Habe im Moment wenig Zeit zur Fehleranalyse. Der RPI3 in unserem Haus funktioniert problemlos mit denselben Tags. Daher muss es irgendwo am RPI zero liegen. Sollte ich die Ursache finden, werden ich sie hier posten und hoffentlich auch die Lösung dazu. Vielleicht ist es ja dann bei deinem NUC ein ähnliches Problem.
Kommentar
-
Ok, interessant... Also wenns mal läuft, ist es echt klasse und funktioniert perfekt. Ka, ob es an der Hardware liegt, wenn auf unterschiedlichen Geräten das gleiche Problem auftritt. Bei mir hat ein einfacher Neustart nicht wirklich geholfen. Erst nach einigen Versuchen ist es dann wieder gelaufen. Ka, was das sein könnte. Im Moment läuft es ja wieder... Wenn dir irgendwas auffällt kannst ja mal Bescheid geben.Ciao Jochen
Kommentar
-
Ich muss das Thema nochmal hochholen.
Habe jetzt das Ganze nochmal neu unter Debian installiert. Allerdings bekomme ich die Gigasets einfach nicht mehr gepaired. Kann da jemand helfen?
Code:[Gigaset keeper]# info 7C:2F:80:F5:EA:71 Device 7C:2F:80:F5:EA:71 (public) Name: Gigaset keeper Alias: Gigaset keeper Paired: no Trusted: yes Blocked: no Connected: yes LegacyPairing: no UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Immediate Alert (00001802-0000-1000-8000-00805f9b34fb) UUID: Link Loss (00001803-0000-1000-8000-00805f9b34fb) UUID: Tx Power (00001804-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb) UUID: Dialog Semiconductor GmbH (0000fef5-0000-1000-8000-00805f9b34fb) UUID: Vendor specific (6d696368-616c-206f-6c65-737a637a796b) Modalias: bluetooth:v0180p0002d0100 ManufacturerData Key: 0x0180 ManufacturerData Value: 02 15 01 00 80 f5 ea 71 c5 .......q. RSSI: -85
Code:[bluetooth]# pair 7C:2F:80:F5:EA:71 Attempting to pair with 7C:2F:80:F5:EA:71 [CHG] Device 7C:2F:80:F5:EA:71 Connected: yes Failed to pair: org.bluez.Error.AuthenticationFailed [CHG] Device 7C:2F:80:F5:EA:71 Connected: no
Ciao Jochen
Kommentar
-
Ah ok sorry, zu wenig Infos.
Ich hab nen Intel NUC. Auf dem lief die ganze Zeit eine Suse Linux VM. Die Gigaset Keeper waren mit dem NUC, bzw. der Suse VM per Bluetooth gekoppelt.
Jetzt habe ich die VM neu aufgesetzt. Allerdings ne Debian VM. Ich sehe die Keeper unter Linux. Allerdings will das Pairing nicht hinhauen.
Verstehe gerade nicht, warum immer ein Authentication Fehler kommt.
Hab mir auch schon nen Wolf gesucht, aber komme nicht weiter.Ciao Jochen
Kommentar
Kommentar