[Aufruf] BLE Adapter testen (v0.6.0)
-
Wäre schön wenn man das irgendwie besser sperren könnte.
Der Adabter funktioniert gut aber ich hab einfach eine ewig lange liste von Objekten
-
Nabend,
ich habe auch mal den BLE installiert, im Grunde zur Anwesenheitserkennung.
Ich habe einen Nut Schlüsselfinder, dieser wurde erkannt und der RSSI aktualsiert sich alle paar Sekunden.
Wie macht ihr das mit Blockly?
-
Ich habe leider auch gerade das Problem, dass ich BLE ohne Filter habe laufen lassen und ich den BLE Adapter/Instanz nicht löschen kann.
Der Löschvorgang bleibt ebenfalls einfach stehen und er zählt nur die Objekte/States
host.iobroker Counted 34258 states "ble.0*" from states
host.iobroker Counted 68431 objects of ble.0
Hab bestimmt schon 10 Versuche unternommen, klappt leider bisher nicht.
Eine weiter generelle Frage:
Ist es möglich, ein Handy mit ble zu erfassen (zwecks Anwesenheitskontrolle).
Meine MAC Adresse des Handys finde ich leider nicht in den tausenden gefundenen Devices
-
Hallo, seit eine Woche hat der BLE Adapter fast 500 fremde Bluetooth Dings gefunden. kann man es vermeiden? ich habe auch 0x2A19, 0x180F, 0x2902, 0x2A04 eingetragen, nix geholfen. `
Geht mir genauso… alles vollgespamt. Und ich kann mir nicht vorstellen, dass in der Nähe von meinem Heizraum so viele Bluetoothgeräte vorbei kommen. 340 Einträge in 3 Tagen :shock:
-
Ich arbeite bereits an einer Version, die alte Objekte automatisch löscht. Dann sollte das mit den tausenden Objekten Vergangenheit sein.
-
Das wäre echt gut, hoffe dass damit auch meine zig tausend Objekte noch gelöscht werden können. Übers Terminal jedenfalls kann ich meine ble.0 Objekte nicht mehr löschen, weil es wohl zu viele sind und statt diese zu löschen irgendwann ein timeout des Befehls ist, schätze ich mal.
Wird wohl bei mir nur auf ein komplettes Neuaufsetzen von ioBroker hinauslaufen, um die ganzen Datenleichen zu entfernen, oder?
-
Das wäre echt gut, hoffe dass damit auch meine zig tausend Objekte noch gelöscht werden können. Übers Terminal jedenfalls kann ich meine ble.0 Objekte nicht mehr löschen, weil es wohl zu viele sind und statt diese zu löschen irgendwann ein timeout des Befehls ist, schätze ich mal.
Wird wohl bei mir nur auf ein komplettes Neuaufsetzen von ioBroker hinauslaufen, um die ganzen Datenleichen zu entfernen, oder? `
Adapter entfernen und danach wieder hinzufügen hat bei mir eigentlich ganz gut geklappt.
-
Das entfernen des ble Adapters klappt bei mir auch wunderbar, auch die Neuinstallation ist kein Problem. Dann habe ich eine funktionierende zweite Instanz ble.1
Das Problem ist nur, dass ich eine Instanz ble.0 nicht entfernen oder benutzen kann, welche über 65.000 Objekte enthält.
Ich kann diese Instanz unter Objekte nicht einmal mehr öffnen, ohne dass der admin abstürzt.
Entfernen klappt leider auch über keinen Weg. Weder über den "Mülleimer", noch übers Terminal.
Muss wohl leider den kompletten ioBroker neu aufsetzen um diese Datenleichen entfernt zu bekommen
-
Bei mir läuft nun seit knapp 70 Stunden die Anweisung del ble.0
Bis übers zählen der Objekte ist er leider noch nicht hinausgekommen…
-
Kannst du mal den ioBroker komplett stoppen und dann auf der Konsole folgendes ausführen?
iobroker del ble.0Evtl sieht man dann mehr.
-
Ich habe den ioBroker über mein Synology NAS laufen übern Docker. Die Konsole im Docker für den ioBroker kann ich nur benutzen, wenn ioBroker auch läuft, dazu muss ich den ioBroker Container wieder starten.
Oder verstehe ich was falsch, wie kann ich ioBroker selbst komplett stoppen ohne den Container im Docker zu stoppen?
-
Du kannst mit Docker auch Befehle in einem laufenden Container ausführen:
docker exec -it containername /bin/bashDann hast du eine Shell, in der du ganz normal Befehle ausführen kannst.
Bzw wenn du den Container vorher stoppst
docker run -it --entrypoint /bin/bash imagenamemit exit kommst du jeweils wieder raus.
-
Hallo,
ich mach hier weiter.
Habe das Update auf BLE 0.54 gemacht.
Seitdem habe ich folgende Meldungen aus dem SQL Adapter im Log und die Daten werden auch dort nicht mehr geschrieben. Einträge aus anderen Adaptern in der SQL klappen noch.
sql.0 2018-11-28 14:45:45.666 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:43.675 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:42.857 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:40.663 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:39.715 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:38.658 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:37.682 info enabled logging of ble.0.c4:7c:8d:66:43:31.fertility, Alias=false sql.0 2018-11-28 14:45:35.692 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:34.737 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:33.642 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:32.635 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:31.941 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:29.646 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:28.645 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:27.554 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:26.715 info enabled logging of ble.0.c4:7c:8d:66:43:31.moisture, Alias=false sql.0 2018-11-28 14:45:21.654 info enabled logging of ble.0.c4:7c:8d:66:43:31.illuminance, Alias=false sql.0 2018-11-28 14:45:20.596 info enabled logging of ble.0.c4:7c:8d:66:43:31.illuminance, Alias=false sql.0 2018-11-28 14:45:19.575 info enabled logging of ble.0.c4:7c:8d:66:43:31.illuminance, Alias=false sql.0 2018-11-28 14:45:17.575 info enabled logging of ble.0.c4:7c:8d:66:43:31.illuminance, Alias=false sql.0 2018-11-28 14:45:16.695 info enabled logging of ble.0.c4:7c:8d:66:43:31.illuminance, Alias=false sql.0 2018-11-28 14:45:15.664 info enabled logging of ble.0.c4:7c:8d:66:43:31.temperature, Alias=false sql.0 2018-11-28 14:45:14.685 info enabled logging of ble.0.c4:7c:8d:66:43:31.temperature, Alias=false sql.0 2018-11-28 14:45:13.655 info enabled logging of ble.0.c4:7c:8d:66:43:31.temperature, Alias=false sql.0 2018-11-28 14:45:11.744 info enabled logging of ble.0.c4:7c:8d:66:43:31.temperature, Alias=false sql.0 2018-11-28 14:45:09.597 info enabled logging of ble.0.c4:7c:8d:66:43:31.temperature, Alias=falseReboot habe ich auch schon. Keine Änderung. Sobald ich den Adapter starte kommen diese Einträge.
Nachtrag: Jetzt dochte ich, ich deaktiviere einfach das Schreiben in die SQL. Aber dann kommt:
sql.0 2018-11-28 15:25:10.527 info disabled logging of ble.0.c4:7c:8d:66:43:31.temperature sql.0 2018-11-28 15:25:09.675 info disabled logging of ble.0.c4:7c:8d:66:43:31.temperature sql.0 2018-11-28 15:25:07.698 info disabled logging of ble.0.c4:7c:8d:66:43:31.temperature sql.0 2018-11-28 15:25:06.598 info disabled logging of ble.0.c4:7c:8d:66:43:31.temperature sql.0 2018-11-28 15:25:05.728 info disabled logging of ble.0.c4:7c:8d:66:43:31.fertility sql.0 2018-11-28 15:25:03.617 info disabled logging of ble.0.c4:7c:8d:66:43:31.fertility sql.0 2018-11-28 15:25:01.594 infoGruß
Holger
-
Könnte ein weiterer negativer Nebeneffekt des Cachings sein, den ich in 0.5.3 eingeführt habe. 0.5.4 war ein Fix hierfür, aber möglicherweise nicht komplett.
Kannst du bitte mal im Reiter Ereignisse die "objectChange"-Ereignisse vom BLE-Adapter beobachten und hier posten? Am besten machst du das in zwei Tabs parallel (1x Ereignisse, 1x Rest).
Adapter stoppen, History für DPs aktivieren, Adapter starten und beobachten. Ich vermute dass hier die ein oder andere Eigenschaft nicht sauber übertragen wird.
-
Hier ein Screen der Ereignisse:
Was meinst du mit "Rest"? Da läuft bei mir sehr viel durch…
Die log Einträge vom SQL kommen auf jeden Fall ohne das in den Ereignissen was passiert.
Gruß
Holger
-
Lösch mal den Filter aus der Quelle und setze ihn bei der Objekt-ID. Als Typ bitte objectChange. Eigentlich sollten die Logs von History nur kommen, wenn am Objekt was geändert wird.
-
Da kommt ziemlich viel:
Wie kann man denn das kopieren, was im Mouse-Over unter Wert kommt? Die object changes kommen alle vom BLE Adapter.
Gruß
Holger
-
Ok, das ist genau das was eigentlich nicht mehr passieren sollte. Ein Screenshot vom Mouse-Over könnte reichen. Ich denke das muss ich dann nochmal selbst nachvollziehen.
Passiert das auch mit dem History-Adapter? Kannst du mir mal kurz zusammenfassen, wie sich das reproduzieren lässt?
-
Die Meldungen kommen ja selbst, wenn ich das Logging mit SQL deaktiviere. Dann halt nur als disable…
Was hatte ich gemacht? Eigentlich nur auf 0.5.4 geupdatet und mich dann gewundert, das die Grafiken nicht mehr geupdatet wurden bzw auf dem Stand von vor dem Update waren. Bei der Fehlersuche dann auf die Einträge im Log gestoßen.
Du solltest noch wissen, dass der BLE auf einem Slave Raspi-Zero läuft. Master und SQL laufen als VM unter Proxmox. Aber wie gesagt, andere Adapter schreiben ja fleissig in die DB.
Gruß
Holger
-
Das Problem liegt größtenteils am BLE-Adapter. Dein Objekt wird ständig geschrieben und enthält dabei den Abschnitt des Objekts in dem SQL-Logging konfiguriert wird. Der SQL-Adapter denkt dann jedes Mal du hast das Logging umkonfiguriert.
Ich hoffe dass ich heute Abend dazu komme es zu beheben.
