SOLVED ble-Adapter stürzt plötzlich ab

[radierer]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	NUC6CAYH mit Proxmox
Arbeitsspeicher:	16GB // 4GB f. ioBroker
Festplattenart:	SSD
Betriebssystem:	Debian
Node-Version:	10.19.0
Nodejs-Version:	10.19.0
NPM-Version:	6.13.4
Installationsart:	Skript
Image genutzt:	Nein
Ort/Name der Imagedatei:	-

Hallo,
leider habe ich seit heute Nachmittag seltsamerweise das Problem, dass der ble-Adapter (https://github.com/AlCalzone/ioBroker.ble) nach kurzer Zeit abstürzt bzw. die States nicht mehr aktualisiert. Ich nutze den Adapter zur Anwesenheitserkennung mit GTags und greife dafür auf die rssi-Werte zurück. Seltsam deswegen, weil ich nichts am System verändert/installiert/deinstalliert habe. Aufgefallen ist es mir, weil plötzlich alle im Haus lebenden Personen auf "abwesend" standen.
Also erstmal geschaut und mit einem Neustarten der Instanz versucht zu richten. Sah auch erst gut aus, aber nach ner knappen Minute werden die States dann wieder nicht aktualisiert. Ich hab mal auf silly gelogt, kann da aber nichts mit werden. Und da ich auch nicht wissentlich was am System geändert habe, habe ich keinen Ansatz für eine Lösung. Daher wäre ich für Tips und Hinweise sehr dankbar.

Hier der Log:

2020-02-29 23:54:02.833  - debug: ble.0 (1712) discovered peripheral 7c:2f:80:99:d9:64
2020-02-29 23:54:02.834  - debug: ble.0 (1712)   has advertisement: true
2020-02-29 23:54:02.834  - debug: ble.0 (1712)   has serviceData: true
2020-02-29 23:54:02.834  - debug: ble.0 (1712)   serviceData = []
2020-02-29 23:54:02.835  - debug: ble.0 (1712)   has manufacturerData: true
2020-02-29 23:54:02.835  - debug: ble.0 (1712)   manufacturerData = 8001021512348099d964bbc5
2020-02-29 23:54:02.835  - debug: ble.0 (1712) plugin _default is handling 7c:2f:80:99:d9:64
2020-02-29 23:54:02.838  - debug: ble.0 (1712) _default: 7c:2f:80:99:d9:64 > got manufacturer data 8001021512348099d964bbc5
2020-02-29 23:54:02.838  - debug: ble.0 (1712) 7c:2f:80:99:d9:64 > got values: {"services.manufacturerData":"8001021512348099d964bbc5"}
2020-02-29 23:54:02.839  - debug: ble.0 (1712) setting state ble.0.7c:2f:80:99:d9:64.services.manufacturerData
2020-02-29 23:54:03.840  - debug: ble.0 (1712) discovered peripheral 7c:2f:80:99:d9:64
2020-02-29 23:54:03.840  - debug: ble.0 (1712)   has advertisement: true
2020-02-29 23:54:03.842  - debug: ble.0 (1712)   has serviceData: true
2020-02-29 23:54:03.842  - debug: ble.0 (1712)   serviceData = []
2020-02-29 23:54:03.842  - debug: ble.0 (1712)   has manufacturerData: true
2020-02-29 23:54:03.843  - debug: ble.0 (1712)   manufacturerData = 8001021512348099d964bbc5
2020-02-29 23:54:03.843  - debug: ble.0 (1712) plugin _default is handling 7c:2f:80:99:d9:64
2020-02-29 23:54:03.846  - debug: ble.0 (1712) _default: 7c:2f:80:99:d9:64 > got manufacturer data 8001021512348099d964bbc5
2020-02-29 23:54:03.847  - debug: ble.0 (1712) 7c:2f:80:99:d9:64 > got values: {"services.manufacturerData":"8001021512348099d964bbc5"}
2020-02-29 23:54:03.847  - debug: ble.0 (1712) setting state ble.0.7c:2f:80:99:d9:64.services.manufacturerData
2020-02-29 23:54:08.862  - debug: ble.0 (1712) discovered peripheral 7c:2f:80:99:d9:64
2020-02-29 23:54:08.863  - debug: ble.0 (1712)   has advertisement: true
2020-02-29 23:54:08.863  - debug: ble.0 (1712)   has serviceData: true
2020-02-29 23:54:08.864  - debug: ble.0 (1712)   serviceData = []
2020-02-29 23:54:08.864  - debug: ble.0 (1712)   has manufacturerData: true
2020-02-29 23:54:08.865  - debug: ble.0 (1712)   manufacturerData = 8001021512348099d964bbc5
2020-02-29 23:54:08.865  - debug: ble.0 (1712) plugin _default is handling 7c:2f:80:99:d9:64
2020-02-29 23:54:08.867  - debug: ble.0 (1712) updating rssi state for 7c:2f:80:99:d9:64
2020-02-29 23:54:08.870  - debug: ble.0 (1712) _default: 7c:2f:80:99:d9:64 > got manufacturer data 8001021512348099d964bbc5
2020-02-29 23:54:08.871  - debug: ble.0 (1712) 7c:2f:80:99:d9:64 > got values: {"services.manufacturerData":"8001021512348099d964bbc5"}
2020-02-29 23:54:08.872  - debug: ble.0 (1712) setting state ble.0.7c:2f:80:99:d9:64.services.manufacturerData
2020-02-29 23:54:08.874  - silly: ble.0 (1712) States user redis pmessage io.ble.0.*/io.ble.0.7c:2f:80:99:d9:64.rssi:{"val":-39,"ack":true,"ts":1583016848869,"q":0,"from":"system.adapter.ble.0","user":"system.user.admin","lc":1583016848869}
2020-02-29 23:54:19.974  - info: hm-rpc.0 (1352) binrpc -> listDevices 36
2020-02-29 23:54:20.058  - info: hm-rpc.0 (1352) new CUxD devices/channels after filter: 0
2020-02-29 23:55:45.886  - silly: ble.0 (1712) redis message expired/evicted __keyevent@0__:expired:io.system.adapter.ble.0.sigKill

Nach dem "system.adapter.ble.0.sigKill" ist der Adapter dann quasi tot und macht nichts mehr. Auch im Log tauch dann nichts mehr auf. Die Instanz bleibt komischerweise auch grün. Ein Neustart der Instanz bringt dann wie oben schon gesagt, nur sehr kurzfristig was.

[haselchen]

@radierer

Hi , welche Version des Adapters nutzt Du ?

[radierer]

Hoppla .. da hab ich wohl die wichtigste Info vergessen. Also Adapterversion ist die 0.10.1.

[radierer]

Ich habe selbst mal ein bisschen geschaut, was da falsch laufen könnte. Kann es evtl. sein, dass ich ein Problem mit dem Redis-Server habe? Geht dem irgendwie der Speicher aus, so dass keine neuen States geschrieben werden können? Und wie könnte ich das prüfen?

[radierer]

Weiter gehts ..
Ich habe eben die Settings in der redis.conf wie von @apollon77 in diesem Thread

-->https://www.forum.iobroker.net/topic/5166/gelöst-redis-logging-via-history-und-odersql/2<--

vorgeschlagen angepasst. Bringt aber leider auch keine Abhilfe. Nach kurzer Zeit werden die rssi Werte weiterhin nicht mehr aktualisiert.

[apollon77]

@radierer also in dem thread ging es um etwas gaaaaaaaaaaanz anderes.

Wenn der redis keys evicted dann hat er nicht genug RAM. Also schau auf die RAM Nutzung deines Systems. Was sagt top bzw „free -m“?

Was läuft so auf dem System? Warum überhaupt redis? was sagt das redis logfile?

[radierer]

@apollon77
Ich weiß, dass es in dem Thread um etwas anderes ging. Mir gings ja nur grundsätzlich um die Einstellungen bzgl. Speicher von Redis.
Auf dem System (s.o.) läuft nur ioBroker. Das Ganze halt als VM unter Debian verwaltet von Proxmox. Von den 16GB Gesamtspeicher des NUC sind für die Debian/ioBroker-VM 4GB zugewiesen.
Info ioBroker:
Platform: linux
os: linux
Architecture: x64
CPUs: 4
Speed: 1497 MHz
Model: Common KVM processor
RAM: 3.8 GB
System uptime: 17:55:09
Node.js: v10.19.0
NPM: 6.13.4
Disk size: 15.7 GiB
Disk free: 13.1 GiB
adapters count: 269
Uptime: 17:55:02
Active instances: 16
Dazu gute 9.600 Objekte und 8200 Zustände.

Aktuelles Ergebnis von free -m:

Daher ist es seltsam, dass es an RAM mangelt. Sollte doch genug vorhanden sein?!

Warum genau Redis, kann ich nicht mehr wirklich sagen. Ich habs mal aus irgendeinem Grund umgestellt. Ich habs aber mal testweise gestern wieder auf file umgestellt, wobei dann aber irgendwann auch nix mehr aktualisiert wurde beim ble-Adapter. Evtl. hab ich beim umstellen auf file auch irgendwas nicht ganz richtig gemacht?! Habs halt normal über "iobroker setup custom" gemacht.

Redis-Log? Hab ich mir bisher nicht angeschaut. Wo finde ich den?

[apollon77]

@radierer redis log entweder in /var/log/redis-server/ oder ggf in /var/log/syslog

Naja am Ende ist es interessant was der RAM sagt wenn es genau soweit ist das er Blödsinn macht.

Ich erinnere mich das Blue im Zweifel je nach Einstellung viele Bluetooth ids einsammelt ... vllt bei dir auch relevant?

[radierer]

Nach reboot der VM auf Proxmox kann ich mein Problem nicht wieder feststellen. Der ble-Adapter läuft aktuell ordentlich durch und ich bekomme (halbwegs) regelmäßig die rssi-Werte übermittelt.
Was mir dennoch nicht ganz klar ist, wieso teilweise mehr als 30 Sekunden vergehen, bis ich einen neuen rssi-Wert bekomme. Im Adapter sind als Intervall für die rssi-Updates 10.000 ms eingestellt, was ja 10 Sekunden entsprechen sollten.
@apollon77 Danke dir auch nochmal für den Tip mit den einsammeln der BT-ID`s .. aber daran sollte es nicht liegen, da ich bei den ble-Objekten unter "allow new devices" false eingetragen habe. Scheint auch zu funktionieren, da keine neuen Devices unter den Objekten eingetragen werden.

Danke & Gruß

[locito09]

@radierer
kannst du bitte das Script teilen für die Anwesenheitserkennung mit GTags?