Log error admin.0 empty Object
-
Mein iobroker (docker) läuft scheinbar ohne Auffälligkeiten. Allerdings bekomme ich vermehrt folgenden Fehler im Log:
admin.0 2026-06-18 07:50:12.515 error empty object! admin.0 2026-06-18 07:50:12.515 error empty object! admin.0 2026-06-18 07:39:29.153 info <== Disconnect system.user.admin from ::ffff:192.168.65.1 adminIm ioBroker container Log sehe ich :
================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] (node:24568) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. (Use `node --trace-warnings ...` to show where the warning was created)Die Fehler treten häufig auf (siehe Ausgabe iob diag)
Leider habe ich das erst jetzt bemerkt. Kann also nicht sagen, ob es mit dem letzen admin Adapter Update zusammenhängt.iob diag Ausgabe:
Nach einer halben Stunde googeln habe ich erstmal aufgegeben.
Wie kann ich dem Fehler auf die Spur kommen? -
Mein iobroker (docker) läuft scheinbar ohne Auffälligkeiten. Allerdings bekomme ich vermehrt folgenden Fehler im Log:
admin.0 2026-06-18 07:50:12.515 error empty object! admin.0 2026-06-18 07:50:12.515 error empty object! admin.0 2026-06-18 07:39:29.153 info <== Disconnect system.user.admin from ::ffff:192.168.65.1 adminIm ioBroker container Log sehe ich :
================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] (node:24568) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. (Use `node --trace-warnings ...` to show where the warning was created)Die Fehler treten häufig auf (siehe Ausgabe iob diag)
Leider habe ich das erst jetzt bemerkt. Kann also nicht sagen, ob es mit dem letzen admin Adapter Update zusammenhängt.iob diag Ausgabe:
Nach einer halben Stunde googeln habe ich erstmal aufgegeben.
Wie kann ich dem Fehler auf die Spur kommen?Etwas ist mir noch aufgefallen. Ich habe mit das komplette Log runtergeladen. Die Fehlermeldungen kommen schnell hintereinander immer so 20 error meldungen innerhalb einer Minute.
Das Merkwürdige, Diese error-Blöcke wiederholen sich genau stündlich. -
Mein iobroker (docker) läuft scheinbar ohne Auffälligkeiten. Allerdings bekomme ich vermehrt folgenden Fehler im Log:
admin.0 2026-06-18 07:50:12.515 error empty object! admin.0 2026-06-18 07:50:12.515 error empty object! admin.0 2026-06-18 07:39:29.153 info <== Disconnect system.user.admin from ::ffff:192.168.65.1 adminIm ioBroker container Log sehe ich :
================================== > LOG REDIRECT system.adapter.admin.0 => false [Process stopped] ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] (node:24568) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification. (Use `node --trace-warnings ...` to show where the warning was created)Die Fehler treten häufig auf (siehe Ausgabe iob diag)
Leider habe ich das erst jetzt bemerkt. Kann also nicht sagen, ob es mit dem letzen admin Adapter Update zusammenhängt.iob diag Ausgabe:
Nach einer halben Stunde googeln habe ich erstmal aufgegeben.
Wie kann ich dem Fehler auf die Spur kommen?Ok, da ich irgendwie weiterkommen wollte und eine Containersicherung habe;-)
habe ich mein Log mal der KI (in meinem Fall deepseek v4) in den Rachen geworfen.Behoben
-
Stündliche "empty object!" Fehler im admin.0 Log: Ursache war eine Race-Condition in
@iobroker/db-objects-redis(objectsInRedisClient.js:3069). DergetObjectView-Lua-Scan iteriert per Redis SCAN-Cursor über Objekt-Keys. Wenn ein Key zwischen SCAN und FETCH per TTL ausläuft, gibt Redisnilzurück →JSON.parse(null)=null→if (!obj)feuertthis.log.error(...).Timing: Session-Timeout (
ttl: 3600= 1h) löste stündlich einen DB-Scan aus → ~22 Fehler-Einträge über ~1 Minute alle 10s. Betroffen waren alle Adapter, die@iobroker/db-objects-redisnutzen (admin.0, node-red.0, javascript.0, rest-api.0).Fix (2 Maßnahmen):
- Log-Level gesenkt:
log.error→log.debugin beiden Build-Varianten (ESM + CJS) vonobjectsInRedisClient.js– die Meldung ist eine harmlose Race-Condition, kein echter Fehler. - TTL erhöht: Admin-Session-Timeout von
3600auf14400(1h → 4h) – reduziert die DB-Scan-Frequenz auf 1/4.
Analyse-Belege: TS-Quellcode (
objectsInRedisClient.ts:3922), kompilierte JS (objectsInRedisClient.js:3056), Admin-Konfiguration (system.adapter.admin.0,native.ttl). Kein upstream-Fix in@iobroker/db-objects-redisv7.2.2 (latest). Keine korrupten Redis-Objekte – die Keys laufen korrekt per TTL ab, der SCAN-Cursor erwischt sie nur vorher. - Log-Level gesenkt:
Die gute Nachricht ist, es ist Ruhe im Log.
Die schlechte, ich weis nicht so recht warum...
Der hat ca. 10min in meinem Container rumgewuselt und ich war schon erstaunt, dass er sich dann automatisch den Quellcode vorgenommen hat.Vlt. kann einer der sich da besser auskennt als ich mal drüberschauen, ob das Sinn ergibt, was deepseek hier gemacht hat, oder ob er nur dafür gesorgt hat, dass die Log-Einträge unterdrückt werden;-)
-
-
Ich kann da nur sagen:
DIREKTE Änderungen im REDIS Code - MUTIG von dir
Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten
Ersell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.
-
Ich kann da nur sagen:
DIREKTE Änderungen im REDIS Code - MUTIG von dir
Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten
Ersell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.
Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten
Da stimme ich voll und ganz zu! Und nicht nur, weil es mit dem nächsten Update sicher wieder weg ist.
Erstell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.
Ich weiß ja, dass KI generierte Issues nicht gern gesehen werden. Und ich selbst kann es nicht wirklich einschätzen, deshalb hoffe ich ja, dass der Beitrag hier im Forum von einem (fachlich versierterem) überflogen wird.
-
Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten
Da stimme ich voll und ganz zu! Und nicht nur, weil es mit dem nächsten Update sicher wieder weg ist.
Erstell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.
Ich weiß ja, dass KI generierte Issues nicht gern gesehen werden. Und ich selbst kann es nicht wirklich einschätzen, deshalb hoffe ich ja, dass der Beitrag hier im Forum von einem (fachlich versierterem) überflogen wird.
Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten
Da stimme ich voll und ganz zu! Und nicht nur, weil es mit dem nächsten Update sicher wieder weg ist.
Erstell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.
Ich weiß ja, dass KI generierte Issues nicht gern gesehen werden. Und ich selbst kann es nicht wirklich einschätzen, deshalb hoffe ich ja, dass der Beitrag hier im Forum von einem (fachlich versierterem) überflogen wird.
Erstell einfach ein Issue mit dem Problem / Logdaten admin Repo. Gib alle relevanten Versionen an.
Und verweis ggF auf eine AI Bwertung hir im Forum.HIER lesen die Core Entwickler nur eingeschränkt mit.
-
Von einer Nachahmung auf produktiven System ist meines Erachtens dringend abzuraten
Da stimme ich voll und ganz zu! Und nicht nur, weil es mit dem nächsten Update sicher wieder weg ist.
Erstell doch ggF ein Issue mit deinen Infos damit sich das ein admin Maintainer ansehen kann.
Ich weiß ja, dass KI generierte Issues nicht gern gesehen werden. Und ich selbst kann es nicht wirklich einschätzen, deshalb hoffe ich ja, dass der Beitrag hier im Forum von einem (fachlich versierterem) überflogen wird.
Erstell einfach ein Issue mit dem Problem / Logdaten admin Repo. Gib alle relevanten Versionen an.
Und verweis ggF auf eine AI Bwertung hir im Forum.HIER lesen die Core Entwickler nur eingeschränkt mit.
-
Ok, da ich irgendwie weiterkommen wollte und eine Containersicherung habe;-)
habe ich mein Log mal der KI (in meinem Fall deepseek v4) in den Rachen geworfen.Behoben
-
Stündliche "empty object!" Fehler im admin.0 Log: Ursache war eine Race-Condition in
@iobroker/db-objects-redis(objectsInRedisClient.js:3069). DergetObjectView-Lua-Scan iteriert per Redis SCAN-Cursor über Objekt-Keys. Wenn ein Key zwischen SCAN und FETCH per TTL ausläuft, gibt Redisnilzurück →JSON.parse(null)=null→if (!obj)feuertthis.log.error(...).Timing: Session-Timeout (
ttl: 3600= 1h) löste stündlich einen DB-Scan aus → ~22 Fehler-Einträge über ~1 Minute alle 10s. Betroffen waren alle Adapter, die@iobroker/db-objects-redisnutzen (admin.0, node-red.0, javascript.0, rest-api.0).Fix (2 Maßnahmen):
- Log-Level gesenkt:
log.error→log.debugin beiden Build-Varianten (ESM + CJS) vonobjectsInRedisClient.js– die Meldung ist eine harmlose Race-Condition, kein echter Fehler. - TTL erhöht: Admin-Session-Timeout von
3600auf14400(1h → 4h) – reduziert die DB-Scan-Frequenz auf 1/4.
Analyse-Belege: TS-Quellcode (
objectsInRedisClient.ts:3922), kompilierte JS (objectsInRedisClient.js:3056), Admin-Konfiguration (system.adapter.admin.0,native.ttl). Kein upstream-Fix in@iobroker/db-objects-redisv7.2.2 (latest). Keine korrupten Redis-Objekte – die Keys laufen korrekt per TTL ab, der SCAN-Cursor erwischt sie nur vorher. - Log-Level gesenkt:
Die gute Nachricht ist, es ist Ruhe im Log.
Die schlechte, ich weis nicht so recht warum...
Der hat ca. 10min in meinem Container rumgewuselt und ich war schon erstaunt, dass er sich dann automatisch den Quellcode vorgenommen hat.Vlt. kann einer der sich da besser auskennt als ich mal drüberschauen, ob das Sinn ergibt, was deepseek hier gemacht hat, oder ob er nur dafür gesorgt hat, dass die Log-Einträge unterdrückt werden;-)
Stündliche "empty object!" Fehler im admin.0 Log
Ganz ehrlich, ich glaube, die KI hat dir da Unsinn erzählt. Die angemeckerten Meldungen kommen von echten defekten Objekten und nicht von irgendwelchen "Race conditions".
Ein Migrieren von Redis zu Jsonl und zurück (via
iob setup custom) entfernt die defekte Objekte. -
-
Stündliche "empty object!" Fehler im admin.0 Log
Ganz ehrlich, ich glaube, die KI hat dir da Unsinn erzählt. Die angemeckerten Meldungen kommen von echten defekten Objekten und nicht von irgendwelchen "Race conditions".
Ein Migrieren von Redis zu Jsonl und zurück (via
iob setup custom) entfernt die defekte Objekte.Ganz ehrlich, ich glaube, die KI hat dir da Unsinn erzählt. Die angemeckerten Meldungen kommen von echten defekten Objekten und nicht von irgendwelchen "Race conditions".
Ein Migrieren von Redis zu Jsonl und zurück (via iob setup custom) entfernt die defekte Objekte.
Ja, da bin ich mir auch fast sicher. Allerdings habe ich keine Möglichkeit gefunden, dahinter zu kommen, um welche Objekte es sich handelt. Allerdings sind die Zyklen schon sonderbar. Ich habe jedenfalls nirgends adapter/flows/scripts gefunden, die einen solchen Zyklus machen.
Die Idee mit der Migration ist Klasse. Wird die Redis db bei der Umstellung zu Jsonl plattgemacht? -
Ganz ehrlich, ich glaube, die KI hat dir da Unsinn erzählt. Die angemeckerten Meldungen kommen von echten defekten Objekten und nicht von irgendwelchen "Race conditions".
Ein Migrieren von Redis zu Jsonl und zurück (via iob setup custom) entfernt die defekte Objekte.
Ja, da bin ich mir auch fast sicher. Allerdings habe ich keine Möglichkeit gefunden, dahinter zu kommen, um welche Objekte es sich handelt. Allerdings sind die Zyklen schon sonderbar. Ich habe jedenfalls nirgends adapter/flows/scripts gefunden, die einen solchen Zyklus machen.
Die Idee mit der Migration ist Klasse. Wird die Redis db bei der Umstellung zu Jsonl plattgemacht?Wird die Redis db bei der Umstellung zu Jsonl plattgemacht?
jep, wenn ich mich recht erinnere, kommt auch eine entsprechende Warnmeldung.
EDIT: also das "Plattmachen" erfolgt beim Zurückspielen in Richtung Redis
Ich hatte mir seinerzeit auch die Zähne daran ausgebissen, herauszufinden, welche Objekte betroffen waren.
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 Anmelden564
Online32.9k
Benutzer83.2k
Themen1.3m
Beiträge