Vorrang TempList Wandthermostat und TempList HM-CC-RT-DN

Posti123 · 15 Oktober 2015, 15:37:33

Hallo,

eine kurze Verständnisfrage:

ich habe einen HM-CC-RT-DN 1 Jahr im Betrieb gehabt. Dieser hat eine eigene TempList. Jetzt kürzlich ist noch ein Wandthermostat hinzugekommen.
Das Wandthermostat hat nun auch eine eigene andere TempList von mir bekommen. Welche TempList hat nun vorrang? Beide? Automatisch die vom Wandthermostat?

Muss ich beiden Geräten die gleiche TempList schicken?

VG

rapster · 15 Oktober 2015, 16:25:25

der RT führt seine Templist auf 'Auto' bei den gesetzten Schaltzeitpunkten wie Eingestellt aus, allerdings wird die desired-temp bei der nächsten Kommunikation mit dem WT (wenn gepeert) direkt mit der Templist des TC überschrieben.
Wenn der RT auf 'Manu' ist und das TC auf 'Auto' wird nur die Templist des TC verwendet.

Gruß
Claudiu

slaecker · 22 November 2015, 16:38:10

Hi,

ich habe auch nachträglich einen Wandthermostat (HM-TC-IT-WM-W-EU) mit einem HM-CC-RT-DN gepeered. Nun habe ich festgestellt, dass sich der HM-CC-RT-DN anders verhält als der Wandthermostat.

Ich sende abends per NFC-Tag am Bett per andFhem Android App zwei Befehle zum Wandthermostat.
1. Schalte auf controlmode manu
2. Stelle auf 18°C
Damit halte ich 18°C bis ich morgens ausgeschlafen habe und den NFC-Tag nochmal scanne, dann wird dem Wandthermostat mitgeteilt er möge bitte wieder auf controlmode Auto stellen um die Temperaturlisten zu nutzen.

Ich sehe am Wandthermostat, dass die Befehle korrekt ankommen (Wechsel von Auto auf Manu und von 22 auf 18°C). Der HM-CC-RT-DN steht auf Manu. Trotzdem schaltet sich morgens um 10:00 Uhr der HM-CC-RT-DN auf Auto 23 °C (was seiner ursprünglichen Temperaturliste vor der Anschaffung des Wandthermostats entspricht). Generell übernimmt der HM-CC-RT-DN aber einwandfrei die Einstellungen des Wandthermostats (Manu -> Auto, Temperatur etc.).

Kann mir jemand sagen was ich nun wo einstellen muss, damit der HM-CC-RT-DN auch nur so läuft wie es der Wandthermostat sagt? Ich bin etwas verwirrt und finde auch nach längerer Recherche den Knackpunkt selbst leider nicht

frank · 22 November 2015, 17:14:27

sind beide auf aktueller fw?

martinp876 · 22 November 2015, 17:29:51

Ich würde mich hier an das von eQ3 angestrebte Verhalten anlehnen. Es gilt hier wie überall, dass "teams" (hier TC und RT) nur notwendige Daten austauschen. Das austauschen von templisten ist NICHT notwendig. Die Zentrale ist intelligent, kennt peergroups und sendet notwendige Infos immer an alle (also TC UND RT).
Ich habe das nicht überall probiert - hält man sich an die Regel, funktioniert es aber sehr gut.

Um das Verhalten in FHEM zu erhalten sollte man (würde ich eh immer) mit tempListTemplate arbeiten.
Erstelle ein template und weise es beiden zu

Code Auswählen

attr <rt_Clima> tempListTmpl WohnzimmerprofilWinter
attr <tc_Climate> tempListTmpl WohnzimmerprofilWinter

dann ein

Code Auswählen

set hm tempList verify
set hm tempList restore

mit restore werden alle Änderungen übertragen - wenn keine notwendig sind eben nicht. Es wird - wie immer - nicht sofort übertragen - das kommt wenn das Device aufwacht (tc sofort, rt beim Aufwachen).
Der Erfolg wird durch ein getConfig zurückgelesen. hat man in den beiden Devices

Code Auswählen

attr <rt> autoReadReg 5_readMissing
attr <tc> autoReadReg 5_readMissing

stellt man alles auf Automatic hat man nach dem "restore" nach 10 min ein "verify" machen. Übrigens werden die templisten auch bei einem hm configCheck geprüft.

slaecker · 22 November 2015, 17:51:42

Hi und danke schonmal für die Antworten bisher.

Zitat von: frank am 22 November 2015, 17:14:27
sind beide auf aktueller fw?

HM-TC-IT-WM-W-EU hat FW 1.2
HM-CC-RT-DN hat FW 1.3

Firmware-Update kann ich ggf. wohl über das HMLan nicht machen, wenn ich das richtig gelesen habe, da ich dafür das HMUSB brauche.

Zitat von: martinp876 am 22 November 2015, 17:29:51
Ich würde mich hier an das von eQ3 angestrebte Verhalten anlehnen. Es gilt hier wie überall, dass "teams" (hier TC und RT) nur notwendige Daten austauschen. Das austauschen von templisten ist NICHT notwendig. Die Zentrale ist intelligent, kennt peergroups und sendet notwendige Infos immer an alle (also TC UND RT).
Ich habe das nicht überall probiert - hält man sich an die Regel, funktioniert es aber sehr gut.

Um das Verhalten in FHEM zu erhalten sollte man (würde ich eh immer) mit tempListTemplate arbeiten.
Erstelle ein template und weise es beiden zu
Code Auswählen Erweitern
attr <rt_Clima> tempListTmpl WohnzimmerprofilWinter attr <tc_Climate> tempListTmpl WohnzimmerprofilWinter

dann ein
Code Auswählen Erweitern
set hm tempList verify set hm tempList restore

mit restore werden alle Änderungen übertragen - wenn keine notwendig sind eben nicht. Es wird - wie immer - nicht sofort übertragen - das kommt wenn das Device aufwacht (tc sofort, rt beim Aufwachen).
Der Erfolg wird durch ein getConfig zurückgelesen. hat man in den beiden Devices
Code Auswählen Erweitern
attr <rt> autoReadReg 5_readMissing attr <tc> autoReadReg 5_readMissing

stellt man alles auf Automatic hat man nach dem "restore" nach 10 min ein "verify" machen. Übrigens werden die templisten auch bei einem hm configCheck geprüft.

Temperaturlisten nutze ich bereits für die TC, für die RT nicht. Ein Verify zeigt folgendes:

Code Auswählen

fail  : ././FHEM/tempListTemplates.cfg:SZ.Heizung_Clima for SZ.Heizung_Clima: SZ.Heizung_Clima not found in file ././FHEM/tempListTemplates.cfg 
fail  : ././FHEM/tempListTemplates.cfg:WZ.Heizung_Clima for WZ.Heizung_Clima: WZ.Heizung_Clima not found in file ././FHEM/tempListTemplates.cfg 
passed: FHEM/tempListTemplates.cfg:Kinderzimmer for KiZ.Heizung_Clima 
passed: FHEM/tempListTemplates.cfg:Schlafzimmer for SZ.Thermostat_Climate 
passed: FHEM/tempListTemplates.cfg:Wohnzimmer for WZ.Thermostat_Climate

XX.Heizung... = RT
XX.Thermostat... = TC
TC sind nur in SZ und WZ vorhanden.

Ich kann in meinen Temperaturlisten gerne noch die RT ergänzen, auch wenn sich mir der Sinn nicht ganz erschließt, da der TC ja die Kontrolle haben sollte.

Auch verstehe ich trotzdem nicht, warum der RT automatisch von Manu auf Auto wechselt, wenn sowohl TC als auch RT am Abend zuvor noch beide auf Manu 18°C standen. Danke für weitere Antworten.

Gruß,
slaecker

frank · 22 November 2015, 18:04:13

ZitatFirmware-Update kann ich ggf. wohl über das HMLan nicht machen, wenn ich das richtig gelesen habe, da ich dafür das HMUSB brauche.

entweder HMUSB oder cul.

slaecker · 22 November 2015, 18:34:39

In Ergänzung zu meinem vorherigen Beitrag habe ich einen configCheck durchgeführt, verstehe aber den Output nicht.

Code Auswählen

configCheck done: 

 missing register list 
    SZ.Thermostat_SwitchTr:	RegL_01: 
    SZ.Thermostat_WindowRec:	RegL_03:SZ.Fenster1r_chn:01,RegL_01:,RegL_07:SZ.Fenster1r_chn:01 
    SZ.Thermostat_remote:	RegL_01:

Die Kanäle SwitchTr und remote nutze ich gar nicht.
WindowRec funktioniert soweit. Was bedeutet die Meldung?

Code Auswählen

peer not verified. Check that peer is set on both sides 
    SZ.Heizung_ClimaTeam p:SZ.Thermostat_Climate 
    SZ.Heizung_ClimaTeam pID:35EA3C02

 peering strange - likely not suitable 
    SZ.Heizung_ClimaTeam pID: Model HM-TC-IT-WM-W-EU should be HM-CC-RT-DN ClimatTeam Channel

Den Kanal _ClimaTeam habe ich gar nicht gepeered. Wie kam es denn hier zum Peering? Ich habe nur _Climate am RT mit _Climate am TC gepeered. Wie kann ich das Peering wieder entfernen ohne evtl. negative Auswirkungen?

Code Auswählen

set SZ.Thermostat_Climate peerChan 0 SZ.Heizung_ClimaTeam single unset und anschließendes drücken der Anlerntasten an beiden Geräten brachte nichts. Der Wandthermostat zeigt kurz "P4" oder so, das Peering bleibt bestehen. Fhem zeigt für den Thermostat auch nur den _Climate des RT unter peerList an.

Code Auswählen

 trigger sent to unpeered device 
    triggerUnpeered: K.Fenster:29A0CE 
    triggerUnpeered: KiZ.Fenster:29A0CE 
    triggerUnpeered: SZ.Fenster1r:29A0CE 
    triggerUnpeered: WZ.Balkontuer:29A0CE 

 trigger sent to undefined device 
    triggerUndefined: K.Fenster:29A0CE 
    triggerUndefined: KiZ.Fenster:29A0CE 
    triggerUndefined: SZ.Fenster1r:29A0CE 
    triggerUndefined: WZ.Balkontuer:29A0CE

Die Fensterkontakte funktionieren einwandfrei, warum zeigt er hier Fehler an?

Code Auswählen

 templist mismatch 
    SZ.Heizung_Clima: file: ././tempList.cfg for SZ.Heizung_Clima does not exist 
    WZ.Heizung_Clima: file: ././tempList.cfg for WZ.Heizung_Clima does not exist 

 templateCheck:

Klar, hab ja für die RT auch (noch) keine Temperaturlisten.

Danke für Feedback!

Gruß,
Dennis

martinp876 · 22 November 2015, 21:25:11

Du solltest kein neues template anlegen. Das ist nicht die Idee.

Setze das Attribut templist auf einen Namen, z.B. Wohnzimmer. Setze das Attribut bei allen auf den gleichen wert. Dann sind diese immer synchron - jedenfalls wenn du verify oder restore machst.

Der. Sinn ist, daß eq3 davon ausgeht, dass alle Kumpel die templist kennen. Also muss ein TC eine entsprechende Änderung nicht über tragen.
Es kommt hier auch nicht darauf an was ich hier möchte, eq3 macht die regeln. Hält man sich nicht daran muss man alle Eventualitäten selbst klaeren

slaecker · 25 November 2015, 21:05:56

Zitat von: martinp876 am 22 November 2015, 21:25:11
Du solltest kein neues template anlegen. Das ist nicht die Idee.

Setze das Attribut templist auf einen Namen, z.B. Wohnzimmer. Setze das Attribut bei allen auf den gleichen wert. Dann sind diese immer synchron - jedenfalls wenn du verify oder restore machst.

Der. Sinn ist, daß eq3 davon ausgeht, dass alle Kumpel die templist kennen. Also muss ein TC eine entsprechende Änderung nicht über tragen.
Es kommt hier auch nicht darauf an was ich hier möchte, eq3 macht die regeln. Hält man sich nicht daran muss man alle Eventualitäten selbst klaeren

Hab den RT jetzt das gleiche tempList Attribut gegeben wie den TC, danach verify und restore. Werde am Wochenende sehen ob es dann korrekt funktioniert oder ob der RT wieder auf mystische Art von Manu auf Auto umstellt.

Kann mir noch jemand beim Lösen des Peers von _ClimaTeam helfen oder soll ich dazu lieber einen eigenen Thread aufmachen?
Ebenso verstehe ich nicht warum die Fensterkontakte nicht gepeered sein sollen, funktionieren alle einwandfrei ...

Code Auswählen

configCheck done: 

 peer not verified. Check that peer is set on both sides 
    SZ.Heizung_ClimaTeam p:SZ.Thermostat_Climate 
    SZ.Heizung_ClimaTeam pID:35EA3C02 

 peering strange - likely not suitable 
    SZ.Heizung_ClimaTeam pID: Model HM-TC-IT-WM-W-EU should be HM-CC-RT-DN ClimatTeam Channel 

 trigger sent to unpeered device 
    triggerUnpeered: K.Fenster:29A0CE 
    triggerUnpeered: KiZ.Fenster:29A0CE 
    triggerUnpeered: SZ.Fenster1r:29A0CE 
    triggerUnpeered: WZ.Balkontuer:29A0CE 

 trigger sent to undefined device 
    triggerUndefined: K.Fenster:29A0CE 
    triggerUndefined: KiZ.Fenster:29A0CE 
    triggerUndefined: SZ.Fenster1r:29A0CE 
    triggerUndefined: WZ.Balkontuer:29A0CE 

 templateCheck:

martinp876 · 26 November 2015, 20:13:15

peer not verified. Check that peer is set on both sides
SZ.Heizung_ClimaTeam p:SZ.Thermostat_Climate
SZ.Heizung_ClimaTeam pID:35EA3C02

Prüfe, dass die beiden gepeert sind - was ist hier eingetragen?

peering strange - likely not suitable
SZ.Heizung_ClimaTeam pID: Model HM-TC-IT-WM-W-EU should be HM-CC-RT-DN ClimatTeam Channel
ein TC sollte Teamchannel mit RT TeamChannel peeren. Was hast du gepeert?

trigger sent to unpeered device
triggerUnpeered: K.Fenster:29A0CE
triggerUnpeered: KiZ.Fenster:29A0CE
triggerUnpeered: SZ.Fenster1r:29A0CE
triggerUnpeered: WZ.Balkontuer:29A0CE

ist 29A0CE deine Zentrale? Muss ich einmal korrogieren, evtl ist diese Meldung zu hart

slaecker · 26 November 2015, 20:38:16

Zitat von: martinp876 am 26 November 2015, 20:13:15

Code Auswählen Erweitern
peer not verified. Check that peer is set on both sides SZ.Heizung_ClimaTeam p:SZ.Thermostat_Climate SZ.Heizung_ClimaTeam pID:35EA3C02

Prüfe, dass die beiden gepeert sind - was ist hier eingetragen?

Ich habe lediglich _Climate des RT mit _Climate des TC gepeered, das ist auch so bei beiden eingetragen (peerList). Lediglich beim _ClimaTeam des RT steht bei peerList _Climate des TC, beim TC seh ich nix von _ClimaTeam des RT.
Wie es zum Peer von _ClimaTeam kam kann ich mir nicht erklären, den Channel hab ich nie benutzt.

Zitat von: martinp876 am 26 November 2015, 20:13:15
Code Auswählen Erweitern
peering strange - likely not suitable SZ.Heizung_ClimaTeam pID: Model HM-TC-IT-WM-W-EU should be HM-CC-RT-DN ClimatTeam Channel
ein TC sollte Teamchannel mit RT TeamChannel peeren. Was hast du gepeert?

Ich habe entsprechend der Wiki-Artikel HIER und HIER _Climate des RT mit _Climate des TC gepeered. _ClimaTeam ist doch nur zum Peeren mehrerer HM-CC-RT-DN untereinander, oder? Ich bekomme den Peer vom _ClimaTeam nicht mehr weg, siehe oben.

Zitat von: martinp876 am 26 November 2015, 20:13:15
Code Auswählen Erweitern
trigger sent to unpeered device triggerUnpeered: K.Fenster:29A0CE triggerUnpeered: KiZ.Fenster:29A0CE triggerUnpeered: SZ.Fenster1r:29A0CE triggerUnpeered: WZ.Balkontuer:29A0CE

ist 29A0CE deine Zentrale? Muss ich einmal korrogieren, evtl ist diese Meldung zu hart

29A0CE ist der HMLAN

martinp876 · 26 November 2015, 21:21:15

Löschen den peer im climateteam, dann prüfen noch einmal.
Welches Kommando hast du genutzt? RTS werden über Team gepeert. Evtl ein bug, wenn man RT und TC peert

JoeALLb · 26 November 2015, 23:33:10

Ich habe das selbe Problem mit dem wandtermostat.

warum schalten die dn von Manu auf Auto von alleine ? Sollten diese nicht immer auf Manu bleiben?

goerdi · 27 November 2015, 21:06:11

Hi !

Ist es nicht so das die RT Ihren Modus (Manu/Auto usw.) vom TC "aufs Auge gedrückt" bekommen ?
Ich habe im Wohnzimmer 2 RT mit einem TC gepeert und an den RTs Button Lock aktiv...
Ist ja auch meines Wissens der Sinn von dem ganzen ?

Gruss Gerd