Probleme beim Zusammenspiel Heizkörperthermostat / Wanthermostat

[MiK77]

Hallo,

vor zwei Tagen habe ich ein Wandthermostat auf Werkseinstellungen zurückgesetzt und danach wieder neu gepairt und mit dem Heizkörperthermostat gepeert.  Seitdem habe ich folgendes Problem:

Immer wenn ein Ereignes in FHEM die desiredTemperature des Heizkörperthermostats umstellt, wird sie 1-3 Minuten später wieder zurück gestellt.

Ich habe nun schon viel versucht. Habe auch schon beide Geräte aus FHEM entfernt und auf Werkseinstellungen zurückgesetzt. Danach wieder alles neu eingerichtet. Es hat nichts geholfen. Solange die beiden nicht gepeert sind tritt das Problem aber nicht auf.

Mache ich irgendetwas grundsätzlich falsch? Muss man bei Peering eine bstimmte Reihenfolge oder anderen zeitlichen Zusammenhang beachten? Gab es vor kurzem irgendeine Änderung in dieser Beziehung?

Viele Grüße

MiK

PS.: Der ursprüngliche Grund für das Zurücksetzen auf Werkseinstellungen war ein mir unbekannter Peer und die Tatsache dass das Deassociate nicht funktioniert hat.

[Wzut]

IMHO , works as designed ... nicht von mir sondern von E3Q.
Sobald ein HT mit einem WT gepeered ist übernimt das WT komplett das Kommando. Das HT agiert nur noch selbstständig wenn es eine Zeit X nichts von seinem Chef hört.
D.h. für dich : Änderungen via FHEM sollten immer das Ziel WT haben und nicht das nun "dumme" HT.

[MiK77]

So etwas habe ich mir schon gedacht. Dagegen sprach, dass es wochenlang auf diese Weise funktioniert hatte. Aber vielleicht lag das an dem seltsamen zusätzlichen fremden Peer im WT. Dann werde ich wohl mal umbauen. Danke!

[MiK77]

Dies funktioniert nun besser, aber ich habe immer noch mein vorheriges Problem:

Das Thermostat schaltet immer mal wieder unmotiviert auf die WindowOpenTemperature. Es ist aber kein Fensterkontakt verbunden und es wurde auch kein Fenster geöffnet.

[Wzut]

Vermutung : wenn es auf die WO Temp geht blinkt auch das Antennen Symbol ?
Wenn ja :  Damit zeigen die Dinger an das ihr Chef nicht oder zuwenig mit ihnen spricht.

Um es genau festzustellen bleibt dir nur verbose 5 am CUL_MAX Device zu setzen und solange zu loggen bis das Ereigniss eintritt,
dann das Log durchgehen und schauen was die beiden miteinander reden. Wenn das ganze relativ lange dauert kannst du auch zusätzlich mit einem notify auf den rferror triggern und loggen, dann hast du schon mal die grobe Zeitrichtung fürs FHEM Log.

[MiK77]

Danke, werde ich machen. Wahrscheinlich tritt es dann nicht mehr ein...

[MiK77]

Zugebenermaßen habe ich vorher mit dem rfmode des CUL rumgespielt. Aber vielleicht ist es ja trotzdem interessant, was bei mir zu einer desiredTemperature von 0° geführt hat:

Code Auswählen Erweitern

2020.10.20 22:37:16 5: cm, IODev CUL_0, len 11, msgcnt 97, msgflag 00, msgType Ack, src 123456, dst 108141, group 0, payload 00, rssi -74
2020.10.20 22:37:16 4: cm, packet from ourselves or a other CUL [123456 / 0], - ignoring !
2020.10.20 22:37:16 5: cm, IODev CUL_0, len 11, msgcnt 97, msgflag 06, msgType ShutterContactState, src 108141, dst 123456, group 0, payload 10, rssi -64.5
2020.10.20 22:37:16 5: cm: dispatch MAX,1,ShutterContactState,108141,10
2020.10.20 22:37:16 5: MAX_Parse, MAX,1,ShutterContactState,108141,10
2020.10.20 22:37:16 5: Wohnungstuer, bat 0, rferror 0, isopen 0, unkbits 0
2020.10.20 22:37:16 5: cm, IODev CUL_0, len 29, msgcnt 75, msgflag 04, msgType WallThermostatControl, src 10b017, dst 106cc2, group 0, payload 22E13184750202106CC210B01700011800222D, rssi -135
2020.10.20 22:37:16 5: cm: dispatch MAX,0,WallThermostatControl,10b017,22E13184750202106CC210B01700011800222D
2020.10.20 22:37:16 5: MAX_Parse, MAX,0,WallThermostatControl,10b017,22E13184750202106CC210B01700011800222D
2020.10.20 22:37:16 2: MAX_Parse, invalid WallThermostatControl packet for addr 10b017 , args > 14 ?
2020.10.20 22:37:16 1: PERL WARNING: Use of uninitialized value $desiredTemperatureRaw in bitwise and (&) at ./FHEM/10_MAX.pm line 1686.
2020.10.20 22:37:16 5: Thermostat_WZ, desiredTemperature 0

[Wzut]

Ein rssi von -135 ist auch extrem, ein Wunder das der CUL da überhaupt noch was gesehen hat.
Offensichtlich ein zerstörtes Telegramm, das 10_MAX sollte aber bei der > 14 Meldung einfach abbrechen.
Da man sowas nicht simulieren kann habe ich damals zur Vorsicht das Fragezeichen angehängt.
Das kann ich nun entfernen und den Abbruch dahinter setzen. Danke für die Info.

[MiK77]

Ja, war eine Ausnahmesituation. Aber kaputte Telegramme kann es ja immer mal geben. Gut, dass Du das jetzt abfangen kannst. Danke!