NEWS
[Adapter] Neuer radar2-Adapter
-
@frankjoke Scheint so als hätte ich jetzt meine Devices verärgert Was gestern Abend noch problemlos klappte (und vorhin auch, nachdem ich den Adapter aktualisiert hatte), will jetzt nicht mehr. Die Devices antworten auf einmal von jetzt auf gleich nicht mehr auf L2Pings, weder vom Adapter noch von der Konsole. Irgendwas ist doch da faul mit den Dingern...
EDIT: Ich habe übrigens noch eine andere Idee, wie man statt L2Ping mit
hcitool
rausfinden kann, ob ein Gerät "alive" ist. hcitool hat den angenehmen Nebeneffekt, dass es bei der Parameterabfrage viahcitool info <MAC>
(und meines Wissens nach NUR beiinfo
) einen Errorlevel speichert. Diesen kann man danach leicht abfragen:Real existierende MAC abgefragt (Ergebnis ist ja unwichtig, daher gleich in
/dev/null
) :root@raspi:~# hcitool info 60:73:BC:C8:CA:42 > /dev/null root@raspi:~# echo $? 0
NICHT existierende MAC abgefragt:
root@raspi:~# hcitool info 60:73:BC:C8:CA:43 > /dev/null root@raspi:~# echo $? 1
Das Ganze funktioniert übrigens auch, wenn
hcitool scan
ein leeres Ergebnis liefert. -
Hi, ich habe heute nochmal ein bisschen weiter rumprobiert und noch folgendes Feedback:
- Im HCITOOL/L2Ping Mode werden bei mir keine BLE Devices erkannt (hier ein Gigaset Keeper). Führe ich einen manuellen LEScan via SSH aus, taucht der Keeper auf (warum auch immer er der Meinung ist, dass der Keeper doppelt da ist):
root@raspi:~# hcitool -i hci0 lescan --duplicates LE Scan ... 7C:2F:80:DD:xx:xx Gigaset keeper 7C:2F:80:DD:xx:xx (unknown)
..wohingegen der Adapter meint:
2019-05-18 01:52:21.438 - info: radar2.0 debug: radar2 found here (CF_Handy_BT, SF_Handy_BT) 2019-05-18 01:52:21.439 - info: radar2.0 debug: and who here (CF_Handy_BT, SF_Handy_BT) 2019-05-18 01:52:21.439 - info: radar2.0 debug: and not here (SF_Keeper_Rosa)
(Jaja, fragt nicht nach, Frauchen wollte das Ding unbedingt rosa)
Man sieht zwar dass er unten in Zeile 2 einen BLE Scan anwirft, aber vermutlich sind die Befehle in Zeile 2, 3, 4 und 6 zu schnell hintereinander, kann das sein? Der BT Adapter kriegt die Umschaltung(?) zwischen LE und BT-Normal vermutlich nicht so schnell hin? Sorry, bin kein Techniker
2019-05-18 02:02:27.234 - info: radar2.0 debug: started #70 hciconfig hci0 up 2019-05-18 02:02:27.476 - info: radar2.0 debug: started #71 hcitool -i hci0 lescan --duplicates 2019-05-18 02:02:27.493 - info: radar2.0 debug: started #72 l2ping -i hci0 -c 1 60:73:bc:c8:xx:xx 2019-05-18 02:02:28.948 - info: radar2.0 debug: started #73 l2ping -i hci0 -c 1 04:b1:67:23:xx:xx (...) 2019-05-18 02:02:34.118 - info: radar2.0 debug: started #74 l2ping -i hci0 -c 1 7c:2f:80:dd:xx:xx 2019-05-18 02:02:52.511 - info: radar2.0 debug: Kill [ '/usr/bin/hcitool', '-i', 'hci0', 'lescan', '--duplicates' ] with SIGINT (...) 2019-05-18 02:03:22.110 - info: radar2.0 debug: started #75 hciconfig hci0 down
Dazu würde die Reaktion passen wenn man versucht, einen BLE Scan zu machen während gerade ein L2Ping (oder irgendwas anderes) läuft:
root@raspi:/opt/iobroker/log# hcitool -i hci0 lescan --duplicates Set scan parameters failed: Input/output error
Vielleicht sollte man den LEScan eher hinter die L2Pings packen und einen kleinen Puffer dazwischen setzen (sowohl zwischen die einzelnen L2Pings als auch als Abstand zum LEScan)? Ist nur eine Idee, keine Ahnung ob das etwas bringt..
- Ich habe im Log regelmäßig einen Fehler, der den Adapter zum Absturz bringt:
2019-05-18 01:39:48.493 - warn: radar2.0 Promise failed @ '; _tickCallback in internal/process/next_tick.js @189:7' error: { SyntaxError: Unexpected token c in JSON at position 0 at JSON.parse (<anonymous>) at A.get.then.res (/opt/iobroker/node_modules/iobroker.radar2/radar2.js:621:47) at <anonymous> at process._tickCallback (internal/process/next_tick.js:189:7) [stack]: 'SyntaxError: Unexpected token c in JSON at position 0\n at JSON.parse (<anonymous>)\n at A.get.then.res (/opt/iobroker/node_modules/iobroker.radar2/radar2.js:621:47)\n at <anonymous>\n at process._tickCallback (internal/process/next_tick.js:189:7)', [message]: 'Unexpected token c in JSON at position 0' } 2019-05-18 01:40:14.188 - info: radar2.0 first scan took 25.646 seconds 2019-05-18 01:40:14.189 - info: radar2.0 will scan external network every 60 minutes 2019-05-18 01:40:15.064 - info: radar2.0 Adapter initialization finished! 2019-05-18 01:45:15.489 - info: host.raspi object change system.adapter.radar2.0 2019-05-18 01:45:15.491 - info: host.raspi stopInstance system.adapter.radar2.0 2019-05-18 01:45:15.492 - info: host.raspi stopInstance system.adapter.radar2.0 killing pid 1657 2019-05-18 01:45:15.497 - info: radar2.0 Adapter disconnected and stopped with dostop(false) and callback(true) 2019-05-18 01:45:15.504 - warn: radar2.0 Adapter will exit in latest 1 sec with code false!
Jemand eine Idee, was das sein könnte und wo es herkommt?
Danke und viele Grüße
Christian -
Mal ne Frage...
Warum kann ich bei "Abwesenheit" nur Werte ab 2 Minuten eintragen?
Ich möchte sofort sehen wenn ein Gerät offline ist... mit dem alten Adapter ging das.Ich hatte mit dem alten Radar Adapter ein Script, welches mir meine Echos lauter gestellt hat, wenn der Fernseher lief... Da der neue Radar2 Adapter ja erst nach 2 Minuten reagiert, ist diese Funktion jetzt unbrauchbar...
Es ist ja schön, das man den Wert einstellen kann, falls man schlechtes WLAN hat...
aber denn warum diese Einschränkung? -
@ChristianF
So weit ich es mitbekommen habe, gibt es mit den Gigaset Keepern Probleme.
Mit meinen G-Tags funktionert alles.
Es werden bei mir sogar die Xiaomi flower care in den Blumentöpfen, allerdings als "unbekannt" gescannt.
Hier kommt dann die Instanz BT und ein 2. Dongle (der noch nicht angeschlossen ist) zum tragen.Bei Anwesenheit reagiert Radar2 ja sofort.
Damit soll verhindert werden, daß z.B. die Heizung hin- und herschaltet, wenn man doch anwesend ist und Radar2 einen Scan versemmelt hat.
bei Radar hat eine Abwesenheitskennung (bei mir zumindest) bis zu 10 Minuten gedauert. Da sind 2 Minuten ja richtig schnell. Bis die Anwesenheit erkannt wurde, mußte ich bis zu 30 Sekunden vor der Türe stehen, bis ich die Türe aufschließen konnte. da ist ja Anwesenheit sofort bei Radar2 ja richtig toll. -
@MathiasJ sagte in [Adapter] Neuer radar2-Adapter:
@ChristianF
So weit ich es mitbekommen habe, gibt es mit den Gigaset Keepern Probleme.
Mit meinen G-Tags funktionert alles.
Es werden bei mir sogar die Xiaomi flower care in den Blumentöpfen, allerdings als "unbekannt" gescannt.
Hier kommt dann die Instanz BT und ein 2. Dongle (der noch nicht angeschlossen ist) zum tragen.Ich vermute auch dass bei mir die Mischung aus BT und BLE dafür verantwortlich ist dass es nicht so wirklich klappt.
Mein G-Tag wird auch nicht erkannt. Hast du die einfach so "out of the box" in Benutzung oder hast du sie in der Gigaset App registriert? Beim Keeper hab ich das damals falsch gemacht und hab versucht das Ding zu erreichen obwohl es registriert war, hat natürlich nicht geklappt.. -
@ChristianF
Wie viele USB-Sticks hast Du dran hängen?
Du brauchst für Radar2 einen BT-Dongle
Du brauchst für BLE einen BT-Dongle
macht zusammen 2 BT-Dongles. -
@MathiasJ hab nur einen hängen und läuft mit Radar2 und BLE ... mach wohl was falsch .. hmm
-
@Supermicha ,
Ich werde msl dehen ob ich kürzere Zeiten erlauben kann, aber mindestens 2 scanzeiten müssen es sein da die Logik nicht genau sagen kann wann ein Gerät gescannt/gefunden wird während eines Zyklusses. -
@Siegfried
Meinst dass du den BLE-Adapter und Radar2 gleichzeitig auf einem BT-controller lsufen hast? Das geht nicht, da 2 Programme nicht gleichzeitig auf das BLE zugreifen können bzw scans unterbrochen werden wenn wer zugreift. -
@frankjoke aber ich bekomme daten von meiner mi -temperatur und meine tags werden vom radar erkannt
-
@ChristianF
Der kill miss bei HCI-Tool LEscan immer gemacht werden da es ewig laufen würde da man dort keineDauer angeben kann.
Bei 85% der scanzeit wird abgebrochen un noch Zeit für andere Dinge zu haben.Übrigens, würde euch raten längere scan-Zeiten von über 30 Sekunden zu nehmen wenn ihr mehr Geräte funden wollt.
Das mit dem Fehler verstehe ich nicht da der der Adapter selbst keinen Fehler ausgibt er aber dann von iobroker gestoppt wird.
Die Promise failed scheint von einem ECB/HP/UWZ-scan zu kommen wo keine Daten zurückgeliefert werden! Da es nur ein warning ist sollte der Adapter nicht abstürzen, werde mir es aber diese Woche anschauen.
-
@Siegfried
Ich hatte nur Probleme damit und verwende seither 2 BT.sticks (kosten ja eh nur <10€). -
Ok, werde folgendes für V2 nächste Woche noch testen:
Eindeutige Zuteilung von BT und BT-LE (damit werden nur BT (ohne LE) von l2scan gescannt.
Getrennte Umschalltung für BT und BT-LE zwischen Noble/hcitool LEscan und BT scan/l2ping. Damit kann man genau einstellen was man wofür verwenden will. Wenn dann keine normalen BT-Geräte verwendet werden dann werden sie auch nicht gescannt! -
@frankjoke Kannst du mir einen Stick empfehlen, der BT/BLE kann und entweder für radar2 arbeitet oder eben für meinen Türschlossantrieb und das onboard BT Modul jeweils für das andere.
Oder geht generell jeder BT USB Stick?Als OS läuft bei mir Xubuntu, falls das für Treiber relevant wäre.
-
Hallo zusammen,
da ist ja einiges zusammengekommen worauf ich mal antworten sollte
@MathiasJ ich habe einen BT Stick. Ich verwende aber auch nur den Radar2 Adapter, den BLE Adapter habe ich zwar installiert aber deaktiviert. Wenn ich hier BLE schreibe meint das nicht den BLE-Adapter, sondern Bluetooth LE an sich.
@frankjoke Dass man den LEScan killen muss ist mir klar. Mir ging es nur darum, ob es vielleicht etwas ungünstig ist, mit dem LEScan anzufangen, dann die L2Pings abzusetzen (während der LEScan läuft) und dann den LEScan zu killen. Meine Idee wäre gewesen, die L2Pings zu machen und dann den LEScan hinterher, damit die sich nicht auf der Luftschnittstelle in die Quere kommen. Das ist aber auch nur eine Vermutung.
Bei den UWZ und EZB Kursen habe ich bisher nicht verstanden wie man das konfiguriert, daher Finger davon gelassen. Gibt es da irgendwo eine Doku zu?@Diginix Ich benutze als Stick einen SPEEDLINK SL-7411-BK VIAS Nano Bluetooth Adapter (vom Mediamarkt) und habe mir jetzt noch einen LogiLink BT0015 bestellt.
Nochmal eine andere Frage in die Runde, wo sich ja hier offenbar viele mit dem Thema Anwesenheitserkennung beschäftigen. Hat jemand eine gute Lösung, um zu prüfen, ob sich Geräte im Gäste-WLAN der Fritzbox aufhalten? Sämtliche Fritz Adapter die ich probiert habe bieten zwar eine Lösung um Gäste-WLAN an und aus zu schalten, aber wirklich eine Lösung für das Erkennen von Geräten dort drin hat keiner..
Viele Grüße
Christian -
Du könntest einen weiteren WLAN-Stick nehmen und den in das Gäste-WLAN einbinden. Dann kannst du per radar2 scannen + erkennen ob/wer eingeloggt ist.
-
@ChristianF
Du brauchst einen WLAN-Stick, der das Gäste-WLAN abhorcht.
Dann funktioniert auch die Anwesenheitskennung im Gäste-Netzwerk.
Ich habe mir dazu eine 2. Instanz Also Radar 2.1 installiert.
darf ich fragen, welchen PC Du benutzt, auf dem IObroker installiert ist?
ich habe die Erfahrung gemacht, daß beim Raspberry der Logilink und beim Tinkerboard/Rock64 der Speedlink der bessere ist. -
hm irgendwie will der radar2 bei mir nicht so recht. Über Adapter kann ich es Installieren aber bleibt Rot. Im Log hab ich auch nichts gesehen. Hatte es aber jetzt nicht lange versucht. Ich wollt die neue 1.2er Installieren. Hab es Manuell versucht aber es bricht immer ab
$ ./iobroker url "https://github.com/frankjoke/ioBroker.radar2" install https://github.com/frankjoke/ioBroker.radar2/tarball/master npm install https://github.com/frankjoke/ioBroker.radar2/tarball/master --production --save --prefix "/opt/iobroker" (System call) ../src/linux/DeviceINQ.cc:35:37: fatal error: bluetooth/bluetooth.h: No such file or directory #include <bluetooth/bluetooth.h> ^ compilation terminated. make: *** [Release/obj.target/BluetoothSerialPort/src/linux/DeviceINQ.o] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:262:23) gyp ERR! stack at emitTwo (events.js:126:13) gyp ERR! stack at ChildProcess.emit (events.js:214:7) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12) gyp ERR! System Linux 4.4.59+gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "configure" "build" gyp ERR! cwd /opt/iobroker/node_modules/node-bluetooth gyp ERR! node -v v8.16.0gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.3 (node_modules/osx-temperature-sensor):npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: node-bluetooth@1.2.5 (node_modules/node-bluetooth): npm WARN optional SKIPPING OPTIONAL DEPENDENCY: node-bluetooth@1.2.5 install: `node-gyp configure build` npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1 process exited with code 0
-
@ChrisXY Ich dachte Exit Code 0 ist ok. Die Fehlermeldungen zuvor kann man ignorieren. Wenn er rot bleibt, hilft nur das ioBroker Log. Installiert ist er wahrscheinlich korrekt.
@frankjoke Ich habe jetzt einen zusätzlichen BT Dongle mit hci2 am PC. Dein Adapter kann sowohl mit dem als auch mit hci0 alles erkennen. Aber eben weiterhin nur mit noble, nicht hci only.
Selbst wenn radar2 auf hci2 arbeitet, kann ich das keyble für den Türschlossantrieb in der Konsole nicht verwenden weil immer ein timeout kommt. Sobald radar2 pausiert ist, funktioniert es.
Daher scheint der Konflikt unabhängig der Hardware auch noch bei noble selbst zu bestehen.
Kann man das entzerren und ja wie? -
also hier mal nach Installation was im Log steht:
host.iobroker 2019-05-20 21:09:35.387 error instance system.adapter.radar2.0 terminated with code null () host.iobroker 2019-05-20 21:09:35.386 warn instance system.adapter.radar2.0 terminated due to SIGSEGV host.iobroker 2019-05-20 21:09:02.739 error instance system.adapter.radar2.0 terminated with code null () host.iobroker 2019-05-20 21:09:02.739 warn instance system.adapter.radar2.0 terminated due to SIGABRT Caught 2019-05-20 21:09:02.738 error by controller[0]: .0: ../deps/uv/src/unix/poll.c:123: uv_poll_start: Assertion `!(((handle)->flags & (UV_HANDLE_CLOSING | UV_HANDLE_CLOSED)) != 0)' failed.
noch mehr
radar2.0 2019-05-20 21:12:03.904 info found '@abandonware/noble' radar2.0 2019-05-20 21:12:03.714 info radar2 initialization started... radar2.0 2019-05-20 21:12:03.602 info starting. Version 1.2.0 in /opt/iobroker/node_modules/iobroker.radar2, node: v8.16.0 radar2.0 2019-05-20 21:11:30.636 info found '@abandonware/noble' radar2.0 2019-05-20 21:11:30.407 info radar2 initialization started... radar2.0 2019-05-20 21:11:30.282 info starting. Version 1.2.0 in /opt/iobroker/node_modules/iobroker.radar2, node: v8.16.0 radar2.0 2019-05-20 21:10:57.684 info radar2 initialization started... radar2.0 2019-05-20 21:10:57.555 info starting. Version 1.2.0 in /opt/iobroker/node_modules/iobroker.radar2, node: v8.16.0 radar2.0 2019-05-20 21:10:39.296 info found '@abandonware/noble' radar2.0 2019-05-20 21:10:39.063 info radar2 initialization started... radar2.0 2019-05-20 21:10:38.935 info starting. Version 1.2.0 in /opt/iobroker/node_modules/iobroker.radar2, node: v8.16.0