Neues Modul HMCCU für Homematic CCU

zap · 28 Januar 2016, 18:01:26

Zitat von: luke666s am 28 Januar 2016, 16:07:16
Kann es sein, dass es Probleme mit Homematic Device Namen gibt wenn diese ein " " also quasi ne Leerstelle enthalten? Ich kann sie nämlich nur über die Adresse einbinden. Wenn ich dann aber was schalten will, gibt es einen "script fehler".

Habe jetzt mal mit einer Steckdose, die ich noch rumliegen hatte getestet. Die Steckdose habe ich als "TEST LICHT" in der CCU angelernt. Dann in FHEM im HMCCU Modul ein "get devicelist".

Folgender Befehl funktioniert dann nicht:

Code Auswählen


define testlicht HMCCUDEV TEST LICHT 1

Leider trennt FHEM in der Kommandozeile bei jedem Leerzeichen gnadenlos. Ich habe es mit " und ' versucht. Ich habe vor das Leerzeichen ein oder zwei \ eingefügt und auch das Leerzeichen durch %20 ersetzt. Bringt alles nix. Beim Define muss also die Adresse verwendet werden, sofern der CCU Gerätename Leerzeichen enthält (ja, ich könnte im Modul alles in einen String joinen, das wird aber beliebig komplex, weil ja auch noch die Angabe des Statechannels möglich sein soll). Ich hoffe, man kann mit dieser Unannehmlichkeit leben.

Das Schalten funktioniert bei mir aus HMCCUDEV heraus jedoch einwandfrei. Habe folgendes getestet:

Code Auswählen


attr testlicht statevals on:true,off:false
set testlicht on
set testlicht datapoint 1.STATE off

Kannst Du bitte mal Deine Gerätedefinition posten? Bei welchem Befehl kommt der Script Error?

In HMCCU direkt gibt es natürlich wieder die Problematik mit der Parameter-Trennung bei Leerzeichen.

Zitat
Wo finde ich die scripte auf dem raspi?

Als Dateien gar nicht. Die Scripte sind direkt im Modulcode als Textstrings hinterlegt.

luke666s · 28 Januar 2016, 21:12:04

also... ja passt man kann die devices an der ccu ja auch umbenennen... mit . statt " " passt es... fast...
ich dachte naiv ein guter fhem name sei "ccu2_Schlafzimmer_Licht_am_Bett" und wollte das CCU Device "Schlafzimmer.Licht.am.Bett" nehmen... das klappte aber auch nicht...
wenn ich das Kürze passt es...

ich habe jetzt nur das Problem wenn ich bei der definition der ccu den rpcserver auf on setzte... dauert es nicht lange und die ccu reagiert nicht mehr....

zap · 29 Januar 2016, 07:24:18

Punkte im CCU Gerätenamen machen Probleme. Mich wundert, dass die CCU das überhaupt akzeptiert. Grund: Der Punkt wird als Abgrenzung in der CCU Geräte/Datenpunkt Notation verwendet. Ein Datenpunkt wird in der CCU wie folgt adressiert:

Interface.Kanal-Name.Datenpunkt (z.B. "BidCos-RF.LICHT-SCHLAFZIMMER:1.STATE")

oder

Interface.Kanal-Adresse.Datenpunkt (z.B. "BidCos-RF.ABC1234567:1.STATE")

Zum RPC-Server: Nach dem Setzen von rpcserver=on meldet sich der RPC-Server Prozess bei der CCU an. Diese Anmeldung dauert 3 Minuten. Während dieser Zeit ist die CCU nicht zu gebrauchen, d.h. ein Zugriff auf das Webinterface geht - wenn überhaupt - extrem schleppend. Meinst Du das mit "nicht reagieren"? Wenn ich meine CCU während der 3 Minuten in Ruhe lasse, läuft der RPC-Server und die CCU problemlos (mein Rekord liegt bei 2 Wochen, nur unterbrochen, weil ich FHEM upgedated habe).

Du kannst Dir aber mal das CCU Logfile anschauen, ob da Fehlermeldungen drin stehen: /var/log/messages
Kann man entweder über die Oberfläche der CCU runterladen oder direkt nach Anmeldung per SSH an der CCU anschauen.

luke666s · 29 Januar 2016, 09:42:31

ahhh... wieder was gelernt

ja, das meinte ich mit nicht reagieren.... genau... hatte aber auch keine 3 min gewartet... bin ja ehrlich... ich hatte das gestern abend alles so mehr oder minder im parallel betreib gemacht und mich geärgert, dass sobald rpcserver auf on war die ccu "weg" war...
dann geht es heute abend weiter

zap · 29 Januar 2016, 11:09:30

Die 3 Minuten sind mir auch ein Rätsel. Der RPC-Server schickt den Init an die CCU und dann dauert es exakt 3 Minuten, bis dieser Aufruf "zurückkehrt". Warum da so ist weiß wohl nur EQ-3.

luke666s · 29 Januar 2016, 12:19:53

neee.... irgendwas passt da nicht... das ding (ccu2) hängt jetzt über schon über 15 minuten... und die einzige änderung zu vorher war: rpcserver on als attr der ccu2 im fhem.

fhem.log
(http://i.imgur.com/QnNqUES.png)

ccurpcd_2001.log
(http://i.imgur.com/xu9SRgf.png)

/var/log/mesages auf der ccu
(http://i.imgur.com/KAIDabb.png)

zap · 29 Januar 2016, 13:03:35

Im ccurpcd_2001.log kommt nach dem "Registering callback ..." nix mehr? Das ist schlecht. Das ist genau die Stelle, wo es nach 3 Minuten weiter gehen sollte mit der Anzahl der Kanäle in der CCU.

Was mich wundert: Im Logfile auf der CCU tauchen Meldungen "rfd: Event ..." auf, die darauf hindeuten, dass die CCU events rausschickt. Hast Du noch was anderes laufen, das sich an die RPC-Schnittstelle der CCU andockt (obwohl das eigentlich funktionieren sollte, wenn es nicht gerade auch auf dem Raspi läuft)?

Ich muss mir das heute Abend auf meiner CCU mal anschauen und die Meldungen vergleichen.

luke666s · 29 Januar 2016, 13:57:09

neee.. nix.. hab auch auf der ccu2 nur noch den CuxD als Plugin (welcher ja auch über rpc kommuniziert) drin.. allles andere habe ich schon raus geschmissen...
Die firmware auf der ccu2 ist 2.15.5, und auf dem frisch installierten raspi läuft fhem 5.7 als dpkg installiert und die HHCCU sachen habe ich ausm SVN

zap · 29 Januar 2016, 16:28:08

CUxD hab ich auch, ist also kein Thema. Bei mir schreibt die CCU überhaupt keine Meldungen in /var/log/messages, wenn ich den RPC Server starte. Du kannst mal auf der CCU prüfen, ob der RFD richtig läuft:

Code Auswählen


# ps -ef | grep `fuser 2001/tcp`
  311 root     /bin/rfd -d -f /etc/config/rfd.conf -l 5

Ich teste das jetzt mal bei mir mit vollem Logging auf der CCU. Und hier das Ergebnis: Nichts zu finden, was auf einen Fehler hindeutet. Beim "Registering Callback ..." steht im CCU Log "user.debug rfd: PlatformInit()". Dann kommt 3 Minuten nichts und danach geht der Event-traffic los.

Das ist bei Dir der letzte Eintrag. Hast Du mal die CCU neu gestartet?

UPDATE: Lies mal ab hier http://forum.fhem.de/index.php/topic,40189.msg376774.html#msg376774
die Beiträge von mifh. Der hatte das gleiche Problem. Scheint mit den Versionen der Perl RPC Module zusammen zu hängen (Evtl.)

luke666s · 29 Januar 2016, 21:59:22

die beiträge kannte ich schon

das paket war schon installiert und PRC::XML ist v1.60 laut cpan

Code Auswählen

 317 root     /bin/rfd -d -f /etc/config/rfd.conf -l 1

läuft auch...

Edit 22:07:
AAAAABER... ich schaue mir grad dein code an... Welche Perl Version hast du? bzw auf welchem OS arbeitest du? raspbian mit wheezy hat nur perl 5.14 FindBin ist aber erst ab 5.2 erhältlich...
ich versuch mal ein neues perl über cpan zu bauen oder hat jemand nen backport???

next edit:
perl über cpan updaten geht nicht :

oh man dann halt ein debian upgrade... könnte alles so leicht sein, wenn der microsd/sd adapter nicht auf der arbeit liegen würde...

Code Auswählen

Elapsed: 5809 sec
u=44.58  s=10.55  cu=2357.70  cs=92.32  scripts=2208  tests=707885
  SHAY/perl-5.22.1.tar.bz2
  /usr/bin/make test -- OK
Running make install
make: *** No rule to make target '/usr/include/arm-linux-gnueabihf/bits/predefs.h', needed by 'perlmini.o'.  Schluss.
  SHAY/perl-5.22.1.tar.bz2
  /usr/bin/make install  -- NOT OK
root@raspi:/opt/fhem#

luke666s · 30 Januar 2016, 19:19:09

Problem gelöst!!!
Update auf Debian Jessie und mit 5.2er perl und FindBin klappts...
komischerweise kam bei wheezy mit 5.16 ohne FindBin keine Fehlermeldung....

zap · 31 Januar 2016, 12:14:08

Zitat von: luke666s am 30 Januar 2016, 19:19:09
Problem gelöst!!!
Update auf Debian Jessie und mit 5.2er perl und FindBin klappts...
komischerweise kam bei wheezy mit 5.16 ohne FindBin keine Fehlermeldung....

Freut mich, dass es läuft!

Ich glaube nicht, dass es am FindBin lag. Das wird nur benötigt, damit das folgende "use RPCQueue" das Modul RPCQueue.pm findet. RPCQueue.pm wiederum hat nichts mit der CCU Kommunikation zu tun sondern kümmert sich nur um das Schreiben/Lesen der File-Queue.

Vermutlich wurden durch das Update auf Jessie mit neuem Perl einige Probleme im RPC-Umfeld behoben. Der Vollständigkeit halber hier noch die von mir verwendete Umgebung:

Debian Wheezy (brauche ich, da es sich bei meinem Raspi eigentlich um eine Meteohub Installation handelt, auf die ich FHEM mit drauf gepackt habe)
Perl 5.14.2
RPC::XML::Server.pm 1.73
RPC::XML::Client.pm 1.42

Entwicklung unter MacOSX, Kontakt zu Linux vermeide ich wenn es geht aufgrund negativer Erfahrungen mit der Library- bzw. Version- bzw. Dependency-Hölle

dferch · 07 Februar 2016, 19:15:12

Hallo,

ich verwende seit ein paar Tagen auch die neuste Version des HMCCU-Modul und möchte meine Thermostate (HM-CC-RT-DN) auslesen und steuern. Nach dem Update auf die aktuellste Version hab ich die Thermostate als HMCCUCHN angelegt. Das sieht so aus:

Code Auswählen


<FHZINFO> 
	<HMCCUCHN_LIST> 
		<HMCCUCHN name="HM_BZ_Thermostat" state="23.0" sets="config datapoint devstate:" attrs="verbose:0,1,2,3,4,5 room group comment:textField-long alias eventMap userReadings:textField-long IODev ccureadingfilter ccureadingformat:name,address,datapoint ccureadings:0,1 ccustate ccuget:State,Value controldatapoint statedatapoint statevals substitute stripnumber:0,1,2 loglevel:0,1,2,3,4,5,6 event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr"> 
			<INT key="CFGFN" value=""/> 
			<INT key="CHANGED" value=""/> 
			<INT key="DEF" value="LEQxxxxxxx:4"/> 
			<INT key="NAME" value="HM_BZ_Thermostat"/> 
			<INT key="NR" value="97153"/> 
			<INT key="STATE" value="23.0"/> 
			<INT key="TYPE" value="HMCCUCHN"/> 
			<INT key="ccuaddr" value="LEQxxxxxxx:4"/> 
			<INT key="ccudevstate" value="Active"/> 
			<INT key="ccuif" value="BidCos-RF"/> 
			<INT key="ccuname" value="BZ_Heizung"/> 
			<INT key="ccutype" value="HM-CC-RT-DN"/> 
			<INT key="channels" value="1"/> 
			<INT key="statevals" value="devstate"/> 
			<INT key="IODev" value="hmccu2"/> 
			<ATTR key="IODev" value="hmccu2"/> 
			<ATTR key="ccureadingfilter" value="(SET_TEMPERATURE|ACTUAL_TEMPERATURE|CONTROL_MODE|FAULT_REPORTING|BATTERY_STATE)"/> 
			<ATTR key="ccureadings" value="1"/> 
			<ATTR key="group" value="Heizung"/> 
			<ATTR key="room" value="Bad"/> 
			<ATTR key="statedatapoint" value="SET_TEMPERATURE"/> 
			<ATTR key="stripnumber" value="1"/> 
			<ATTR key="substitute" value="CONTROL_MODE!0:Auto,1:Manual,2:Party,3:Boost;;FAULT_REPORTING!0:Ok,4:CommError,6:LowBat,(1|2|3|5|7):GenError"/> 
			<STATE key="BZ_Heizung.ACTUAL_TEMPERATURE" value="26.7" measured="2016-02-07 18:55:47"/> 
			<STATE key="BZ_Heizung.BATTERY_STATE" value="2.7" measured="2016-02-07 18:55:47"/> 
			<STATE key="BZ_Heizung.CONTROL_MODE" value="Auto" measured="2016-02-07 18:55:47"/> 
			<STATE key="BZ_Heizung.FAULT_REPORTING" value="Ok" measured="2016-02-07 18:55:47"/> 
			<STATE key="BZ_Heizung.SET_TEMPERATURE" value="23.0" measured="2016-02-07 18:55:47"/> 
			<STATE key="state" value="23.0" measured="2016-02-07 18:55:47"/> 
		</HMCCUCHN> 
	</HMCCUCHN_LIST> 
</FHZINFO>

Soweit ok. Ich kann die Temperatur setzen:

Code Auswählen


set HM_BZ_Thermostat devstate 22

Dann ist die Temperatur bei 22°. Prima. Jetzt würde ich aber auch gerne noch die Thermostate in "Manuell", "Automatik" oder "Boost" setzen. Das klappt zwar, aber ich erhalte in FHEM einen Fehler. Der Befehl ist (manuell/aus):

Code Auswählen


set HM_BZ_Thermostat datapoint MANU_MODE 4.5

Im Logfile steht dann:

Code Auswählen


HMCCU: Error URL = http://192.168.2.21:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:4.AUTO_MODE").Value()
HMCCUCHN: HM_BZ_Thermostat Execution of CCU script failed

Ich hab etwas im Homematic-Forum gesucht und der Befehl zum Setzen des "AUTO_MODE" müsste so aussehen:

Code Auswählen


http://192.168.2.21:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:4.AUTO_MODE").State(1);

Unterstützen die HMCCU-Module das Setzen des Modus eines Thermostat ? Wenn ja, was muss ich tun ?

Vielen Dank schonmal,
Gruß,
David

zap · 07 Februar 2016, 19:54:22

Könnte sein, dass das ein Fehler im Modul ist. Setze bitte mal testweise das Attribut ccuget auf State und versuch das nochmal.

Kann das leider erst morgen abend testen.

Das seh ich gerade erst, was spricht gegen

set HM_BZ_Thermostat datapoint AUTO_MODE 1

dferch · 07 Februar 2016, 20:11:05

Hi Zap,

klasse - das funktioniert. Nach Setzen von ccuget=State klappt es:

Manueller Modus

Code Auswählen

set HM_BZ_Thermostat datapoint MANU_MODE 4.5

Automatik Modus

Code Auswählen

set HM_BZ_Thermostat datapoint AUTO_MODE 1

Wenn ich das jetzt für 7 Thermostate einstelle, wird dann die Kommunikation zwischen FHEM/CCU verlangsamt (wie es in der Doku beschrieben ist) ? Wird die direkte Kommunikation zum Thermostat nach setzen von ccuget=State auch für die Aktualisierung der Readings ausgeführt oder nur beim SET von Datenpunkten ?

Vielen Dank und Gruß,
David