ich nutze seit einiger Zeit die neuen Heizkörper- (HM-CC-RT-DN) und Wandthermostate (HM-TC-IT-WM-W-EU) und sie bringen mich zur Verzweiflung!
Sie verlieren (?) ständig die Verbindung zur CCU2 und schalten selbsttätig vom Manu in den Auto Modus um.
Ebensowenig kann ich Fenstersensoren an die Thermostate und die CCU2 gleichzeitig anmelden, ohne dass es dadurch am laufenden Band Fehlermeldungen hagelt.
Im Einzelnen:
Da ich im täglich wechselnden Schichtdienst arbeite nutzt es mir nichts, einmal das Wochenprogramm einzustellen und dieses dann unverändert laufen zu lassen.
Ich nutze als Basis für meine Heizungssteuerung Auszüge aus Skripten von Swifty und dem Forenbeitrag zur Heizungssteuerung über Google Calendar.
Ich lasse also per Skript in regelmässigen Abständen den im Google Calendar eingetragenen Dienst lesen und schicke bei Dienständerung die neuen Tageseinstellungen an die Thermostate (sie laufen im Auto Modus, da sie sich aus irgend einem Grund immer wieder selbsttätig von Manu auf Auto umstellen).
Dies erfolgt über
include "hmxml.inc.php";
switch($HM_Typ[$i])
{
case "HM-CC-RT-DN": // Ventilthermostat
HMXML_setTempProfile($IPS_HM_DeviceID[$i], $tempProfileNew[$i]);
break;
case "HM-TC-IT-WM-W-EU": // Wandhermostat
HMXML_setTempProfile($IPS_HM_DeviceID[$i], $tempProfileNew[$i], 1);
break;
}
Unglücklicherweise ergibt sich hier regelmäßig das Problem, dass die Thermostate und die CCU2 sich „verlieren“. Dies äußerst sich dadurch, dass die Uhren in den Thermostaten auf 00:00 springt und die eingestellten Programme nicht angezeigt oder abgearbeitet werden. Eine undefinierte Zeit später (diese kann Minuten betragen, aber auch mehrere Stunden oder Tage) steht plötzlich wieder die korrekte Uhrzeit zur Verfügung und die eingestellten Heizprogramme werden abgearbeitet. Ach ja, wenn ich über die Web-UI der CCU2 nachschaue, sind die geschickten Heizprogramme korrekt eingetragen.
Ausserdem habe ich an der CCU2 für jedes Fenster Sensoren angemeldet, die mir den Status auf einer LED Anzeige darstellen. Lerne ich die Fenstersensoren nun ausserdem an den Thermostaten an, so melden sie bei Fensteröffnung/-schliessung sehr oft einen Übertragungsfehler. Diese Meldung ist nicht immer korrekt, leider oft genug doch. Entweder bekommt das entsprechende Thermostat das Öffnen oder Schliessen nicht mit oder in selteneren Fällen wird die Anzeige nicht korrekt eingestellt.
Hat jemand ähnliche Probleme oder idealerweise sogar die Lösung dafür???
Ich hatte mal ähnliche Probleme und es hing mit der Gruppenfunktion zusammen, obwohl keine originär eingerichtet war. Nachdem ich dann eine eingerichtet hatte und diese wieder löschte, war der Spuk vorbei.
Ok, hab’s gefunden und werde mal probieren, was passiert.
Einfach mal alles gruppieren und dann die Gruppe wieder löschen?
Habe übrigens vorhin einfach mal die komplette CCU2 auf Werkszustand gesetzt und ein zuvor gemachtes Backup wieder eingespielt.
Danach hatten die Thermostate die Uhrzeit wieder. Ob das allerdings dauerhaft und nicht nur vorübergehend ist, muss sich erst zeigen.
Mensch schade. Mit Tapatalk gestaltet sich die Suche schlecht. Das mit 00:00 hatten wir schon mal behandelt. Im Homematic-Forum findet sich auch was zur automatischen Verstellung.
Gut, dass wir gerade Sommer haben.
Ich steuere meine übrigens mit dem Projekt von Swifty.
Ja, echt schade. Ich suche immer noch nach Lösungen.
Das Projekt von Swifty nutze ich letztendlich auch, jedoch ist es für meine Zwecke zu unflexibel.
Die sich ständig ändernden Dienste machen eine schneller reagierende Lösung notwendig, die auch z.B. auf sich kurzfristig geänderte Anfangs- oder Endzeiten reagiert und nicht zu viel Aufwand erfordert.
Da ist Google Calendar schon recht interessant. Kurz den Dienst ins Smartphone eingegeben und den Rest erledigt IPS.
So zumindest ist das der Grundgedanke, wenn bloss die Thermostate mitspielen würden.
Na ja, ich suche weiter…
Zu dem 00:00 Problem finde ich nichts, suche wohl nach den falschen Begriffen.
Durch einige Fummelein haben sich für mich Verdachtsmomente ergeben, nachdem die Thermostate in negativer Wechselwirkung mit RF-LAN-Gateways (HM-LGW-O-TW-W-EU) stehen.
Habe nun meine beiden „alten“ LAN-Konfigurations-Adapter (HM-CFG-LAN) wieder ausgepackt und angeschlossen und die RF-LAN-Gateways abgeklemmt. Derzeit ist noch alles im grünen Bereich, mal abwarten, was in ein paar Stunden passiert.
Das kann ich bestätigen. Jetzt wo Du von den HM-LGW-O-TW-W-EU geschrieben hast passt Dein Problem zu einem entsprechendem 0:00 Uhr Syndrom welches bei mir aufgetreten ist.
Ich hatte einen von drei LAN-Adaptern durch das Gateway ersetzt. Der Effekt trat dann interessanterweise bei allen neuen Wandthermostaten auf - auch bei denen die über LAN-Adapter bedient wurden.
Letztendlich habe ich das Ding eingemottet und den alten LAN-Adapter wieder in Betrieb genommen. Seit dem ist Ruhe und die Wandthermostate laufen perfekt.
Wäre gut gewesen das LAN-Gateway gleich zu erwähnen…
Wie schon mal geschrieben setzen sich bei mir die Thermostate nach dem ersten Reboot am Tag (oder nach ein paar Stunden) der CCU2 (ohne LAN-Gateway) auf 00:00 und die CCU produziert haufenweise Fehlermeldungen. Ein kurz drauf durchgeführter zweiter Reboot setzt dann alles wieder auf die richtige Zeit und die Fehlermeldungen sind wie vor dem ersten booten. Ist beliebig wiederholbar (den Zeitrhythmus habe ich allerdings noch nicht rausgefunden).
Die Problematik mit der Manu-Auto Umstellung ist auch im Homematic-Forum schon mehrfach durchgekaut. Lösung bisher keine.
Auch 5 Stunden nach „Rauswurf“ der Gateways läuft die Anlage sauber.
Bin gespannt, wie es sich weiter entwickelt. In den letzten Tagen gab es nur Probleme; entweder ist eines oder beide Gateways ausgestiegen, die CCU von IPS verschwunden oder die Thermostate spielten verrückt (wahlweise auch eine Kombination aller Probleme auf einmal).
Wenn ich jetzt allerdings lese, dass es auch ohne der Gateways zu Thermostatschwierigkeiten gekommen ist, werde ich skeptisch.
Aktuell laufen 2 x CCU2 mit jeweils 1 x LAN-GW „neu“ ohne Schluckauf auch mit den „neuen“ Thermostaten und Stellantrieben (die Aktoren/Sensoren sind fest zugeordnet, jeweils ca. 50% über CCU bzw. GW). Die 4 Geräte decken jeweils ein Stockwerk ab und werden per POE (802.3af) mit Saft versorgt.
Aus eigener Erfahrung ein paar Hinweise zur Einrichtung bzw. zum Betrieb. Evtl. hilft es ja bei dem einen oder anderen Problem:
den DHCP-Lease des GWs im DHCP-Server NICHT auf reserviert/statisch setzen
das Feld „IP-Adresse“ beim Verbinden des GWs über WebUI LEER lassen
Bei Einsatz von „managed“ Netzwerkhardware (speziell wenn „Spanning Tree“ läuft oder laufen muss (-> z.B. SONOS nutzt zwangsweise STP):
„Spanning Tree“ auf den Switchports zur CCU und LAN-GW deaktivieren (-> BPDU filtering)
„IGMP Snooping“ aktivieren
„Flow Control“ deaktiviert lassen bzw. auf den entsprechenden Ports deaktivieren
@r4m3u5 (Jens):
Hm, da muss ich mal ein wenig experimentieren.
Allerdings ergeben sich mir hier ein paar Netzwerkfragen, mit denen ich mich (noch!) nicht auskenne.
1.) der DHCP Lease: ich habe meinen Router (Fritz!Box 7490) angewiesen, den MACs der GWs bestimmte IPs zuzuweisen. ist es das, was ich unterlassen sollte? Habe ich anfänglich sogar gemacht, ohne Erfolg.
2.) Das Feld „IP-Adresse“ ist leer (ok, das war jetzt keine Frage :o)
3.) Bei mir laufen tatsächlich einige SONOS Komponenten. Wie und wo deaktiviere ich jedoch „Spanning Tree“? Mein Router ist eine FritzBox 7490 (hier hängt direkt die CCU2 dran) und dahinter werkelt noch ein D-Link DGS 1016D unmanaged Gigabit Switch (hier hängen die GWs dran, z.T. über dLan).
4.) Auch hier die Frage zur Aktivierung/Deaktivierung: wo und wie aktiviere/deaktiviere ich „IGMP Snooping“ und „Flow Control“?
Ach ja, ich nutze kein POE, die GWs hängen an der eigenen Stromversorgung. Ich denke mal, das macht keine Probleme.
Das meinte ich! Ich hatte die Leases auch sofort reserviert und konnte danach einen Blinker-Effekt feststellen … manchmal war das GW verbunden … manchmal nicht. Das Verhalten kann ich mir logisch nicht wirklich erklären. Nach dem Entfernen der Reservierung war das Phänomen jedenfalls weg und seitdem läuft das GW auch nach z.B. Neustart der CCU2 oder Netzausfall einwandfrei.
Wenn die IP hier eingetragen war hat die CCU das GW in 9 von 10 Fällen bei mir nicht gefunden. Da war es wieder … das mit dem „logisch zu erklären“ …
Da Dein Switch nicht „manageable“ ist und die FB kein STP kennt - keine Chance! SONOS nutzt zwangsweise STP von Haus aus um Loops zu vermeiden, und das ist gut so (siehe z.B.: SONOS & STP). Im Zusammenhang mit dem LAN-GW sollte das nicht zwingend ein Problem sein. Ich konnte aber feststellen, dass die CCU bei der Einrichtung des GWs dieses wesentlich schneller gefunden hat, wenn STP auf den Ports zum GW und zur CCU2 „disabled“ war.
Wie vorher … geht nicht mit einem „unmanaged“ Switch. IGMP Snooping lief bei mir sowieso aus anderen Gründen schon und es war auch eher als Empfehlung gedacht, da auf den Ports sowohl des GWs als auch der CCU2 hin und wieder Multicasts zu sehen sind (warum auch immer … ich hab´s nicht weiter untersucht).
(Sehr) kurze Erklärung zu IGMP-Snooping: Multicasts werden von einem Switch normalerweise an alle Ports gesendet. IGMP-Snooping sorgt dafür, dass nur die Ports/Clients die Pakete erhalten, die auch wirklich am entsprechenden Multicast-Stream teilnehmen wollen.
Für die Abschaltung von Flow-Control gilt das gleiche: keine Hände -> keine Kekse. Das sollte aber bei „unmanaged“ Switches normalerweise nicht greifen. Vereinfacht gesagt ist der „Trick“ bei Flow-Control, dass „Pause-Frames“ eingestreut werden um Überlastungen auf Ports mit geringeren Geschwindigkeiten (z.B. zwischen 1 GBit <> 100 MBit) auszugleichen. Erfahrungsgemäß macht das aber, wenn aktiviert, fast immer Probleme. Geräte kennen diese „Pause-Frames“ z.B. nicht oder ignorieren sie.
Sorry, POE war „off topic“ … so hängen die CCUs und die GWs zumindest an der USV im Keller. Außerdem hasse ich Steckernetzteile!
Wenn es den Aufwand rechtfertigt würde ich die DLANs zum Test mal aus dem Spiel nehmen und die CCU inkl. der GWs direkt an den Switch hängen.
Danke für die ausführliche Erklärung, ich bin mal wieder etwas schlauer geworden
Ohne dLan habe ich es schon probiert, einer der beiden GWs war direkt über den Switch angeschlossen. Leider war das auch nicht besser. Ich werde Den einen GW mal wieder anschließen und die IP nicht festlegen lassen. Mal sehen, ob sich etwas ändert.
Nun läuft hier sowohl ein LAN-Adpater, als auch ein LAN-Gateway problemlos.
Was aber ganz und gar nicht funktioniert ist ein LAN-Gateway an einem dLan Adapter. Kaum angeschlossen, verliert die Uhr der Thermostate die Beherrschung und schaltet auf 00:00 zurück. Ausserdem steigt besagter LAN-Gateway spätestens nach 8 Stunden aus dem System aus.
Auszug aus dem Changelog der neuen CCU2 FW V2.9.10:
[HMCCU2-507] HM-LGW-O-TW-W-EU Firmware Update funktioniert nicht wenn IP Adresse in WebUI konfiguriert ist
[HMCCU2-508] RFD kann keine Verbindung zu HM-LGW-O-W-TW-EU aufbauen, wenn in der WebUI eine IP Adresse konfiguriert ist
(siehe z.B.: 