MAX! Wandthermostat rferror nach associate mit MAX Heizkörperthermostat

[sqs-it]

Hallo,

kurze Frage, ich habe in einem Raum drei MAX Heizkörper Thermostate und ein MAX Wandthermostat. Alles wie MAX Cube an fhem angebunden.
Einzeln funktioniert soweit alles ganz vernünftig.
Sobald ich jedoch ein "set associate Wandthermostat Heizkoerperthermostat1" mache, wechselt der status des Wandthermostates auf rferror. Die neuen Sollwerte werden trotzdem problemlos an das Heizkörperthermostat gesendet. Ist hierzu was bekannt?

Factory Reset aller beteiligten Komponenten und deassociate inkl. neuem associate hat keine Abhilfe geschaffen.

[Matthias Gehre]

Der rferror entsteht, da das Wandthermostat vergeblich auf eine Antwort (ein Ack) vom Heizkörperthermostat wartet.
Es fehlt noch ein
set associate Heizkoerperthermostat1 Wandthermostat

[sqs-it]

Guten Morgen,

ich habe die letzten Tage einiges ausprobiert.

Zunächst mal einen factory reset aller Komponenten (jeweils Hardwareseitig via reset-Knopf/Kombination)
Dannach wie vorgeschlagen die "set associate" befehle in beide Richtungen:
 a) "set associate Wandthermostat Heizkoerperthermostat1" b) "set associate Heizkoerperthermostat1 Wandthermostat"
Zustand jetzt ist, dass das Heizkörperthermostat den im Wandthermostat eingestellten Wert übernimmt. Auch scheint die Funktion in die andere Richtung soweit zu funktionieren, da am Heizkörperthermostat die Batterie schwach wurde und dies am Wandthermostat angezeigt wurde. Nach erneuern der Batterien am Heizkörperthermosatat war das icon am Wandthermostat verschwunden.
Der eigentlichen Fehler, nämliche die rf-error Meldung in fhem bzw. das blinkende Antennen icon am Wandthermostat(und auch wirklich nur da) ist jedoch weiterhin vorhanden.
Dennoch funktioniert der Datenaustausch zwischen Wandthermostat und Heizkörperthermostat sowie zwischen Wandthermostat und fhem via MaxCube wie gewünscht.

Hat noch jemand einen Tipp oder soll ich das, da es ja zu funktionieren scheint einfach ignorieren?

Besten Dank!

[stgeran]

Das Problem besteht auch wenn NUR ein CUL und ein Max Heizkörperthermostat vorhanden sind.
2013-09-18_12:00:42 Hzg_Buero mode: manual
2013-09-18_12:00:42 Hzg_Buero battery: ok
2013-09-18_12:00:42 Hzg_Buero desiredTemperature: 22.0
2013-09-18_12:00:42 Hzg_Buero temperature: 21.6
2013-09-18_12:00:42 Hzg_Buero valveposition: 77
2013-09-18_12:00:42 Hzg_Buero 22.0 °C (rf error)
2013-09-18_14:47:22 Hzg_Buero mode: manual
2013-09-18_14:47:22 Hzg_Buero battery: ok
2013-09-18_14:47:22 Hzg_Buero desiredTemperature: 22.0
2013-09-18_14:47:22 Hzg_Buero 22.0 °C (rf error)
Dabei blinkt das Funksymbol am Thermostat.

Es ist wie in der Fernsehwerkstatt: DerKunde sagt, gestern ging es noch.

[sqs-it]

Es wird immer seltsamer. Nun ist mir aufgefallen, dass alle Heizkörperthermostate in unserem Haus den Wert übernehmen, den ich an dem mit dem, dem Wandthermostat "bidirektional associatetem" Heizkörpertheromstat einstelle.

Bisher hatte ich Sollwerte im Wohnzimmer über das Wandthermostat (das mit dem rf-error) gestellt. Dies wurde dann auch an das Heizkörperthermostat weitergegeben, genau wie gewünscht. Alle anderen Heizkörperthermostate blieben davon unberührt. Wenn ich jedoch direkt an dem Heizkörper im Wohnzimmer etwas ändere betrifft das alle Heizkörperthermostate obwohl diese niemals miteinander associated wurden oder ähnliches...

Ist zwar nicht so dramatisch da ich die Bedienung für das Wohnzimmer dann einfach ausschließlich über das Wandthermostat machen würde, aber komisch finde ich die Sache dennoch.

[Matthias Gehre]

Das Zusammenspiel aus associate und groupId scheint noch nicht ganz geklärt. Wäre schön, wenn man im Wiki alle dazu
gefundenen Informationen zusammentragen könnte.

[sqs-it]

Habe jetzt parallel alle Thermostate mit der mitgelieferten Software eingerichtet. zwar ist der rf-error noch immer vorhanden aber es scheint alles wie gewünscht zu funktionieren.
Rein zur info: die groudid die vorher bei jedem thermostat 0 war ist nun für jeden Raum eine eigene.

[watz]

Hallo,

mit dem MAX!Wandthermostat hatte ich leider ebenfalls einige Probleme. Inzwischen scheint es aber zu funktionieren. Da ja nicht nur ich Probleme hatte, habe ich meine Beobachtungen niedergeschrieben, in der Hoffnung es möge Anderen helfen.


Was bei mir den rf_error im WT beseitigt hat:
----------------------------------------------

Ausgangssituation: Das Thermostat, an welches das Wandthermostat angelernt werden soll, hat "groupid 1". Das ganze MAX! System wird über einen MAX!Cube gesteuert

1. MAX!Cube in pairingmodus versetzt (_DEVNAME_MAXCUBE_ ist dabei der devicename meines MAX!Cube)
   set _DEVNAME_MAXCUBE_ pairmode
   
2. Das Wandthermostat durch gedrückt halten der Boot-Taste ebenfalls in pairmode gesetzt

3. FHEM erkennt nun das "neue Gerät" und gibt ihm einen Namen (_DEVNAME_WANDTHERMOSTATE_)

4. Dem neuen Gerät habe ich nun händisch die gleiche groupid wie dem Thermostat gegeben:
   attr _DEVNAME_WANDTHERMOSTATE_ groupid 1
   (Es dauert einige Zeit bis diese Änderung wirklich im FHEM sichtbar ist)
   
5. Nun habe ich das Wandthermostat und das Thermostat per associate miteinander überkreuz befreundet
   (folgendes mit angepassten devicenamen oben in der FHEM-Kommandozeile eingeben)
   set _DEVNAME_WANDTHERMOSTATE_ associate _DEVNAME_THERMOSTATE_
   set _DEVNAME_THERMOSTATE_ associate _DEVNAME_WANDTHERMOSTATE_
   
Ab nun gab es bei mir keine rf_error mehr im Wandthermostat. Das Funksymbol hört auch auf panisch zu blinken. Ändere ich nun am Thermostat oder am Wandthermostat die Themeraturvorgabe oder den Modus so wird dies quasi sofort (maximal ein bis zwei Sekunden Verzögerung) auch auf dem jeweils anderen Gerät angezeigt.

Soweit ist das also alles wunderbar!

Anmerkung:
Vielleicht wäre es ein gute Idee dieses Befreunden von der Bedienung her zu erleichtern? Mein Vorschlag wäre: Man befreundet über die FHEM-Oberfläche vom Thermostat aus "in der Detailansicht" per Knopfdruck (set _DEVICENAME_ associate _DEVICENAME_ ) mit dem Wandthermostat. Dabei sollte FHEM so klug sein gleich beide "set ... associate ... " zu senden und beim Wandthermostat auch gleich die korrekte groupid setzen.



Eine Merkwürdigkeit gibt es aber noch:
-----------------------------------------
Sende ich über FHEM eine neue Wunschtemperatur an das Wandthermostat, so wird diese quasi direkt vom Wandthermostat empfangen und angezeigt. Die Temperatur am Thermostat ändert sich dabei auch instantan mit. Was ja auch gewünscht ist.

ABER: Wenn ich über FHEM eine neue Wunschtemperatur an das Thermostat schicke, so kommt diese dort sofort an. Auf dem Wandthermostat erst gut eine Minute später. Genau hier scheint es also noch Optimierungsmöglichkeiten zu geben.

Muss FHEM hier vielleicht zusätzlich ein Signal an das Wandthermostat schicken? Oder das Signal direkt ans Wandthermostat "umleiten" falls in der Gruppe eins vorhanden ist?

Eigentlich ist dieses Verhalten ja sehr verwunderlich, denn sind zwei Thermostate über die gleiche groupid verbunden (da sich beide im gleichen Raum befinden), so ist es meines Wissens ja  ausreichend über die FHEM-Oberfläche nur einem die neue Wunschtemperatur mitzuteilen und schups ist sie auch auf dem zweiten entsprechend geändert.


Viele Grüße!

[watz]

Kann die oben beschriebene Merkwürdigkeit vielleicht irgendwie damit zusammen hängen, dass das Thermostat zwar

Internals -> groupid 1

aber

Readings -> groupid 0

hat?

Verwirrte Grüße!

[Matthias Gehre]

Hey,

1. Nur die groupid in Readings ist wichtig. Die groupid in Internals ist falsch, und sollte nach dem nächsten Update nicht mehr gesetzt werden.

2. attr _DEVNAME_WANDTHERMOSTATE_ groupid 1 wird nicht funktionieren. Um die groupid zu setzen ist
set _DEVNAME_WANDTHERMOSTATE_ groupid 1 erforderlich. Danach kontrollieren, ob es in den Readings geändert wurde.

Viele Grüße
Matthias

[watz]

Hallo Matthias,

danke für die Rückmeldung. Bei  attr_ und set_ hatte ich mich im Breitrag leider verschrieben. (Peinlich!)

Der Punkt ist: Sobald alle Fensterkontakte, Thermostate und Wandthermostate (die in einem Raum sind) in der identischen Gruppe sind, funktioniert die Kommunikation korrekt. Sehr schön soweit!


---


Die Falle, in die FHEM-Einsteiger (oder Umsteiger) mit einem bereits im Einsatz befindlichen Cube tappen können ist:

Autocreate liest zwar (Teile) der Infos aus dem MAX!Cube aus, aber schreibt nicht die dort (über die ELV-Software) definierten groupid Angaben in fhem.cfg
-> Damit sind dann alle per autocreate angelegten Geräte in der Default groupid 0. Was halt nicht korrekt ist.


Unabhängig davon scheint noch ein zweites Problem zu bestehen:

Setzt man per "set MAX_12345 weekProfile ..." einen neuen Wochenplan, so wandert der derzeit nicht auf das Wandthermostat, obwohl Thermostat und Wandthermostat die selbe groupid haben.


Ich würde gerne konkrete Patches für beides anbieten, war mir aber nicht sicher wo man das idealerweise im Code ändern sollte.

Grüße

[Matthias Gehre]

Das Autocreate Problem habe ich vor ein paar Tagen behoben (hoffentlich), als dir aufgefallen ist, dass eine groupid in INTERNALS steht.
Das zweite Problem mit dem Wandthermostat könnte mit http://forum.fhem.de/index.php/topic,15567.0.html zusammenhängen.

[watz]

> Das Autocreate Problem habe ich vor ein paar Tagen behoben (hoffentlich), als dir aufgefallen ist, dass eine groupid in INTERNALS steht.
danke!

>Das zweite Problem mit dem Wandthermostat könnte mit http://forum.fhem.de/index.php/topic,15567.0.html zusammenhängen.
hm... scheint zumindest nicht die einzige Ursache zu sein: Bei mir sind die "unknownBytes" nicht vorhanden ( $unknownBytes eq "").

Das Problem, dass die beim Thermostat per set weekProfile gesetzten Wochenpläne nicht zum Wandthermostat wandern bleibt bei mir derzeit bestehen.

Viele Grüße!