Bei HM-CC-RT-DN im ClimaTeam nur einen auf manuell setzen?

Begonnen von tante ju, 23 Dezember 2017, 16:11:06

Vorheriges Thema - Nächstes Thema

tante ju

Ich habe hier zwei HM-CC-RT-DN, die ein ClimaTeam sind und über FHEM und HMCCU auf dem RPi gesteuert werden und da auch die Raumtemperatur herbekommen.

Im Wiki unter https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat steht:
Zitat
Channel (Kanal) 05 _ClimaTeam

Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet

    Änderungen der Temperatur am Handrad
    Einschalten des Boost-Modus am Taster

an seine "Teamkollegen" weiter. Folgende Änderungen werden nicht weitergegeben:

    Status der Fensterkontakte
    Temperaturlisten/Wochenplan und daraus folgende Änderungen
    Änderungen durch Fernbedienungen
    Änderungen durch eine HomeMatic-Zentrale
(Hervorhebungen durch mich)

Wenn ich jetzt allerdings nur einen der RT auf Manuell und Off setze über FHEM, dann werden tatsächlich beide auf Off gestellt.
Also irgendwie passt das Verhalten nicht zu der Beschreibung im Wiki.

Wie kann ich denn nur einen logisch auf manuell setzen? (Habe jetzt erstmal in Off-Stellung die Batterien rausgenommen)

ext23

Hi,

das habe ich auch eben festgestellt, dass die Doku nicht passt. Aber ich bin ganz früh drüber. So brauche ich nur auf einem die Temperatur setzen und nicht auf beiden. Für das Button Lock gilt das leider nicht, das muss auf jedem manuell gesetzt werden.

Aber ich habe auch so meine Probleme mit den HM-CC-RT-DN (Hab die alten VD's raus geworfen).

Ich habe zwei HM-CC-RT-DN und einen Fenster Sensor mit den beiden HM-CC-RT-DN's gepeered. Beide HM-CC-RT-DN laufen im Burst Mode. Beide HM-CC-RT-DN sind mit FHEM gepaired. Das läuft soweit alles gut. Jetzt habe ich einen Virtuellen Temp Sensor unter FHEM angelegt aber ich bekomme den ums verrecken nicht an die HM-CC-RT-DN gepeered. Da kommt irgend wann ein Missing Ack oder eben garnichts. Das peering sehe ich im Virtuellen Temp Sensor, in dem Weather Channel der HM-CC-RT-DN steht aber nach wie vor nur 000000000.

Ich habe keine Ahnung was ich da falsch mache zumal das mit dem Virtuellen Temp Sensoren bei meinen einzelnen HM-CC-RT-DN wunderbar funktioniert.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

tante ju

Zitat von: ext23 am 29 März 2018, 08:58:18
Hi,

das habe ich auch eben festgestellt, dass die Doku nicht passt. Aber ich bin ganz früh drüber. So brauche ich nur auf einem die Temperatur setzen und nicht auf beiden. Für das Button Lock gilt das leider nicht, das muss auf jedem manuell gesetzt werden.

Aber ich habe auch so meine Probleme mit den HM-CC-RT-DN (Hab die alten VD's raus geworfen).

Ich habe zwei HM-CC-RT-DN und einen Fenster Sensor mit den beiden HM-CC-RT-DN's gepeered. Beide HM-CC-RT-DN laufen im Burst Mode. Beide HM-CC-RT-DN sind mit FHEM gepaired. Das läuft soweit alles gut. Jetzt habe ich einen Virtuellen Temp Sensor unter FHEM angelegt aber ich bekomme den ums verrecken nicht an die HM-CC-RT-DN gepeered. Da kommt irgend wann ein Missing Ack oder eben garnichts. Das peering sehe ich im Virtuellen Temp Sensor, in dem Weather Channel der HM-CC-RT-DN steht aber nach wie vor nur 000000000.

Ich habe keine Ahnung was ich da falsch mache zumal das mit dem Virtuellen Temp Sensoren bei meinen einzelnen HM-CC-RT-DN wunderbar funktioniert.

Eigentlich genau mein Setup. Das mit der Temperatur funktioniert aber meistens.

ext23

Ich hab mein Fehler gefunden warum ich das Virtuelle Device nicht peeren konnte. Ich habe vergessen beim Virtuellen Device das IODev zu setzen :-(

Jetzt funktioniert alles bestens!

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

pc1246

Zitat von: ext23 am 04 April 2018, 08:42:54
Ich hab mein Fehler gefunden warum ich das Virtuelle Device nicht peeren konnte. Ich habe vergessen beim Virtuellen Device das IODev zu setzen :-(

Jetzt funktioniert alles bestens!

/Daniel
Moin
Daran bin ich auch schon verzweifelt. Zum Glueck stand da dann irgendwann was von missing IO!
Waere im Wiki einen Eintrag wert. Da man irgendwie nicht denkt, dass ein virtuelles device ein IO braucht!
Gruss Christoph
HP T610
Onkyo_AVR;Enigma2; SB_Server; SB_Player; HM-USB; PhilipsTV; harmony hub; Jeelink mit PCA301; Somfy; S7-300; LGW; HUE; HM-IP auf Charly; div

ext23

Richtig, bei der Meldung bin ich dann auch stutzig geworden ;-)
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

frank

früher wurde das attr auch mal automatisch angelegt, denke ich. vielleicht hat martin hier etwas "optimiert". das fehlt bei einigen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

#7
1) wie beschrieben im wiki muss jedes device die anderen über aenderungen "an ihm" an allle relevanten melden. Also:
Ein teammitglied an alle anderen die manuelle aenderung ( control mode, temperatur, boost,.,)
Ein fensterkontakt an jedes einzelne teammitglied
Eine remote an jedes teammitglied.
Die zentrale an jedes teammitglied.
Man muss korrekt peeren, dann machen es die sensoren auch.
In der zentrale ( fhem) wird das team erkannt (wenn die peers gelesen sind) und es werden alle teammitglieder informiert\umgestellt. Die zentrale ist defensiv und wartet typisch aus das aufwachen der rts. Dauert etwas. Kann man ueber attribute umstellen, empfehle ich nicht.

Das umstellen eines wochenprogramms oder registersettings ist nicht inbegriffen.

2) das korrigieren des virt device muss ich nachsehen. Dachte es schon geloest zu haben, sorry

3) das verhalten ist vom mode unabhaengig.

4) die raumtemperatur misst jeder rt selbst. Nur die solltemp wird übertragen!

5) ich denke, den burst kann man mit aktueller fw des rt nicht mehr abschalten. Hat bei mir nicht mehr funktioniert

ext23

Ahh ok, danke für die Ausführung, dann wirkt FHEM da also zu einem Teil mit. Naja umso besser.

Wegen dem Burst Mode, mhh ich hab den auch bei vielen Geräten an, bis jetzt hatte ich noch keine Probleme damit. Aber gerade bei der Heizung möchte ich das er sofort reagiert, von daher würde ich hier ungerne auf den BurstMode verzichten.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)