Weiter zum Inhalt
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Hell
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dunkel
  • 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. ioBroker Allgemein
  4. Problem mit BLE Adapater

NEWS

  • Neuer ioBroker-Blog online: Monatsrückblick März/April 2026
    BluefoxB
    Bluefox
    8
    1
    1.7k

  • Verwendung von KI bitte immer deutlich kennzeichnen
    HomoranH
    Homoran
    10
    1
    721

  • Monatsrückblick Januar/Februar 2026 ist online!
    BluefoxB
    Bluefox
    18
    1
    1.2k

Problem mit BLE Adapater

Geplant Angeheftet Gesperrt Verschoben ioBroker Allgemein
blerssiadapterabwesendgtag
6 Beiträge 2 Kommentatoren 604 Aufrufe 2 Beobachtet
  • Ä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.
  • M Offline
    M Offline
    moses123
    schrieb am zuletzt editiert von
    #1

    Hallo Zusammen,

    ich verwendet aktuell den BLE Adapter, da ich neben der Anwesend- Erkennung auch noch ein paar Xiaomi Thermometer auslese.

    Für die Anwesend- Erkennung werden Gigaset GTags (Bluetoothbeacons) genutzt. Diese werden erkannt und es gibt auch rssi- Werte.

    Über die rssi Werte läuft die Erkennung, wenn der Timestamp des rssi-Wertes sich über einen definierten Zeitraum nicht ändert, wird davon ausgegangen, dass dieses Beacon nicht mehr in Reichweite ist, also der Besitzer weg ist.

    Leider gab es bei der letzten Version wohl eine Änderung, so dass der rssi-Wert nur neu in den State geschrieben wird, wenn sich dieser geändert hat. Bei einem am Schlüsselbund hängenden und in der Ecke liegenden GTag ein Problem, da der rssi-Wert dann auch mal gleich bleiben kann. Mit dem Ergebnis, dass dieser auch mal als Abwesend erkannt wird, weil sich der Timestamp nicht ändert. Und im Haus die Lichter ausgehen und der Alarm scharf geschaltet wird...

    Ich könnte die Zeile im Adapter ändern, aber vielleicht hat ja jemand eine Idee, welche Infos ich statt des Timestamps nutzen könnte.
    Radar2 geht leider nicht, da ich mit diesem die Xiaomi Thermometer nicht auslesen kann und beide Zusammen stören sich...

    Gruß,
    Moses123

    AlCalzoneA 1 Antwort Letzte Antwort
    0
    • M moses123

      Hallo Zusammen,

      ich verwendet aktuell den BLE Adapter, da ich neben der Anwesend- Erkennung auch noch ein paar Xiaomi Thermometer auslese.

      Für die Anwesend- Erkennung werden Gigaset GTags (Bluetoothbeacons) genutzt. Diese werden erkannt und es gibt auch rssi- Werte.

      Über die rssi Werte läuft die Erkennung, wenn der Timestamp des rssi-Wertes sich über einen definierten Zeitraum nicht ändert, wird davon ausgegangen, dass dieses Beacon nicht mehr in Reichweite ist, also der Besitzer weg ist.

      Leider gab es bei der letzten Version wohl eine Änderung, so dass der rssi-Wert nur neu in den State geschrieben wird, wenn sich dieser geändert hat. Bei einem am Schlüsselbund hängenden und in der Ecke liegenden GTag ein Problem, da der rssi-Wert dann auch mal gleich bleiben kann. Mit dem Ergebnis, dass dieser auch mal als Abwesend erkannt wird, weil sich der Timestamp nicht ändert. Und im Haus die Lichter ausgehen und der Alarm scharf geschaltet wird...

      Ich könnte die Zeile im Adapter ändern, aber vielleicht hat ja jemand eine Idee, welche Infos ich statt des Timestamps nutzen könnte.
      Radar2 geht leider nicht, da ich mit diesem die Xiaomi Thermometer nicht auslesen kann und beide Zusammen stören sich...

      Gruß,
      Moses123

      AlCalzoneA Offline
      AlCalzoneA Offline
      AlCalzone
      Developer
      schrieb am zuletzt editiert von
      #2

      @moses123 Kannste mir mal ein Debug-Log machen? Eigentlich sollte sich da nichts geändert haben.

      Warum `sudo` böse ist: https://forum.iobroker.net/post/17109

      1 Antwort Letzte Antwort
      0
      • M Offline
        M Offline
        moses123
        schrieb am zuletzt editiert von
        #3

        Hallo,

        ich bin gerade dabei, das Problem nachzustellen. Ich hatte ja eine Zeile im Verdacht, die verhindern soll, dass zu oft ein Update vom rssi durchgeführt wird.

        Ich lasse mal den History mitlaufen, um zu sehen, ob da eine zu große Lücke entsteht. Seit meiner ersten Meldung ist es ruhig geblieben, der PI wurde aber auch mal neu gestartet...

        1 Antwort Letzte Antwort
        0
        • M Offline
          M Offline
          moses123
          schrieb am zuletzt editiert von
          #4

          So, heute Nacht ist es dann drei mal aufgetreten, im History sieht man Lücken für den rssi-Update.

          Debug habe ich jetzt mal noch nicht mitlaufen lassen, da ich gestern keine Zeit hatte, das so einzurichten, dass der SD-Karte nicht voll läuft.

          Die History sieht dann so aus:

          -71	true		2020-12-28 00:07:29.582	00:07:29.582
          -81	true		2020-12-28 00:07:18.536	00:07:18.536
          -82	true		2020-12-28 00:07:08.486	00:07:08.486
          -77	true		2020-12-28 00:06:57.406	00:06:57.406
          -82	true		2020-12-28 00:06:39.331	00:06:39.331
          -71	true		2020-12-28 00:04:22.591	00:04:22.591*
          -81	true		2020-12-28 00:04:02.489	00:04:02.489
          -71	true		2020-12-28 00:01:34.679	00:01:34.679*
          -81	true		2020-12-28 00:01:19.609	00:01:19.609
          -71	true		2020-12-28 00:01:08.552	00:01:08.552
          -81	true		2020-12-28 00:00:58.490	00:00:58.490
          -71	true		2020-12-28 00:00:40.414	00:00:40.414
          -81	true		2020-12-28 00:00:29.341	00:00:29.341
          -82	true		2020-12-28 00:00:19.284	00:00:19.284
          -71	true		2020-12-28 00:00:02.197	00:00:02.197
          

          In der Regel erfolgt das Update innerhalb von ca. 20 Sekunden (ist im Adapter so eingestellt), so dass mein Skript dann nicht reagiert, aber es gibt dort auch Lücken (00:01:34 und 00:04:22), da sind die Abstände>2 Min.

          Ich vermute, da keinerlei doppelten rssi-Werte in der Reihe auftauchen, dass hier die Filterung in Zeile 387 eine Rolle spielt:

          (rssiState.val !== peripheral.rssi && // only save changes
          

          Diese Zeile ist vor 2 Monaten bei der 0.12 dazu gekommen. Eigentlich macht diese Zeile keinen Sinn, denn es können ja auch mal gleiche rssi- Werte gelesen werden, wenn auch recht selten...

          AlCalzoneA 1 Antwort Letzte Antwort
          0
          • M Offline
            M Offline
            moses123
            schrieb am zuletzt editiert von
            #5

            Nachtrag: Geändert habe ich die Zeilen an der Stelle im Main.ts so, also SaveChanges raus, und Prüfung auf TS nicht LC:

            if (rssiState == null ||
                    //(rssiState.val !== peripheral.rssi && // only save changes
                       ( rssiState.ts + rssiUpdateInterval < Date.now()) // and dont update too frequently
                ) {
            

            Und nun sieht das Historylog so aus, es wird jetzt schön regelmäßig ein Wert geschrieben, auch wenn der dem vorigen entspricht:

            -81	true		2020-12-28 08:22:56.761	
            -71	true		2020-12-28 08:22:46.722	
            -77	true		2020-12-28 08:22:35.664	
            -77	true		2020-12-28 08:22:24.587	
            -81	true		2020-12-28 08:22:14.547	
            -71	true		2020-12-28 08:22:03.495	
            -81	true		2020-12-28 08:21:53.434	
            -81	true		2020-12-28 08:21:43.378	
            -81	true		2020-12-28 08:21:33.329	
            -71	true		2020-12-28 08:21:22.271	
            -81	true		2020-12-28 08:21:12.207	
            -81	true		2020-12-28 08:21:02.163	
            -71	true		2020-12-28 08:20:51.103	
            -81	true		2020-12-28 08:20:41.039	
            -71	true		2020-12-28 08:20:30.994	
            -81	true		2020-12-28 08:20:20.945	
            -81	true		2020-12-28 08:20:09.871	
            -71	true		2020-12-28 08:19:59.830	
            -77	true		2020-12-28 08:19:48.766
            
            1 Antwort Letzte Antwort
            0
            • M moses123

              So, heute Nacht ist es dann drei mal aufgetreten, im History sieht man Lücken für den rssi-Update.

              Debug habe ich jetzt mal noch nicht mitlaufen lassen, da ich gestern keine Zeit hatte, das so einzurichten, dass der SD-Karte nicht voll läuft.

              Die History sieht dann so aus:

              -71	true		2020-12-28 00:07:29.582	00:07:29.582
              -81	true		2020-12-28 00:07:18.536	00:07:18.536
              -82	true		2020-12-28 00:07:08.486	00:07:08.486
              -77	true		2020-12-28 00:06:57.406	00:06:57.406
              -82	true		2020-12-28 00:06:39.331	00:06:39.331
              -71	true		2020-12-28 00:04:22.591	00:04:22.591*
              -81	true		2020-12-28 00:04:02.489	00:04:02.489
              -71	true		2020-12-28 00:01:34.679	00:01:34.679*
              -81	true		2020-12-28 00:01:19.609	00:01:19.609
              -71	true		2020-12-28 00:01:08.552	00:01:08.552
              -81	true		2020-12-28 00:00:58.490	00:00:58.490
              -71	true		2020-12-28 00:00:40.414	00:00:40.414
              -81	true		2020-12-28 00:00:29.341	00:00:29.341
              -82	true		2020-12-28 00:00:19.284	00:00:19.284
              -71	true		2020-12-28 00:00:02.197	00:00:02.197
              

              In der Regel erfolgt das Update innerhalb von ca. 20 Sekunden (ist im Adapter so eingestellt), so dass mein Skript dann nicht reagiert, aber es gibt dort auch Lücken (00:01:34 und 00:04:22), da sind die Abstände>2 Min.

              Ich vermute, da keinerlei doppelten rssi-Werte in der Reihe auftauchen, dass hier die Filterung in Zeile 387 eine Rolle spielt:

              (rssiState.val !== peripheral.rssi && // only save changes
              

              Diese Zeile ist vor 2 Monaten bei der 0.12 dazu gekommen. Eigentlich macht diese Zeile keinen Sinn, denn es können ja auch mal gleiche rssi- Werte gelesen werden, wenn auch recht selten...

              AlCalzoneA Offline
              AlCalzoneA Offline
              AlCalzone
              Developer
              schrieb am zuletzt editiert von
              #6

              @moses123 sagte in Problem mit BLE Adapater:

              Eigentlich macht diese Zeile keinen Sinn, denn es können ja auch mal gleiche rssi- Werte gelesen werden, wenn auch recht selten...

              Joar, das hängt vom Anwendungsfall ab, ob das Sinn macht. Wenn man die RSSI nicht betrachtet, dann reduziert diese Prüfung die Anzahl der Updates massiv. Kann ich aber gerne konfigurierbar machen.

              Warum `sudo` böse ist: https://forum.iobroker.net/post/17109

              1 Antwort Letzte Antwort
              0

              Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.

              Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.

              Mit deinem Input könnte dieser Beitrag noch besser werden 💗

              Registrieren Anmelden
              Antworten
              • In einem neuen Thema antworten
              Anmelden zum Antworten
              • Älteste zuerst
              • Neuste zuerst
              • Meiste Stimmen


              Support us

              ioBroker
              Community Adapters
              Donate
              FAQ Cloud / IOT
              HowTo: Node.js-Update
              HowTo: Backup/Restore
              Downloads
              BLOG

              482

              Online

              32.9k

              Benutzer

              83.0k

              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