Neues Modul HMCCU für Homematic CCU

ToM_ToM · 23 Dezember 2015, 10:12:57

Hey, ich hatte jetzt in der Zwischenzeit noch Make und einen C Compiler installiert.

apt-get install make

apt-get install gcc

apt-get install python-dev

apt-get install expat

cpan install HTTP::Daemon

Und endlich lässt es sich installieren und läuft.

Vielen Dank für deine Hilfe.

zap · 23 Dezember 2015, 10:44:05

Make ist natürlich zwingend erforderlich. Da wäre ich anhand der Fehlermeldung aber nie drauf gekommen

Bevor Du irgendwelche HMCCU Devices definierst, zieh Dir die neue Version der Module von gestern Abend. Ich musste die Reading-Namen ändern, da FHEM zukünftig für Identifier keine Doppelpunkte mehr zulassen wird.

ToM_ToM · 23 Dezember 2015, 10:50:08

Ja, ich bin auch nur durch Zufall darauf gekommen als er bei einer anderen Abhängigkeit wegen "Make" gemeckert hatte.

Ich konnte jetzt die HMCCU anlegen und er zeigt mir auch als Status "Ok" an. Aber get devicelist bringt mir keine Ergebnisse. Habe gerade die CCU neu gestartet. Allerdings hängt dort so viel dran dass das mittlerweile ca. 20 Minuten dauert bis die wieder hochgefahren ist.

ToM_ToM · 23 Dezember 2015, 11:47:13

So, CCU ist neu gestartet und der RPC-Serve läuft auch. Aber get devicelist bringt mir immer noch keine Ergebnisse.

zap · 23 Dezember 2015, 12:16:58

Das sieht doch gut aus. DevCount = 290 ist das Ergebnis von "get devicelist". Der Befehl produziert keine Ausgabe. Du kannst aber mal versuchen, noch ein "dump" anzuhängen, also get xxx devicelist dump. Falls ich das nicht wieder ausgebaut habe, sollte dann eine Liste aller Devices und Channels im FHEM Fenster angezeigt werden.

Bei einem define mit HMCCU wird get devicelist automatisch ausgeführt.

Ansonsten kannst Du los legen und mal per HMCCUDEV ein CCU Geräte oder per HMCCUCHN einen CCU Kanal definieren. Die Datenpunkte sollten dann automatisch vom ccurpcd aktualisiert werden.

Autocreate gibt's (noch) nicht.

Ralli · 23 Dezember 2015, 12:30:34

Für autocreate einfach ein return "UNDEFINED NeuerDeviceName ModulName Def" zurückgeben

.

zap · 23 Dezember 2015, 12:47:13

Zitat von: Ralli am 23 Dezember 2015, 12:30:34
Für autocreate einfach ein return "UNDEFINED NeuerDeviceName ModulName Def" zurückgeben .

Von wo zurückgeben?

Ralli · 23 Dezember 2015, 12:54:16

An fhem - aus Deinem Modul (bzw. dem RPCd), was mit mit dem noch nicht definierten Gerät noch nichts anfangen kann.

zap · 23 Dezember 2015, 13:13:01

Hmm, der spärlichen "Doku" entnehme ich, dass das was mit einer Parse Funktion zu zu hat, die unter bestimmten Bedingungen aufgerufen wird. Und die gibt das diesen String zurück.

Von neuen Devices erfährt HMCCU aus einer zeitgesteuerten Funktion, die die Event-Queue auswertet. Da bringt das Zurückgeben dieses Strings nichts. Außerdem gibt es noch 2 Probleme zu lösen:

1. Die RPC Schnittstelle schickt beim NewDevice Event nur die Adresse des Gerätes mit. Leider hat die CCU keinen API Call eingebaut, mit dem ich von der Adresse zum Namen des Gerätes komme. Da bleibt nur das erneute Einlesen aller Geräte. Daher ignoriert HMCCU derzeit die NewDevice Events.

2. Ich habe Bedenken, per autocreate für jedes CCU Device (und vielleicht noch für jeden Kanal?) ein FHEM Device anlegen zu lassen. Das wird schnell unübersichtlich (habe fast 300 Kanäle) und wahrscheinlich benötigt auch nicht jeder alle CCU Devices in FHEM

ToM_ToM · 23 Dezember 2015, 14:29:17

Hey, also das mit der Ausgabe hat funktioniert.

Ich habe jetzt auch mein erstes Device angelegt (Homematic Thermostat). Aber wie bekomme ich z.B. die Temperatur-Daten in die Readings?

Viele Grüße

Thomas.

ToM_ToM · 23 Dezember 2015, 15:59:09

Okay, es hat etwas gedauert aber die Readings sind jetzt mittlerweile gefüllt.

Aber die Daten sind schon über eine Stunde alt. Es aktualisert sich in FHEM nichts wenn ich am Thermostat die Temperatur ändere.
Wie werden die Events getriggert?

zap · 23 Dezember 2015, 18:47:06

Die CCU schickt die Events an den ccurpcd.pl Prozess. Der schreibt die Events in eine File Queue, standardmäßig /tmp/ccuqueue.dat (und .idx). In HMCCU sorgt dann eine Timer gesteuerte Funktion dafür (alle 3-10 Sekunden, einstellbar), dass die Events aus der File Queue gelesen und an die Client devices in Form von Readings verteilt werden. Zumindest einmal scheint dieser Prozess bei Dir ja funktioniert zu haben. Bei mir vergehen zwischen Aktion in CCU und Reaktion in FHEM nur wenige Sekunden.

Du kannst prüfen, ob Der ccurpcd Events empfängt, indem Du Dir den Zeitstempel der Datei /tmp/ccuqueue.dat anschaust. Der sollte bei Deiner Anzahl an CCU Kanälen nicht älter als 1 Minute sein, denn irgendwas schickt die CCU immer, gerade wenn man Wandthermostate im Einsatz hat. Wenn die Größe der Datei ccuqueue.dat >0 ist, stehen Events drin, die man sich auch z.B. per "tail ccuqueue.dat" anschauen kann. Der RPC Server empfängt immer Events für alle Geräte der CCU, auch wenn für diese kein Device in FHEM existiert.

Falls gar nichts funktioniert wären die letzten Zeilen der Datei /opt/fhem/log/ccurpcd.log interessant. Außerdem eventuelle Meldungen von HMCCU im fhem Log (z.B. dass seit einiger Zeit keine Events von der CCU kamen).

Noch was: nach dem Starten des RPC Servers vergehen exakt 3 Minuten, bevor die ersten Events von der CCU eintreffen. Warum dass so ist, kann vermutlich nur EQ3 beantworten.

Bei mir läuft der RPC Server seit ca. 3 Wochen stabil ohne Performance Probleme.

ToM_ToM · 23 Dezember 2015, 18:55:49

Hey Zap,

schon mal vielen Dank für deinen wirklich guten Support.
Ich habe mir die Datei angesehen und sie ist leer (0KB Größe) aber der Zeitstempel aktualisiert sich ca. alle 5 Sekunden. Scheint also kein Zugriffsproblem zu sein.

In der Log steht folgendes:

Code Auswählen

23.12.2015 17:45:21 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 17:45:21 Entering server loop. Use kill -SIGINT 1403 to terminate program
23.12.2015 17:45:21 ListDevices
23.12.2015 17:45:23 NewDevice: received 140 device specifications
23.12.2015 17:53:36 Received 250 events from CCU since last check
23.12.2015 18:38:49 Creating file queue
23.12.2015 18:38:49 Initializing RPC server
23.12.2015 18:38:50 callback server created
23.12.2015 18:38:50 Adding callback for events
23.12.2015 18:38:50 Adding callback for new devices
23.12.2015 18:38:50 Adding callback for deleted devices
23.12.2015 18:38:50 Adding callback for modified devices
23.12.2015 18:38:50 Registering callback
23.12.2015 18:41:50 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 18:41:50 Entering server loop. Use kill -SIGINT 1403 to terminate program
23.12.2015 18:41:50 ListDevices
23.12.2015 18:41:52 NewDevice: received 140 device specifications
23.12.2015 18:50:59 Received 250 events from CCU since last check

Ich kann in der Log aber nichts Auffälliges feststellen.
Ich hatte FHEM jetzt zwischendrin ein paar Mal neu gestartet.

Wenn ich

Code Auswählen

get HM_KU_Thermostat channel 4
manuell in FHEM aufrufe, bekomme ich auch die korrekten Daten die ich vorher über die CCU-Weboberfläche gesetzt habe.
Das Problem liegt also irgendwie in der automatischen Übertragung bzw. Aktualisierung.

zap · 23 Dezember 2015, 21:50:20

Wenn sich der Zeitstempel aktualisiert, dürfte alles in Ordnung sein. HMCCU liest ja alle paar Sekunden Events aus der Datei und leert sie dadurch. Auch der Eintrag "received 250 events since last check" im Log passt. Der ccurpcd schreibt immer nach 250 events diese Meldung ins Log. Werden gar keine Readings aktualisiert?

Was mir in dem Logauszug auffällt: es fehlt zwischendrin eine "RPC server terminated" Meldung (nach 17:53). Wenn der ccurpcd korrekt beendet wird, muss er eine entsprechende Meldung ins Log schreiben, also per "attr rpcserver off" oder beim Stoppen von Fhem. Hast Du den Prozess mal anderweitig abgeschossen? Das sollte man nicht zu oft machen, da in diesem Fall der RPC Server nicht korrekt von der CCU abgemeldet wird.

Hast Du ein Wandthermostat? Definiere das mal als HMCCUDEV Device oder einen Tür/Fenster Sensor. Die schicken bei mir sofort Feeback, wenn ich ein Fenster öffne. Auch Temperatur und Feuchte werden alle paar Minuten aktualisiert.

Hast Du bei Deinen Devices irgendwelche Attribute gesetzt? ccureadings darf nicht gesetzt sein oder muss 1 sein.

ToM_ToM · 23 Dezember 2015, 22:08:21

Hey,
ja ich hatte immer den Pi neu gestartet anstatt die Prozesse zu killen.

Jetzt habe ich mal den RPC Server über das Attribute off gesetzt, FHEM neu gestartet und dann den RPC Server wieder per Attribute aktiviert.

Code Auswählen

23.12.2015 21:25:55 Received 250 events from CCU since last check
23.12.2015 21:52:36 Shutdown RPC server
23.12.2015 21:53:31 Creating file queue
23.12.2015 21:53:31 Initializing RPC server
23.12.2015 21:53:31 callback server created
23.12.2015 21:53:31 Adding callback for events
23.12.2015 21:53:31 Adding callback for new devices
23.12.2015 21:53:31 Adding callback for deleted devices
23.12.2015 21:53:31 Adding callback for modified devices
23.12.2015 21:53:31 Registering callback
23.12.2015 21:56:31 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 21:56:31 Entering server loop. Use kill -SIGINT 1398 to terminate program
23.12.2015 21:56:31 ListDevices
23.12.2015 21:56:33 NewDevice: received 140 device specifications
23.12.2015 22:02:47 Shutdown RPC server
23.12.2015 22:02:47 RPC server terminated
23.12.2015 22:04:08 Creating file queue
23.12.2015 22:04:08 Initializing RPC server
23.12.2015 22:04:08 callback server created
23.12.2015 22:04:08 Adding callback for events
23.12.2015 22:04:08 Adding callback for new devices
23.12.2015 22:04:08 Adding callback for deleted devices
23.12.2015 22:04:08 Adding callback for modified devices
23.12.2015 22:04:08 Registering callback

Ein Wandthermostat habe ich leider nicht.

Aber auch der Fenstersensor aktualisiert sich nich von alleine.
Ich habe die Daten auch manuell abfragen müssen.
Und nachdem ich dann das Fenster geöffnet habe (ca. 2 min auf gelassen) und dann wieder geschlossen, kam auch keine Aktualisierung in der Zwischenzeit.