UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[haselchen]

@alcalzone

Gute Idee, kann ja mal meine SmartHome Bastelkiste durchforsten :)
Ich meine, nen speziellen Thread dafür schon aktuell gelesen zu haben :thinking_face:

Danke euch Beiden (@Diginix ) für die schnellen Infos.

[Homoran]

@alcalzone sagte in Test Adapter radar2 v1.2.x GitHub:

@haselchen Gibt wohl auch Lösungen auf ESP32-Basis, die dürften dann ein besseres Kosten-Nutzen-Verhältnis haben

In der Summe?
https://www.bueromarkt-ag.de/bluetooth-usb-adapter_aplic_nano_bt,p-417722.html

[haselchen]

@diginix

Meinst du das so? :

Ich weiss leider nicht anhand der Einstellungen, welcher Adapter in welcher Form sucht oder sendet.
Hab deshalb bei der Installation von beiden Adaptern den Haken beim Radar 2 rausgenommen (siehe Kreuz).

[Diginix]

@haselchen Ja, genau da. Ich habe den Haken bei mir drin, damit noble frei für mein Skript ist.
Wenn der BLE Adapter aber auch hcitool nutzt, wäre noble beim radar2 vllt ein Test wert. Wenn du den Haken aber bereits raus hast und es nicht klappt, dann nutzt BLE vlle auch noble. Ich habe den BLE Adapter nicht im Einsatz, weiß es also nicht. Aber weder radar2 noch BLE belegen die BT Hardware ja ununterbrochen sondern immer nur zyklisch. Irgendwie würde man es also vllt schaffen dass sie genau versetzt oder eben mit getrennter Bibliothek arbeiten.

[haselchen]

@diginix

Gar nicht schlecht der Ansatz, den Update Intervall kann man ja bei beiden einstellen.
Das könnte ich mal ausprobieren.

[AlCalzone]

@homoran Nee ich meinte eine Software-Lösung für ESP, die die Sensoren ausliest und per MQTT an ioBroker meldet. Hab ich vor kurzem mal hier im Forum irgendwo gelesen.

[MaZchen]

Hi!

Mir ist heute aufgefallen, dass ich keine UWZ Meldungen mehr bekomme. Ich finde nicht einmal den Datenpunkt in den Objects. (Adapter V2.03)

Geht es noch jemanden so?

Marcus

[Diginix]

@mazchen Sind die Bedingungen erfüllt:

To use UWZ you need to have your location configured in ioBroker.Admin! If the value of max messages is >0 the each warning will be written in a separate state, otherwisde they will be combined. You can also set if you want to use long warning text but all info is available in short one as well.

Ich habe es noch nie genutzt und daher in der Instanz:

Bei dir müsste da also etwas >0 stehen und die Geokoordinaten im Admin.

[MaZchen]

@diginix ja. Location ist definiert und Verzögerung = 120 (testweise auch auf 1 reduziert)

[Diginix]

@mazchen Dann sollte es tatsächlich funktionieren. Aber der adapter wird schon lange nicht mehr gepflegt. Wer weiß was sich bei dem UWZ Dienst geändert hat. Hast dir mal den DWD Adapter angeschaut?
K.a. was UWZ leistet, aber die DWD Warnungen passen bei mir.

[MaZchen]

Muss ich wohl oder übel. War halt praktisch, radar2 funktioniert super (noch) für die Anwesenheitserkennung, da war UWZ ein nettes Nebenprodukt.

PS: danke für die raschen Antworten :-)

[Streit187]

@diginix Servus Diginix. Es sieht so aus als wäre das Problem gelöst. Nach meinem Update von NPM auf v6 und Node.js auf v14 kann ich keine Aussetzer mehr feststellen.

[Diginix]

@streit187 Wie lange läuft es denn bei dir mit nodejs 14 nun ohne Aussetzer?
Bei meinem NUC liegt es wohl an der internen BT Hardware. Andere haben mir das bestätigt.
Da gibt es wohl immer mal Spannungsprobleme und dann fällt die ggf. aus. Im schlechtesten Fall muss der ganze NUC heruntergefahren und kurz stromlos genommen werden. Das kam aber schon Monate nicht mehr vor.

[Streit187]

@diginix Bei mir läuft es jetzt 48 Stunden ohne beobachteten Aussetzer und 24 Stunden ohne den cron job und ohne jeden Eingriff.

[Diginix]

@streit187 Ok, das ist schön aber so eng waren die Probleme bei mir nie. Also selbst 1 Monat ist nicht zwingend ein Beleg für "passiert nie wieder". Dann beobachte mal weiter. Vllt ist es beim Raspi auch tatsächlich für immer ok.

[Streit187]

@diginix Also bei mir lief es vorher keine zwei Stunden am Stück.

[Diginix]

@streit187 Wow, ok. Das ist natürlich dann schon eine beachtliche Verbesserung.

[SlipKoRn_DH88]

Hallo zusammen,

ich nutze seit 2 Wochen den Radar2 Adapter für die Anwesenheitserkennung via Bluetooth und Gigaset G-Tags für zwei Personen.

Ich habe leider das Problem, dass die G-Tags immer wieder nicht als anwesend erkannt werden. Mal der eine, mal der andere. Mal für wenige Minuten, mal für mehrere Stunden. Beide G-Tags liegen nebeneinander an der gleichen Stelle. Ein Reichweitenproblem vermute ich nicht. Die Entfernung um Raspberry Pi 4 beträgt 3m.

Hier einmal das Protokoll:

2022-04-17 00:00:20.137 - info: radar2.0 (16075) debug: radar2 found uIP's: []
2022-04-17 00:00:20.226 - info: radar2.0 (16075) debug: ChangeState ack:true of _uBTs = ["00:51:7e:1f:e9:d3","00:7c:2d:af:a8:ee","04:fc:63:5e:c2:13","24:fc:e5:6b:36:1b","47:34:4c:6b:f0:df","a4:30:7a:01:1c:ab","cd:70:b4:98:05:17","d2:31:1a:a6:c2:99","dd:6f:90:45:73:f6","e1:a1:99:03:55:9a","ed:ed:70:6f:56:1f","f3:33:37:ec:a2:db","f3:33:97:99:72:0e"]
2022-04-17 00:00:22.726 - info: radar2.0 (16075) debug: started #1664 hciconfig hci0 down
2022-04-17 00:00:22.862 - info: radar2.0 (16075) debug: started #1665 hciconfig hci0 up
2022-04-17 00:00:23.121 - info: radar2.0 (16075) debug: started #1666 hcitool -i hci0 lescan --duplicates
2022-04-17 00:00:23.145 - info: radar2.0 (16075) debug: started #1667 l2ping -i hci0 -c 1 58:9e:c6:20:3f:00
2022-04-17 00:00:27.184 - info: radar2.0 (16075) debug: started #1668 l2ping -i hci0 -c 1 58:9e:c6:20:48:50
2022-04-17 00:00:48.152 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"00:7c:2d:af:a8:ee","btName":"(unknown)","btVendor":"Samsung Electronics Co, Ltd"}
2022-04-17 00:00:48.153 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"e1:a1:99:03:55:9a","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.154 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"f3:33:37:ec:a2:db","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.162 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"f3:33:97:99:72:0e","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.168 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"ed:ed:70:6f:56:1f","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.176 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"47:34:4c:6b:f0:df","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.181 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"a4:30:7a:01:1c:ab","btName":"(unknown)","btVendor":"Samsung Electronics Co, Ltd"}
2022-04-17 00:00:48.184 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"cd:70:b4:98:05:17","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.186 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"00:51:7e:1f:e9:d3","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.189 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"04:fc:63:5e:c2:13","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.192 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"24:fc:e5:6b:36:1b","btName":"(unknown)","btVendor":"Samsung Electronics Co, Ltd"}
2022-04-17 00:00:48.194 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"d2:31:1a:a6:c2:99","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.204 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"dd:6f:90:45:73:f6","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:48.207 - info: radar2.0 (16075) debug: -BtFound unknown with {"by":"lescan","address":"43:34:3c:4f:3c:dd","btName":"(unknown)","btVendor":"N/A"}
2022-04-17 00:00:50.132 - info: radar2.0 (16075) debug: ChangeState ack:true of GTagAnnika._nHere = 18
2022-04-17 00:00:50.135 - info: radar2.0 (16075) debug: radar2 found here (GTagAnnika)
2022-04-17 00:00:50.136 - info: radar2.0 (16075) debug: and who here (GTagAnnika)
2022-04-17 00:00:50.136 - info: radar2.0 (16075) debug: and not here (GTagNico)
2022-04-17 00:00:50.137 - info: radar2.0 (16075) debug: radar2 found uBT's: [ '00:51:7e:1f:e9:d3', '00:7c:2d:af:a8:ee', '04:fc:63:5e:c2:13', '24:fc:e5:6b:36:1b', '43:34:3c:4f:3c:dd', '47:34:4c:6b:f0:df', 'a4:30:7a:01:1c:ab', 'cd:70:b4:98:05:17', 'd2:31:1a:a6:c2:99', 'dd:6f:90:45:73:f6', 'e1:a1:99:03:55:9a', 'ed:ed:70:6f:56:1f', 'f3:33:37:ec:a2:db', 'f3:33:97:99:72:0e'

Und hier die Einstelllungen des Radar2 Adapters.

Ich habe bereits mit verschiedenen Abfrageintervallen herumexperimentiert und zwischen hcitool lescan und Nobel gewechselt.

Node-JS: 14.19.0
Admin: 5.3.8
Host: 4.0.21
NPM: 6.14.16

Hat jemand eine Idee? Danke!

[Matthes]

@slipkorn_dh88
Die G-Tags dürfen nicht gepairt sein - z. B. Smartphone usw. Wenn doch, diese Verbindung lösen.
Mit dem internen Bluetooth hatte ich auch Probleme - allerdings Beelink B3. Mit einen externen BT-Adapter Version 4 läuft es bisher stabil seit ca. 3 Wochen.

Grüße aus dem Sauerland.

[SlipKoRn_DH88]

@matthes

@matthes sagte in Test Adapter radar2 v1.2.x GitHub:

@slipkorn_dh88
Die G-Tags dürfen nicht gepairt sein - z. B. Smartphone usw. Wenn doch, diese Verbindung lösen.
Mit dem internen Bluetooth hatte ich auch Probleme - allerdings Beelink B3. Mit einen externen BT-Adapter Version 4 läuft es bisher stabil seit ca. 3 Wochen.

Grüße aus dem Sauerland.

Danke dir schon einmal für die Info. Die G-Tags sind beide nicht mit anderen Geräten gepairt. Das können wir schon einmal ausschließen.
Ich hatte noch die Batterien in verdacht. Trotz das die G-Tags neu sind, haben die Batterien möglicherweise nicht mehr genug Saft. Werde hier mal die Tage neue testen.
Ich habe hier noch einen Bluetooth 4.0 USB Stick. Das könnte ich testen. Hier einfach den Stick einstecken und das wars?