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

[BeautyBoyBob]

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 :D

[radicalreel]

@anrada73:

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:

[AlCalzone]

Ich arbeite bereits an einer Version, die alte Objekte automatisch löscht. Dann sollte das mit den tausenden Objekten Vergangenheit sein.

[BeautyBoyBob]

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?

[radicalreel]

@BeautyBoyBob:

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.

[BeautyBoyBob]

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

[BeautyBoyBob]

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…

[AlCalzone]

Kannst du mal den ioBroker komplett stoppen und dann auf der Konsole folgendes ausführen?

iobroker del ble.0

Evtl sieht man dann mehr.

[BeautyBoyBob]

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?

[AlCalzone]

Du kannst mit Docker auch Befehle in einem laufenden Container ausführen:

docker exec -it containername /bin/bash

Dann 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 imagename

mit exit kommst du jeweils wieder raus.

[holgerwolf]

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=false

Reboot 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	info	

Gruß

Holger

[AlCalzone]

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.

[holgerwolf]

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

[AlCalzone]

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.

[holgerwolf]

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

[AlCalzone]

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?

[holgerwolf]

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

[AlCalzone]

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.

[AlCalzone]

@holgerwolf:

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. `

Probier bitte mal v0.5.5. Ich hatte den Fix nur auf Geräte-Objekte angewendet, aber nicht Channels und States.

[holgerwolf]

Jepp, mit 0.5.5. passt es wieder.

Jetzt heißt es wieder auf den nächsten Frost warten…

Danke und Gruß

Holger