Neues Modul HMCCU für Homematic CCU

[zap]

Alles klar, das mit dem dump habe ich wohl überlesen in der Doku 

Alles klar, ich versuche auch mal via debugging weiter zu kommen, aber es kommt auch kein "Event" wenn ich schalte.
Scheint so als würde das reading von Fhem selbst gesetzt...?!- Also ohne entsprechenden input der ccu?

Ja, das ist so. Wenn Du von FHEM aus in der CCU etwas schaltest, wird direkt nach dem set ein get ausgeführt und so das Ergebnis des set überprüft. Ich vermute mal, dass ich an dieser Stelle das Ergebnis nicht in state kopiere. Das sollte der wenige Sekunden später kommende Event erledigen. Du scheinst also doch noch Probleme mit dem RPC Server zu haben. Ich poste demnächst mal ein kleines Howto zum RPC Server mit einigen Tipps, worauf man bei Problemen achten soll. Du kannst aber schon mal prüfen, ob die Datei /tmp/ccuqueue.dat aktualisiert wird. Außerdem vielleicht mal irgendwelche fhem Log Einträge prüfen, die "HMCCU" enthalten.

P.S. und mach aus ;; im substitute bitte ein ;

P.S.P.S Bin nur froh, dass der RPC Server anscheinend auch bei ToM_ToM läuft, sonst würde ich langsam wirklich Zweifel bekommen. Bei mir läuft das Ding völlig problemlos.

[lukasbastelpeter]

Alles klar,
die ccuqueue.dat  ist leer! Kann es sein, dass der Server keine Rechte hat dahin zu schreiben? Wenn ja, wie geb ich ihm die?

[zap]

Alles klar,
die ccuqueue.dat  ist leer! Kann es sein, dass der Server keine Rechte hat dahin zu schreiben? Wenn ja, wie geb ich ihm die?

Da der RPC-Server die ccuqueue.dat anlegt, sollte er die Rechte haben. Dass sie leer ist, hat ebenfalls nichts zu sagen. Es ist ja eine Queue, d.h. der RPC-Server schreibt seine Events rein (=> Datei wird größer) und das HMCCU IO Device in FHEM liest die Events aus der Datei (=> Datei wird kleiner bis 0).

Du musst auf die Zeitstempel der Datei achten (ls -l ccuqueue.dat). Werden die aktualisiert? Gibt es in fhem log Meldungen der Art "received no events since 180 seconds" oder so ähnlich?

[ToM_ToM]

Hallo Zap,

ja ich habe es mit und ohne %20 probiert. Aber leider ohne Erfolg.

@lukasbastelpeter:
Schau mal ob sich die "last write time" der Datei ändert.
Um die Rechte zu ändern google mal nach "CHMOD". Ich arbeite mit WinSCP. Das ist ein Dateimanager und damit geht das ziemlich einfach.

Und kleiner Tip: Mach dir mal die Mühe auch die anderen Seiten dieses Beitrags zu lesen. Die meisten deiner Fragen wurden hier schon beantwortet.


VG, Thomas

[lukasbastelpeter]

Erstmal danke für den super, und fixen Support an solchen Tagen ...

Ja, die Meldung habe ich sekündlich im Log... Der Timestamp ist auch aktuell...
Daher die Frage ob ich die Meldung unterdrücken kann ... Meine arme SD-Karte...

2015.12.26 18:39:01 1: HMCCU: 500 Can't connect to 192.168.20.XXX:8181
2015.12.26 18:39:01 1: HMCCU: RPC server started with pid 590
2015.12.26 18:39:02 1: define AZ.Deckenlampe HMCCUDEV XXX 1: CCU device name not found for XXX
2015.12.26 18:39:02 1: configfile: CCU device name not found for XXXstatefile: Please define AZ.Deckenlampe first

Jemand Ideen?

[zap]

Erstmal danke für den super, und fixen Support an solchen Tagen ...

Ja, die Meldung habe ich sekündlich im Log... Der Timestamp ist auch aktuell...
Daher die Frage ob ich die Meldung unterdrücken kann ... Meine arme SD-Karte...


Jemand Ideen?

Schalte erst mal den RPC Server wieder ab (damit die Meldungen aufhören) oder setze loglevel auf irgendwas > 1. Dein Problem liegt an anderer Stelle.

Die Meldung "HMCCU: 500 Can't connect to 192.168.20.XXX:8181" besagt, dass ein Homematic Script nicht ausgeführt werden kann, weil HMCCU die CCU auf Port 8181 nicht erreichen kann. Ist die IP-Adresse korrekt? Vermutlich passiert der Fehler beim Definieren des IO Devices in FHEM mit dem Modul HMCCU. Dabei wird get devicelist ausgeführt. Das schlägt mit o.g. Fehlermeldung fehl. Deshalb funktioniert auch das folgende Define der Deckenlampe nicht, da im internen Speicher von HMCCU das CCU-Gerät nicht bekannt ist (das hätte eben get devicelist geliefert).

[lukasbastelpeter]

IP stimmt auf jeden Fall, da bin ich im WebInterface unterwegs.
Das Gerät gibt es auch auf jeden Fall, denn genau mit der Konfiguration hat es ja funktioniert?! Manchmal nimmt er es nach einem Boot so an, manchmal nicht...
Wenn ich es dann zwei,drei,vier mal versuche, akzeptiert er es dann irgendwann...

[zap]

Hallo Zap,

ja ich habe es mit und ohne %20 probiert. Aber leider ohne Erfolg.

In Deinem Beispiel mit dem Screenshot hast Du zwei Readings stehen:

HM-CC-RT-DN: Wert = LEQ1076554.4.ACTUAL_TEMPERATURE
HM-CC-RT-DN LEQ1076554.4.ACTUAL_TEMPERATURE: Wert = Temperatur

Wie kam das 1. Reading zustande? Da scheint irgendwas mit dem Leerzeichen schief gelaufen zu sein.

Du könntest im Frontend Forum im Tablet-UI Thread mal die Frage stellen, ob Tablet-UI Probleme hat, wenn in Reading-Names Leerzeichen vorkommen bzw. wie man damit umgehen muss. Oder Du könntest bei Deinen CCU Geräten auf Leerzeichen verzichten. Oder Du benutzt das Attribut "ccureadingformat" und setzt es auf address. Dann haben die Readings grundsätzlich die Adresse der CCU-Geräte als Name. Das sollte dann funktionieren.

Funktioniert eigentlich der Befehl get datapoint im IO Device (HMCCU) wenn der CCU Gerätename ein Leerzeichen enthält? Musst Du den Namen dann in doppelten Hochkomma angeben? Also irgendwie ist das mit den Leerzeichen in der Gerätenamen keine so gute Idee ...

UPDATE: Ich werde in HMCCU bei Readingnames die Leerzeichen automatisch durch Unterstriche ersetzen (neue Version kommt aber nicht vor Montag). Und zwar deshalb:

http://forum.fhem.de/index.php/topic,45788.msg376767.html#msg376767

D.h. FHEM wird keine Leerzeichen mehr als Readingnames zulassen.

[lukasbastelpeter]

Ich mal wieder,

ich habe die Doku und den Thread durchforstet, Systemvariablen werden nicht gepusht oder?

[zap]

Ich mal wieder,

ich habe die Doku und den Thread durchforstet, Systemvariablen werden nicht gepusht oder?

Nein, die RPC Schnittstelle der CCU unterstützt keine Systemvariablen. Dafür (und auch für CUxD Geräte in der CCU) musst Du Dir mit einem at Device in FHEM behelfen, das regelmäßig einen "get <iodev_name> vars <muster>" absetzt.

Nochmal zu Deinen Problemen mit der CCU Verbindung: Scheinen mir Netzwerkprobleme zu sein. Hat m.E. nichts mit dem Modul HMCCU zu tun. Nutzt du WLAN? Welches Betriebssystem verwendest Du?

[lukasbastelpeter]

Hi, ok. Das mit den Systemvariablen läuft bei mir jetzt schon so.

Gestern habe ich das Problem mal vorführen wollen. Mit dem Ergebnis, dass alles perfekt funktioniert hat.

Bis zu einem Reboot -.-...
Das ist aber immer so oder? BZW anscheinend kann man FHEM keine states und readings über den Boot behalten. Denn immer wenn ich neu boote meckert er, dass er die Devices in der CCU nicht kennt, d.h. Entweder schaffe ich es dass FHEM sich auch das Ergebnis von get devicelist merkt, oder ich definiere die ganzen HMCCUDevs mit einem at erst 5 Minuten nach booten.


Die Kiste läuft auf einem Raspberry B+, via Kabel an dem gleichen Switch wie die CCU wird gefüttert von einer Fritzbox.
Mein Macbook hängt via SSH in dem FritzboxWlan.

[RainerG]

Hallo zusammen, ich hab das gleiche "Leiden" wie lukasbastelpeter im Post # 141:
Beim Auslösen eines Schaltbefehls auf dem HMW-IO-12-Sw7-DR wird dieser ausgeführt, FHEM "schmiert" aber ab und kann nur mit "sudo /etc/init.d/fhem start" wiederbelebt werden. Im Log steht:

Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 238

Die Änderungen von zap aus Antwort #143 sind eingespielt!

Code Auswählen Erweitern

define HMCCU2 HMCCU 192.168.xxx.240
attr HMCCU2 ccureadings 1
attr HMCCU2 room HM
attr HMCCU2 rpcserver on
define hm_licht HMCCUDEV MEQ0064384 14
attr hm_licht IODev HMCCU2
attr hm_licht room HM
attr hm_licht statechannel 14
attr hm_licht statevals on:true,off:false
attr hm_licht substitute true:on,false:off,1:on,0:off

Hat jemand Ideen, wo ich noch suchen kann? (hab grad den Pi und Perl geupdatet, hat auch bloß nix gebracht)
Danke vom Harz

[zap]

Hi, ok. Das mit den Systemvariablen läuft bei mir jetzt schon so.

Gestern habe ich das Problem mal vorführen wollen. Mit dem Ergebnis, dass alles perfekt funktioniert hat.

Bis zu einem Reboot -.-...
Das ist aber immer so oder? BZW anscheinend kann man FHEM keine states und readings über den Boot behalten. Denn immer wenn ich neu boote meckert er, dass er die Devices in der CCU nicht kennt, d.h. Entweder schaffe ich es dass FHEM sich auch das Ergebnis von get devicelist merkt, oder ich definiere die ganzen HMCCUDevs mit einem at erst 5 Minuten nach booten.

Die CCU Geräte und Kanäle werden in internen Variablen gespeichert. Wie auch Internals überleben diese einen Neustart von FHEM nicht. Lediglich Readings werden zwischengespeichert und stehen nach dem Neustart wieder zur Verfügung.

Allerdings wird bei einem Neustart von FHEM ja das cfg File abgearbeitet, d.h. das HMCCU IO Device wird definiert und dabei auch "get devicelist" ausgeführt. Genau da passiert bei Dir aber der Fehler (zumindest nach den Fehlermeldungen im Log). Beim Versuch, die Geräte der CCU einzulesen, kommt der Fehler, dass die CCU nicht erreicht werden kann.

Hast Du etwas anderes laufen, das auch die TCL-Rega Schnittstelle der CCU nutzt? Läuft der REGA Prozess auf der CCU (wahrscheinlich, sonst würde es nie funktionieren und nicht nur sporadisch).

[zap]

Hallo zusammen, ich hab das gleiche "Leiden" wie lukasbastelpeter im Post # 141:
Beim Auslösen eines Schaltbefehls auf dem HMW-IO-12-Sw7-DR wird dieser ausgeführt, FHEM "schmiert" aber ab und kann nur mit "sudo /etc/init.d/fhem start" wiederbelebt werden. Im Log steht:Die Änderungen von zap aus Antwort #143 sind eingespielt!

Bitte prüfe, ob am Anfang der Dateien 88_HMCCUDEV.pm und 88_HMCCUCHN.pm tatsächlich "use Time::HiRes;" steht (Zeilen 45 bzw. 42). Falls nicht, lade die beiden Dateien von Sourceforge und kopiere sie ins Modulverzeichnis.

Falls der Use-Befehl schon vorhanden ist: Hast Du die Module neu geladen, nachdem Du die Updates im Modulverzeichnis installiert hast (reload 88_HMCCUDEV und reload 88_HMCCUCHN) ?

Der Fehler in Deinem Fall ist definitiv, dass use Time::HiRes fehlt und damit usleep nicht bekannt ist.

[zap]

So, wie versprochen hier einige Tipps und Hinweise zum RPC-Server. Dieser Beitrag ist auch im 1. Posts dieses Threads verlinkt.

Der RPC-Server ccurpcd.pl wird mit dem Befehl "set rpcserver on/off" gestartet oder gestoppt. Das Attribut rpcserver legt fest, ob der RPC Server beim Start von FHEM automatisch gestartet wird. Sollte es notwendig sein, den RPC-Server manuell zu beenden, so kann die durch einen manuellen Aufruf von ccurpcd.pl mit folgender Syntax erfolgen:

ccurpcd.pl shutdown <ccu_host_or_ip> <port> <pid>

Reload von 88_HMCCU: Vor dem Reload des Moduls 88_HMCCU muss der RPC-Server auf jeden Fall beendet werden, da durch den Reload die Internals RPCPID und RPCPRC verloren gehen und somit das IO-Device den Bezug zum RPC-Server verliert.

FHEM neu starten: Der RPC-Server wird beim Stoppen von FHEM korrekt beendet. Allerding muss vor dem erneuten Starten von FHEM gewartet werden, bis der RPC-Server Prozess nicht mehr läuft. Daher sollte der Befehl "/etc/init.d/fhem restart" bzw. "shutdown restart" nicht bei aktivem RPC-Server verwendet werden, da hier vor dem Starten nicht lange genug gewartet wird. Besser ist "/etc/init.d/fhem stop", dann warten bis RPC-Server auch gestoppt wurde ("ps -ef | grep ccurpcd.pl") und dann starten mit "/etc/init.d/fhem start". In neueren Version von HMCCU funktioniert "shutdown restart" korrekt.

Fehlersuche:

RPC-Server Start: Wenn der RPC-Server mit dem Befehl "set rpcserver on" aus FHEM heraus korrekt gestartet wurde, werden folgende Internals des HMCCU IO Device gesetzt:

RPCPID = Unix Prozess-ID(s) des/der RPC-Server Prozesse(s) (ccurpcd.pl)
RPCPRC = Dateiname des RPC-Server Prozesses

Das Reading "rpcstate" zeigt den Status des RPC servers an.

Wenn der RPC-Server nicht läuft oder das IO-Device aus irgendwelchen Gründen den Bezug zum RPC-Servers verloren hat, ist RPCPID = 0 und RPCPRC = "none".

Der Start des RPC-Servers wird in der Datei ccurpcd_Port.log im FHEM Log-Verzeichnis protokolliert. Ein korrekter Start des RPC-Servers sieht z.B. so aus:

Code Auswählen Erweitern


26.12.2015 16:57:58 callback server created
26.12.2015 16:57:58 Adding callback for events
26.12.2015 16:57:58 Adding callback for new devices
26.12.2015 16:57:58 Adding callback for deleted devices
26.12.2015 16:57:58 Adding callback for modified devices
26.12.2015 16:57:58 Registering callback
26.12.2015 17:00:58 RPC callback with URL http://192.168.1.12:7401/fh initialized
26.12.2015 17:00:58 Entering server loop. Use kill -SIGINT 14211 to terminate program
26.12.2015 17:00:58 ListDevices
26.12.2015 17:01:00 NewDevice: received 179 device specifications


Zu beachten: Zwischen "Registering callback" und "RPC callback with URL ..." vergehen 3 Minuten! Während dieser 3 Minuten sollte man es vermeiden, auf das GUI der CCU zuzugreifen. Danach erhält der RPC-Server eine Liste der CCU Geräte bzw. Kanäle, was mit "NewDevice: ..." protokollert wird.

File-Queue: Der RPC-Server schreibt die von der CCU empfangenen Events in eine File-Queue (Standard /tmp/ccuqueue_Port.dat und /tmp/ccuqueue_Port.idx). Das HMCCU IO Device in FHEM liest die Events regelmäßig (einstellbar über Attribut "rpcinterval") aus dieser Queue und verteilt sie an die Client-Devices (HMCCUCHN, HMCCUDEV).

Prüfen auf CCU-Events: Ein Indiz für das Funktionieren des RPC-Servers ist die permanente Aktualisierung des Zeitstempels der Datei ccuqueue.dat. Dies kann durch wiederholtes Ausführen des Befehls "ls -l /tmp/ccuqueue.dat" verifiziert werden. Es ist normal, dass ccuqueue.dat meistens die Größe 0 Byte hat, da eventuelle Events relativ schnell von HMCCU gelesen werden und dadurch die Datei geleert wird. Sofern zufällig Events in der Datei stehen, können sie mit dem Befehl "cat /tmp/ccuqueue.dat" ausgegeben werden (ein tail -f auf die Datei sollte man vermeiden).

Events bleiben aus: Wenn HMCCU bei aktivem RPC-Server für 300 Sekunden keine Events erhält, schreibt es eine Meldung in das FHEM Logfile ("HMCCU: Received no events from CCU since 300 seconds").

Manueller Test: Je nach Fehlerbild kann es sinnvoll sein, den RPC-Server einmal manuell zu starten, um den Fehler eingrenzen zu können, möglichst als User "root". Dazu gibt man auf der Kommandozeile folgenden Befehl ein (bitte Pfade ggf. ändern):

Code Auswählen Erweitern


/opt/fhem/FHEM/ccurpcd.pl ccu-ip 2001 /tmp/testqueue /tmp/ccurpcd.log &


Wichtig ist, nicht die Standard Queue- und Log-Files zu verwenden, da es sonst beim regulären Start aus FHEM zu Zugriffsproblemen kommen kann.
Da beim manuellen Start des RPC-Servers keine Events von FHEM aus der Queue gelesen werden, kann man (nach 3 Minuten) mit dem Befehl "cat /tmp/testqueue.dat" die Events anschauen und so feststellen, ob die Kommunikation zwischen CCU und dem RPC-Server funktioniert. Zum Beenden des RPC-Servers den Befehl "kill -SIGINT prozess-id" verwenden.