Neues Modul HMCCU für Homematic CCU

[zap]

Hallo RPC Prozess Opfer!

Als Attachment eine neue Version der Datei 88_HMCCU.pm. Bitte im ./FHEM Verzeichnis speichern. Ich stelle die erst mal nicht in Sourceforge bereit. Erst wenn ich weiß, dass Eure Probleme damit behoben sind.

Funktional hat sich nichts geändert. Lediglich das Starten des RPC-Servers habe ich zeitlich entzerrt.

Bitte vor Tests mit der neuen Version aufräumen, soll heißen: Prüfen, dass alle ccurpcd Prozesse beendet sind. Falls noch welche laufen, diese wie weiter oben beschrieben beenden, damit die Schnittstelle sauber in der CCU deregistriert wird.

Dann die neue Version installieren und FHEM durchstarten. Darauf achten, dass das Attribut rpcserver auf 'off' steht und den RPC Server erst mal manuell starten.

So sieht es aus (im FHEM Log), wenn der RPC-Server (in diesem Fall sind es 2 wg. wireless und HM-IP) sauber gestartet wird:

Code Auswählen Erweitern


2016.04.08 15:35:12 0: HMCCU: RPC server started with pid 18064
2016.04.08 15:35:13 0: HMCCU: RPC server started with pid 18065
2016.04.08 15:35:20 1: HMCCU: Registering callback http://192.168.1.12:7401/fh2001 with ID CB2001 at http://homematic:2001/
2016.04.08 15:35:21 1: HMCCU: RPC callback with URL http://192.168.1.12:7401/fh2001 initialized
2016.04.08 15:35:21 1: HMCCU: Registering callback http://192.168.1.12:7410/fh2010 with ID CB2010 at http://homematic:2010/
2016.04.08 15:35:21 1: HMCCU: RPC callback with URL http://192.168.1.12:7410/fh2010 initialized
2016.04.08 15:35:26 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.08 15:35:26 0: HMCCU: Received IN event. RPC server CB2010 initialized.


Entscheidend ist "Received IN event ..."

Das Ganze im ccurpcd_2001.log:

Code Auswählen Erweitern


08.04.2016 15:35:13 Creating file queue
08.04.2016 15:35:13 Initializing RPC server
08.04.2016 15:35:13 Callback server created listening on port 7401
08.04.2016 15:35:13 Adding callback for events
08.04.2016 15:35:13 Adding callback for new devices
08.04.2016 15:35:13 Adding callback for deleted devices
08.04.2016 15:35:13 Adding callback for modified devices
08.04.2016 15:35:13 Adding callback for replaced devices
08.04.2016 15:35:13 Adding callback for readded devices
08.04.2016 15:35:13 Entering server loop. Use kill -SIGINT 18064 to terminate program
08.04.2016 15:35:20 ListDevices CB2001. Sending init to HMCCU
08.04.2016 15:35:23 NewDevice: received 228 device specifications


Entscheidend hier "ListDevices ... Sendind init to HMCCU"


Alles wird gut!

[Achiim]

Leider noch keine entscheidende Änderung:

Ich habe das neue Modul getestet und den RPCserver manuell gestartet, wie gewünscht

Code Auswählen Erweitern


2016.04.08 17:33:10 0: HMCCU: RPC server started with pid 7390
2016.04.08 17:33:17 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.08 17:33:18 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 17:37:39 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.08 17:37:39 0: HMCCU: RPC server(s) with PID(s) 7390 shut down. f=1
2016.04.08 17:37:40 0: HMCCU: All RPC servers stopped


Da sich nach 4 Minuten Warten nichts gezeigt hat, habe ich den RPSserver kontrolliert beendet, damit mein HMCCU auf "stopped" geht.

Folgendes habe ich in der ccu...2001.log:

Code Auswählen Erweitern


08.04.2016 17:33:24 Creating file queue
08.04.2016 17:33:24 Initializing RPC server
08.04.2016 17:33:28 Callback server created listening on port 7401
08.04.2016 17:33:28 Adding callback for events
08.04.2016 17:33:28 Adding callback for new devices
08.04.2016 17:33:28 Adding callback for deleted devices
08.04.2016 17:33:28 Adding callback for modified devices
08.04.2016 17:33:28 Adding callback for replaced devices
08.04.2016 17:33:28 Adding callback for readded devices
08.04.2016 17:33:28 Entering server loop. Use kill -SIGINT 7390 to terminate program
08.04.2016 17:37:38 RPC server terminated
08.04.2016 17:37:38 RPC server received 0 (1) events


Dann habe ich die CCU neu gestartet und den Test wiederholt:

Code Auswählen Erweitern


2016.04.08 17:46:04 0: HMCCU: RPC server started with pid 7614
2016.04.08 17:46:11 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.08 17:46:11 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 17:46:16 2: HMCCU: Received no events from CCU since 300 seconds


Und dann nichts mehr... (An dieser Stelle kann positiv hervorgehoben werden, dass die Logmeldung mit den 300s nur einmal kommt....  obwohl, seit dem Start des Prozesses sind erst 12s vergangen, da wundert sich der Leihe wie man da seit 300s auf etwas warten kann   )

In der ccu...2001.log:

Code Auswählen Erweitern


08.04.2016 17:46:20 Creating file queue
08.04.2016 17:46:20 Initializing RPC server
08.04.2016 17:46:23 Callback server created listening on port 7401
08.04.2016 17:46:23 Adding callback for events
08.04.2016 17:46:23 Adding callback for new devices
08.04.2016 17:46:23 Adding callback for deleted devices
08.04.2016 17:46:23 Adding callback for modified devices
08.04.2016 17:46:23 Adding callback for replaced devices
08.04.2016 17:46:23 Adding callback for readded devices
08.04.2016 17:46:23 Entering server loop. Use kill -SIGINT 7614 to terminate program


Ich erhalte kein "IN Event" von der CCU auf die Intiialisierung...

Hinweis:
Meine CCU hat den Firmwarestand: 2.17.15

Die ccuqueue_2001.dat ist bei mir jetzt leer.

(Ich fühle mich (noch) nicht als Opfer. Die Idee mit dem Modul HMCCU finde ich genial, wenn's denn mal läuft....  )

BTW:    Was sind eigentlich readded devices? Sterben die nach dem Lesen? Das ist dem "ccurpcd_2001.log" zu entnehmen..."Adding callback for readded devices" 

[zap]

Die Zeitstempel in der ccurpcd_2001.log liegen immer nach denen im FHEM-Log. Das ist gelinde gesagt "strange". So kann das nicht funktionieren.

Die Meldung "Entering server loop" im ccurpcd_2001.log muss zeitlich vor der Meldung "Registering callback ..." im FHEM-Log liegen. Sonst lauscht der RPC-Server noch nicht, wenn die CCU schon anfängt, Daten zu schicken. Dann geht der IN verloren.

Bei Dir wird der RPC-Server Prozess um 17:33:10 geforkt. Um 17:33:17 beginnt die Registrierung an der CCU. Die erste Meldung von dem gestarteten Prozess im ccurpcd_2001.log ist aber erst von 17:33:24 und der Server-Loop startet dann 4 Sekunden später. Nun frage ich mich: Was macht Deine Kiste 14 Sekunden lang?

Wenn Du das mal mit meinen Logs vergleichst: Da liegen die Meldungen in ccurpcd_2001.log VOR den Registrierungsmeldungen im FHEM Log.

Alleine von "Creating File Queue" bis "Entering Server Loop" vergehen bei Dir 4 Sekunden, während das bei mir 0 Sekunden dauert.

Also immer noch Timing Probleme. Ist Dein Server so ausgelastet? Schreib mal ein paar Infos zu Deinem System (Hardware, Betriebssystem).

[Achiim]

Das ist ein pi 2 B mit debian auf dem FHEM mit allen Komponenten die in meiner Fusszeile zu finden sind läuft... Anbei ein aktueller Screen-Shot der TOP-Prozesse..



Wenn ich's richtig verstanden habe, dann muss FHEM mit dem HMCCU Modul solange warten, bis sich der RPCserver in der Event-Loop befindet.... Das kann nicht Zuverlässig mit einer Wartezeit von x Sekunden gelöst werden. Hierzu solltest Du ein Signal vom RPC-Server an das FHEM-Modul HMCCU senden. Erst wenn dieses Signal da ist, ist das System "betriebsbereit"....

[Nic0205]

Hallo zap,

bei mir sieht es sehr ähnlich aus. Ich habe die gleiche Hardwarebasis (Pi 2B) und folgende Logs:
rpc-log

Code Auswählen Erweitern

08.04.2016 19:14:42 RPC server terminated
08.04.2016 19:14:42 RPC server received 41920 (41920) events
08.04.2016 19:32:55 Creating file queue
08.04.2016 19:32:55 Initializing RPC server
08.04.2016 19:32:56 Callback server created listening on port 7401
08.04.2016 19:32:56 Adding callback for events
08.04.2016 19:32:56 Adding callback for new devices
08.04.2016 19:32:56 Adding callback for deleted devices
08.04.2016 19:32:56 Adding callback for modified devices
08.04.2016 19:32:56 Adding callback for replaced devices
08.04.2016 19:32:56 Adding callback for readded devices
08.04.2016 19:32:56 Entering server loop. Use kill -SIGINT 1236 to terminate program
08.04.2016 19:32:59 ListDevices
08.04.2016 19:33:02 NewDevice: received 220 device specifications

fhem log

Code Auswählen Erweitern

2016.04.08 19:29:34 1: in SHUTDOWN
2016.04.08 19:29:34 0: Server shutdown
2016.04.08 19:29:35 0: HMCCU: RPC server not running
2016.04.08 19:29:40 1: Including fhem.cfg
2016.04.08 19:29:40 3: telnetPort: port 7072 opened
2016.04.08 19:29:41 3: WEB: port 8083 opened
2016.04.08 19:29:41 3: WEBphone: port 8084 opened
2016.04.08 19:29:41 3: WEBtablet: port 8085 opened
2016.04.08 19:29:41 2: eventTypes: loaded 17 events from ./log/eventTypes.txt
2016.04.08 19:29:41 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 40.
2016.04.08 19:29:45 1: Including ./log/fhem.save
2016.04.08 19:29:45 1: statefile: Please define CCU2 first
2016.04.08 19:29:45 1: in INITIALIZED
2016.04.08 19:29:45 1: usb create starting
2016.04.08 19:29:45 3: Probing CUL device /dev/ttyAMA0
2016.04.08 19:29:45 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.08 19:29:45 1: usb create end
2016.04.08 19:29:45 2: Error messages while initializing FHEM: statefile: Please define CCU2 first
2016.04.08 19:29:45 0: Featurelevel: 5.7
2016.04.08 19:29:45 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1551)
2016.04.08 19:29:45 3: ipc fronthem:127.0.0.1:33426 (ws): ws alive with pid 1552
2016.04.08 19:30:19 1: in ATTR
2016.04.08 19:31:01 1: in SAVE
2016.04.08 19:31:23 1: in SHUTDOWN
2016.04.08 19:31:23 0: Server shutdown
2016.04.08 19:31:23 0: HMCCU: RPC server not running
2016.04.08 19:32:00 1: Including fhem.cfg
2016.04.08 19:32:00 3: telnetPort: port 7072 opened
2016.04.08 19:32:02 3: WEB: port 8083 opened
2016.04.08 19:32:02 3: WEBphone: port 8084 opened
2016.04.08 19:32:02 3: WEBtablet: port 8085 opened
2016.04.08 19:32:13 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.08 19:32:15 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 34.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 34.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 34.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827, <$fh> line 34.
2016.04.08 19:32:39 1: Including ./log/fhem.save
2016.04.08 19:32:39 1: in INITIALIZED
2016.04.08 19:32:39 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.08 19:32:39 1: usb create starting
2016.04.08 19:32:40 3: Probing CUL device /dev/ttyAMA0
2016.04.08 19:32:40 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.08 19:32:40 1: usb create end
2016.04.08 19:32:40 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.04.08 19:32:40 0: Featurelevel: 5.7
2016.04.08 19:32:40 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 897)
2016.04.08 19:32:40 3: ipc fronthem:127.0.0.1:50723 (ws): ws alive with pid 1049
2016.04.08 19:32:52 0: HMCCU: RPC server started with pid 1236
2016.04.08 19:32:59 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.08 19:33:00 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.08 19:33:05 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.08 19:44:02 2: HMCCU: Received no events from CCU since 300 secondsns

ich habe ein HMDEV Gerät angelegt und den Status (ist ein Schalter) ein paar mal mit

Code Auswählen Erweitern

set kueche_wandleuchte on 

Code Auswählen Erweitern

set kueche_wandleuchte off an und aus gemacht. aber der rpc scheint davon nichts mitzubekommen, bzw. scheint er nicht mehr richtig zu laufen. das log sieht dann so aus:

2016.04.08 20:40:10 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
2016.04.08 20:40:14 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
2016.04.08 20:40:18 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed
2016.04.08 20:40:28 1: HMCCUDEV: Kueche_wandleuchte Execution of CCU script or command failed

[zap]

@Nico0205: Bei Dir läuft der RPC Server korrekt. Es scheint auch nicht an der Aktualisierung zu scheitern sondern schon beim Schalten selbst. Bitte poste mal die Definiton von der Lampe (list kueche_wandleuchte). Außerdem bitte noch Name und Adresse des zugehörigen Devices in der CCU.

@Achiim: Habe auch einen Raspi 2b. Auf meinem läuft neben FHEM noch ein Apache Webserver und ein Meteohub Wettestations Server. Meine CPU Last liegt bei <2%, die Load bei <0.3 und das bei ca. 150 Tasks.

Die Idee mit der Signalisierung kurz vor dem Serverloop hatte ich schon mal in einer der ersten Versionen eingebaut, das aber wieder als überflüssig verworfen, weil ich der Meinung war, dass 2-3 Sekunden Warten reichen sollte um einen Perl-Prozess zu starten. Scheinbar doch sinnvoll, kommt also wieder rein.

Trotzdem würde ich mir an Deiner Stelle mal Gedanken machen, was Deinen Rechner ausbremst. 4 Sekunden für die Ausführung von nicht mal 50 Zeilen Perlcode sind schon eine Hausnummer.

UPDATE: Gerade gesehen, dass Du anscheinend einen Desktop bzw. X-Server laufen hast. Das erklärt die Last. Habe ich mir gespart.

[Nic0205]

Hallo zap,

so ist die Definition:

Code Auswählen Erweitern

Internals:
   DEF        KEQ0170945 1
   IODev      d_ccu
   NAME       Kueche_wandleuchte
   NR         24
   STATE      false
   TYPE       HMCCUDEV
   ccuaddr    KEQ0170945
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    K�che Wandleuchten
   ccutype    HM-LC-Sw1PBU-FM
   channels   2
   statevals  devstate|on|off
   Readings:
     2016-04-08 21:50:54   K_che_Wandleuchten.0.AES_KEY 0
     2016-04-08 21:50:54   K_che_Wandleuchten.0.CONFIG_PENDING false
     2016-04-08 21:50:54   K_che_Wandleuchten.0.DEVICE_IN_BOOTLOADER false
     2016-04-08 21:50:54   K_che_Wandleuchten.0.DUTYCYCLE false
     2016-04-08 21:50:54   K_che_Wandleuchten.0.LOWBAT false
     2016-04-08 21:50:54   K_che_Wandleuchten.0.RSSI_DEVICE 1
     2016-04-08 21:50:54   K_che_Wandleuchten.0.RSSI_PEER 177
     2016-04-08 21:50:54   K_che_Wandleuchten.0.STICKY_UNREACH false
     2016-04-08 21:50:54   K_che_Wandleuchten.0.UNREACH false
     2016-04-08 21:50:54   K_che_Wandleuchten.0.UPDATE_PENDING false
     2016-04-08 21:50:54   K_che_Wandleuchten.INHIBIT false
     2016-04-08 21:50:54   K_che_Wandleuchten.INSTALL_TEST N/A
     2016-04-08 21:50:54   K_che_Wandleuchten.ON_TIME N/A
     2016-04-08 21:50:54   K_che_Wandleuchten.STATE false
     2016-04-08 21:50:54   K_che_Wandleuchten.WORKING false
     2016-04-08 21:50:54   state           false
Attributes:
   IODev      d_ccu
   statechannel 1
   statevals  on:true,off:false

[Achiim]

ERFOLG

Nachdem ich auf einen PI3 umgezogen bin und den Test wiederholt habe, startet der RPCserver und geht in den Status "Running". Siehe Screen-Shot. Es ist spät geworden... Morgen mehr...

[Achiim]

zum Stand der Dinge:

• RPCserver läuft grundsätzlich (leider nur auf dem "schnelleren" PI3 und das "Timing-Problem" beim Start sollte noch gelöst werden)
• HMCCU-Device geht auf Error

Folgende Hinweise:

a) im FHEM Log finde ich

Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2827.

b) Bug?
wenn man HMCCU definiert, dann werden die set/get Kommandos in FHEM sichtbar. Leider fehlt dann bei "set myCCU2 rpcserver" der Parameter "on" bzw. "off". Die Liste it leer. Erst wenn man das Attribut rpcport setzt (ich habe wie gewünscht auf 2001 gesetzt") weden die  Parameter "on" bzw. "off" sichtbar.

c) Betriebsbereitschaft nach dem Startvorgang
Auch wenn ich jetzt auf dem PI3 den RPCserver starten konnte, stehe ich zum Test der "Signalisierung" auf dem PI2 zur Verfügung, falls Du eine neue Version hast.

d) HMCCU Device geht auf Error
Jetzt habe ich den Zustand ähnlich wie Nic0205. Meine d_Stehlampe geht auf "Error" sobald ich den Status mit "get d_Stehlampe devstat" abfrage. Hier die Definiton:

Code Auswählen Erweitern


Internals:
   DEF        MEQ0714259 1
   IODev      myCCU2
   NAME       d_Stehlampe
   NR         64
   STATE      Initialized
   TYPE       HMCCUDEV
   ccuaddr    MEQ0714259
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    HM-LC-Dim1T-Pl-3 MEQ0714259
   ccutype    HM-LC-Dim1T-Pl-3
   channels   4
   statevals  devstate|on|off
   Readings:
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.DIRECTION off
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERHEAT off
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERLOAD off
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_REDUCED off
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL 0.000000
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL_REAL 0.000000
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.1.WORKING off
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.2.DIRECTION 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERHEAT 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERLOAD 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_REDUCED 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL 0.000000
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL_REAL 0.000000
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.2.WORKING 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.3.DIRECTION 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERHEAT 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERLOAD 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_REDUCED 0
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL 0.000000
     2016-04-09 03:14:13   HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL_REAL 0.000000
     2016-04-09 01:28:53   HM-LC-Dim1T-Pl-3_MEQ0714259.3.WORKING 0
     2016-04-09 09:35:06   state           Initialized
Attributes:
   IODev      myCCU2
   statechannel 1
   statevals  on:true,off:false
   substitute true:on,false:off,1:on,0:off


Im Log steht dann:

Code Auswählen Erweitern


2016.04.09 09:48:41 1: HMCCU: Error URL = http://192.168.178.16:8181/do.exe?r1=dom.GetObject("BidCos-RF.MEQ0714259:1.STATE").Value()
2016.04.09 09:48:41 1: HMCCUDEV: d_Stehlampe Execution of CCU script or command failed


[zap]

Hallo zap,

so ist die Definition:

Code Auswählen Erweitern


   ccuname    K�che Wandleuchten


Das Problem ist der Umlaut im CCU Devicename. Dieser wird zwischen CCU und FHEM falsch gemapt. Einzige Abhilfe derzeit: Device in der CCU (auch die Kanäle) umbenennen. Das Problem haben andere auch, allerdings habe ich dafür noch keine echte Lösung, da je nach verwendeter Umgebung für FHEM das Mapping anders sein muss. Nach der Umbenennung in der CCU einmalig "get d_ccu devicelist" ausführen.

Noch ein Tipp: Du solltest noch das Attribut substitute für das Device setzen:

Code Auswählen Erweitern


attr Kueche_wandleuchte substitute STATE!true:on,false:off,1:on,0:off


Dann werden auch die Werte, die von der CCU kommen entsprechend übersetzt.

[zap]

Das "Timing-Problem" beim Start sollte noch gelöst werden

Ist in Arbeit.

im FHEM Log finde ich
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191.

Warnings wg. Verwendung des Perl Operators ~~. Kann ignoriert werden. In der nächsten Version verzichte ich darauf.

wenn man HMCCU definiert, dann werden die set/get Kommandos in FHEM sichtbar. Leider fehlt dann bei "set myCCU2 rpcserver" der Parameter "on" bzw. "off". Die Liste it leer. Erst wenn man das Attribut rpcport setzt (ich habe wie gewünscht auf 2001 gesetzt") weden die  Parameter "on" bzw. "off" sichtbar.

Ist bei mir nicht so. Hast Du mal die Webseite von FHEM refreshed? In der Set-Funktion wird bei ? der ganz normale String mit allen möglichen Befehlen zurückgegeben.

Auch wenn ich jetzt auf dem PI3 den RPCserver starten konnte, stehe ich zum Test der "Signalisierung" auf dem PI2 zur Verfügung, falls Du eine neue Version hast.

Kommt.

Jetzt habe ich den Zustand ähnlich wie Nic0205. Meine d_Stehlampe geht auf "Error" sobald ich den Status mit "get d_Stehlampe devstat" abfrage. Hier die Definiton:

Code Auswählen Erweitern


Attributes:
   IODev      myCCU2
   statechannel 1
   statevals  on:true,off:false
   substitute true:on,false:off,1:on,0:off


Im Log steht dann:

Code Auswählen Erweitern


2016.04.09 09:48:41 1: HMCCU: Error URL = http://192.168.178.16:8181/do.exe?r1=dom.GetObject("BidCos-RF.MEQ0714259:1.STATE").Value()
2016.04.09 09:48:41 1: HMCCUDEV: d_Stehlampe Execution of CCU script or command failed


Problem ist, dass "set devstate" per Default versucht, den Datenpunkt STATE zu setzen bzw. zu lesen. Der fehlt aber bei einem Dimmer. Ich habe zwar keinen, vermute aber, dass der Datenpunkt LEVEL passen würde und hier 0 = aus und 1.0 = an ist. Wenn das so ist, kannst Du mal folgendes probiere:

Code Auswählen Erweitern


attr d_Stehlampe statedatapoint LEVEL
attr d_Stehlampe statevals on:1.0,off:0.0


Dann sollte "get devstate" funktionieren. Alternativ geht "get/set datapoint 1.LEVEL" auch ohne die Attribute oben.

Für die dynamische Einstellung

Code Auswählen Erweitern


attr d_Stehlampe controldatapoint 1.LEVEL
attr d_Stehlampe webCmd control
attr d_Stehlampe widgetOverride control:slider,0.0,0.1,1.0


Wobei ich mir bei der slider Syntax nicht ganz sicher bin. Ich glaube, bei Nicht-Ganzzahlen muss man da noch was beachten.

[zap]

Neue Testversion von 88_HMCCU.pm und ccurpcd.pl hängt an. Die Ausführung auf 2 Raspis gleichzeitig wird vermutlich funktionieren, aber die CCU ziemlich belasten.
Um Seiteneffekte auszuschließen, würde ich es nur auf einem starten.

[Achiim]

Danke für deine Hilfe. Mit der Definition des "statedatapoint" hat es geklappt. Das sieht bei mir jetz so aus

Code Auswählen Erweitern


Internals:
   DEF        MEQ0714259 1
   IODev      myCCU2
   NAME       d_Stehlampe
   NR         64
   STATE      1.000000
   TYPE       HMCCUDEV
   ccuaddr    MEQ0714259
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    HM-LC-Dim1T-Pl-3 MEQ0714259
   ccutype    HM-LC-Dim1T-Pl-3
   channels   4
   statevals  devstate|on|off
   Readings:
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.AES_KEY closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.CONFIG_PENDING closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.DEVICE_IN_BOOTLOADER closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.DUTYCYCLE closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.RSSI_DEVICE open
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.RSSI_PEER 44
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.STICKY_UNREACH closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.UNREACH closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.0.UPDATE_PENDING closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.DIRECTION closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERHEAT closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERLOAD closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_REDUCED closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.INHIBIT closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.INSTALL_TEST N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL 0.000000
     2016-04-09 15:12:35   HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL_REAL 1.000000
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.OLD_LEVEL N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ON_TIME N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.RAMP_STOP N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.RAMP_TIME N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.2.WORKING closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.DIRECTION closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERHEAT closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_OVERLOAD closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ERROR_REDUCED closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.INHIBIT closed
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.INSTALL_TEST N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL 0.000000
     2016-04-09 15:12:35   HM-LC-Dim1T-Pl-3_MEQ0714259.3.LEVEL_REAL 1.000000
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.OLD_LEVEL N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.ON_TIME N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.RAMP_STOP N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.RAMP_TIME N/A
     2016-04-09 15:00:36   HM-LC-Dim1T-Pl-3_MEQ0714259.3.WORKING closed
     2016-04-09 15:12:35   WZ-Stehlampe-1.DIRECTION closed
     2016-04-09 15:12:35   WZ-Stehlampe-1.ERROR_OVERHEAT closed
     2016-04-09 15:12:35   WZ-Stehlampe-1.ERROR_OVERLOAD closed
     2016-04-09 15:12:35   WZ-Stehlampe-1.ERROR_REDUCED closed
     2016-04-09 15:00:36   WZ-Stehlampe-1.INHIBIT closed
     2016-04-09 15:00:36   WZ-Stehlampe-1.INSTALL_TEST N/A
     2016-04-09 15:12:35   WZ-Stehlampe-1.LEVEL 1.000000
     2016-04-09 15:12:35   WZ-Stehlampe-1.LEVEL_REAL 1.000000
     2016-04-09 15:00:36   WZ-Stehlampe-1.OLD_LEVEL N/A
     2016-04-09 15:00:36   WZ-Stehlampe-1.ON_TIME N/A
     2016-04-09 15:00:36   WZ-Stehlampe-1.RAMP_STOP N/A
     2016-04-09 15:00:36   WZ-Stehlampe-1.RAMP_TIME N/A
     2016-04-09 15:12:35   WZ-Stehlampe-1.WORKING closed
     2016-04-09 15:12:35   state           1.000000
Attributes:
   IODev      myCCU2
   statechannel 1
   statedatapoint LEVEL
   statevals  on:1.0,off:0.0
   substitute STATE!(0|false):off,(1|true):on;LOWBAT!(0|false):no,(1|true):yes;(0|false):closed,(1|true):open


Nunja, die Definition des "substitude" habe ich auch von einem Beispiel übernommen. Das erscheint mir für den Dimmer auch nicht unbedingt zu passen.

Hinweis:
Als weitere Optimierung habe ich nun auch die RAM-Disk für /tmp auf dem PI3 eingerichtet....

Jetzt schau ich erst mal Bundesliga und werden deine neuen Module nachher mal testen.

[zap]

Mit dem Substitute musst Du mal rumtesten. Vielleicht so:

LEVEL!1.000000:on,0.000000:off

Du kannst auch stripnumbers auf 1 setzen, dann schneidet er alles nach der 1. Nachkommastelle ab.

Ich empfehle auch, eventonchangereading auf .* zu setzen, da sonst sehr viele Events generiert werden.

[Achiim]

Hallo zap,

ich sage mal fast... 

Ich habe den Test nur auf dem PI2 gemacht.

Code Auswählen Erweitern


2016.04.09 21:43:17 0: HMCCU: RPC server started with pid 2556
2016.04.09 21:43:25 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.09 21:43:25 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.09 21:43:37 2: HMCCU: Unknown RPC event type [SL]


Leider bleibt der RPCserver wieder im Status "starting" hängen, aber ein Event vom typ SL habe ich bisher noch nicht gesehen...

Hinweise:
ccuqueue_2001.dat ist leer
ccuqueue_2001.idx ist 1 Byte gross

Es hat etwas gedauert, bis ich den Test machen konnte. Sorry... aber ich musste erst ein bisschen mit der funktionierenden Installation auf dem PI3 "spielen" und habe mir die tollen Möglichkeiten angeschaut und teilweise vorgestellt, was ich damit alles machen will.... Da ist das Kopfkino bei mir angesprungen.... 

Ich habe es gleich nochmal versucht. Das Verhalten scheint reproduzierbar.