Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[dtp]

Hi,

wenn ich in den Objekten nach einem Namen suche, dann dreht sich die Sanduhr ewig.

War vorher nicht so. Haben das Problem auch andere?

[Jan1]

@dtp
kein Problem

[Thomas Braun]

@dtp Schau mal wie die Auslastung beim Speicher ist.

[dtp]

Soweit recht unkritisch, würde ich sagen.

[Thomas Braun]

@dtp Was ist das? Schau mit top oder free direkt auf dem System nach.

[dtp]

Das ist der Docker-Container auf meiner Synology DS718+ mit 6 GB RAM.

Hier mal die Werte nach eingabe von top.

Das kann nicht die Ursache des Problems sein. Bei allen anderen Spalten reagiert die Suche sofort. Nur, wenn ich nach einem Namen suche, läuft ewig die Sanduhr.

Ein Neustart des ioBroker bzw. des Containers hat auch nichts an dem Problem geändert.

[sigi234]

@dtp sagte in admin 4.1.1 - Sanduhr bei Namenssuche:

War vorher nicht so. Haben das Problem auch andere?

Gerade getestet, kann ich bestätigen.

[dtp]

Danke. Läuft der ioBroker bei dir auch im Docker-Container oder auf einer anderen Hardware?

[sigi234]

@dtp sagte in admin 4.1.1 - Sanduhr bei Namenssuche:

Danke. Läuft der ioBroker bei dir auch im Docker-Container oder auf einer anderen Hardware?

Windows

[Thomas Braun]

@dtp Dein System swappt.
Auf meiner Kiste jedenfalls keine nennenswerte Verzögerung. Ich vermute, dass da eine Instanz sehr viele Objekte anlegt.

[dtp]

Hab gerade herausgefunden, dass das Problem mit dem sourceanalytics-Adapter zusammenzuhängen scheint. Wenn ich den stoppe und die Datenpunkte lösche, geht die Namenssuche wieder.

[crunchip]

@dtp hattest du nicht gestern Probleme beim Einrichten von source....und hattest alle DP gewählt?

[dtp]

@crunchip sagte in admin 4.1.1 - Sanduhr bei Namenssuche:

hattest du nicht gestern Probleme beim Einrichten von source....und hattest alle DP gewählt?

Ja, aber das hatte ich schon wieder rückgängig gemacht, indem ich die Auswahl aufhob und dann abwartete, bis der Zähler wieder auf 0 zählte.

Danach habe ich dann alle von sourceanalytics angelegten Datenpunkte gelöscht.

[crunchip]

@dtp hast du die Objekte auch gelöscht?

[dtp]

Ja, siehe oben.

Danach funktioniert die Namenssuche ja auch wieder. Aber mit angelegten sourceanalytics-Datenpunkte offensichtlich nicht. Egal, wie viele da angelegt wurden.

[crunchip]

@dtp in welcher Version läuft der Adapter?
Scheinbar hängt da noch was im System bzw wurde nicht richtig gelöscht.
Ich hab v 0.4.2 laufen

[dtp]

@crunchip sagte in admin 4.1.1 - Sanduhr bei Namenssuche:

Ich hab v 0.4.2 laufen

Ich auch. Der Adapter macht aber auch noch andere Probleme. So bekomme ich immer die folgende Warnmeldung, obwohl die Datenpunkte definitiv als number angelegt sind.

sourceanalytix.0	2020-07-12 10:35:42.034	warn	(691) This object will not be created in future versions. Please report this to the developer.
sourceanalytix.0	2020-07-12 10:35:42.033	warn	(691) Object sourceanalytix.0.hm-rpc__0__NEQ0862336__1__GAS_POWER.2020.consumed.weeks.48 is invalid: obj.common.name has an invalid type! Expected "string" or "object", received "number"

[Jan1]

@dtp sagte in admin 4.1.1 - Sanduhr bei Namenssuche:

Expected "string" or "object", received "number"

Eben und im Log steht ja, dass number falsch ist :-)

[paul53]

@dtp sagte:

obj.common.name has an invalid type!

Das betrifft offenbar nicht den Wert, sondern den Namen.

[dtp]

Ich kann das ja nicht großartig beeinflussen, da die entsprechenden Datenpunkte automatisch vom hm.rpc-Adapter angelegt wurden. Aber der Objektname hat doch nicht den Typ number, oder?

@Jan1 sagte in admin 4.1.1 - Sanduhr bei Namenssuche:

Eben und im Log steht ja, dass number falsch ist

Stimmt auch wieder.

Aber wie gesagt, ich habe da eher keine Einflussmöglichkeiten, oder? Zudem scheint es ja um den Objektnamen zu gehen.