NEWS
Nochmal FritzDECT 2.6.1 und 2.6.2 mit merkwürdigem Verhalten
-
Ein neuer Thread, weil es sich weder um die Bereichsüberschreitung noch um die in meinem anderen Post genannten Warnungen handelt. Beide Warnungen sind aus den Logs verschwunden, soweit ok.
Nun allerdings einige andere merkwürdige Verhalten des Adapters, die ich mir nicht erklären kann. Vielleicht hat Jemand eine Idee.
Nach dem Update von 2.6.1 auf 2.6.2 und dem Löschen der beiden DP wie von von
@michael-schmitt https://forum.iobroker.net/uid/37644 beschrieben, waren die Warnungen weg und das Problem schien gelöst.Dann musste ich allerdings feststellen, dass der DP für den Monatsertrag plötzlich falsch war.

Nach Downgrade auf 2.6.1 war der Wert wieder richtig (Diagramm)

Interessant allerdings, dass zwischenzeitlich der Wert immer weiter abgenommen, statt zugenommen hat.Also wieder zurück auf 2.6.1 - die beiden DP "datatimed" und "datatimem" allerdings nicht gelöscht.
Sofort wurde der Wert wieder korrekt angezeigt. Also habe ich es bei dieser Version 2.6.1 belassen.Heute morgen nun wieder falsche Werte, die nicht nachvollziehbar sind. Nachts springt der Monatsertrag spontan von 37759 auf 34274.

Reboot der DECT Dose und des FritzDECT-Adapter änderten an dem falschen Wert nichts.
Direkt in der DECT200 ist der Wert jedoch korrekt.

Ich habe dann die beiden DP "datatimed" und "datatimem", welche wohl noch von der 2.6.2 übrig waren wieder gelöscht (Adapter stopp, löschen, Adapter start).
Nun stimmen die Werte wieder und es gibt auch bislang keine Warnungen im Log.
Inzwischen zweifele ich schon an mir selbst.
Normalerweise müsste ja die Version 2.6.1 wieder Warnungen im Log erzeugen. Möglich also, dass noch weitere DP von der 2.6.2 in der jetzt wieder laufenden 2.6.1 vorhanden sind.Ich erwarte jetzt keine sofortige Reaktion auf das Problem. Ich will das auch erst weiter beobachten, wollte das aber schon mal zur Diskussion stellen. Und vermutlich müsst ihr Euch auch erst in dieses für mich verzwickte Problem reindenken.
Erstmal aber schönen Sonntag.
-
Ich wärme das Thema nochmals auf.
Auf Grund der o.g. Probleme war ich im Sommer 2025 beim Adapter fritzdect v 2.6.1 geblieben. Er lief bis dato auch völlig problemlos; auch mit dem neu hinzu gekommenen AVM Energy250 für den Stromzähler.
Nach dem Update der Fritz-FW auf 8.20, welche nun auch die Einspeisewerte liefert, hatte ich das Update des fritzdect-Adapters auf die aktuelle Version 2.6.2 vorgenommen.
Doch die Probleme begannen von Neuem. Wieder stimmten die Werte nicht. Gleicher Fehler wie im Ausgangspost beschrieben. Es wurden falsche Verbrauchswerte geliefert. Zurück auf 2.6.1 - wieder alles ok.
Das Problem besteht also weiterhin und ein System hinter den falschen Werten konnte ich nicht entdecken.Für ein anderes Problem habe ich allerdings den Grund gefunden:
In die DP "datatimed" und "datatimem" wird das aktuelle Datum / der Zeitstempel geschrieben.
Aktuell gerade also:
Mon Feb 16 2026 02:05:04 GMT+0100 (Mitteleuropäische Normalzeit). Als Unix-Zeit: 1771241985Intern liegt dieser Wert aber als Wert in Millisekunden vor. So erscheint er dann auch, wenn es zur Meldung kommt, dass der Wert der DP größer als "2147483647" ist (bekannte UNIX-Datumsgrenze 2038).
Um den Fehler zu beheben funktionieren zwei work around:
-
Objekt bearbeiten: fritzdect.0.DECT_116300179317.energy_stats.datatimed,
dort den Wert für max. löschen -
oder an den Wert "2147483647" 3 Nullen dranhängen, also 2147483647000
Dieses Problem betrifft alle DECT Geräte (Steckdosen, Energy 250)
Letzteres Problem lässt sich im Zuge eines Adapter Updates sicher leicht lösen, da der Wert für 2038 sicher als default hard codiert ist.
Für die falschen Verbrauchswerte habe ich keine Lösung; die falschen Werte stehe auch in keinem mathematischen Verhältnis zu den korrekten Werten.
-
-
Ich wärme das Thema nochmals auf.
Auf Grund der o.g. Probleme war ich im Sommer 2025 beim Adapter fritzdect v 2.6.1 geblieben. Er lief bis dato auch völlig problemlos; auch mit dem neu hinzu gekommenen AVM Energy250 für den Stromzähler.
Nach dem Update der Fritz-FW auf 8.20, welche nun auch die Einspeisewerte liefert, hatte ich das Update des fritzdect-Adapters auf die aktuelle Version 2.6.2 vorgenommen.
Doch die Probleme begannen von Neuem. Wieder stimmten die Werte nicht. Gleicher Fehler wie im Ausgangspost beschrieben. Es wurden falsche Verbrauchswerte geliefert. Zurück auf 2.6.1 - wieder alles ok.
Das Problem besteht also weiterhin und ein System hinter den falschen Werten konnte ich nicht entdecken.Für ein anderes Problem habe ich allerdings den Grund gefunden:
In die DP "datatimed" und "datatimem" wird das aktuelle Datum / der Zeitstempel geschrieben.
Aktuell gerade also:
Mon Feb 16 2026 02:05:04 GMT+0100 (Mitteleuropäische Normalzeit). Als Unix-Zeit: 1771241985Intern liegt dieser Wert aber als Wert in Millisekunden vor. So erscheint er dann auch, wenn es zur Meldung kommt, dass der Wert der DP größer als "2147483647" ist (bekannte UNIX-Datumsgrenze 2038).
Um den Fehler zu beheben funktionieren zwei work around:
-
Objekt bearbeiten: fritzdect.0.DECT_116300179317.energy_stats.datatimed,
dort den Wert für max. löschen -
oder an den Wert "2147483647" 3 Nullen dranhängen, also 2147483647000
Dieses Problem betrifft alle DECT Geräte (Steckdosen, Energy 250)
Letzteres Problem lässt sich im Zuge eines Adapter Updates sicher leicht lösen, da der Wert für 2038 sicher als default hard codiert ist.
Für die falschen Verbrauchswerte habe ich keine Lösung; die falschen Werte stehe auch in keinem mathematischen Verhältnis zu den korrekten Werten.
@Rico-Sander sagte in Nochmal FritzDECT 2.6.1 und 2.6.2 mit merkwürdigem Verhalten:
Für ein anderes Problem habe ich allerdings den Grund gefunden:
In die DP "datatimed" und "datatimem" wird das aktuelle Datum / der Zeitstempel geschrieben.
Aktuell gerade also:
Mon Feb 16 2026 02:05:04 GMT+0100 (Mitteleuropäische Normalzeit). Als Unix-Zeit: 1771241985Intern liegt dieser Wert aber als Wert in Millisekunden vor. So erscheint er dann auch, wenn es zur Meldung kommt, dass der Wert der DP größer als "2147483647" ist (bekannte UNIX-Datumsgrenze 2038).
Um den Fehler zu beheben funktionieren zwei work around:
-
Objekt bearbeiten: fritzdect.0.DECT_116300179317.energy_stats.datatimed,
dort den Wert für max. löschen -
oder an den Wert "2147483647" 3 Nullen dranhängen, also 2147483647000
Dieses Problem betrifft alle DECT Geräte (Steckdosen, Energy 250)
Letzteres Problem lässt sich im Zuge eines Adapter Updates sicher leicht lösen, da der Wert für 2038 sicher als default hard codiert ist.
Für die falschen Verbrauchswerte habe ich keine Lösung; die falschen Werte stehe auch in keinem mathematischen Verhältnis zu den korrekten Werten.
Falls esw ein dazu passendes Issue beim Adapter gibt, häng die Info bitte an. Wenn nicht leg bitte ein Issue im Adapter Repository an. HIER geht die Info ziemlich sicher unter.
-
-
Dieser Issue sollte passen: https://github.com/foxthefox/ioBroker.fritzdect/issues/676