Neues Modul HMCCU für Homematic CCU

[zap]

Ich befürchte, das wird nix unter Windows. Der Fehler bei der Installation ist wohl bekannt:

To paraphrase, there seems to be a 'fork' emulation issue on Windows Perl. The failing code is trying to start a child HTTP listener, but there ends up not being any process or protocol listening on the port

Ein Tipp ist wohl, während der Installation die Firewall abzuschalten. Weiß aber nicht, ob das was bringt.

Außerdem ist es fraglich, ob der RPC Server unter Windows funktioniert, insbesondere das Starten aus dem HMCCU Modul heraus.

Bitte nicht falsch verstehen, soll jetzt nicht demotivieren. Nur um Enttäschungen zu vermeiden, wenn es dass am Ende nicht läuft.

[MaSie]

SCHADE.

Trotzdem Dank für Deine Mühen.

[EdgarM]

Hallo Masie,

was spricht denn dagegen, das FHEM in eine virtuelle Ubuntu umgebung zu installieren.

Vorteile: Bei änderungen / update von Windows lässt es sich einfach mitnehmen.

Nachteil: ( für manche ) ist halt Linux

grüße

[EdgarM]

Hi zap,

vorweg: Ich versuche ehrlich, soviel zu lesen wie ich kann, aber fhem kann durchaus komplex werden

Ich kann ( wie bereits geschrieben ), die Thermostate auslesen, auch die Werte von Hand verändern.

Mein Setup ist leicht anders jetzt:

Name Heizkörper : HzB

setzen der Temperatur: set HzB datapoint 4.SET_TEMPERATURE 25

Jetzt wollte ich allerdings das Tablet UI benutzen, damit meine Frau mich nicht mehr schimpft, weil sie nichts mehr einstellen kann

Dort schaffe ich es allerdings nicht, auch nur die aktuelle Temperatur anzuzeigen, geschweige denn einzustellen. Überall steht etwas von z.b. desired-temp, aber auch eine google Suche bringt mich immer nur auf die gleichen Seiten, allerdings finde ich keine Beschreibung, wie ich an diese Eigenschaften komme. Auch _Clima ist so ein Treffer, der bei mir nirgendwo was auslöst

Vielleicht kannst Du mir bei meinem Verständnissproblem helfen.

gruß und Danke ( und sorry, für das ständige Fragen )

PS: Wenn erwünscht, würde ich auch eine Beschreibung machen, wie das Modul installiert und eingestellt wird, da in der Wiki ja noch kein Eintrag vorhanden ist.

[zap]

@EdgarM: Zu Deiner Frage später.

Zunächst eine allgemeine Info: Habe ein Update für 88_HMCCU.pm und 88_HMCCUDEV.pm auf Sourceforge bereitgestellt (Link siehe wie immer 1. Post in diesem Thread).

Neu: Der Befehl get channel bei HMCCU und bei HMCCUDEV akzeptiert nun die Angabe mehrerer Kanäle. Bei einem HMCCUDEV Device kann man nun folgende Abfrage absetzen:

get mydevice channel 0.^UNREACH 1

Mit diesem Befehl wird der Datenpunkt 'UNREACH' von Kanal 0 und alle Datenpunkte von Kanal 1 gelesen.

Für das IO Device sieht der analoge Befehl so aus:

get mydevice channel LEQ1234567:0.^UNREACH LEQ1234567:1

[zap]

Hi zap,

vorweg: Ich versuche ehrlich, soviel zu lesen wie ich kann, aber fhem kann durchaus komplex werden

Das stimmt. Deshalb mache ich nur die Dinge, die mit der CCU nicht gehen, mit FHEM.

Ich kann ( wie bereits geschrieben ), die Thermostate auslesen, auch die Werte von Hand verändern.

D.h. Du hast Readings mit den Werten in Deinen Devices. Das hört sich schon mal gut an.

Jetzt wollte ich allerdings das Tablet UI benutzen, damit meine Frau mich nicht mehr schimpft, weil sie nichts mehr einstellen kann

Dort schaffe ich es allerdings nicht, auch nur die aktuelle Temperatur anzuzeigen, geschweige denn einzustellen. Überall steht etwas von z.b. desired-temp, aber auch eine google Suche bringt mich immer nur auf die gleichen Seiten, allerdings finde ich keine Beschreibung, wie ich an diese Eigenschaften komme. Auch _Clima ist so ein Treffer, der bei mir nirgendwo was auslöst

Das mit der Frau kenne ich. Die Darstellung auf einem Tablet ist auch der Grund für die Entwicklung von HMCCU. Allerdings lasse ich es etwas einfacher angehen. Tablet UI ist sicher mit das komplexeste Frontend, aber hat auch die meisten Möglichkeiten. Ich habe mich allerdings noch nicht damit beschäftigt, daher kann ich Dir kaum helfen. Im Zweifel solltest Du Fragen dazu im Bereich "Frontends" stellen.

Ich habe mir mal einige der HTML Beispiel Templates von Tablet-UI angeschaut. Da gibt es Einträge wie:

Code Auswählen Erweitern


<div data-type="label" data-devices="xyz" data-get="reading" ...


Damit wird anscheinend ein Textfeld zum Anzeigen eines Readings definiert. Bei data-devices müsste vermutlich "HzB" stehen und bei Reading eben der Name des Wertes, der angezeigt werden soll. Nach diesem Schema scheinen viele Elemente bei Tablet-UI definiert zu werden. Aber wie gesagt: ich kenne mich damit nicht wirklich aus. Ich verwende für die Darstellung das Modul INFOPANEL, das aber lange nicht so flexibel ist wie Tablet UI.

Was ich allerdings nicht verstehe: Warum kann Deine Frau das Thermostat nicht per Hand bedienen? Im Zweifel mach es wie ich und kopple das Thermostat am Heizkörper mit einem Wandthermostat. Damit kann man sehr komfortabel die Heizkörper bedienen.

[EdgarM]

Hi zap,

die Regierung bestimmt, was wir tun

Wir haben nur ein Wandthermostat im Wohnzimmer, in den restlichen Zimmern lediglich Heizungsthermostate. Früher(TM) haben wir den Hauptzulauf an oder ausgemacht, jetzt bleibt der immer an. Deswegen müßte man alle Heizungen von Hand ändern, und das wäre dann schon nervig. Und mein Hauptargument für SmartHome war ja, dass man das einfach und zentral machen kann. ... Irgendwann :-D

Ich mache es jetzt einfach mal so wie du. Ich fange gerade an, mich in RSS einzulesen, vielleicht verstehe ich dann genug für den nächsten Schritt Und meine Frau kann dann schon mal damit spielen

Danke für Deine freundliche Unterstützung.

grüße

[chavalaloco]

Hi Leute
Ich bin mit meinem Latein am Ende wenn ich die CCU definieren möchte, bekomme ich immer die Fehlermeldung "Cannot load module HMCCU".
Rechte passen, XML::Simple ist auch installiert.
Ich komme nicht mehr weiter, bitte helft mir .
In meinem Log steht folgendes:

reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.

Gruß Chavalaloco

[zap]

reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.

Das ist krass. Die Meldung kommt vom Perl Lexer und besagt eigentlich, dass ein '<' als Start eines HTML-Tags erkannt wurde aber das abschließende '>' fehlt. Nun ist Zeile 26 in 88_HMCCU.pm eine Kommentarzeile. In der wird zwar '<' als Kennzeichnung eines Parameters verwendet. Aber 1. mit abschließendem '>' und 2. in einem Kommentar. Das sollte Perl also eigentlich ignorieren.

Seltsam ist auch, dass das Problem anscheinend nur bei Dir auftritt (wobei ich nicht weiß, wie viele Leute das Modul verwenden). Ich vermute, dass die Datei irgendwie korrupt ist.

Hier nochmal die Zeile mit dem Fehler:

Code Auswählen Erweitern


#  get <name> parfile [<parfile>]


Frage: Ich nehme an, Du hast die aktuelle Version des Modules aus Sourceforge runter geladen?

Bitte: Kannst Du mit die Datei mal per Mail schicken oder die ersten 30 Zeilen hier posten (bitte nicht die ganze Datei posten).

Wenn Du selbst testen möchtest, wirf einfach alle Kommentarzeilen am Anfang der Datei raus und versuche es nochmal.

BTW: XML::Simple wird nicht mehr benötigt. Bitte aber darauf achten, dass folgende Dateien im FHEM-Modulverzeichnis ( /FHEM) liegen:

88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl

[zap]

Ich habe im FHEM Sourceforge Repository die Version 2.2 der HMCCU Module bereitgestellt.

Die Module unterstützen nun das Auslesen und Setzen von Konfigurationsparametern von CCU Geräten und Kanälen. Der Zugriff erfolgt mit RPC (putParamset, getParamset). Daher werden nur BidCos Devices unterstützt.

Folgende Befehle sind für HMCCU-Devices nun verfügbar:

get devname config {devicename|deviceaddress|channelname|channeladdress}
get devname configdesc {devicename|deviceaddress|channelname|channeladdress}
set devname config {devicename|deviceaddress|channelname|channeladdress} parameter=value [...]

Für HMCCUDEV-Devices (Geräteadresse über Definition bekannt):

get devname config [channelnumber]
get devname configdesc [channelnumber]
set devname config [channelnumber] parameter=value [...]

Für HMCCUCHN-Devices (Geräteadresse und Kanalnummer über Definition bekannt):

get devname config
get devname configdesc
set devname config parameter=value [...]

Zu beachten:

• Der Befehl get configdesc zeigt eine Beschreibung der Parameter inklusive Datentyp und Read/Write Flags an. Diese Beschreibung ist nicht für alle Parametersets verfügbar. Also nicht wundern, wenn der Befehl "ins Leere läuft"
• Der Befehl get config liest Parameter und speichert die Werte als Readings mit dem Präfix "R-", sofern das Attribut ccureadings=1 ist. Im Gegensatz zu normalen Datenpunkt bezogenen Readings werden diese nicht an Client-Devices propagiert.
• Beim Setzen von Parametern muss unbedingt auf das korrekte Format der Werte geachtet werden. So müssen z.B. Dezimalwerte manchmal mit 6 Nachkommastellen angegeben werde
• Einige Parameter akzeptieren nur Werte in bestimmten nummerischen Bereichen
• Einige Parameter lassen sich nicht setzen, obwohl sie von get configdesc als beschreibbar ausgegeben werden.
• Thermostate haben eine sehr großen Anzahl an Parametern. Das Auslesen produziert entsprechend viele Readings. Ich denke noch über eine Filterfunktion nach

Beispiel: Temperaturwerte für bestimmte Tageszeiten in einem Thermostaten setzen

set CCU config KL-SZ-TH P1_TEMPERATURE_FRIDAY_1=17.000000 P1_TEMPERATURE_FRIDAY_2=21.000000

Beispiel für Parameter-Readings:

Code Auswählen Erweitern


R-KL-SZ-TH.LOCAL_RESET_DISABLE 0 2015-12-04 17:28:30
R-KL-SZ-TH.LOW_BAT_LIMIT 2.200000 2015-12-04 17:28:30
R-KL-SZ-TH.MANU_MODE_PRIORITIZATION 1 2015-12-04 17:28:30
R-KL-SZ-TH.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0 2015-12-04 17:28:30
R-KL-SZ-TH.MODUS_BUTTON_LOCK 0 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_1 420 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_10 1440 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_11 1440 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_12 1440 2015-12-04 17:28:30


Hinweis: Die Datei HMCCU_Readme.txt ist noch nicht aktualisiert.

[zap]

Neue Version von 88_HMCCU.pm eingecheckt. Es steht nun der Befehl "get deviceinfo" zur Verfügung. Der Befehl gibt eine Liste aller Kanäle und Datenpunkte eines CCU Devices aus. Sehr hilfreich bei der Definition und Nutzung von HMCCU Client-Devices in FHEM.

Beispiel:

get CCU deviceinfo KEQ0038200

Ausgabe:

Code Auswählen Erweitern


Channel KEQ0038200:0 ST-WZ-Bass:0
  DP BidCos-RF.KEQ0038200:0.UNREACH = false
  DP BidCos-RF.KEQ0038200:0.STICKY_UNREACH = false
  DP BidCos-RF.KEQ0038200:0.CONFIG_PENDING = false
  DP BidCos-RF.KEQ0038200:0.LOWBAT = false
  DP BidCos-RF.KEQ0038200:0.DUTYCYCLE = false
  DP BidCos-RF.KEQ0038200:0.RSSI_DEVICE = 1
  DP BidCos-RF.KEQ0038200:0.RSSI_PEER = 207
Channel KEQ0038200:1 ST-WZ-Bass:1
  DP BidCos-RF.KEQ0038200:1.STATE = false
  DP BidCos-RF.KEQ0038200:1.ON_TIME =
  DP BidCos-RF.KEQ0038200:1.INHIBIT = false


[Ralli]

Gute Idee!

[AHA1805]

Hallo,

ich verfolge der Beitrag schon eine weile.
Ich finde die Idee super, das würde heißen man muss das HM Protokoll nicht regenerieren.

Ich hätte drei Fragen dazu.
* Wie ist die Reaktionszeit in FHEM wenn ein Sensor  (Taster) gedrückt wird welcher über die CCU eingebunden wurde?
D.h. kann ich diese noch in notify einbinden und in "Echtzeit " damit andere Aktoren schalten.
*Wie ist die Reaktionszeit beim Schalten von Aktoren die mit der CCU gepaired sind und über FHEM schalten möchte?
*Wie würde die Pflege des Moduls aussehen, der Support von Martin für HM ist sensationell.

Ich will hiermit aber niemanden kritisieren

Schöne Grüße
Hannes

Gesendet von meinem SM-T715 mit Tapatalk

[zap]

* Wie ist die Reaktionszeit in FHEM wenn ein Sensor  (Taster) gedrückt wird welcher über die CCU eingebunden wurde?
D.h. kann ich diese noch in notify einbinden und in "Echtzeit " damit andere Aktoren schalten.

Es gibt bei Einsatz von HMCCU zwei Möglichkeiten, in FHEM vom Drücken eines Tasters zu erfahren:

1) Man definiert ein AT Device und fragt regelmäßig den Zustand eines CCU Gerätes ab. Bei einem Intervall von wenigen Sekunden würde die Zustandsänderung entsprechend schnell in FHEM ankommen.

2) Man nutzt den HMCCU RPC-Server. Dieser Server wird von der CCU sofort benachrichtigt, wenn sich ein Status ändert. Da ich den RPC-Server als externen Prozess implementieren musste (FHEM ist für eine direkte Implementierung nicht so gut geeignet), gibt es auch hier eine Zeitdifferenz. Der RPC-Server schreibt Ereignisse von der CCU (z.B. das Drücken eines Tasters) in eine Queue. Diese Queue wird von HMCCU in definierbaren Intervallen abgefragt. Derzeit sind 3, 5 oder 10 Sekunden vorgesehen. Über den attr Befehl können aber auch andere Intervalle eingestellt werden. Ich würde hier aber nicht unter 2 Sekunden gehen. D.h. FHEM erfährt spätestens 2 Sekunden nach dem Drücken des Tasters davon.
Achtung! Die RPC Schnittstelle der CCU hat den Nachteil, dass sie nur BidCos Devices unterstützt. Wenn Du also CUxD einsetzt, funktioniert die Benachrichtigung über den RPC-Server nicht. Für diese Geräte bleibt nur der AT Befehl.

*Wie ist die Reaktionszeit beim Schalten von Aktoren die mit der CCU gepaired sind und über FHEM schalten möchte?

Es gib keine wahrnehmbare Verzögerung. Das Ausführen des Schaltbefehls erfolgt sofort per Homematic Script.

*Wie würde die Pflege des Moduls aussehen, der Support von Martin für HM ist sensationell.

Ich habe das Modul entwickelt, da ich es selbst benötige. Alles was von der CCU nicht unterstützt wird, mache ich mit FHEM (und nur das). Da ich gerne eine FHEM basierte einheitliche Bedienoberfläche auf einem Tablet einsetzen möchte, brauchte ich eine Möglichkeit, von FHEM aus mit der CCU zu kommunizieren.

Fehler versuche ich zeitnah zu beheben, da sie vermutlich auch mich direkt betreffen. Ich kann hier aber keine Reaktionszeit garantieren, da ich einen relativ stressigen Job und einige zeitaufwändige Hobbies habe und die Entwicklung nur nebenher läuft.

Über funktionale Erweiterungen würde ich erst mal nachdenken, ob sie für alle Nutzer sinn machen und sie dann (bei vertretbarem Aufwand) umsetzen. Aber da das Ganze Open Source ist, steht es jedem frei, den Code an die eigenen Bedürfnisse anzupassen.

[mifh]

Hallo,

HMCU ist ja genau, was ich gesucht hatte. Ich habe einen raspberry mit fhem laufen, über den ich ein paar Funktsteckdosen, Rolldaären usw ansteuere. Alles nur in Senderichtung: 433Mhz Sender oder FS20 UART Sender. Klappt soweit gut. Jetzt will ich auch ein paar Sensoren (Taster, Fensterkontake usw anschließen). Ich habe mir dazu gerade eine Homatic CCU2 zugelegt und geschaut, wie ich die an meinen PI mit fhem anschließen kann.

Das Anlernen eines Tasters HM-PB-2-WM55 an die CCU hat auch geklappt. Das Auslösen des Tasters soll an FHEM weitergereicht werden und dort halt Vorgänge auslösen. Dazu habe ich HMCCU auf dem PI installiert (btw: die Dokumentation liest sich gut!).

Ich kann auch problemlos eine Systemvariable von FHEM auf der CCU schalten.
Den in der CCU angelernten Taster sehe ich auch in FHEM, soweit so gut.

Aber wie kriege ich ein event mit, wenn der Taster ausgelöst wird?
Mit at abfragen, wird ja wohl nichts werden, der Zustandswechsel ist ja nicht dauerhaft.
Also RPC-Server? Den kriege ich nicht so recht ans Laufen. Wenn ich den anschalte, startet er brav und schreibt ein langweiliges Logfile ohne aufregende Einträge:

Code Auswählen Erweitern


13.12.2015 19:49:39 Creating file queue
13.12.2015 19:49:39 Initializing RPC server
13.12.2015 19:49:40 callback server created
13.12.2015 19:49:40 Adding callback for events
13.12.2015 19:49:40 Adding callback for new devices
13.12.2015 19:49:40 Adding callback for deleted devices
13.12.2015 19:49:40 Adding callback for modified devices
13.12.2015 19:49:40 Registering callback

Außerdem scheint er FHEM lahmzulegen. Wenn der RPC-Server läuft, bringt ein

Code Auswählen Erweitern


get d_ccu devicelist

den gesamten FHEM-Prozess ohne relevante Einträge im fhem.log ins Nirwana (web-Oberfläche ist tot, kein CPU-Verbrauch). Das File in /tmp enthält nur 1 Byte.

Meine Konfiguration:

Code Auswählen Erweitern


define d_ccu HMCCU hm-ccu2
attr d_ccu ccureadings 1
attr d_ccu parfile /opt/fhem/scripts/hmvalues.txt
# hängt, wenn aktiviert
#attr d_ccu rpcinterval 3
#attr d_ccu rpcserver on
attr d_ccu statevals on:true,off:false
attr d_ccu stripchar :
attr d_ccu substitute false:closed,true:open
attr d_ccu verbose 5

define d_hm_dw_window HMCCUDEV T1 readonly
attr d_hm_dw_window IODev d_ccu
attr d_hm_dw_window alias T1
attr d_hm_dw_window ccureadings 1
attr d_hm_dw_window room test
attr d_hm_dw_window substitute false:closed,true:open
attr d_hm_dw_window verbose 5


Was mache ich falsch?

Ach ja, alle 10 Minuten beschwert fhem sich über die leere Parameterfile hmvalues.txt

Code Auswählen Erweitern


2015.12.13 20:15:00 1: HMCCU: d_ccu Empty parameter file
2015.12.13 20:15:00 3: at_ccu: HMCCU: d_ccu Empty parameter file
2015.12.13 20:25:00 1: HMCCU: d_ccu Empty parameter file
2015.12.13 20:25:00 3: at_ccu: HMCCU: d_ccu Empty parameter file


Wozu dient diese Datei und wie fülle ich sie?

Noch eine kleine Beobachtung: ich mache gerne ein tail -f auf eine log-Datei. Mache ich das für ccurpcd.log, merkt fhem wohl, dass da jemand einen Finder auf der Datei hat und meckert:

Code Auswählen Erweitern


2015.12.13 19:40:17 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 32656


Das Vorhandensein einer Daemon-Instanz über ein filehandle auf der Logdatei zu ermitteln, ist kreativ, aber eher unüblich. Da könnte ein Satz in der Doku helfen.