Neues Modul HMCCU für Homematic CCU

[zap]

Ich muss mir das morgen trotzdem nochmal anschauen. Das Setzen des Datenpunktes wird nämlich immer mit State() ausgeführt. Nach jedem Set wird aber nochmal per get der Wert abgefragt (ein Überbleibsel aus der Vor-RPC-Server Ära). Und hier kommt das Attribut ccuget zum Einsatz. Vermutlich hat das Setzen also vorher auch schon funktioniert, nur das Abfragen nicht. Wenn ich das richtig verstehe, erfolgt das Abfragen per Datenpunkt CONTROL_MODE erfolgt.

Habe zwar einige Thermostate, fahre meine aber immer im Auto Mode. Daher muss ich es mir erst mal anschauen ....

[zap]

So, habe mit jetzt mal die Doku zu den Datenpunkten des Thermostaten angeschaut. Unter

http://www.eq-3.de/Downloads/PDFs/Dokumentation_und_Tutorials/HM_Script_Teil_4_Datenpunkte_1_503.pdf

steht folgende Tabelle:

Code Auswählen Erweitern


Name            Typ      Zugriff
----------------------------------------------
CONTROL_MODE       option   lesend
FAULT_REPORTING    option   lesend
BATTERY_STATE      float    lesend
VALVE_STATE        integer  lesend
BOOST_STATE        integer  lesend
ACTUAL_TEMPERATURE float    lesend
SET_TEMPERATURE    float    lesend/schreibend
AUTO_MODE          action   schreibend
MANU_MODE          float    schreibend
BOOST_MODE         action   schreibend
COMFORT_MODE       action   schreibend
LOWERING_MODE      action   schreibend


Bedeutet: Den aktuellen Modus liest Du über CONTROL_MODE aus. Gesetzt wird er aber über AUTO_MODE, MANU_MODE, BOOST_MODE, COMFORT_MODE und LOWERING_MODE. Damit ist auch klar, wie der Fehler im Log zustande kam. Der AUTO_MODE wurde zwar gesetzt, allerdings ist der folgende Lesebefehl für die Verifikation fehlgeschlagen, da AUTO_MODE nur schreibenden Zugriff erlaubt.

Ich werfe diese Leseverifikation in der nächsten Version raus oder mache sie zumindest optional per Attribut einstellbar. Wenn der RPC-Server aktiv ist, braucht man das nicht.

Alle weiteren Parameter (wie z.B. Zeiten, Wochenprogramm, usw.) können nur über "set config" eingestellt werden. Dabei gibt es aber gerade bei den Zeiteinstellungen vieles zu beachten, da man immer komplette Wochenprogramme übertragen muss.

[zap]

Ich habe gerade die Version 2.7 eingecheckt. Achtung! Die Source-Forge Adresse hat sich geändert (als Vorbereitung für eine zukünftige Installation per "update"). Sie lautet jetzt

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/FHEM/

Neue / geänderte Funktionen:

• Der Logging-Mechanismus wurde auf Log3/verbose umgestellt. Das Attribut loglevel funktioniert daher nicht mehr. Bitte verbose benutzen
• Wenn für ein Client-Device mindestens 2 Zustände über das Attribut statevals definiert sind (z.B. statevals = on:true,off:false) kann mit dem Befehl set devname toggle zwischen diesen Zuständen umgeschaltet werden. Es werden auch mehr als 2 Zustände unterstützt.
• Mit dem neuen Attribut ccuverify kann gesteuert werden, ob nach einem Set-Befehl für den gleichen Datenpunkt automatisch ein Get ausgeführt wird. Das ist nur sinnvoll, wenn der RPC-Server nicht genutzt wird, daher ist diese Funktion per Default ausgeschaltet (=0).
• Der RPC-Server kann nun mit dem Befehl set devname restartrpc neu gestartet werden.
• Der Zustand des RPC-Servers wird im Internal RPCState angezeigt. Folgende Zustände sind möglich: "stopped", "starting"; "running", "stopping", "restarting".
• Im RPCState "starting", "stopping" oder "restarting" akzeptieren die Client-Devices und das IO-Device keinerlei Befehle, da die CCU beim Starten und Stoppen des RPC-Servers ausgelastet ist. Ein get/set Befehl liefert dann die Meldung "CCU busy" zurück und STATE wird auf "busy" gesetzt.
• In einigen Fällen generiert HMCCU nun Events, auf die mit notify reagiert werden kann (s.u.)

Events:

"RPC server restarting" - Der RPC-Server wird gerade neu gestartet.
"RPC server starting" - Der RPC-Server wird gerade gestartet.
"RPC server running" - Der RPC-Server wurde gestartet. Darauf könnte man mit einem "get update" reagieren, um einmalig alle Gerätestati zu aktualisieren.
"RPC server stopped" - Der RPC-Server wurde gestoppt.
"No events from CCU since 300 seconds" - In den letzten 5 Minuten gab es keine Updates von den CCU. Darauf könnte man mit einem "set restartrpc" reagieren, da evtl. die CCU neu gestartet wurde und deshalb keine Events mehr geschickt werden.
"nn devices deleted in CCU" - In der CCU wurden nn Geräte gelöscht. Darauf könnte man mit einem "get devicelist" reagieren.
"nn devices added in CCU" - In der CCU wurden nn Geräte angelernt. Reaktion wie oben (get devicelist).

Vorgehensweise für das Update:

• FHEM stoppen: /etc/init.d/fhem stop
• Prüfen/warten, bis der RPC-Server gestoppt wurde: ps -ef | grep "ccurpcd"
• Neue Dateien ins FHEM Modulverzeichnis kopieren
• FHEM starten: /etc/init.d/fhem start
• Ca. 3 Minuten warten, bis im HMCCU IO-Device RPCState = "running" ist (sofern der RPC-Server genutzt wird)

Abkündigung:

Das Attribut ccustate wird in einer der nächsten Versionen wegfallen. Ebenso die dazu gehörende Funktion HMCCU_State(). Durch die Umbenennung der Readingnames in FHEM konforme Namen sind diese Funktionen nicht mehr notwendig. Falls jemand Einwände hat, bitte melden.

[zap]

Neue Version der Module im Contrib Pfad eingecheckt. Eigentlich sollte ab dieser Version der FHEM Update-Mechanismus unterstützt werden. Leider habe ich übersehen, dass der beim contrib Verzeichnis nicht greift. Werde daher demnächst auf Github umziehen. Bis dahin bitte weiter den Download Link aus dem 1. Beitrag verwenden.

Zunächst ein wichtiger Hinweis: EQ3 hat eine neue CCU-Firmware mit Homematic IP Unterstützung veröffentlicht. Leider hatte ich noch keine Zeit, die zu testen. Aufgrund der Vielzahl von Änderungen (auch bei der RPC Schnittstelle) könnte es zu Problemen im Zusammenspiel mit HMCCU kommen. Im Zweifel also bitte mit dem CCU Update noch ein paar Tage warten.
Wenn möglich wird die nächste Version von HMCCU Homematic IP unterstützen!

Nun zu den Neuerungen:

• HMCCU gibt es einen neuen Befehl get updateccu. Dieser Befehl arbeitet wie get update, d.h. es werden alle Datenpunkte/Readings aller FHEM-Devices aktualisiert. Einziger Unterschied: Der optionale Device-Filter bei get update bezieht sich auf FHEM Devicenames während der Filter bei get updateccu sich auf CCU Devicenames bezieht
• Das Attribut ccustate wurde gestrichen
• Die Unterstützung von CCU Gerätegruppen in HMCCUDEV wurde verbessert (s. Bsp. unten). Wenn ein Datenpunkt eines Mitglieds einer Gerätegruppe aktualisiert wird, werden auch die entsprechenden Readings im HMCCUDEV Gruppen-Device aktualisiert.
• HMCCUDEV unterstützt nun virtuelle Devices (das sind Gerätegruppen ohne Gegenstück in der CCU (s. Bsp. unten)
• Das Attribut ccureadingfilter unterstützt nun mehrere Filterregeln durch , getrennt. Die Regeln können auf bestimmte CCU Gerätekanäle eingeschränkt werden (s. Bsp. untern)
• Neues Attribut mapdatapoints für HMCCUDEV Gruppen-Devices. Da der RPC-Server Gruppen-Devices nicht automatisch aktualisiert, kann mit einem Mapping der Datenpunkte der echten Devices auf die Gruppen-Device Datenpunkte eine Aktualisierung ermöglicht werden. Syntax für das Mapping: Channel-Name.Datapoint=Group-Channel-Name.Datapoint[,...] (s. Bsp. unten)

Beispiel für ein CCU Gruppendevice bestehend aus einem Wand- und einem Heizkörperthermostaten:

Code Auswählen Erweitern


# G-AZ-HZ=Gruppenname in CCU.
# KL-AZ-HZ=CCU-Name Heizkörperthermostat
# KL-AZ-TH=CCU-Name Wandthermostat.
# Explizite Angabe der echten CCU Geräte mit group= notwendig! Alternativ kann mit groupexp= ein
# regulärere Ausdruck für die CCU Gerätenamen angegeben werden
define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ group=KL-AZ-HZ,KL-AZ-TH

# Nur einige Datenpunkte als Readings speichern. ccureadingfilter erlaubt jetzt die Angabe von CCU Channel names
attr HM_G_AZ_HZ ccureadingfilter G-AZ-HZ:1!(CONTROL_MODE|SET_TEMPERATURE),^KL-AZ!(^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT$|^VALVE|^CONTROL)

# Nach Setzen der Zieltemperatur Wert per Abfrage verifizieren
attr HM_G_AZ_HZ ccuverify 1

# Steuerung der Zieltemperatur per Slider Widget ermöglichen
attr HM_G_AZ_HZ controldatapoint 1.SET_TEMPERATURE
attr HM_G_AZ_HZ webCmd control
attr HM_G_AZ_HZ widgetOverride control:slider,10,1,25

# Datenpunkte der echten Geräte auf die Datenpunkte der Gruppe mappen
attr HM_G_AZ_HZ mapdatapoints KL-AZ-TH:2.SET_TEMPERATURE=G-AZ-HZ:1.SET_TEMPERATURE,KL-AZ-TH:2.CONTROL_MODE=G-AZ-HZ:1.CONTROL_MODE

# Für den Befehl get devstate
attr HM_G_AZ_HZ statechannel 1
attr HM_G_AZ_HZ statedatapoint SET_TEMPERATURE

# Bei Zahlen 1 Stelle hinter dem Komma als Reading speichern
attr HM_G_AZ_HZ stripnumber 1

# Werte aus CCU in Readings ersetzen
attr HM_G_AZ_HZ substitute LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST

# Userreadings
# Funktion HMCCU_Dewpoint() berechnet den Taupunkt aus Temperatur und Luftfeuchte
# Funktion HMCCU_AggReadings() aggregiert die Werte identischer Datenpunkte. Hier werden alle LOWBAT Datenpunkte
# der echten Geräte UND verknüpft. Wenn alle "no" sind, ist das Ergebnis auch "no". Wenn mindestens einer "yes" ist,
# ist das Ergebnis "yes".
attr HM_G_AZ_HZ userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}, LOWBAT_STATE:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","cnt","yes","")}


Virtuelle Devices ohne Gegenstück in der CCU (ohne CCU Gerätegruppe) definieren:

define myvirtdev HMCCUDEV virtual group=Dev[,...]
define myvirtdev HMCCUDEV virtual groupex=DevExp

Virtuelle Devices sind immer read only.

BTW: So ein Gruppen-Device "schmiegt" sich sehr harmonisch in ein FHEM Tablet UI Thermostat Widget ein (das war der Hauptgrund, dass ich das implementiert habe):

Code Auswählen Erweitern


      <div data-type="thermostat" data-device="HM_G_AZ_HZ"
        data-get="G-AZ-HZ.1.SET_TEMPERATURE"
        data-set="datapoint 1.SET_TEMPERATURE"
        data-valve="KL-AZ-HZ.4.VALVE_STATE"
        data-unit="%B0"
        class="large">
      </div>


[dferch]

Hi Zap,

vielen Dank für die neuen Funktionen im Modul. Hab auch virtuelle Gruppen in Benutzung und fange gerade mit TabletUI an. Probiere die neuen Funktionen am Wochenende mal aus.

Viele Grüße,
David

[zap]

So, nach einem schweißtreibenden Update meiner CCU auf 2.17.14 (Homematic IP Unterstützung) hier einige Infos zum Thema bzw. HM-IP:

• HMCCU läuft mit der CCU2 Firmware 2.17.14
• HM-IP Devices werden von HMCCU (noch) nicht unterstützt. Die Gründe sind vielfältig. Hauptgrund ist aber, dass sich das Format der Geräteadressen / Seriennummern für HM-IP Geräte geändert hat. Das muss ich HMCCU erst beibringen => Viel Arbeit.

Die 2.17.14 Firmware ist m.E. übles Gefrickel. Ich habe das Update nach der empfohlenen Methode durchgeführt, d.h. Backup, dann Factory Reset, dann 2.17.14 einspielen, dann Restore. Läuft alles, Performance ist ok. Allerdings werden immer wieder Fehler ins Log geschrieben. Ich habe eine simple IP Steckdose angelernt (HMIP-PS). Sollte von 2.17.14 unterstützt werden. Bedienung ist zwar möglich, allerdings wird im WebUI die Steckdose als "unbekanntes Gerät vom Typ DEVICE" dargestellt.

Ich denke, wer nicht unbedingt HM-IP benötigt, sollte mit dem Update noch warten. Ich werde es drauf lassen. Brauche schließlich was zum Entwickeln.

P.S. Habe durch die HM-IP Testerei endlich den Grund gefunden, warum der RPC Server nach dem Starten 3 Minuten Bedenkzeit benötigt, bis er seine Arbeit aufnimmt. Was soll ich sagen: der Grund war eher vor dem Bildschirm zu suchen. Zu meiner Verteidigung kann ich nur vorbringen, dass die Doku an dieser Stelle unscharf (oder beschissen) ist. Wie auch immer: Vor dem HM-IP Release wird es noch ein Update für den RPC-Server geben, damit wenigstens das mal richtig funktioniert.

[Ralli]

Hast Du nun 2.17.4 oder 2.17.14 drauf? Das ist ein himmelweiter Unterschied!

RPC-Server: system.multicall? Oder was war das Problem?

[zap]

Hast Du nun 2.17.4 oder 2.17.14 drauf? Das ist ein himmelweiter Unterschied!

RPC-Server: system.multicall? Oder was war das Problem?

2.17.14, habe gerade meinen vorherigen Beitrag korrigiert.

Nein, Multicall war nicht das Problem. Das wird von RPC::XML::Server unterstützt. Das Problem ist das Handshaking, also der Verbindungsaufbau mit der CCU. Ich hatte das Init als Request losgeschickt. Und dann hat es 3 Minuten gedauert, bis dieser Request zurückkam. Danach habe ich den Server-Loop gestartet, um CCU Events entgegen zu nehmen.
Der Denkfehler: Der Init-Request ist deshalb nicht gleich zurückgekehrt, weil die CCU während der Initialisierung eine Anfrage an dem RPC-Server schickt. Zu dem Zeitpunkt lief aber auf HMCCU Seite noch nix. Daher hat die CCU 3 Minuten auf eine Antwort gewartet. Dann hat ein Timeout zugeschlagen und der Init-Call kam zurück.
Jetzt mache ich es anders. Der RPC Server wird gestartet. Dann wird erst der Init-Request an die CCU geschickt. Jetzt klappt Init und auch Stop ohne Verzögerung.

[jojojo]

Ich habe Probleme mit dem RPC-Server.

Wenn ich ihn über attr d_ccu rpcserver on starte,
wird die Verbindung zur CCU korrekt initialisert.
Aber nach exakt einer Minute erscheint im FHEM-Log, das der Server wieder gestoppt wurde.

z.B.
2016.03.12 21:06:59 0: HMCCU: RPC server started with pid 29873
2016.03.12 21:07:59 0: HMCCU: All RPC servers stopped

In Wirklichkeit läuft der RPC-Server aber weiter, und empfängt auch weiter Daten von der CCU,
die nach ccuqueue_2001.dat geschrieben werden.
Nur FHEM bekommt da nichts von mit, weil es davon ausgeht, das der RPC-Server nicht läuft.
Irgendeine Idee, an welcher Stelle ich den Fehler suchen muss?

Danke und Gruß
Jürgen

[jojojo]

Ok, habe das Problem gefunden.
Es ist die Funktion HMCCU_CheckProcess in 88_HMCCU.pm
Dort wird mit "ps -ef" die Prozessliste ermittelt.

Ich habe aber FHEM in einer Jail unter freeBSD laufen,
dort liefert ps -ef was anderes als unter Linux.
Deswegen findet FHEM die ProzessID nicht.

Nach anpassen der Funktion läuft es.

Viele Grüße
Jürgen

[zap]

Hallo,
bitte poste hier mal Deine Änderungen. Ich wollte heute sowieso eine neue Version einchecken, die das Starten des RPC-Servers optimiert (3 Minuten Pause entfällt). Da kann ich das einbauen.

Bin auch nicht sehr glücklich mit der ps -ef Lösung. Momentan wird nur Debian und MacOS berücksichtigt.

Ich prüfe derzeit die Umstellung auf Proc::Processtable. Hat eben den Nachteil, dass ein weiteres Perl Modul installiert werden muss. Dafür ist das dann Plattform unabhängig.

[jojojo]

Hier die Änderungen.

Code Auswählen Erweitern


sub HMCCU_CheckProcess ($$)
{
        my ($hash, $port) = @_;
        my $name = $hash->{NAME};

        my $modpath = AttrVal ('global', 'modpath', '/usr/local/fhem');
        my $rpcserver = $modpath."/FHEM/ccurpcd.pl";

### ps -a
        my $pdump = `ps -a | grep $rpcserver | grep -v grep`;       
        my @plist = split "\n", $pdump;

        foreach my $proc (@plist) {
                # Remove leading blanks, fix for MacOS. Thanks to mcdeck
                $proc =~ s/^\s+//;
                my @procattr = split /\s+/, $proc;

### Indizes anpassen
               return $procattr[0] if ($procattr[0] != $$ && $procattr[4] =~ /perl$/ &&
                   $procattr[5] eq $rpcserver && $procattr[7] eq "$port");
        }

        return 0;
}


Ich muss aber dazu sagen, ich bin kein freeBSD-Experte.
Auf der Maschine bin ich auch nur Gast mit meiner jail

[zap]

Eine neue Version von HMCCU steht ab sofort im contrib Verzeichnis (Link siehe erster Beitrag).

Fehlerbehebung:

• Der RPC-Server wird nun praktisch ohne Verzögerung gestartet und gestoppt. Insbesondere die 3 Minuten Wartezeit nach dem Start wurde auf 10 Sekunden reduziert. Wenn das stabil ist, werden auch die 10 Sekunden entfallen.
• Die Methode zum Prüfen laufender RPC-Server wurde geändert. Es wird nun die BSD kompatible Syntax 'ps ax' verwendet. Das sollte mit FreeBSD, Debian und MacOS funktionieren.

Die neue Version ist kompatibel mit der aktuellen CCU2 Firmware 2.17.14. Homematic-IP wird allerdings noch nicht unterstützt. Hier bitte ich noch um ein paar Tage Geduld. Ich kann aber jetzt schon sagen, dass HMCCU Homematic-IP unterstützen und damit diesen Gerätezweig für FHEM erschließen wird.

[jojojo]

Ja, was soll ich sagen. Funktioniert 

An der Stelle auch nochmal ein dickes Danke für das Modul.

Viele Grüße
Jürgen

[zap]

Ich habe gerade die Version 3.0 eingecheckt. Diese Version unterstützt nun Homematic IP.

Voraussetzung (nur bei Verwendung von Homematic IP): CCU2 Firmware 2.17.15

Die Get/Set Befehle unterstützen HM-IP Geräte. Damit auch Updates/Events von HM-IP Geräten automatisch an FHEM geschickt werden, muss ein zweiter RPC-Server konfiguriert werden. Dies erfolgt mit dem Befehl attr rpcport. Mit diesem Attribut wird eine Liste der Interfaces festgelegt, die HMCCU unterstützen soll:

• 2000: BidCos-Wired
• 2001: BidCos-RF
• 2010: HMIP-RF

Beispiel: RPC-Server für BidCos-RF und HMIP-RF konfigurieren:

Code Auswählen Erweitern


attr my_ccu rpcport 2001,2010


Nach der Konfiguration die RPC-Server mit attr rpcserver on starten. HMCCU startet für jeden rpcport automatisch einen Prozess.

Weitere Neuerungen in dieser Version:

• Für Client-Devices vom Typ HMCCUDEV steht der Set-Befehl on-timer zur Verfügung, sofern das Device einen Datenpunkt ON_TIME besitzt, mit dem Attribut statevals Werte für 'on' und 'off' festgelegt sind und ein statechannel definiert ist.
• Mit dem Befehl get dump devtypes im Modul HMCCU kann man sich eine Liste der CCU Gerätetypen anzeigen lassen.
• Mit dem Befehl get dump datapoints im Modul HMCCU kann man sich eine Liste aller CCU Gerätetypen mit allen Datenpunkten anzeigen lassen. Für jeden Datenpunkt wird der Datentyp sowie die zulässigen Operationen (Read, Write, Event) angezeigt.
• Der Befehl get deviceinfo in den Modulen HMCCUDEV und HMCCU zeigt nun ebenfalls die Datentypen, Operationen sowie den aktuellen Wert der Datenpunkte eines Devices an.
• Bei den Befehlen get datapoint und set datapoint wird nun geprüft, ob der angegebene Datenpunkt existiert und die Operation (Setzen/Lesen) zulässig ist. Im Webinterface wird bei get datapoint eine Auswahlliste der gültigen Datenpunkte angezeigt. Die Datenpunküberprüfung kann mit attr ccuflags dptnocheck im Modul HMCCU global ausgeschaltet werden
• Mit dem Attribut ccuflags im Modul HMCCU können verschiedene Flags (durch Komma getrennt) gesetzt werden. Das Flag 'singlerpc' sorgt dafür, dass auch bei mehreren RPC-Ports nur ein RPC-Server Prozess gestartet wird. Das ist mit Vorsicht zu genießen, da je nach Auslastung von FHEM und Anzahl der CCU Events Nachrichten verloren gehen können.

Für die Installation der CCU Firmware 2.17.15 geht man am besten wie folgt vor:

• Backup erstellen
• CCU in Recovery Modus booten
• CCU auf Werkseinstellungen zurücksetzen
• Firmware 2.17.15 installieren
• Ggf. Zusatzsoftware installieren (z.B. CUxD)
• Backup einspielen

Wenn CUxD installiert werden soll, muss es unbedingt die Version 1.5.1 sein!