Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Diginix]

Warum willst du den Echo per radar erkennen? Das ist doch im alexa Adapter schon zu sehen ob er online ist oder nicht.

[steimi]

@lobomau mal das probiert?

@frankjoke sagte in [Adapter] Neuer radar2-Adapter:

@steimi
wenn ihr neues node installiert bitte wieder die Zeile aus der installation mit 'which node' ausführen:

sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)

Die Berechtigung gilt immer nur auf das exakte bin file des installierten nodes.

[steimi]

@steimi sagte in [Adapter] Neuer radar2-Adapter:

Ich habe ein Problem mit der Überwachung eines Servers - evtl ist radar2 dazu nicht der richtige Adapter? Ich habe einen Windows-Homeserver welcher per Lightsout in den Standby geschickt wird, sobald bestimmte Geräte nicht zu erreichen sind. Über ioBroker und Alexa kann ich den Server aufwecken. Geht der Server wieder in Standby wird dieser jedoch weiterhin von radar2 als anwesend erkannt. In der Konfig des radar2-Adapters habe ich nur den Namen und die IP-Adresse des Rechner (feste IP) angegeben, jedoch keine MAC-Adresse. Anscheinend wird aber intern die ermittelte MAC-Adresse weiterhin zur Anwesenheitsermittlung herangezogen - kann das sein?

@frankjoke kannst du mir dazu weiterhelfen?

[Diginix]

@Diginix sagte in [Adapter] Neuer radar2-Adapter:

@frankjoke Das ist der Output:
Im Log steht dann bei Instanz Start wieder:

2019-04-21 12:13:17.788  - warn: radar2.0 Noble not available, Error: Error: The module '/opt/iobroker/node_modules/@abandonware/bluetooth-hci-socket/lib/binding/binding.node'was compiled against a different Node.js version usingNODE_MODULE_VERSION 57. This version of Node.js requiresNODE_MODULE_VERSION 64. Please try re-compiling or re-installingthe module (for instance, using `npm rebuild` or `npm install`).at Object.Module._extensions..node (internal/modules/cjs/loader.js:718:18)at Module.load (internal/modules/cjs/loader.js:599:32)at tryModuleLoad (internal/modules/cjs/loader.js:538:12)at Function.Module._load (internal/modules/cjs/loader.js:530:3)at Module.require (internal/modules/cjs/loader.js:637:17)at require (internal/modules/cjs/helpers.js:22:18)at Object.<anonymous> (/opt/iobroker/node_modules/@abandonware/bluetooth-hci-socket/lib/native.js:6:15)at Module._compile (internal/modules/cjs/loader.js:689:30)at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)at Module.load (internal/modules/cjs/loader.js:599:32)
2019-04-21 12:13:17.801  - warn: radar2.0 node-bluetooth not found!

Das liest sich so als müsste ich mal das reinstall Skript vom ioBroker laufen lassen. Weil ja alles alte noch mit nodejs 8 gebaut wurde.
Ich warte aber mal ab bis du dich dazu äußerst.

@frankjoke
"npm rebuild" bzw. "sudo npm rebuild" hat nicht geholfen.
Aber ich habe einfach mal paar node module neu installiert und nun läuft radar2 mit nodejs 10.x

npm install node-pre-gyp
npm install node-bluetooth
npm install @abandonware/bluetooth-hci-socket

[Diginix]

Nachdem ich heute ja den radar2 mit nodejs 10.x zum Laufen gebracht habe und das auch über 5 Stunden problemlos lief. Geht er jetzt ohne jegliches Zutun auf rot und selbst ein System Reboot hilft nicht mehr. Das ist doch echt zum ...
Bei allen Mehrwerten der Ver 2. All diese Probleme hatte ich mit dem alten Adapter in 12 Monaten nicht.

Im Log steht nun alle 30 Sekunden das:

2019-04-23 21:02:41.171  - info: host.BT3-PRO instance system.adapter.radar2.0 started with pid 9414
2019-04-23 21:02:43.373  - info: radar2.0 starting. Version 1.0.7 in /opt/iobroker/node_modules/iobroker.radar2, node: v10.15.2
2019-04-23 21:02:43.771  - info: radar2.0 radar2 initialization started...
2019-04-23 21:02:43.774  - info: radar2.0 radar2 starting main...
2019-04-23 21:02:43.787  - info: radar2.0 net-ping not available! Will try to use normal ping!
2019-04-23 21:02:43.938  - error: radar2.0 uncaught exception: bind EACCES 0.0.0.0:67
2019-04-23 21:02:43.939  - error: radar2.0 Error: bind EACCES 0.0.0.0:67
    at state.handle.lookup (dgram.js:242:18)
    at process._tickCallback (internal/process/next_tick.js:63:19)
2019-04-23 21:02:43.940  - info: radar2.0 Adapter disconnected and stopped with dostop(false) and callback(true)
2019-04-23 21:02:44.197  - info: radar2.0 found '@abandonware/noble'
2019-04-23 21:02:44.209  - info: radar2.0 found 'node-bluetooth'
2019-04-23 21:02:44.210  - info: radar2.0 radar2 set to flag items away if they are not seen for 10 minutes
2019-04-23 21:02:44.212  - info: radar2.0 Remove name end for host names: .fritz.box
2019-04-23 21:02:44.213  - info: radar2.0 arp-scan will use the following interfaces: [ 'enp1s0' ]
2019-04-23 21:02:44.213  - info: radar2.0 radar2 set to scan every 30 seconds and printers every 720 minutes.
2019-04-23 21:02:44.235  - warn: radar2.0 Adapter will exit in latest 1 sec with code false!
2019-04-23 21:02:44.263  - info: radar2.0 terminating
2019-04-23 21:02:44.283  - error: Caught by controller[0]: { Error: bind EACCES 0.0.0.0:67
2019-04-23 21:02:44.283  - error: Caught by controller[0]:     at state.handle.lookup (dgram.js:242:18)
2019-04-23 21:02:44.283  - error: Caught by controller[0]:     at process._tickCallback (internal/process/next_tick.js:63:19)
2019-04-23 21:02:44.283  - error: Caught by controller[0]:   errno: 'EACCES',
2019-04-23 21:02:44.283  - error: Caught by controller[0]:   code: 'EACCES',
2019-04-23 21:02:44.283  - error: Caught by controller[0]:   syscall: 'bind',
2019-04-23 21:02:44.283  - error: Caught by controller[0]:   address: '0.0.0.0',
2019-04-23 21:02:44.284  - error: Caught by controller[0]:   port: 67 }
2019-04-23 21:02:44.284  - error: host.BT3-PRO instance system.adapter.radar2.0 terminated with code 0 (OK)
2019-04-23 21:02:44.284  - info: host.BT3-PRO Restart adapter system.adapter.radar2.0 because enabled

Nutze jetzt vorerst notgedrungen die alte radar Version und beobachte mal deren Stabilität.

[MathiasJ]

Wurde nicht öfter davor gewarnt, auf Node 10.x upzudaten? :innocent:

[Diginix]

Die letzten Probleme mit radar2 hängen mMn nicht mehr damit zusammen.
Es kommen ja keine Fehler im Log die damit in Zusammenhang stehen. Alle node module sind installiert und mit nodejs10 gebaut.

Alle anderen Adapter inkl radar(1) laufen ja auch ohne Probleme. Auch ein ioB Teammitglied hat mir bestätigt dass mit dem aktuellen JS Controller kein nodejs 8.x benötigt wird.

Mal abgesehen davon habe ich ja "nur" Ubuntu aktualisiert und nodejs 10 ungewollt zwangsweise bekommen und ein Downgrade klappt eben nicht mehr.
Ich möchte aktuell ungern das gesamte System neu aufsetzen nur um nodejs 8 wieder zu erhalten.

[SBorg]

@Diginix sagte in [Adapter] Neuer radar2-Adapter:

Warum willst du den Echo per radar erkennen? Das ist doch im alexa Adapter schon zu sehen ob er online ist oder nicht.

Zum einen bin ich kein Freund davon eine Funktionalität auf mehrere Adapter (unnötiger weise) aufzuteilen. Das verursacht bei komplexeren Installationen später nur Ärger.
Zum anderen kann ich ihn per radar direkt per IP ansprechen, Alexa sagt mir nur rudimentär "online".

[lobomau]

@steimi sagte in [Adapter] Neuer radar2-Adapter:

sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f which node)

Ja, kurz eingetippt und sofort wurde radar2 wieder grün :+1:

[deta]

Wollte nur mal bestätigen, das hat bei mir auch mit nodesjs 10.x funktioniert. BT läuft auch jetzt wieder

cu Deta

@frankjoke
"npm rebuild" bzw. "sudo npm rebuild" hat nicht geholfen.
Aber ich habe einfach mal paar node module neu installiert und nun läuft radar2 mit nodejs 10.x

npm install node-pre-gyp
npm install node-bluetooth
npm install @abandonware/bluetooth-hci-socket

[Diginix]

Interessant dass es bei dir auch geholfen hat.
Bei mir ja leider nur für 5-6 Stunden. K.a. warum und wieso.
Mal sehen wann @frankjoke was dazu sagen kann.

Bis dahin ist radar(1) wieder im Einsatz und das stabil mit nodejs 10 seit fast 24h.

[deta]

@Diginix sagte in [Adapter] Neuer radar2-Adapter:

Interessant dass es bei dir auch geholfen hat.
Bei mir ja leider nur für 5-6 Stunden. K.a. warum und wieso.
Mal sehen wann @frankjoke was dazu sagen kann.

Bis dahin ist radar(1) wieder im Einsatz und das stabil mit nodejs 10 seit fast 24h.

Also bei mir läuft immer noch alles. Das sind jetzt über 12 Stunden.

[frankjoke]

Ok, danke an alle die inzwischen einige Aufklärungsarbeit geleistet haben!

Eine Zusammenfassung kurz:

1. Wenn ein neues node (V8->V10) installiert wird sollten auch die node-tools (node-gyp, u.s.w) neu installiert werden
2. Wenn ein neues node (V8.x auf V8.y oder V8 auf V10 ...) installiert wird muss müssen auch die Berechtigungen neu vergeben werden:

sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)

3. Wenn andere updates am System vorgenommen werden die neue BT-Treiber oder utilities installieren müssen alle im Install spoiler stehenden Installationsbefehle neu ausgeführt werden. Fehler wie { Error: bind EACCES 0.0.0.0:67 deuten darauf hin dass sich was geändert hat da keine Berechtigung zum Aufbau einer dhcp-Verbindung besteht.

War wieder im Spital (diesmal mit Notebook, habe neuen Gips aus Kunststoff und keine Fäden von der OP mehr :-) ) und hab etwas dazuprogrammiert aber erst heute zu Hause nach der Rückkehr testen können:

V1.2.0 steht auf git!
Die Änderungen in Kürze:

1. Möglichkeit zur Verwendung von hcitool anstatt noble unter linux geschaffen (default).
2. _LastHere wird bei Adapterrestart nicht geändert
3. Default Abfragezyklus auf 30 Sekunden geändert

Bei 1) ist es möglich ohne noble auszukommen, ich verwende dann ausschließlich hcitool scan und hcitool lescan! Für normales BT ist das besser da länger gescannt wird, für BT-LE sollte es egal sein da beide Module das selbe machen.
Ich habe dies deshalb als default angegeben welche unter linux auch so verwendet werden soll. Wenn ihr umsteigt müsst ihr nun auch

sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hcitool`)
sudo setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hciconfig`)

eingeben (ist in der readme/install-Liste aufgenommen worden).

Die 2) bedeutet dass _lastHere das letzte Datum wenn das Gerät gesichtet wurde bleibt. Einziger Nachteil: Währen Adapterstart kann es vorkommen dass Geräte als abwesend gezeigt werden wenn der Adapter längere Zeit still steht.

Die 3) wurde umgestellt da viele Nutzer den Default von 20 Sekunden beibehalten haben aber die Scanzeit zu kurz war um viele BT-Geräte zu finden. Mit dem neuen hcitool-Verfahren wird 85% der Zeit gescannt, und zwar beide BT-Methoden gleichzeitig. Allerdings darf sonst am gleichen BT-Controller kein anderes BT-Programm laufen, auch nicht auf der Kommandozeide. Erst wieder nachdem radar2 gestoppt wird! Vorteil: Einige Geräte die unter Radar1 gefunden wurden und unter radar2 nicht mehr sollten jetzt wieder gefunden werden!

p.s.: Hab die Version noch nicht auf npm und ins repo gegeben da ich hoffe mit eurem Feedback mögliche bugs noch auszukurieren! Von git aber nicht mittels 'beliebig' installieren!

[Diginix]

@frankjoke Bist mein Held!
Habe soeben aktualisiert und alle Befehle in die Konsole gehauen und er ist tatsächlich wieder auf grün gegangen und findet was er finden soll.
In der Adapterkonfig ist die "hcionly" nicht angehakt. D.h. es wird bei mir noch noble verwendet?
D.h. dein "default" bei Punkt 1. steht bei noble. Es las sich für mich so, dass hcitool standard wäre.

Vielen Dank für deine Erläuterungen und weiterhin gute Besserung!

PS: Ich habe die setcap Befehle mal in mein Systemupdate Shell Skript gepackt. So werden sie jedesmal wieder mit ausgeführt. Sollte ja sicher keine Nachteile haben oder?

[frankjoke]

@Diginix

Ok, bin froh dass es funktioniert.
Der Default wird nur genommen wenn du neu installierst, da du upgedated hast ist der Wert bei dir unbekannt also 'false'. Setze es auf selbst auf true um es mal zu testen, wenn es mit noble funktioniert u8nd du keine non-BT-LE-Geräte scannst ist es egal.

[Diginix]

@frankjoke Habe es mal umgestellt. Vielleicht wird das Samsung A5 dann wieder genau so stabil mit BT erkannt wie mit dem radar(1) Adapter.

Habe ein BT Audio Receiver und ein Eqiva Türschlossantrieb, die beide denke ich mal BTLE sind. Da diese immer zuhause sind, sind deren Erkennbarkeit auch Trigger für die Funktionsweise von radar und der BT Hardware.
In der Vergangenheit ist die BT Hardware manchmal innerhalb von 24h "ausgestiegen" und musste Konsole kurz deaktiviert und wieder aktivert werden, um wieder in ioBroker nutzbar zu sein.

sudo rfkill block bluetooth
sudo rfkill unblock bluetooth

Ich behalte alles mal im Auge.

[Diginix]

Erstes Problem.
Zwei BT Geräte stehen auf true obwohl sie _lastHere vor fast einer Stunde waren.
Nach 10 Minuten soll ein Gerät aber als abwesend gelten.

Im ioBroker Log ist nichts auffälliges zu sehen. Also z.B. kein Konflikt dass der BT Scan bereits läuft oder ähnliches.

Adapter Neustart hat geholfen. Es hat aber mehrere Scanzyklen gebraucht bis alle BT Geräte, die anwesend sind, auch erkannt wurden. Und es sind nur 5.

Einstellungen: hcionly, scan alle 30 Sekunden, nach 10 Minuten offline

[frankjoke]

@Diginix ,
Ist das nochmal aufgetreten?
Welches scanintervall hast du?

Du kannst leicht herausfinden ob was btle oder bt ist: findest du die teile mit hcitool scan dann ists normales BT, mit hcitool lescan ist's BT-LE.

[MathiasJ]

@frankjoke
Ich habe gestern das update gemacht.
Wenn ich aber umschalte auf "only hci" bleiben meine G-Tags offline.......

[frankjoke]

@all,

Habe eine kleine Korrektur auf die selbe Version auf git gestellt:

Beim Adapter(re)start wird bei BT kein Anwesend gesetzt, erst nach dem ersten Scan wird anwesend upgedated.
Das sollte verhindern dass alle Geräte die länger nicht gesehen wurden auf abwesend gesetzt werden bevor der scan läuft.

Sonst hab ich nochmal durchgecheckt ob BT-geräte richtig gefunden werden.... bei mir funktioniers!