Hallo Zusammen,
seit 3 Tagen zeigen meine HM-CC-RT-DN Heizkörperthermostate ein gewisses Eigenleben - bemerkt im FHEM Logfile. Dazu sehe ich meistens zwischen 22 Uhr und Mitternacht täglich set Befehle im Logfile, und dass obwohl alle meine HM-CC-RT-DN auf "controlManu off" stehen und nichts manuell ausgelöst wurde.
z.B.
2014.08.25 22:04:12 3: CUL_HM set HEIZ_WASCH_Clima desired-temp off
2014.08.25 22:06:29 3: CUL_HM set HEIZ_GROZI1_Clima desired-temp off
2014.08.25 22:11:57 3: CUL_HM set HEIZ_BUEGEL_Clima desired-temp off
2014.08.25 22:13:43 3: CUL_HM set HEIZ_GROZI2_Clima desired-temp off
2014.08.26 00:14:52 3: CUL_HM set HEIZ_LAGER1_Clima desired-temp off
2014.08.26 00:16:30 3: CUL_HM set HEIZ_LAGER2_Clima desired-temp off
2014.08.26 00:19:46 3: CUL_HM set HEIZ_LAGER3_Clima desired-temp off
Haben andere User evtl. Selbiges oder gibt es ein Fix wie man das abstellen könnte?
Danke und Grüße
Chris
vielleicht hat es damit zu tun:
http://forum.fhem.de/index.php/topic,26378.msg194428.html#msg194428 (http://forum.fhem.de/index.php/topic,26378.msg194428.html#msg194428)
gruss frank
Danke Frank, das könnte es sein.
Ich habe hier ein größeres Projekt mit derzeit 25 Stück HM-CC-RT-DN Heizkörperthermostate. Da produziert ein tägliches set auf die desired-temp eine Menge Logs und natürlich Funkverkehr (1% Regel), insbesondere wenn 15-20 HM-CC-RT-DN in kurzen Abständen auf die desired Temp gesetzt werden. Mit den üblichen weiteren Funkverkehr kommt man so schnell an seine 1% Grenze.
Kann man diese auto-set Funktion evtl. optional machen?
Grüße
chris
ZitatIch habe hier ein größeres Projekt mit derzeit 25 Stück HM-CC-RT-DN Heizkörperthermostate. Da produziert ein tägliches set auf die desired-temp eine Menge Logs und natürlich Funkverkehr (1% Regel), insbesondere wenn 15-20 HM-CC-RT-DN in kurzen Abständen auf die desired Temp gesetzt werden. Mit den üblichen weiteren Funkverkehr kommt man so schnell an seine 1% Grenze.
bei solchen grössenordnungen solltest du über ein zusätzliches io-device in verbindung mit der vccu nachdenken. die würde bei einem ausfall durch overload auf das andere io switchen.
so ganz verstehe ich das nicht.
Habe es einmal getestet - ein RT 30-mal desired-temp gesetzt, das ganze mit 3 Burst getriggert. Das kostet 5% der 1h performance. Im eingebauten Fall wird natürlich kein Burst gesendet (ein Burst hat ein Äquivalent von ~16 messages, das hat also 48 messages gekostet)
Prüfe doch einfach einmal die Auslastung
HMLAN Internal msgLoadEst
HMInfo
get hm msgStat
ich halte das nicht wirklich für Kritisch, zumal es sowieso in der Nacht passiert, wenn der rt seine Uhrzeit holt - auch nicht bei 25 devices. Ein HMLAN kann etwa 1600 messages pro Stunde (32 messages sind somit ~2%, aber die Berechnung in HMLAN ist genauer)
p.s.: Ich rede von der Kapazität des HMLAN (100% Kapazität sind also 1% der Bandbreite in der "Luft")
Hallo Martin,
ich habe die Funkbelastung durch die automatischen "set-Befehle" beobachtet und stimme Dir zu - die zusätzliche Belastung ist unter Normalbedingungen eher zu vernachlässigen.
Ich habe jedoch ein weiters Problem festgestellt:
durch die automatischen "set-Befehle" setzen sich meine Heizkörperthermostate nach einem langen Lüften (gepeert mit SEC-SC Fensterkontakten) nicht mehr auf die Ursprungstemperatur zurück, da die automatischen "set-Befehle" zwischenzeitlich die desired-Temp entsprechend (z.B. auf die abgesenkte 12 Grad Temp) ändern.
Schließe ich das Fenster bleibt das Heizkörperthermostat dann auf 12 Grad.
Grüße
Chris
Hej Chris,
wo wir bei der Diskussion aus diesem Thread (http://forum.fhem.de/index.php/topic,26861.msg203222.html) angekommen wären. ;-)