Vor einiger Zeit habe ich angefangen unser Haus “smart” zu machen. Für die Automatisierung habe ich mich für das Projekt FHEM entschieden welches auf einem kleinen Raspberry Pi 3 werkelt und daher ohne Hersteller-Clouds klar kommt. FHEM arbeitet mit sehr vielen Hersteller-Protokollen zusammen und ist umfangreich editierbar. Allerdings setzt es einen gewissen Grad an Programmierkenntnissen voraus. Und manchmal findet man die Lösung für seine Probleme nicht immer sofort sondern über mehrere Quellen verteilt.
So erging es mir z.B. als ich meine Homematic Funk-Heizkörperthermostate HM-CC-RT-DN nachträglich mit externen Temperatursensoren verbinden wollte. Die Homematic-Sensoren lassen sich zwar unabhängig von FHEM mit den Thermostaten peeren, kosten aber ne Menge. Und da XIAOMI seine Aquara Sensoren für sehr schmales Geld anbietet stand für mich schnell fest: die sollen es werden.
Die nun folgende Prozedur funktioniert aber auch mit anderen externen Sensoren so lang sie in der Lage sind ihre Werte an FHEM zu übermitteln.
Ein Blick ins FHEM-Wiki verspricht: kinderleicht. *hust*
Dort wird das Peering nur “husch-husch” beschrieben. Allerdings gibt es ein paar Klippen zu umschiffen bis alles so läuft wie gewünscht. Nachdem ich über mehrere Quellen mir alle Informationen zusammen getragen habe schreibe ich sie hier mal nieder. In erster Linie für mich für weitere Sensoren, aber vielleicht hilft es dem ein oder anderen ebenfalls.
zum peeren mit externen Sensoren muss man sich in FHEM ein virtuelles Homematic-Device (in meinem Fall fürs Wohnzimmer) anlegen. den Teil <Homematic-Id> ersetzt man durch eine beliebige, 6stellige Zahl die in Zukunft als eigenständige “Adresse” des Device dient.
define Wohnzimmer_virt_Temperatur CUL_HM <Homematic-Id>
Dem Device einen virtuellen Kanal hinzufügen:
set Wohnzimmer_virt_Temperatur virtual 1
Da das kein virtueller Knopf sondern ein Sensor ist benennen wir das mal um:
rename Wohnzimmer_virt_Temperatur_Btn1 Wohnzimmer_virt_Temperatur_Sensor1
Ich füge das Device nun dem Raum “Heizung” hinzu (ist aber nicht erforderlich)
attr Wohnzimmer_virt_Temperatur_Sensor1 room Heizung
Das Device muss nun noch wissen mit wem es die Daten kommuniziert, in meinem Fall ist das ein nanoCUL
attr Wohnzimmer_virt_Temperatur IODev nanoCUL
Das Attribut “expert” bitte löschen.
deleteattr expert
Nun wird das virtuelle Device mit meinem Thermostat gepeert. Bei den Thermostaten macht man dies über den Kanal 01 Weather
set Wohnzimmer_virt_Temperatur_Sensor1 peerChan 0 Wohnzimmer_Heizung_Weather single set
Bevor man nun weiter macht sollte man (nein, man muss) dringend warten bis das Peering abgeschlossen ist. Man erkennt es daran dass im Status des Thermostat CMDs_done steht und mit dem Befehl
set hm peerXref
das Peering in beide Richtungen eingetragen ist. das sieht dann so aus:
Sollte das Peering in beide Richtungen nicht abgeschlossen sein dann den letzten Schritt
set Wohnzimmer_virt_Temperatur_Sensor1 peerChan 0 Wohnzimmer_Heizung_Weather single set
so lang wiederholen bis beide Richtungen zu sehen sind.
Im Grunde genommen kann man nun schon überprüfen ob Daten vom virtuellen Device ans Thermostat übermittelt werden.
Mit
set Wohnzimmer_virt_Temperatur_Sensor1 virtTemp 30
sollte nach kurzer Zeit in FHEM beim Thermostat im Weather-Channel bei state nach kurzer Zeit die 30 angekommen sein.
Gut, nun müssen wir aber noch die Werte vom XIAOMI (oder anderem) Sensor automatisiert zum Thermostat bekommen.
Das macht man per “at”
In meinem Fall sieht das so aus:
define at_Wohnzimmer_virt_Temperatur at +*00:05 { my $T=(ReadingsVal("Sensor_Wohnzimmer","temperature",20.0));; fhem "set Wohnzimmer_virt_Temperatur_Sensor1 virtTemp $T";;}
Damit wird alle 5 Minuten der gemessene Temperaturwert vom “Sensor_Wohnzimmer” (mein XIAOMI Aqara) an das virtuelle Device (welches wir gerade erstellt haben) übergeben und schlussendlich dank Peering ans Thermostat übergeben.
Ich verschiebe nun noch das at in den Raum “Zeitschaltuhren”
attr at_Wohnzimmer_virt_Temperatur room Zeitschaltuhren
Der Übersichtlichkeit wegen nun noch mal alle Schritte ohne Erklärung und mit verkürzten Namen nacheinander:
define wz_vTemp CUL_HM <Homematic-Id>
set wz_vTemp virtual 1
rename wz_vTemp_Btnl wz_vTemp_Sensor1
attr wz_vTemp_Sensor1 room Heizung
attr wz_vTemp IODev nanoCUL
deleteattr expert
set wz_vTemp_Sensor1 peerChan 0 WZ_Heizung_Weather single set
define at_wz_vTemp at +*00:05 { my $T=(ReadingsVal("Sensor_WZ","temperature",20.0));; fhem "set wz_vTemp_Sensor1 virtTemp $T";;}
attr at_wz_vTemp room Zeitschaltuhren
Nun sollte alles laufen.
Schön, dass Du damit schon Erfahrungen hast, ich will unser Haus dieses Jahr auch noch schlau machen…
Ich frage mich jetzt nur, warum diese Kopplung Heizkörperthermostat Thermosensor überhaupt nötig ist. Kann der Thermostat nicht selbstständig messen?
Nötig ist sie nicht, die Homematic Thermostate haben ja nen eingebauten Sensor. Aber speziell bei unserem Wohnzimmer/Büro ist der externe Sensor schon von Nöten. Aufgrund er guten Wärmedämmung langt tatsächlich ein großer Heizkörper um beide (offen miteinander verbundenen) Räume zu heizen. Allerdings wird die Temperatur dann ausschließlich direkt neben der Balkontür gemessen.
Falls die Räume nicht so groß sind langt in der Tat das Thermostat. Sollte man zur Raummitte hin eine konstante Abweichung haben so kann man im Thermostat auch ein Offset einstellen.
Geht das nur wenn man n eigenen cul stick oder ähnliches hat ? ich habe alles über die ccu2 mit fhem verbunden und ich meine das ich damals als ich das probiert habe daran verzweifelt bin 😀
Das Peeren ist nicht von der/dem CUL abhängig, das Verbinden wird ja in FHEM vorgenommen.
Hallo Ulf, ich habe mir den Temperatursensor angesehen. Welche Kommunikationstechnologie wird hierbei verwendet? Funk 833MHz? Für alternative Lieferanten sehe ich nur WiFi.
Moin Stefan.
Die Dinger verwenden ZigBee. Nähere Infos dazu findest Du u.a. bei Wikipedia
Hallo Ulf,
super das du die Schritt noch mal anders aufgelistet hast.
Einige Fehler wirklich in der anderen Beschreibung.
Allerdings bekomme ich das Virtual Device nicht mit dem HM-CC-RT-DN gekoppelt.
Die HM-CC-RT-DN habe ich schon länger im Fhem, also vorher schon mal ganz normal gepairt. Jetzt versuche ich dies mit dem Virtual zu verbinden, die pendings ändern sich allerdings nicht, auch wenn ich 1 Stunde lang warte. Drücke ich die Anlerntaste, erhalt ich nur die Meldung F4 auf dem Thermostat.
Kannst du mir noch einen Tipp geben, ich bin ratlos.
Über set hm peerXref sehe ich auch nur eine Richtung:
wz_SchlafzimmervT_Sen1 => OG.HeizungSchlaf_Weather
Gruß
Christian
Ulf… ich danke dir!
Diese „husch-husch“ Erklärungen haben mich wahnsinnig gemacht, stundenlanges, erfolgloses probieren stand an, bis ich deinen Post gefunden habe… Zack… beim 1. Versuch klappt alles 🙂
Hmmm, da bin ich jetzt ein wenig überfragt. Aber ich gebe Dir den Rat Deine Frage vielleicht mal in der Facebook-Gruppe zu FHEM zu stellen. Du findest sie hier:
https://www.facebook.com/groups/740686515942461/
Dort hab ich mir allerhand Wissen angeeignet. Denn das, was man im Forum oder auf diversen Seiten findet ist oftmals recht umständlich geschrieben. Was schlussendlich auch der Grund war weshalb ich das hier noch mal so ausführlich aufgedröselt habe.
Ich erinnere mich daran dass auch ich anfangs nur in eine Richtung den Sync hatte. Und ich meine ich habe alle Devices komplett noch mal rausgeschmissen und Stück für Stuck neu eingebunden. Und dann hat es geklappt.
Hallo,
danke für die Anleitung.
Hätte das Projekt auch vor, es funktioniert aber leider das Peering nicht. Aber
ich kenne mich mit FHEM auch (noch) nicht gut aus.
Folgende Geräte habe ich:
– ebenfalls die Homematikthermostate HM-CC-RT-DN
– zur kommunikation das Aufsteck-Funkmodul für den Raspberry Pi HM-MOD-RPI-PCB
– Temperatursensoren Xiaomi Aqara welche über den deCONZ (USB-Stick) mit den Raspberry kommunizieren
– (einen nanoCUL hätte ich auch)
Kann es an dem Befehl “attr Wohnzimmer_virt_Temperatur IODev nanoCUL” liegen? Ich habe zwar einen nanoCUL, aber der hat ja bei mir eigenlich nichts mit den Geräten zu tun. Oder?
Muss ich zur Kommunikation evlt. das HM-MOD-RPI-PCB Modul oder den deCONZ verwenden?
Vielen Dank
Vielen Grüße
Klaus
Hallo Klaus,
jetzt muss ich erst einmal versuchen zu lesen was Du meinst 😉
So der Profi in Sachen FHEM bin ich nämlich auch nicht.
Ich bin noch bei der Arbeit, schaue es mir heute Nacht mal zu Hause an.
Muss ich eh, mein FHEM zickt auch ein wenig rum und ich weiß noch nicht so recht warum
So, ich hab noch mal drüber nachgedacht.
Ein paar Fragen zum “Abarbeiten:
Die Werte vom Xiaomi-Device, werden die mit dem “at-Modul” an den virtuellen Sensor übergeben? Sprich: steht in dem Modul ein Zeitpunkt an dem mit “set_virtTemp xx.xx” an den virtuellen Sensor übergeben?
Kommen diese Werte im virtuellen Sensor an? Hast Du dort in den Readings den aktuellen Wert?
Hast Du schon mal versucht im virtuellen Sensor mit “set” einen Temperaturwert manuell zu setzen?
Kommt dieser Wert im Weather-Channel des Thermostat an?
Vielen Dank! So funktioniert es auf Anhieb. Das unvollständige FHEM Wiki dazu hat mich Stunden gekostet. Wäre schön wenn diese Infos auch dort einfließen.
Hallo, auch wenn der letzte Kommentar schon etwas her ist wollte ich mal kurz nachfragen. Laut Beschreibung liest es sich so, als wenn das Thermostat sowohl mit Fhem gepairt ist, als auch mit dem virtuellen Device gepeert.
Ich frage deshalb, weil ich einen Heizkörperthermostat von Homematic classic nutze und noch am überlegen bin wie ich den am einfachsten in Kombination mit meinem Shelly H&T-Sensor kombiniere.
Moin Marko.
Die Sensoren sind nicht direkt mit den Thermostaten gepairt, sie sind werden über den Umweg des virtuellen Sensors gepairt. Schlussendlich ist es egal woher die gemessene Temperatur kommt, Du kannst theoretisch jeden x-beliebigen Sensor nehmen der in der Lage ist seine Werte an FHEM zu liefern.
Die Thermostate müssen in der Lage sein das Pairing über FHEM abwickeln zu können, und schon kannst Du mit FHEM dem Thermostat vorgaukeln dass der Sensor vom passenden Typ ist. Und das können die Homematic Thermostate. Schau mal nach ob Deine Thermostate in FHEM den Weather-Channel angelegt haben, darüber läuft das Pairing.