@fredf sagte in ioBroker funktioniert zwar, aber Admin ist sehr langsam:

@nodoe
Zu 1. am Beispiel alias. Ordner markieren und über den Pfeil den Objektbaum herunterladen, dann öffnet sich ein Popup im dem die Anzahl der Objekte zu sehen ist.

Zu 2. meine mich an ein Skript hier im Forum zu erinnern, suche mal danach.

Hallo zusammen,

nachdem sich mein Router bei einem Stromausfall im Gewitter verschluckt hatte und mein VPN-Zugang zum smarten Heim (bin gerade 1000 km entfernt) down war, bin ich inzwischen wieder online.

@fredf: Danke für den Tipp, damit konnte ich mit viel Geduld die Quelle der vielen Objects und States ermitteln: der experimentelle Fronius-Solarweb-Adapter hat mir allein je 445k States und Objects erzeugt, da er kontinuierlich alle 5 min. die PV-Daten in eigene Objekte geschrieben hat.

Bei der Deinstallation des Adapters kommt nur leider folgender Fehler:

Delete adapter "fronius-solarweb"
host.ioBroker Counted 1 meta of fronius-solarweb
host.ioBroker Counted 1 adapter for fronius-solarweb
host.ioBroker error: Maximum call stack size exceeded
host.ioBroker Cannot get keys async: Maximum call stack size exceeded
host.ioBroker Counted 1 states (system.adapter.fronius-solarweb.*) from states
host.ioBroker error: Maximum call stack size exceeded
host.ioBroker file fronius-solarweb.admin deleted
host.ioBroker object fronius-solarweb deleted
host.ioBroker object fronius-solarweb.admin deleted
host.ioBroker Deleting 2 object(s).
host.ioBroker Deleting 1 state(s).
removed 8 packages in 3.616s

86 packages are looking for funding
  run `npm fund` for details

Der Adapter ist jetzt weg, die Objects und States aber noch da.
Vermutlich waren es zu viele, so dass folgender Fehler kommt:
host.ioBroker error: Maximum call stack size exceeded
host.ioBroker Cannot get keys async: Maximum call stack size exceeded

Hier vermutlich off-topic, aber hat jemand eine Idee, wie ich die Objects und States noch loswerden kann?

Vielen Dank schonmal.

----- EDIT: Ich habe die Redis-DB mit externen Tools bearbeiten und die Fronius-Solarweb-Einträge mit überschaubarem Aufwand löschen können - voila: jetzt sind es noch je ca. 5.000 Objects und States. Backup arbeitet wieder fehlerfrei, Admin läuft auch wieder zügig, alles gut. -----

@apollon77 Jep, gestern schon an Adapter-Entwickler gemeldet.

@tombox
Sorry, da kann ich Dir wohl nicht folgen. Bei mir ist "Türfalle einziehen" in der App standardmäßig an, meinst Du das? Da dreht das Schloss aber entsprechend der Kaibrierung (Drehwinkel?) nicht so weit wie bei unlock=Force unlock (max. Kraft?). Öffnen/Schließen geht damit problemlos.

Beste Weihnachtsgrüße!

@tombox

Das Schloss hat Firmware 2.4.16884, die Bridge 2.2.16924. Die sollten eigentlich aktuell sein.

Unabhängig davon habe ich einen Anhaltspunkt: Bei unlock=unlock(0) öffnet das Schloss, zieht die Falle ein und springt in dieselbe Position zurück wie bei der App-Steuerung. In der App steht dann "offen". Von da aus lässt sich dass schloss auch mit lock=true schließen. Öffne ich das Schloss mit unlock=Force unlock, öffnet das Schloss, dreht beim Einziehen der Falle weiter als mit App bzw. unlock=unlock(0) und springt dann nicht so weit zurück (ca. 30° weiter Richtung "auf" gedreht). In der App steht "eingezogen" (nicht "offen"). Dann schließt das Schloss nicht mit lock=true und es kommt der beschriebene Fehler im log.

Mir ist noch etwas aufgefallen: Ich würde gerne standardmäßig unlock ="Without auto pull spring" einstellen und damit morgens die Tür standardmäßig öffnen, ohne die Falle zu ziehen. Das funktioniert einmalig, anschließend springt unlock auf unlock=unlock(0) zurück. Ist das gewollt? Ich fände es besser, wenn der eingestellte Zustand erhalten bliebe.

Beste Grüße und danke für die tolle Arbeit!

@tombox

Hallo zusammen,

bin gerade erst zum installieren und testen gekommen. Alle unlock-Funktionen laufen.

Bei lock=true bekomme ich folgenden Fehler im log und das Schloss bewegt sich nicht:

tedee.0 788259	2023-12-23 01:23:15.901	error	{"error-code":3,"error-description":"BLE API error"}
tedee.0 788259	2023-12-23 01:23:15.901	error	AxiosError: Request failed with status code 406

Welche Optionen habe ich? Der Admin läuft mit der latest-version 6.12.0.

Beste Grüße.

@tombox Das kann ich urlaubsbedingt erstmal nicht testen, habe den Adapter deinstalliert und den Fronius-Adapter wieder laufen, der direkt die WR-Daten liest.

@apollon77 Jep, gestern schon an Adapter-Entwickler gemeldet.

@nik82 sagte in Test Adapter fronius-solarweb:

@tombox
Ich habe jetzt ein echtes Problem, ich habe 114000 Objekte die er gerade löschen will, ich habe geschaut, er löscht 400 Objekte in ca. 2,5 Minuten.

Kann man die Objekte irgendwie schneller löschen?
Bzw. wie kann ich das jetzt abbrechen, damit ich einfach über Nacht löschen lassen kann?

Ich hatte ein vergleichbares Problem, allerdings mit ca. je 445.000 Objects und States (Fronius-Solarweb-Adapter lief länger zum Testen munter im Parallelbetrieb zum aktiven Fronius-Adapter mit). Dann gingen kein Backup und kein Admin mehr. Externes Bearbeiten der Redis-DB und Löschen der fronius-solarweb-Einträge hat geholfen.

@fredf sagte in ioBroker funktioniert zwar, aber Admin ist sehr langsam:

@nodoe
Zu 1. am Beispiel alias. Ordner markieren und über den Pfeil den Objektbaum herunterladen, dann öffnet sich ein Popup im dem die Anzahl der Objekte zu sehen ist.

Zu 2. meine mich an ein Skript hier im Forum zu erinnern, suche mal danach.

Hallo zusammen,

nachdem sich mein Router bei einem Stromausfall im Gewitter verschluckt hatte und mein VPN-Zugang zum smarten Heim (bin gerade 1000 km entfernt) down war, bin ich inzwischen wieder online.

@fredf: Danke für den Tipp, damit konnte ich mit viel Geduld die Quelle der vielen Objects und States ermitteln: der experimentelle Fronius-Solarweb-Adapter hat mir allein je 445k States und Objects erzeugt, da er kontinuierlich alle 5 min. die PV-Daten in eigene Objekte geschrieben hat.

Bei der Deinstallation des Adapters kommt nur leider folgender Fehler:

Delete adapter "fronius-solarweb"
host.ioBroker Counted 1 meta of fronius-solarweb
host.ioBroker Counted 1 adapter for fronius-solarweb
host.ioBroker error: Maximum call stack size exceeded
host.ioBroker Cannot get keys async: Maximum call stack size exceeded
host.ioBroker Counted 1 states (system.adapter.fronius-solarweb.*) from states
host.ioBroker error: Maximum call stack size exceeded
host.ioBroker file fronius-solarweb.admin deleted
host.ioBroker object fronius-solarweb deleted
host.ioBroker object fronius-solarweb.admin deleted
host.ioBroker Deleting 2 object(s).
host.ioBroker Deleting 1 state(s).
removed 8 packages in 3.616s

86 packages are looking for funding
  run `npm fund` for details

Der Adapter ist jetzt weg, die Objects und States aber noch da.
Vermutlich waren es zu viele, so dass folgender Fehler kommt:
host.ioBroker error: Maximum call stack size exceeded
host.ioBroker Cannot get keys async: Maximum call stack size exceeded

Hier vermutlich off-topic, aber hat jemand eine Idee, wie ich die Objects und States noch loswerden kann?

Vielen Dank schonmal.

----- EDIT: Ich habe die Redis-DB mit externen Tools bearbeiten und die Fronius-Solarweb-Einträge mit überschaubarem Aufwand löschen können - voila: jetzt sind es noch je ca. 5.000 Objects und States. Backup arbeitet wieder fehlerfrei, Admin läuft auch wieder zügig, alles gut. -----

@fredf Den Fronius-Adapter habe ich auch drauf und schon in Verdacht gehabt. Hatte ihn deinstalliert, aber keine Änderung. Zwischenzeitlich hatte ich ebenso den Fronius-Solarweb-Adapter parallel laufen. Vielleicht sind bei den Deinstallationen die zugehörigen Objects und States nicht gelöscht worden. Damit habe ich schon 2 Fragen:

1. Herausfinden auf Kommandozeilen-Ebene welcher Adapter/Instanz wieviel Objects/States erzeugt
2. Bereinigen der Datenbank um Objects/States von nicht mehr vorhandenen Adaptern/Instanzen

@bahnuhr sagte in ioBroker funktioniert zwar, aber Admin ist sehr langsam:

@nodoe

Du hast gerade einmal 11 Beiträge; also bist du doch relativ neu bei iob.

Warum dann 6.0.0; stable ist das nicht.

@nodoe sagte in ioBroker funktioniert zwar, aber Admin ist sehr langsam:

ioBroker läuft auf einem NUC7i7 mit 32GB RAM in einem PROXMOX-Container.

TOP; habe ich auch.

@nodoe sagte in ioBroker funktioniert zwar, aber Admin ist sehr langsam:

Datenbank ist Redis.

Warum das ?
Gibt keinen Sinn, oder doch ?

@nodoe sagte in ioBroker funktioniert zwar, aber Admin ist sehr langsam:

Anzahl der Objekte bzw. States liegen (je ca. 450.000!).

Ich habe iob schon lange; und ca. 50 Adpater installiert; und ca. 200 Scripte.
Und komme damit noch nicht einmal auf 20.000 Objekte.
Wo kommen die her ?

Fazit:
Hardware ist ok.
Fahre iob auf stable und alles ist gut.
Und prüfe deine Scripte !
450.000 Objekte ist nicht normal.

P.S.
Kann jeder anders sehen

Danke schonmal für die Antwort. Ich nutze ioBroker produktiv seit ca. 3 Jahren mit ca. 30 Adaptern. Insofern vielleicht nicht mehr ganz neu. Aber ja, im Schreiben von Beiträgen bin ich aus Zeitgründen vielleicht nicht ganz so gut, aber dafür im Lesen ;-).

Stable-Version des Admin 5.3.4 habe ich natürlich ausprobiert und dasselbe Phänomen, also leider nicht alles gut.

Dass 450k Objekte nicht normal sind ist ja gerade der Kern meiner Frage: wie kann ich auf Kommandozeilen-Ebene herausfinden, wo die herkommen (welcher Adapter/Instanz). Und danach im Idealfall: wie kann ich die Zahl reduzieren?

Vielen Dank für jede Unterstützung!

Hallo zusammen,

ich greife diesen Beitrag nochmal auf, da ich ein ähnliches Verhalten wie h1ob habe, ioBroker "läuft stabil" (Vis, Skripte, Schaltvorgänge), der Admin (incl. 6.0.0) ist zwar erreichbar, zeigt aber nur den Laufbalken und keine Adapter, Instanzen, etc. Bei mir könnte es aber an der Anzahl der Objekte bzw. States liegen (je ca. 450.000!). Zumindest wird das beim Start des Backups gemeldet (was damit nicht mehr funktioniert).

Gibt es eine Möglichkeit, auf der Kommandoebene die Anzahl der Objekte/States pro Adapter/Instanz auszugeben? Vielleicht hilft dann schon die Modifikation der Einstellungen bzw. die Deinstallation des Adapters weiter, der so viele Daten erzeugt.

ioBroker läuft auf einem NUC7i7 mit 32GB RAM in einem PROXMOX-Container. Datenbank ist Redis.

Vielen Dank schon einmal!