Neues Modul HMCCU für Homematic CCU

[zap]

Die möglichen Parameter siehst Du wie in FHEM üblich entweder per "?" Angabe oder im Webinterface in der Auswahlliste hinter set/get/attrib.

FHEM bietet ja auch das Klonen von Devices an. So kannst Du z.B. einen Fenstersensor definieren, alle notwendigen Attribute setzen und dann das FHEM Device klonen. Danach in der Kopie nochmal "DEF" anklicken und noch die Adresse anpassen. Ggf. noch das ein oder andere Attribut korrigieren, sofern erforderlich. Fertig. Das ist jedenfalls schneller, als jeden Sensor einzeln zu definieren und v.a. die Attribute zu setzen.

Sobald Du mal wieder ein Update in FHEM machst, wird auch die HMCCU Hilfe in der lokalen FHEM Online Hilfe verfügbar. Da sind fast alle Parameter und Befehle beschrieben.

[tuppertasse]

Okay die Hilfe ist jetzt drin durch das update!
nur schmeisst der mir immer noch raus --> please define rpcserver first wenn ich denn über das device per attr starten will. Komisch. So ganz blicke ich da auch noch nicht durch.

Ich muss jetzt anscheinend für ein device in der CCU das HMCCUDEV und HMCCUCHN definieren gemäß der help:

Code Auswählen Erweitern

define window_living HMCCUCHN WIN-LIV-1 readonly
define temp_control HMCCUCHN BidCos-RF.LEQ1234567:1
define window_living HMCCUDEV WIN-LIV-1 readonly
define temp_control HMCCUDEV BidCos-RF.LEQ1234567 1

Warum einmal mit ":" und einmal ohne ?
Was ist wenn das Device mehr als einen Kanal hat also zB mein Hutschienenkator hat 4 ?
Was meinst du ist die beste Vorgehensweise: Mein bisheriger fhem Aufbau war über HM_CUL --> wenn ich das jetzt auf HMCCU umstelle ist besser bei null anzufangen und Schritt für Schritt "umzuschreiben" ?

[zap]

nur schmeisst der mir immer noch raus --> please define rpcserver first wenn ich denn über das device per attr starten will. Komisch. So ganz blicke ich da auch noch nicht durch.

Ich vermute, Du versuchst "set rpcserver on" auszuführen. Da fehlt dann der Name des HMCCU IO Device, "rpcserver" ist ja nur der Befehl. Wenn Dein IO-Device z.B. "meine_schoene_CCU" heißt, lautet der Befehl "set meine_schoene_CCU rpcserver on".

Ich muss jetzt anscheinend für ein device in der CCU das HMCCUDEV und HMCCUCHN definieren gemäß der help:

Nein, eine doppelte Definition mit HMCCUCHN und HMCCUDEV kann man zwar machen, ist aber nicht sinnvoll (auch wenn es grundsätzlich unterstützt wird). Hier hatte ich mal ein paar Beispieldefinitionen gepostet: https://forum.fhem.de/index.php/topic,51339.msg429984.html#msg429984

HMCCUCHN ist eine einfachere Form von HMCCUDEV. D.h. wenn Du bei einem Homematic Gerät nur einen Kanal benötigst (z.B. bei einem Tür-/Fenstersensor reicht Kanal 1), dann definierst Du das FHEM Device am besten über HMCCUCHN. Als Parameter wird dann entweder der Name des Kanals in der CCU oder die Adresse des Kanals angegeben. Die Kanaladresse ist immer Geräteadresse:Kanalnummer. Wenn Du den Kanalnamen verwendest, ist nur dann ein Doppelpunkt anzugeben, wenn auch der Kanalname in der CCU einen Doppelpunkt enthält. Es ist eben der Name in der CCU, nicht mehr und nicht weniger. Bei den Tür-/Fenstersensoren macht auch der Parameter "readonly" Sinn, da es hier nichts zu schalten gibt.

Bei allen anderen Geräten würde ich HMCCUDEV empfehlen. Die damit angelegten FHEM Devices enthalten alle Kanäle. Bei HMCCUDEV wird dann auch der Gerätename in der CCU oder die Geräteadresse (ohne Doppelpunkt und Kanalnummer) angegeben.

Gut nachvollziehen kannst Du das, wenn Du bei einem FHEM Geräte (egal ob HMCCUDEV oder HMCCUCHN) den Befehl "get deviceinfo" ausführst. Dann zeigt Dir FHEM eine Liste aller Kanäle und Datenpunkte an. Bei einem HMCCUCHN Gerät ist das genau ein Kanal, bei einem HMCCUDEV Gerät alle Kanäle.

Was meinst du ist die beste Vorgehensweise: Mein bisheriger fhem Aufbau war über HM_CUL --> wenn ich das jetzt auf HMCCU umstelle ist besser bei null anzufangen und Schritt für Schritt "umzuschreiben" ?

Wenn die Geräte sowohl in FHEM per CUL sichtbar sind als auch in der CCU, kannst Du schrittweise migrieren. Grundsätzlich ist es möglich, die Geräte in beiden Welten zu sehen. Da kenne ich mich aber nicht so gut aus (Frage wurde hier im Forum aber schon mal behandelt).

P.S. Habe ehrlich gesagt nicht damit gerechnet, dass jemand tatsächlich von CUL auf HMCCU umstellt. Wenn es hier mehr Bedarf gibt, schreibe ich vielleicht mal sowas wie einen "Migration Guide".

[tuppertasse]

P.S. Habe ehrlich gesagt nicht damit gerechnet, dass jemand tatsächlich von CUL auf HMCCU umstellt. Wenn es hier mehr Bedarf gibt, schreibe ich vielleicht mal sowas wie einen "Migration Guide".

Tja, ich hätte es auch nicht gedacht da ich vor bestimmt einem Jahr mein FHEM eingedampft habe. Warum ? Naja für mich ist es zwar ein sehr mächtiges Werkzeug aber für einen "Nicht-Programmierer ala Linux & Perl" einfach zu "kryptisch". Die Fehlersuche hat mich Zeit ohne Ende gekostet. Und bei Einspielen von Updates hatte ich wieder Probleme weil es wahrscheinlich nicht sauber programmiert war (klar ist meine Schuld aber wenn man mehrere Wege zum Ziel hat und sich dann anscheinend für den "falschen" entscheidet dann ist das frustrierend).
Somit bin ich auch die CCU2 umgesprungen und habe mir super einfach über KLICKIBUNTI alles zusammengemacht. Für einen Linux-NOOB wie ich es bin genau das richtige. Jetzt kam der Wunsch auf alles das was die CCU2 nicht kann wieder über FHEM abzufahren und bin auf deine Möglichkeit gestossen. Daher kann ich nun meine gesicherte FHEM Umgebung schrittweise anpassen was ich noch brauche und was nicht   Das ist der Hintergrund und nochmal ein RIESENLOB an deine Kooperation / Erstellung / Hilfestellung hier zu dem Thema HMCCU !
Ich hätte nie gedacht wieder mal zurück nach FHEM zu kommen --> DANKE

Nun zu meinem aktuellen Stand.
RPCSERVER läuft - die ersten Datenpunkte habe ich auch mal eingelesen. Sie sind nur statisch also werden nicht, wenn sich der Datenpunkt ändert, autoamtisch auch in FHEM abgezeigt sondern nur wenn ich zB auf get xxx channel gehe.
Frage daher: Wie aktualisiere ich die Datenpunkte ? Über HMCCU get update ?
Früher wurden die Anzeige in Logfiles geschrieben um eine Historie zu haben (Filelog); wie ist das bei HMCCU ?

UPDATE 11:46:
RPCServer lief nicht mehr --> wurde im Log terminated warum auch immer. habe ihn neu gestartet und nun kommen auch events on change des devices an !

[zap]

RPCSERVER läuft - die ersten Datenpunkte habe ich auch mal eingelesen. Sie sind nur statisch also werden nicht, wenn sich der Datenpunkt ändert, autoamtisch auch in FHEM abgezeigt sondern nur wenn ich zB auf get xxx channel gehe.
Frage daher: Wie aktualisiere ich die Datenpunkte ? Über HMCCU get update ?
Früher wurden die Anzeige in Logfiles geschrieben um eine Historie zu haben (Filelog); wie ist das bei HMCCU ?

Wenn der RPC Server richtig läuft, müssen die Readings automatisch aktualisiert werden. Die Befehle get xxx channel und get xxx update sind für manuelle Updates gedacht. Ein get update im IO Device aktualisiert global galaktisch alle definierten CCU Devices. Ein get update in einem Client-Device eben nur die Readings des entsprechenden Device.

Um zu prüfen, ob der RPC Server korrekt läuft, kannst Du mal folgendes ausprobieren:
- Im Internal RPCPID des IO Device muss (mindestens) 1 Zahl > 0 stehen, nämlich die Prozess-ID des RPC Servers
- Im Internal RPCState muss "running" stehen
- Im Verzeichnis /tmp sollten zwei Dateien existieren: ccuqueue_2001.dat und ccuqueue_2001.idx. Der Zeitstempel dieser Dateien sollte alle paar Sekunden aktualisiert werden. Meistens haben diese Dateien eine Größe von 0 oder 1.
- Interessant für die Fehlersuche ist auch die Datei /opt/fhem/log/ccurpcd_2001.log sowie sämtliche Einträge in der fhem Logdatei, die "HMCCU:" enthalten. Die kannst Du mir gerne per Forum-Mail schicken

[tuppertasse]

- Im Internal RPCPID des IO Device muss (mindestens) 1 Zahl > 0 stehen, nämlich die Prozess-ID des RPC Servers

Ja größer Null

- Im Internal RPCState muss "running" stehen

state = running

- Im Verzeichnis /tmp sollten zwei Dateien existieren: ccuqueue_2001.dat und ccuqueue_2001.idx. Der Zeitstempel dieser Dateien sollte alle paar Sekunden aktualisiert werden. Meistens haben diese Dateien eine Größe von 0 oder 1.

Ja ist so !

- Interessant für die Fehlersuche ist auch die Datei /opt/fhem/log/ccurpcd_2001.log sowie sämtliche Einträge in der fhem Logdatei, die "HMCCU:" enthalten. Die kannst Du mir gerne per Forum-Mail schicken

Die werde ich dir mal per Mail schicken !

[tuppertasse]

Nachtrag:
Der rpcserver scheint sich nach einiger Zeit zu beenden. Im Log steht folgendes nachdem einige Perl Warnungen ausgegeben werden:

Code Auswählen Erweitern

2016.04.01 17:17:06 1: PERL WARNING: Use of uninitialized value $pdump in split at ./FHEM/88_HMCCU.pm line 1558.
2016.04.01 17:17:06 0: HMCCU: All RPC servers stopped


[zap]

Der Prozess-Check schlägt fehl. Welches Betriebssystem verwendest Du? Wie sieht die Ausgabe von folgendem Befehl aus:

Code Auswählen Erweitern


ps ax | grep fhem | grep -v grep


[tuppertasse]

Moment läuft der rpcserver nicht und trotzdem habe ich diese Einträge (grübelgrübel):

Code Auswählen Erweitern

  446 ?        S     56:09 perl fhem.pl fhem.cfg
29924 ?        S      0:00 perl fhem.pl fhem.cfg

der Befehl

Code Auswählen Erweitern

ps -ef | grep ccurpcd.pl
bringt folgendes Ergebnis:

Code Auswählen Erweitern

fhem       559   446  0 Apr01 ?        00:13:44 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.xx.yyy 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
pi       30164 29910  0 08:30 pts/0    00:00:00 grep --color=auto ccurpcd.pl

[zap]

Der RPC Server läuft, aber HMCCU merkt das nicht. Bitte mal folgenden Befehl ausführen und die Ausgabe posten:

Code Auswählen Erweitern

ps ax | grep ccurpcd

Welches Berriebssystem?

[tuppertasse]

Betriebssystem ist Debian Wheezy 7.9
proc ergibt:

Code Auswählen Erweitern

Linux version 4.1.20-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) )

Abfrage ergibt:

Code Auswählen Erweitern


  559 ?        S     14:34 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.xx.yyy 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
4366 pts/0    S+     0:00 grep --color=auto ccurpcd


[zap]

Die Ausgabe passt. Ist mir ein Rätsel, warum die Prozessprüfung in HMCCu fehl schlägt (ich meine die "pdump" Fehlermeldung in Deinem Logfile).

Einzige verbleibende Möglichkeit: HMCCU findet den ps Befehl nicht bzw. der User fhem darf den nicht ausführen. Das würde mich doch aber sehr wundern. Das ist schwierig zu testen, muss ich erst mal drüber nachdenken.

Nachgedacht: Gib mal bitte in der Eingabezeile der FHEM Oberfläche folgende Zeile ein:

Code Auswählen Erweitern


{`ps ax | grep ccurpcd`}


Es sollte der RPC Prozess angezeigt werden. Bitte beachten: Die Anführungszeichen sind umgedreht, im Zweifel die Zeile oben einfach kopieren.

[tuppertasse]

Hallo anbei das Ergebnis der Abfrage:

Code Auswählen Erweitern

  559 ?        S     17:14 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.40.141 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
23003 ?        S      0:00 sh -c ps ax | grep ccurpcd
23005 ?        S      0:00 grep ccurpcd

Verstehen tue ich das grad nicht. Ich frag mich nur ob es richtig ist dass noch ein Prozess gestartet wird wenn ich den rpcserver starte und FHEM mir dann auch running und OK anzeigt. grübelgrübel

[zap]

Wenn ich es richtig verstanden habe, startest Du den RPC-Server. In FHEM wird "running" angezeigt. Aber nach kurzer Zeit geht die Anzeige auf "stopped". Trotzdem läuft der Prozess ccurpcd.pl weiter.

Hintergrund zu der ganzen Testerei: HMCCU prüft alle paar Sekunden, ob der Prozess ccurpcd.pl noch läuft. Dazu wird der Unix-Befehl "ps" verwendet. Aus irgendwelchen Gründen funktioniert bei Dir diese Prüfung nicht richtig. Darauf deutet die Fehlermeldung mit dem "pdump" im Logfile von FHEM hin.

Meine Vermutung war nun, dass der Nutzer "fhem" nicht die notwendigen Rechte hat, um "ps" auszuführen oder die Datei nicht findet. Daher die manuelle Ausführung über die Kommandozeile von FHEM. Da da funktioniert hat, liegt das Problem woanders.

Blöd ist: Du bist der einzige mit diesem Problem.

Oder kann ich Dein Frage so interpretieren, dass es nun doch läuft und nun nicht "stopped" sondern "running" angezeigt wird?

[tuppertasse]

Blöd ist: Du bist der einzige mit diesem Problem.

immer ich 

Oder kann ich Dein Frage so interpretieren, dass es nun doch läuft und nun nicht "stopped" sondern "running" angezeigt wird?

Nein ist weiterhin so. Allerdings könnte ich schwören, dass wenn ich jetzt in FHEM den befehl eingebe um die rpcserver zu starten wird ein ZWEITER Prozess gestartet. Ich meine mich zu erinnern, dass dann noch ein Prozess gestartet wird, der dann irgendwann abbricht. Die Frage ist woher und wer7was/wo startet den jetzigen Prozess  

ERGÄNZUNG 08.08:
Den Prozess bekomme ich aus FHEM nicht mehr gestoppt --> siehe Filelog Eintrag:

Code Auswählen Erweitern

2016.04.04 08:04:40 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pid=559
2016.04.04 08:04:40 1: HMCCU: d_HMCCU2 Start of RPC server failed
2016.04.04 08:05:25 0: HMCCU: RPC server not running
2016.04.04 08:05:43 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pid=559
2016.04.04 08:05:43 1: HMCCU: d_HMCCU2 Start of RPC server failed

Die Frage ist also liefen zwei Prozesse oder ist der rpcserver mit Fehler ausgestiegen und konnte nicht beendet werden. Das weiss ich nicht. Ich kille den Prozess jetzt und starte nochmal den rpcserver

Update 08:15:
Prozess konnte nur mit kill -9 beendet werden.
Neu gestartet mit FHEM ohne Probleme. Test läuft also