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
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
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 :-[
sind beide auf aktueller fw?
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
attr <rt_Clima> tempListTmpl WohnzimmerprofilWinter
attr <tc_Climate> tempListTmpl WohnzimmerprofilWinter
dann ein
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
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.
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
attr <rt_Clima> tempListTmpl WohnzimmerprofilWinter
attr <tc_Climate> tempListTmpl WohnzimmerprofilWinter
dann ein
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
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:
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_ClimateXX.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
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.
In Ergänzung zu meinem vorherigen Beitrag habe ich einen configCheck durchgeführt, verstehe aber den Output nicht.
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?
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?
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.
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?
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
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
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 ...
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:
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
Zitat von: martinp876 am 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?
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 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 (http://www.fhemwiki.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Channel_.28Kanal.29_02_Climate) und HIER (http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Channel_.28Kanal.29_02_Climate) _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 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
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
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?
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
Zitat von: martinp876 am 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
set SZ.Thermostat_Climate peerChan 0 SZ.Heizung_ClimaTeam single unsethat nichts gebracht, im RT_ClimaTeam steht der TC_Climate immer noch in peerList.
Zitat von: JoeALLb am 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?
Zitat von: goerdi am 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
Also ich hab die gleiche Kombi nochmal im Wohnzimmer (1x RT, 1x TC) und da funktioniert alles soweit. Auch ist hier _ClimaTeam unpeered.
Komisch ist, dass die unterschiedlichen Kanäle der RTs unterschiedliche controlMode Werte anzeigen.
Wohnzimmer:
TC: controlMode auto
RT: controlMode manual
RT_Clima: controlMode auto
Schlafzimmer:
TC: controlMode auto
RT: controlMode auto
RT_Clima: controlMode auto
Verstehe nicht warum es da Unterschiede gibt.
Den RT solltest du vergessen. Die anderen machen die Musik
Es gab nur irgendwo den Tipp, den RT auf Manu zu stellen, dass er sich nicht mit dem Wandtermostat in die Haare kriegt. Was ich dem hier entnehme, ist das hinfällig. Muss ich dem RT dann auch kein Wochenprogramm mehr zuweisen? Was macht der RT, wenn der Wandtermostat ausfällt? Auf sein eigenes Programm umstellen?
Dass die controlModes in den verschiedenen Kanälen unterschiedlich ausgewiesen werden macht mich trotzdem stutzig, das ist doch unlogisch.
Das Peering von _ClimaTeam konnte ich übrigens immer noch nicht lösen, der RT erkennt nun nicht mal mehr den Fenstersensor ... werde den RT wohl die Tage mal auf Werkseinstellungen zurücksetzen ... wenn das geht, muss ich mal in der Bedienungsanleitung nachlesen.
Hast Du deinen RT mal zurückgesetzt? NAch einem Update von FW 1.0 auf 1.4 war meiner nicht mehr zu gebrauchen.
Nach dem Zurücksetzen auf Werkseinstellungen ging er dann wieder hervorragend.
Man kann einem device nur an einem Kanal einenkontrolmode zuweisen.
Unterschiedliche device haben unterschiedliche modes und damit unterschiedliche Kommandos.
Um TC und RT zu peeren sollte man, nach den peeren, beiden die identische templist aus dem templistfile zuweisen. Änderungen mit hminfo steuern.
Änderungen am TC werden zum RT uebertragen. Den RT als Eingabe sperren.
Änderungen über die console werden von fhem an beide gesendet. Man muss nur einen aendern. Natürlich muss die peerlist stimmen, damit fhem die Gruppen erkennt.
Eine Gruppe von RTS funktioniert identisch.
Die einzige mögliche alternative ist, die devices auf manuell zu setzen und alles von der zentrale aus steuern. Geschmackssache, nicht mein weg.