Neues Modul HMCCU für Homematic CCU

[zap]

HMCCU ist ein Modul für die Kommunikation zwischen FHEM und einer Homematic CCU. Die Module HMCCUDEV und HMCCUCHN werden für die Definition von Client-Devices verwendet. Der integrierte RPC Server sorgt für den Empfang von CCU Events, mit denen Readings in Client-Devices automatisch aktualisiert werden, sobald sich die entsprechenden Werte in der CCU ändern.
Ab Version 4.0 wird mit dem Modul HMCCURPC ein externer RPC-Server bereitgestellt, der auch binary RPC (z.B. für CUxD) unterstützt.

Features:

• Unterstützt BidCos-RF (Funk), BidCos-Wired (drahtgebunden), HMIP-RF (Homematic IP) und CUxD (nur mit HMCCURPC)
• Unterstützt (teilweise mit Einschränkungen) folgende CCU2 Addons: HomeGear, OSRAM Lightify
• Lesen und Schreiben von Datenpunkten von CCU Geräten
• Lesen und Schreiben von CCU Systemvariablen
• Werte aus der CCU werden als Readings in FHEM gespeichert
• Automatische Konvertierung und Skalierung von Werten beim Lesen und Schreiben
• Automatisches Update von Geräten bzw. Readings in FHEM bei Änderungen in der CCU
• Ausführen von CCU Programmen
• Ausführen von beliebigen Homematic CCU Scripts. Ergebnis kann als Readings gespeichert werden
• Lesen und Schreiben von CCU Geräte- und Kanalparametern
• Unterstützung der CCU Gruppen-Devices (Serial INTnnnnnnn)
• Unterstützung von CCU Team-Devices (Adresse *nnnnnn)

HMCCU verwendet Homematic Script und XML-RPC für die Kommunikation mit der CCU. Seit dem 13.09.2016 ist HMCCU Teil des FHEM SVN Zweigs und kann per update Befehl installiert und aktualisiert werden.

Beispiele für Client-Devices gibt es hier

Doku im Wiki: https://wiki.fhem.de/wiki/HMCCU

Wichtig!

Aufgrund der Verwendung von Homematic Script dürfen Namen in der CCU nur einmal verwendet werden, d.h. ein Gerätename in der CCU darf nicht auch für ein Gewerk oder ein anderes Objekt verwendet werden! Homematic Geräte- und Kanalnamen dürfen keine Umlaute verwenden.


Funktion der Module:

• HMCCU - Das ist das IO Device Modul für die Kommunikation mit der CCU. Funktioniert im Prinzip auch ohne die Client-Devices
• HMCCURPC - Externes RPC-Server Modul
• HMCCUDEV - Client-Device Modul für komplette CCU-Geräte (also z.B. für einen Dimmer oder eine Steckdose)
• HMCCUCHN - Client-Device Modul für einen einzelnen Kanal eines CCU-Gerätes.
• HMCCUConf - Default Attribute für einige Homematic Geräte.

Die Befehle der Module akzeptieren folgende Geräte-/Kanal- und Datenpunkt-Angaben:

Device = {Device-Name|[Interface.]Device-Address}
Channel = {Channel-Name|[Interface.]Device-Address:Channel-Number}
Datapoint = {Device|Channel}.Datapoint-Name

Beispiel IO Device mit HMCCU:

Code: [Auswählen]

# IO Device definieren
define d_ccu HMCCU 192.168.10.10

# Alle CCU Geräte einlesen (passiert beim define automatisch)
get d_ccu devicelist

# CCU Variable abholen und als Reading speichern
get d_ccu vars Anwesenheit

# Alle CCU Variablen abholen und als Reading speichern
get d_ccu vars .*

# BidCos-RF und HM-IP RPC Server konfigurieren und starten
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on # Automatisch starten
set d_ccu rpcserver on

# Alle Kanäle und Datenpunkte eines CCU Geräts anzeigen (THERMOSTAT_WZ = Device-Name in CCU)
get d_ccu deviceinfo THERMOSTAT_WZ

Beispiel für ein Client-Device für ein CCU Gerät

Code: [Auswählen]

# Pumpe mit State-Channel = 1
define d_Pumpe HMCCUDEV LEQ1234567 1

# Attribut statevals sorgt dafür, dass man den Gerätestatus ohne devstate setzten kann
attr d_Pumpe statevals on:true,off:false

# Gelesene Werte ersetzen (get Befehle liefern true/false, RPC server liefert 0/1)
attr d_Pumpe substitute true:on,false:off,1:on,0:off

# Pumpe einschalten (2 Varianten, 1. Variante funktioniert wg. Attribut statevals)
set d_Pumpe on
set d_Pumpe devstate on

Beispiel Client-Device für einen CCU Gerätekanal:

Code: [Auswählen]

# TF-Haus-1 ist der Kanalname in der CCU, Device ist readonly (Sensor)
define d_tuer HMCCUCHN TF-Haus-1 readonly

# Gelesen Werte ersetzen (get Befehle liefern true/false, RPC server liefert 0/1)
attr d_tuer substitute true:open,false:closed,1:open,0:closed

Beispiel HM-Script ausführen:

Datei /opt/fhem/hmtest.scr anlegen mit HM-Script Code (Ausgabe aller Systemvariablen der CCU). Readings werden nur gesetzt, wenn die Ausgabe des HM-Scripts Wertepaare im Format Reading=Value enthält. Wertepaare müssen durch Newline getrennt sein:

Code: [Auswählen]

object osysvar;
string ssysvarid;
foreach (ssysvarid, dom.GetObject(ID_SYSTEM_VARIABLES).EnumUsedIDs())
{
   osysvar = dom.GetObject(ssysvarid);
   WriteLine (osysvar.Name() # "=" # osysvar.Value());
}

Script ausführen:

Code: [Auswählen]

set d_ccu hmscript /opt/fhem/hmtest.scr


[traxanos]

Ich habe leider keine CCU und hab alles an FHEM hab mich aber immer wieder geärgert das ich nicht eine CCU2 einhängen kann. So könnte man die Vorteile aus beiden Welten verbinden. Hoffe das Modul wird immer besser ausgebaut, dann überlege ich zu wechseln

[zap]

Das Modul habe ich sozusagen "aus der Not heraus" entwickelt. Ich fahre schon länger zweigleisig, d.h. alles was geht mache ich mit Homematic und der CCU2. Alles was die CCU nicht kann, habe ich über FHEM realisiert. Nun gibt es aber Szenarien, die eine Kommunikation beider Systeme erforderlich machen.

Beispiel 1: Ich schalte den AV-Receiver ein. Das FHEM Pioneer AVR Modul erkennt das und schaltet über die CCU und die Schaltsteckdose den Bass ein.

Beispiel 2: Ich versorge die CCU aus FHEM mit Wetterinformationen (u.a. aus meiner Wetterstation und Wetter.com). Die CCU nutzt diese Infos z.B. für die Prüfung, ob bei Regen die Dachfenster zu sind.

Zum Thema Ausbau: Was wäre denn interessant? Ich möchte auf jeden Fall noch die Ausführung von CCU Programmen einbauen.

[Inputsammler]

Hey,

Das
Modul hört sich gut in. Ich habe auch teilweise die Ccu2 und Fhem's am laufen.
Bei mir läuft die ccu nur temporär.
Ich werde das Modul ab September mal testen.
Hab gerade wenig Zeit.

Gruß Gerd

[zap]

Vor dem Ausprobieren das Modul nochmal runterladen. Habe einige Fehler korrigiert.

[3dmanipulator]

hört sich sehr interessant an. vor allem vor dem hintergrund dass die ccu2 als bausatz zur zeit billiger ist als das lan modul.

ich benutze eigentlich zwave; aber die heizkörperthermostate arbeitn da nicht so doll.

deshalb überlege ich die heizkörper komplett über homematik laufen zu lassen. läuft denn der datenaustausch zwischen fhem und der ccu2 so, dass ich als infoboard und zur gelegentlich erhöhung der temperatur auf der fhem oberfläche bleiben kann?

grüße horst

[zap]

Momentan kann man nur STATE der in der CCU definierten Geräte setzen. Die Erweiterung auf andere Datapoints (zB für ein Thermostat) kann ich aber noch einbauen. Die momentan eingebauten Funktionen sind halt die, die ich selbst benötige. Da es aber doch anscheinend den ein oder anderen Interessenten gibt, werde ich das Modul noch etwas ausbauen.

Bei mir liegt der Schwerpunkt auf der CCU, d.h. ich mache nur die Dinge über FHEM, die mit der CCU nicht out of the box gehen. Für den Rest ist mir FHEM enfach zu mühsam, frickelig und zeitaufwändig, insbesondere bei großen Installationen (habe da über Jahre mit FS20 reichlich Erfahrungen gesammelt).

Momentan überlege ich, eine webbasierte Statusanzeige über das Infopanel Modul von FHEM zu realisieren. Dafür hole ich auch Infos per HMCCU aus der CCU ab. Allerdings fehlen da schon wieder so viele Funktionen, dass ich nun vor der Wahl stehe, Infopanel selbst anzupassen (was wieder viel Zeit kosten wird) oder doch auf eine professionelle Lösung wie IP Symcom zu setzen.

UPDATE: Schlechtes Wetter => Viel Zeit => Setzen und Auslesen von Datenpunkten eingebaut 

Damit kann nun z.B. die Solltemperatur eines Thermostaten in der CCU geändert werden.

[Pfriemler]

Ich frage mich auch gerade ob ich nicht bei dem aktuellen Bausatzpreis für die CCU2 vieles aus FHEM ausgliedern kann. Irgendwie bin ich für mich Klick-mich-zusammen-Logik eigentlich empfänglicher als für die (mächtigere) FHEM-Variante. Aber meine meisten HomeMatic-Geräte reden ohnehin direkt miteinander.

Gehe ich recht in der Annahme, dass bei einem richtigen (also gleichen) Setzen der Zentralen-ID in CCU2 und FHEM den Status der Geräte direkt mitloggen kann und man so den Status weiter direkt in FHEM auswerten kann, ohne die CCU2 dazu zu befragen?

[Ralli]

OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?

[zap]

OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?

Ich glaube, der CCU2 kann man keine bestimmte HMID unterjubeln. Allerdings ist die CCU-Software mittlerweile ja quelloffen und kann so auf anderen Devices (Raspberry o.a.) installiert werden. Das lässt natürlich einiges erwarten für die Zukunft, sofern sich genügend "Freiwillige" finden, die daran arbeiten.

[zap]

Ich frage mich auch gerade ob ich nicht bei dem aktuellen Bausatzpreis für die CCU2 vieles aus FHEM ausgliedern kann. Irgendwie bin ich für mich Klick-mich-zusammen-Logik eigentlich empfänglicher als für die (mächtigere) FHEM-Variante. Aber meine meisten HomeMatic-Geräte reden ohnehin direkt miteinander.

Das war auch bei mir der Grund, nach dem Wechsel von FS20 auf Homematic auch gleich die Plattform in Richtung CCU zu wechseln. Warum sich mit kryptischen "defines" rumquälen, wenn man vieles einfach per Mausklick machen kann. Natürlich hat FHEM noch seine Existenzberechtigung wenn es um das Einbinden von Nicht-Homematic Komponenten geht Habe meine Wetterstation, meinen AV-Receiver und die Anwesenheitskontrolle mit FHEM realisiert und per HMCCU Modul mit der CCU "verheiratet". Best of both worlds, wie es so schön heißt.

Gehe ich recht in der Annahme, dass bei einem richtigen (also gleichen) Setzen der Zentralen-ID in CCU2 und FHEM den Status der Geräte direkt mitloggen kann und man so den Status weiter direkt in FHEM auswerten kann, ohne die CCU2 dazu zu befragen?

Wenn Du die ID der Zentrale verwendest sollte das funktionieren.

[mgernoth]

Hallo,

OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?

Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.

Allerdings ist die CCU-Software mittlerweile ja quelloffen und kann so auf anderen Devices (Raspberry o.a.) installiert werden.

Quelloffen ist das leider nicht: https://github.com/eq-3/occu
Nur eine Ansammlung an Blobs für verschiedene Plattformen kompiliert.

Viele Grüße
  Michael

[Mr. P]

Da es aber doch anscheinend den ein oder anderen Interessenten gibt, werde ich das Modul noch etwas ausbauen.

Hej zap,

um den Kreis der Interessenten noch etwas zu erweitern:
Zwar nicht direkt für mich, aber für ein Projekt, das ich betreue, bei dem kommende Heizsaison fertig umgestellt sein soll. :-)

[Pfriemler]

Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.

Wird ja immer besser. Muss ich nicht alles neu anlernen in FHEM.
CCU2 ist soeben bestellt.

[zap]

Hej zap,

um den Kreis der Interessenten noch etwas zu erweitern:
Zwar nicht direkt für mich, aber für ein Projekt, das ich betreue, bei dem kommende Heizsaison fertig umgestellt sein soll. :-)

Datenpunkte setzen geht mittlerweile (z.B. Zieltemperatur für Thermostate). Muss mich mal schlau machen, wie ich den Kram ins SVN Contrib bekomme. Macht die Updates etwas einfacher.