Neues Modul HMCCU für Homematic CCU

zap · 05 Januar 2016, 19:33:02

Neue Version der Module / Dateien eingecheckt. Link siehe 1. Post.

Bei der Installation beachten: Vor dem Reload der Module den RPC-Server stoppen, dann "reload", danach "get devicelist" (IOdev), dann RPC-Server wieder starten.

Bug fixes:

Fehler beim Prüfen auf laufenden RPC Server Prozess unter MacOS behoben.

Neue Funktionen:

In jedem Client Device (definiert über HMCCUDEV oder HMCCUCHN) steht nun der Befehl "get update" zur Verfügung. Dieser Befehl aktualisiert alle Datenpunkte / Readings eines Client Devices unter Berücksichtigung der Attribute "ccureadings" und "ccureadingfilter". Der Befehl kann z.B. direkt nach der Definition eines Client Devices ausgeführt werden, um den aktuellen Zustand abzufragen (der RPC Server aktualisiert die Client Devices nur bei Änderungen).
Im IO Device (HMCCU) steht ebenfalls der Befehl "get update" zur Verfügung. Dieser Befehl aktualisiert alle Datenpunkte / Readings aller Client Devices. Die zu aktualisierenden Client Devices können durch die optionale Angabe eines Filters für den FHEM Devicename eingeschränkt werden. Es bietet sich an, diesen Befehl als Reaktion auf den globalen FHEM Event "INITIALIZED" per Notify auszuführen, um nach dem Start von FHEM alle Client Devices auf den aktuellen Stand zu bringen.
Beim Update der Stati von Client Devices vom Typ HMCCUDEV (Attribute "statechannel" und "statedatapoint") wird nun auch der Statechannel berücksichtigt. Dadurch werden die Stati von Client-Devices korrekt aktualisiert, die mehrere Kanäle mit identischen Datenpunkten haben (z.B. Schließerkontakte). D.h. es können nun z.B. für einen Schließerkontakt 3 Client-Devices vom Typ HMCCUDEV definiert werden, die sich jedoch im Attribut "statechannel" unterscheiden müssen. Trotz dieser neuen Funktion empfehle ich, in solchen Fällen auf das Modul HMCCUCHN zurück zu greifen und für jeden Kanal ein eigenes Device in FHEM zu definieren.

Testversion des RPC Servers für Wired und Funk:

Als Attachment gibt es eine "Probierversion" eines RPC-Servers, der hoffentlich in der Lage ist, BidCos-RF und Wired Events gleichzeitig zu empfangen. Vielleicht kann das mal jemand testen, der beide Arten von Komponenten in Betrieb hat. Zur Installation:

RPC-Server im IO Device stoppen
Kopie der Orginaldatei anlegen
Attachment ccurpcmpd.pl unter dem Namen ccurpcd.pl im FHEM Modulverzeichnis speichern (Rechte setzen!)
Für das IO Device das Attribut "rpcport" auf "2001,2000" setzen
RPC-Server im IO Device starten

Wenn es funktioniert oder auch nicht wäre Feedback schön. Bei Fehlern möglichst mit der ccurpcd.log

FitzZZ · 05 Januar 2016, 20:16:00

Zitat von: zap am 28 Dezember 2015, 09:28:54
Das geht natürlich und ich überlege, das auch so in die offiziellen Module aufzunehmen. Allerdings wird damit die Wartezeit zwischen set und nachfolgendem get verzehnfacht (100 ms => 1 s). Im Prinzip ist das usleep() und das get nur erforderlich, wenn kein RPC-Server verwendet wird, denn der RPC-Server wird durch das Set sowieso ein Event mit dem geänderten Wert von der CCU bekommen.

Die Fehlermeldung bei RainerG besagt eindeutig, dass usleep nicht gefunden wurde. Deshalb schmiert FHEM ab. Ich vermute immer noch, dass hier zwar die aktuellen Module und auch Time::HiRes installiert wurden, die Module aber mangels Reload bzw. FHEM-Neustart (Reload genügt normalerweise) nicht verwendet werden.

Hi zap!

Ich hab gestern angefangen Dein Werk bei mir einzuarbeiten (erstmal dickes DANKE für die viele Arbeit!!)

Ich habe Rainers Problem - Time::HiRes ist auf Version 1.9728 und der RPi und damit auch FHEM haben schon mehrere Neustarts hinter sich... sollte ich auch auf sleep gehen oder kannst Du noch was ändern?

Danke und VG

hometux · 05 Januar 2016, 20:45:05

Hallo zap,

Das ist ja ein richtig tolles Weihnachtsgeschenk - ganz vielen Dank.

Ich konnte eben nur ganz kurz einen ersten Probelauf durchführen.

Es sieht erst einmal toll aus, wenn nach einem get ccu update alle Geräte sofort mit Daten da sind. Das funktioniert offensichtlich.
Ein Problem habe ich noch bei der Aktivierung des 2. RPC Dienstes. Hier führt das Eintragen der beiden Ports zu einem Fehler, in dessen Folge sich der RPC Dienst beendet. Sieht mir aber eher nach Kleinigkeit aus.

Zitat2016.01.05 20:31:14 1: Including fhem.cfg
2016.01.05 20:31:14 3: WEB: port 8083 opened
2016.01.05 20:31:14 3: WEBphone: port 8084 opened
2016.01.05 20:31:14 3: WEBtablet: port 8085 opened
2016.01.05 20:31:14 2: eventTypes: loaded 1648 events from ./log/eventTypes.txt
"my" variable $value masks earlier declaration in same scope at ./FHEM/88_HMCCU.pm line 1747, <$fh> line 54.
2016.01.05 20:31:16 1: HMCCU: RPC server started with pid 10659
Argument "2001,2000" isn't numeric in addition (+) at ./FHEM/ccurpcd.pl line 129.
Error: Can't initialize RPC server
2016.01.05 20:31:16 1: Including ./log/fhem.save
2016.01.05 20:31:16 0: Featurelevel: 5.7
2016.01.05 20:31:16 0: Server started with 128 defined entities (fhem.pl:10220/2015-12-21 perl:5.018002 os:linux user:fhem pid:10657)

2016.01.05 20:32:16 1: HMCCU: RPC server has been shut down. f=0

Wie gesagt, ich konnte eben nur kurz probieren, morgen weiss ich mehr.

lukasbastelpeter · 05 Januar 2016, 21:50:34

Hi FitzZZ, sorry ich bin grad unterwegs, suche mal in dem Thread nach meiner Lösung mit
Use Time:Res ...
Das hinter Time::Res war bei mir das ausschlaggebende.

Nochmals vielen Dank an zap!
Btw: wie muss ich einen Dimmer "set"en damit er an oder aus oder vielleicht sogar auf einen bestimmten Wert geht?

Danke!

zap · 05 Januar 2016, 21:56:54

Zum Thema Time::Hires

Ich werfe das usleep morgen raus. Wer heute schon ne Lösung will: in den .pm Files nach usleep suchen und entweder die Zeile rauswerfen oder, wenn man den RPC Server nutzt, sowohl usleep als auch das folgende Get löschen. Alternativ kann man auch usleep() durch sleep(1) ersetzen.

FitzZZ · 05 Januar 2016, 23:15:57

Zitat von: lukasbastelpeter am 05 Januar 2016, 21:50:34
Hi FitzZZ, sorry ich bin grad unterwegs, suche mal in dem Thread nach meiner Lösung mit
Use Time:Res ...
Das hinter Time::Res war bei mir das ausschlaggebende.

Zitat von: zap am 05 Januar 2016, 21:56:54
Zum Thema Time::Hires

Ich werfe das usleep morgen raus. Wer heute schon ne Lösung will: in den .pm Files nach usleep suchen und entweder die Zeile rauswerfen oder, wenn man den RPC Server nutzt, sowohl usleep als auch das folgende Get löschen. Alternativ kann man auch usleep() durch sleep(1) ersetzen.

Danke euch beiden!

zap · 06 Januar 2016, 07:45:33

Zitat von: lukasbastelpeter am 05 Januar 2016, 21:50:34
Btw: wie muss ich einen Dimmer "set"en damit er an oder aus oder vielleicht sogar auf einen bestimmten Wert geht?

Schau mal hier und suche nach "dimmer":

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

Scheint im Kanal 1 (abhängig vom Gerätetyp) der Datenpunkt LEVEL zu sein. Den kannst Du auf Werte zwischen 0.0 und 1.0 setzen. Ruf doch einfach mal "get deviceinfo" für den Dimmer auf, dann siehst Du alle Datenpunkte mit den aktuellen Werten.

hjjk · 06 Januar 2016, 16:02:24

Zum Thema Time::Hires

Bei meinen Versuchen auf raspberry wheezy 3.9.40 mit perl 5.14.2 stürzte fhem immer bei den Aufrufen usleep ab.
Ich habe dann in 88_HMCCUDEV.pm use Time::HiRes durch use Time::Hires qw(gettimeofday usleep); ersetzt/ergänzt.
Seitdem läuft es bei mir.

zap · 06 Januar 2016, 17:28:50

Zitat von: hjjk am 06 Januar 2016, 16:02:24
Zum Thema Time::Hires

Bei meinen Versuchen auf raspberry wheezy 3.9.40 mit perl 5.14.2 stürzte fhem immer bei den Aufrufen usleep ab.
Ich habe dann in 88_HMCCUDEV.pm use Time::HiRes durch use Time::Hires qw(gettimeofday usleep); ersetzt/ergänzt.
Seitdem läuft es bei mir.

Jep. Mittlerweile bin ich auch drauf gekommen. Updates habe ich gerade eingecheckt. Damit sollte das usleep() Thema hoffentlich erledigt sein (betraf nur HMCCUDEV und HMCCUCHN). Außerdem habe ich noch einen kleinen Bug in HMCCU gefixt.

@hometux: Die Fehlermeldung beim Starten des RPC-Servers für Wired/Wireless ist seltsam. Bei mir funktioniert das. Anbei eine neue Version mit einem zusätzlichen Log-Statement. Bitte dann mal die letzten Zeilen der ccurpcd.log posten. Wie sieht bei Dir das Attribut "rpcport" aus? Falls Du statt 2001,2002 da "2001,2002" (in Anführungszeichen) stehen hast, lass die mal weg.

hometux · 06 Januar 2016, 19:16:10

Hallo zap,

Es funktioniert!
Das Problem lag wohl daran, dass in einem alten Post noch ein anderer Name für den RPC-Server angegeben war. Dadurch blieb der alte RPC Dienst weiterhin in Betrieb. Nachdem ich dies heute abend bereinigt habe, läuft der neue RPC Dienst ohne Fehler und sieht auch bisher sehr gut aus.

Eine kleine Auffälligkeit mit HMCCUDEV habe ich bein Testen noch gefunden (ist kein wirkliches Problem, aber evtl. Indiz für eine Unschärfe). Ich versuche einmal, es zu beschreiben:

a) HM-Sec-TiS (Neigungssensor) liefert als HMCCUDEV beim "get xxx update" Befehl (interessanterweise auch bei "get ccu update") einen Fehler (nur im Dialog, nicht im Logfile). Führt man stattdessen den "get xxx devstate" Befehl aus, wird der Status korrekt gelesen und substituiert. Ich habe daraufhin den Sensor als HMCCUCHN definiert. Anschließend funktioniert auch der get xxx update Befehl einwandfrei. In beiden Fällen war übrigens die Definition als readonly erfolgt.

b) HM-Sec-SD (Rauchmelder) liefert als HMCCUDEV readonly mit "get xxx devstate" einen auswertbaren Status (0/1). Ruft man stattdessen den "get xxx update" Befehl auf, so wird kein Wert geliefert, allerdings auch kein Fehler. Der Status verbleibt auf initialized. In diesem Fall brachte ein Umstellen auf HMCCUCHN nichts.

Das Verhalten wirkt so ähnlich wie ein entsprechender Readingsfilter.

Ansonsten bin ich hoch begeistert. Es sieht einfach toll aus, wenn einem nach dem Start jetzt der vollständige Status entgegenleuchtet.

zap · 06 Januar 2016, 21:10:00

Zitat von: hometux am 06 Januar 2016, 19:16:10
Hallo zap,

Es funktioniert!

D.h. Es werden sowohl wired als auch bidcosrf Devices vom RPC Server aktualisiert? Wenn dem so ist, werde ich den neuen Server einchecken.

Zitat
Das Problem lag wohl daran, dass in einem alten Post noch ein anderer Name für den RPC-Server angegeben war. Dadurch blieb der alte RPC Dienst weiterhin in Betrieb. Nachdem ich dies heute abend bereinigt habe, läuft der neue RPC Dienst ohne Fehler und sieht auch bisher sehr gut aus.

Das war ja so gedacht, dass die Datei ccurpcmpd.pl aus dem Attachment in meinem Post die bisherige ersetzen soll, und zwar unter dem Namen ccurpcd.pl. Nur die kennt HMCCU.

Zu den get update Problemen: Hast Du die 88_HMCCU.pm von heute nochmal runtergeladen? In get update gab es beim Substitute noch einen Fehler.

Ansonsten poste bitte mal die Definition des problematischen Devices und die Ausgabe von get deviceinfo mit dem Fehler.

hometux · 06 Januar 2016, 21:51:19

Hallo zap,

Das Update von heute habe ich eingespielt. Auch damit beobachte ich das Update Problem.

Ich würde das Verhalten gerne noch einen Tag beobachten, bis ich ein Gesamtbild habe. Zeitweilig hatte ich das Gefühl, dass Aktualisierungen später kommen, aber das kann auch der Einlesephase geschuldet sein.

zap · 07 Januar 2016, 08:11:45

Zitat von: hometux am 06 Januar 2016, 21:51:19
Hallo zap,

Das Update von heute habe ich eingespielt. Auch damit beobachte ich das Update Problem.

Ich würde das Verhalten gerne noch einen Tag beobachten, bis ich ein Gesamtbild habe. Zeitweilig hatte ich das Gefühl, dass Aktualisierungen später kommen, aber das kann auch der Einlesephase geschuldet sein.

Schau Dir mal die Zeitstempel für die Startphase des RPC-Servers in der Datei ccurpcd.log an. Normalerweise lässt sich die CCU für die Registrierung der Callback-Funktion exakt 3 Minuten Zeit. Da Du nun 2 Ports (2000 und 2001) registrierst, könnte sich diese Zeit verdoppeln. D.h. in den ersten 6 Minuten nach dem Start des RPC-Servers kommen keine Events (Vermutung, habe kein Wired und nutze nur einen Port).

Ansonsten wird die Aktualisierungsfrequenz durch das Attribut rpcinterval bestimmt.

hometux · 07 Januar 2016, 19:50:51

Hallo zap,

Hier die Ergebnisse meiner heutigen Probeläufe. Es scheint leider doch noch Probleme bei 2 parallelen RPC Prozessen zu geben.

Ich hatte zunächst die Einstellung
rpcport 2000,2001
Damit schienen alle Wired Ereignisse anzukommen. Wireless Ereignisse kamen nicht an, bzw. ich hatte den Eindruck das ganz selten einmal welche durchkamen.

Ich habe dann die Einstellung vertauscht. Bei der Einstellung
rpcport 2001,2000
kamen nach meinem Eindruck alle Wireless Ereignisse an. Wired Ereignisse habe ich nicht gesehen, allerdings hatte ich auch hier den Eindruck, dass ganz selten einmal doch eines "durchkam".

Im Logfile gab es keine Fehlermeldungen. Der (neue) rpc Prozess startete ohne Fehlermeldungen und blieb den ganzen Tag aktiv.

Zu der vorher beschriebenen HMCCUDEV Anomalie habe ich am Beispiel des Neigesensors HM-Sec-TiS (Verschluss_Schwingtor) folgendes Verhalten dokumentieren können. Wie gesagt, durch Definition als HMCCUCHN kann man das Problem einfach umgehen, aber es ist m.E. dennoch merkwürdig:

Vorgehen:

get ccu update
liefert Fehlerdialog:
103 client devices successfully updated. Update for 1 client devices failed

get Verschluss_Schwingtor update
liefert Fehlerdialog:
HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed
Readings:
state Error

get Verschluss_Schwingtor devstate
ist erfolgreich
Readings:
Schwingtor_Zustand.STATE zu
state zu

get Verschluss_Schwingtor deviceinfo
liefert Fehlerdialog:
HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed
(das steht auch im Logfile)

Die fhem.cfg dazu:

Zitatdefine Verschluss_Schwingtor HMCCUDEV LEQXXX6818 1 readonly
attr Verschluss_Schwingtor IODev ccu
attr Verschluss_Schwingtor devStateIcon auf:fts_garage_door_10@green zu:fts_garage_door_100@red .*:fts_garage_door_50@grey
attr Verschluss_Schwingtor fp_Grundriss_Garten 159,485,5, ,Verschluss_Schwingtor
attr Verschluss_Schwingtor group Verschluss
attr Verschluss_Schwingtor icon fts_garage
attr Verschluss_Schwingtor room Garage
attr Verschluss_Schwingtor statedatapoint STATE
attr Verschluss_Schwingtor substitute true:auf,false:zu,1:auf,0:zu
attr Verschluss_Schwingtor statechannel 1

Logfilemeldung lautet bei Fehler jeweils:

Zitat2016.01.07 18:29:30 1: HMCCU: Error URL = http://xx.xx.xx.xx:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQXXX6818:1.STATE").State()
2016.01.07 18:29:30 1: HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed

Jetzt habe ich das HMCCUDEV zu einem HMCCUCHN umdefiniert. Damit funktionieren die Befehle:

get ccu update
get Verschluss_Schwingtor update
get Verschluss_Schwingtor devstate

get Verschluss_Schwingtor deviceinfo
gibt es hier nicht, kann also auch keinen Fehler melden

Die fhem.cfg jetzt:

Zitatdefine Verschluss_Schwingtor HMCCUCHN LEQXXX6818:1 readonly
attr Verschluss_Schwingtor IODev ccu
attr Verschluss_Schwingtor devStateIcon auf:fts_garage_door_10@green zu:fts_garage_door_100@red .*:fts_garage_door_50@grey
attr Verschluss_Schwingtor fp_Grundriss_Garten 159,485,5, ,Verschluss_Schwingtor
attr Verschluss_Schwingtor group Verschluss
attr Verschluss_Schwingtor icon fts_garage
attr Verschluss_Schwingtor room Carport
#attr Verschluss_Schwingtor statechannel 1
attr Verschluss_Schwingtor statedatapoint STATE
attr Verschluss_Schwingtor substitute true:auf,false:zu,1:auf,0:zu

zap · 07 Januar 2016, 21:26:01

Danke für das Testen des RPC Servers. Das war ein Versuch, 2 Schnittstellen über einen Server abzufrühstücken. Funktioniert anscheinend nicht. Hatte ich befürchtet. Dann muss ich wohl den aufwändigeren Weg gehen und 2 Prozesse implementieren. In dem Fall musst Du noch etwas Geduld haben.

Zu dem Update Problem komme ich erst morgen.

Eine Frage: Du schreibst, dass "get Verschluss_Schwingtor devstate" funktioniert (auch über HMCCUDEV). Weiter unten schreibst Du aber, dass im Log eine Fehlermeldung auftaucht:

Code Auswählen


2016.01.07 18:29:30 1: HMCCU: Error URL = http://XX.XX.XX.XX:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQXXX6818:1.STATE").State()
2016.01.07 18:29:30 1: HMCCUDEV: Verschluss_Schwingtor Execution of CCU script failed

Das widerspricht sich m.E., zumal die erste Meldung von HMCCU kommt. Wird diese Meldung wirklich als Reaktion auf "get devstate" für ein HMCCUDEV Device geschrieben? Auch seltsam: beide Meldungen kommen zur gleichen Zeit.

Verstehe ich das richtig: "get update" funktioniert für alle HMCCUDEV Geräte, nur nicht für das Schwingtor?

Hintergrund meiner Fragen: Die Meldung "Execution of script failed" kann nur von meinem "get update", "get channel" oder "get deviceinfo" kommen. Die Meldung "Error URL ..." hingegen nur von einem "get devstate" oder "get datapoint".