MAX! Heizkörperthermostat "STATE 16.0 °C (rf error)"

Begonnen von mimue, 17 Oktober 2014, 09:31:39

Vorheriges Thema - Nächstes Thema

mimue

Gestern hatte ich diese Meldung bei einem Gerät.

Nach längerem Suchen zum Thema ( die Forum Suchfunktion lieferte nichts, Google schon Forum 15855.0 ) scheint mir, daß der Heizkörperthermostat keine korrekte Rückmeldung von FHEM mehr bekommt.

Das Funksymbol am Gerät blinkt, allerdings funktioniert alles einwandfrei, Befehle werden übermittelt und ausgeführt.

Ich habe das Gerät in den Auslieferungszustand zurückversetzt und neu an FHEM angemeldet, damit war der Effekt weg.

Heute stelle ich das Gleiche bei einem anderen Thermostat fest.

Könnte es sein, daß CUL_MAX unter bestimmten Konstellationen Meldungen nicht mehr richtig quittiert ?

Wie kann ich das eingrenzen ?

mimue

$Id: 10_MAX.pm 6548 2014-09-13 11:56:56Z mgehre $
$Id: 14_CUL_MAX.pm 5282 2014-03-22 10:02:33Z mgehre $
$Id: 00_CUL.pm 6755 2014-10-12 13:12:10Z rudolfkoenig $
MAX! Heizkörperthermostat plus (BC-RT-TRX-CyG-2)
Gigabyte Brix, Arch Linux, CUL_MAX, TCM310, HM-Lan, LevelJET, VIERA, Fritz AHA, Fritz RC, FBDECT, NetIO, Alexa, Netatmo Presence

John

Hallo mimue,

es wäre gut, wenn du Deine Signatur mit der Hardware-Konfiguration aktualisieren würdest, dann wären schon einige Fragen geklärt.

Was mir einfällt zum Thema:

Das Thermostat kann ja mit mehreren Geräten gleichzeitig assoziiert sein. Wenn eines davon nicht mehr erreichbar ist, wird das Funksymbol blinken.
Wenn also der Kommunikationspartner von dieser Assoziation nichts mehr weiss, wird er auf die Anfrage des Thermostats nicht antworten.

Vielleicht versuchst du einen Factory-Reset am Thermostat und assoziierst die Partner neu.

Verwendest du die GroupID oder hast diese in der Vergangenheit verwendet ?
(ich meine diese Funktion ist noch nicht wirklich funktionsfähig und macht eine Menge Probleme).

John

CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

mimue

Danke für die fixe Rückmeldung, John,

Zitat von: John am 17 Oktober 2014, 12:16:35
Das Thermostat kann ja mit mehreren Geräten gleichzeitig assoziiert sein. Wenn eines davon nicht mehr erreichbar ist, wird das Funksymbol blinken.
Wenn also der Kommunikationspartner von dieser Assoziation nichts mehr weiss, wird er auf die Anfrage des Thermostats nicht antworten.

Die Thermostate sind _ausschließlich_ an FHEM als Zentrale angemeldet.

ZitatVielleicht versuchst du einen Factory-Reset am Thermostat und assoziierst die Partner neu.

Das funktioniert zwar, kann aber nicht die Lösung sein. Ich denke FHEM bestätigt einfach Anfragen des HKT+ unter gewissen Voraussetzungen nicht mehr wie erwartet. Das würde ich gerne abstellen.

N.B. Die Funktionalität ist ja in keiner Weise eingeschränkt, lediglich das Blinken des Antennensymbols und die Meldung (rf error) fallen auf.

ZitatVerwendest du die GroupID oder hast diese in der Vergangenheit verwendet ?

Nein

mimue
Gigabyte Brix, Arch Linux, CUL_MAX, TCM310, HM-Lan, LevelJET, VIERA, Fritz AHA, Fritz RC, FBDECT, NetIO, Alexa, Netatmo Presence

John

#3
ZitatDie Funktionalität ist ja in keiner Weise eingeschränkt, lediglich das Blinken des Antennensymbols und die Meldung (rf error) fallen auf.

Vielleicht hast du ein Feldstärke-Problem.
Vergleich den RSSI (Received Signal Strength Indicator) Wert mit den Thermostaten, die keine Probleme machen.
(Je kleiner der Wert, umso schlechter also -85 ist ungünstiger als -65)

Wie ist die Distanz zwischen CUL und Thermostat einzuschätzen ?
Wenn das Thermostat vergeblich versucht seine Werte abzusetzen, wird auch das Antennensymbol erscheinen.

Tritt das auch auf, wenn du den Thermostat in die Nähe vom CUL positionierst ?
Gibt es verdächtige Einträge in der Log-Datei ?

Stell das Reading verbose vom CUL_MAX-Device temporär auf 5 und sieh dir die LOG-Datei an. Dein Thermostat kannst du über die ID erkennen.

John
CubieTruck Docker Node-Red Tasmota Shelly Homematic-IP

mimue

#4
Zitat von: John am 17 Oktober 2014, 16:23:21
Vielleicht hast du ein Feldstärke-Problem.

Wie kann ich ein Feldstärkeproblem haben, wenn das Teil voll funktional ist ? Alle Thermostate laufen seit der letzten Heizperiode, wir reden _nicht_ von einer Neuinstallation.

Wie ich bereits oben erwähnt habe funktioniert alles perfekt, bis auf die (meiner Ansicht nach fehlerhafte) Anzeige (rf error).

ZitatStell das Reading verbose vom CUL_MAX-Device temporär auf 5 und sieh dir die LOG-Datei an.

Das schau ich mir mal an. Danke.

mimue

P.S. Also das hat auch keine tollen Erkenntnisse gebracht. Außer, daß man vor dem Erhöhen auf verbose 5 den FBAHA außer Betrieb nehmen sollte, der läßt die Logdatei so schnell anschwellen, daß der arme Raspberry die Flügel streckt :-(

Jedenfalls habe ich das jetzt pragmatisch mit Rücksetzen auf Werkseinstellung erledigt. Das geht ja Ratz Fatz über den CULMAX0 und beweist einmal mehr, daß der rf error wohl eher eingebildet ist, sonst hätte das wohl kaum funktioniert.

Möglicherweise ist das Teil auch so programmiert, daß der rf error sich nur durch Factory Reset zurückstellen läßt.

Na ja, wie auch immer, für mich hat sich der Fall damit erledigt.
Gigabyte Brix, Arch Linux, CUL_MAX, TCM310, HM-Lan, LevelJET, VIERA, Fritz AHA, Fritz RC, FBDECT, NetIO, Alexa, Netatmo Presence

MAC66666

#5
Ich buddel das Thema mal aus. Habe fast das gleiche Problem, nur dass ein Werksreset nicht half. Ich Empfange alle Daten vom Thermostat, habe aber den RF Error. Daten an das Thermostat senden (zumindest desiredTemperature) geht nicht. RSSI ist -29.5, Abstand ca. 25 cm zum CULMAX ;-) Ist das zu nah vielleicht? Das Thermostat lag ohne Batterien über ein Jahr nur rum.

Edit: Mein Cube hat nun auch ein packetsLost Reading. Ist mir vorher nie aufgefallen, wird wohl davon sein...

RSSI

-29.5

2018-11-06 01:51:02
TimeInformationHour

5

2018-11-06 01:39:30
battery

ok

2018-11-06 01:45:01
batteryState

ok

2018-11-06 01:45:01
desiredTemperature

20.0

2018-11-06 01:45:01
groupid

0

2018-11-06 01:51:01
mode

manual

2018-11-06 01:45:01
msgcnt

1

2018-11-06 01:41:56
state

20.0 °C (rf error)

2018-11-06 01:51:02
temperature

21.4

2018-11-06 01:45:01
valveposition

12

2018-11-06 01:45:01


Nochmal Edit:

Ist jetzt ein paar Meter Weg an einer anderen Heizung, Reset und neu angelernt, gleiche Symptome. Nur habe ich jetzt mehr Readings, so z. B. auch das Wochenprogramm. Wenn ich desiredTemperature sende, geht nicht. Am Gerät ändern wird nicht an FHEM gesendet....
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

MAC66666

Seit dem Pairing haben sich auch keine Readings mehr verändert...
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

Jackson

Den rf error kenne ich auch. Allerdings der Thermostate empfängt aber weiterhin die Befehle in beiden Richtungen.

Ich nutze aber den org. MAX!Cube.

Bzgl. den Readings..

Wann hast du das letzte mal FHEM bzw. den Server neu gestartet? Letzte Woche haben sich bei mir die Readings auch nicht mehr aktualisiert. Die Kommunikation der Thermostate untereinander, also auch zum Wandthermostaten funktionierte aber.

Nach einem Neutstart vom Server und dem Cube lief es dann wieder.





FHEM5.9@RPI3

MAC66666

Da gerade mein Raspi den Geist aufgegeben hatte und ich mit FHEM umgezogen bin, starte ich gerade noch relativ oft neu. Daran liegt es leider nicht, aber danke für die Idee.

Andererseits hat es sicher einen (bereits vergessenen) Grund, warum ich diesen (stark vergilbten) Max Thermostat in meiner Wühlkiste gefunden habe  ;D 8 weitere Thermostate funktionieren problemlos. Ich gehe einfach mal davon aus, er ist defekt.

Hab ihn jetzt erst mal im Flur, wo ich nicht wirklich eine Verbindung zu FHEM brauche, da dort eh immer die gleiche Temp gehalten wird. Und wenn da einer dran kurbelt, fällt das gleich auf an der Eingangstür...

Sollte doch noch jemand eine Eingebung haben, gerne !

FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

MAC66666

Hmpf, weieres Thermostat hat Rrf error... diesmal empfängt fhem aber noch regelmäßig, kann nur nichts hin senden. Ebenfalls ein Thermostat, welches länger nicht in Gebrauch war...
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota