Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Error/Bug
  4. ble-Adapter stürzt plötzlich ab

NEWS

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    16
    1
    1.8k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    896

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    2.1k

ble-Adapter stürzt plötzlich ab

Geplant Angeheftet Gesperrt Verschoben Gelöst Error/Bug
ble bluetooth stürzt ab sigkil
10 Beiträge 4 Kommentatoren 431 Aufrufe 6 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • R Offline
    R Offline
    radierer
    schrieb am zuletzt editiert von radierer
    #1
    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.

    haselchenH 1 Antwort Letzte Antwort
    0
    • R 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.

      haselchenH Offline
      haselchenH Offline
      haselchen
      Most Active
      schrieb am zuletzt editiert von
      #2

      @radierer

      Hi , welche Version des Adapters nutzt Du ?

      Synology DS218+ & 2 x Fujitsu Esprimo (VM/Container) + FritzBox7590 + 2 AVM 3000 Repeater & Homematic & HUE & Osram & Xiaomi, NPM 10.9.4, Nodejs 22.21.0 ,JS Controller 7.0.7 ,Admin 7.7.19

      1 Antwort Letzte Antwort
      0
      • R Offline
        R Offline
        radierer
        schrieb am zuletzt editiert von
        #3

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

        1 Antwort Letzte Antwort
        0
        • R Offline
          R Offline
          radierer
          schrieb am zuletzt editiert von
          #4

          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?

          1 Antwort Letzte Antwort
          0
          • R Offline
            R Offline
            radierer
            schrieb am zuletzt editiert von
            #5

            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. :(

            apollon77A 1 Antwort Letzte Antwort
            0
            • R 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. :(

              apollon77A Offline
              apollon77A Offline
              apollon77
              schrieb am zuletzt editiert von apollon77
              #6

              @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?

              Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77

              • Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
              • Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
              1 Antwort Letzte Antwort
              0
              • R Offline
                R Offline
                radierer
                schrieb am zuletzt editiert von
                #7

                @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:
                0353464d-5daa-40cd-9015-ff88f97b9779-grafik.png
                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?

                apollon77A 1 Antwort Letzte Antwort
                0
                • R 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:
                  0353464d-5daa-40cd-9015-ff88f97b9779-grafik.png
                  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?

                  apollon77A Offline
                  apollon77A Offline
                  apollon77
                  schrieb am zuletzt editiert von
                  #8

                  @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?

                  Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77

                  • Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
                  • Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
                  1 Antwort Letzte Antwort
                  0
                  • R Offline
                    R Offline
                    radierer
                    schrieb am zuletzt editiert von
                    #9

                    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ß

                    1 Antwort Letzte Antwort
                    0
                    • L Offline
                      L Offline
                      locito09
                      schrieb am zuletzt editiert von
                      #10

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

                      1 Antwort Letzte Antwort
                      0
                      Antworten
                      • In einem neuen Thema antworten
                      Anmelden zum Antworten
                      • Älteste zuerst
                      • Neuste zuerst
                      • Meiste Stimmen


                      Support us

                      ioBroker
                      Community Adapters
                      Donate

                      695

                      Online

                      32.6k

                      Benutzer

                      82.1k

                      Themen

                      1.3m

                      Beiträge
                      Community
                      Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                      ioBroker Community 2014-2025
                      logo
                      • Anmelden

                      • Du hast noch kein Konto? Registrieren

                      • Anmelden oder registrieren, um zu suchen
                      • Erster Beitrag
                        Letzter Beitrag
                      0
                      • Home
                      • Aktuell
                      • Tags
                      • Ungelesen 0
                      • Kategorien
                      • Unreplied
                      • Beliebt
                      • GitHub
                      • Docu
                      • Hilfe