FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: zap am 19 August 2015, 19:45:30

Titel: Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 19 August 2015, 19:45:30
HMCCU ist ein Modul für die Kommunikation zwischen FHEM und einer Homematic CCU. Die Module HMCCUDEV und HMCCUCHN werden für die Definition von Client-Devices verwendet. Der integrierte RPC Server sorgt für den Empfang von CCU Events, mit denen Readings in Client-Devices automatisch aktualisiert werden, sobald sich die entsprechenden Werte in der CCU ändern.
Ab Version 4.0 wird mit dem Modul HMCCURPC ein externer RPC-Server bereitgestellt, der auch binary RPC (z.B. für CUxD) unterstützt.

Features:

HMCCU verwendet Homematic Script und XML-RPC für die Kommunikation mit der CCU. Seit dem 13.09.2016 ist HMCCU Teil des FHEM SVN Zweigs und kann per update Befehl installiert und aktualisiert werden.

Beispiele für Client-Devices gibt es hier (https://forum.fhem.de/index.php/topic,51339.0.html)

Doku im Wiki: https://wiki.fhem.de/wiki/HMCCU

Wichtig!

Aufgrund der Verwendung von Homematic Script dürfen Namen in der CCU nur einmal verwendet werden, d.h. ein Gerätename in der CCU darf nicht auch für ein Gewerk oder ein anderes Objekt verwendet werden! Homematic Geräte- und Kanalnamen dürfen keine Umlaute verwenden.


Funktion der Module:

Die Befehle der Module akzeptieren folgende Geräte-/Kanal- und Datenpunkt-Angaben:

Device = {Device-Name|[Interface.]Device-Address}
Channel = {Channel-Name|[Interface.]Device-Address:Channel-Number}
Datapoint = {Device|Channel}.Datapoint-Name


Beispiel IO Device mit HMCCU:

# IO Device definieren
define d_ccu HMCCU 192.168.10.10

# Alle CCU Geräte einlesen (passiert beim define automatisch)
get d_ccu devicelist

# CCU Variable abholen und als Reading speichern
get d_ccu vars Anwesenheit

# Alle CCU Variablen abholen und als Reading speichern
get d_ccu vars .*

# BidCos-RF und HM-IP RPC Server konfigurieren und starten
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on # Automatisch starten
set d_ccu rpcserver on

# Alle Kanäle und Datenpunkte eines CCU Geräts anzeigen (THERMOSTAT_WZ = Device-Name in CCU)
get d_ccu deviceinfo THERMOSTAT_WZ

Beispiel für ein Client-Device für ein CCU Gerät

# Pumpe mit State-Channel = 1
define d_Pumpe HMCCUDEV LEQ1234567 1

# Attribut statevals sorgt dafür, dass man den Gerätestatus ohne devstate setzten kann
attr d_Pumpe statevals on:true,off:false

# Gelesene Werte ersetzen (get Befehle liefern true/false, RPC server liefert 0/1)
attr d_Pumpe substitute true:on,false:off,1:on,0:off

# Pumpe einschalten (2 Varianten, 1. Variante funktioniert wg. Attribut statevals)
set d_Pumpe on
set d_Pumpe devstate on

Beispiel Client-Device für einen CCU Gerätekanal:

# TF-Haus-1 ist der Kanalname in der CCU, Device ist readonly (Sensor)
define d_tuer HMCCUCHN TF-Haus-1 readonly

# Gelesen Werte ersetzen (get Befehle liefern true/false, RPC server liefert 0/1)
attr d_tuer substitute true:open,false:closed,1:open,0:closed

Beispiel HM-Script ausführen:

Datei /opt/fhem/hmtest.scr anlegen mit HM-Script Code (Ausgabe aller Systemvariablen der CCU). Readings werden nur gesetzt, wenn die Ausgabe des HM-Scripts Wertepaare im Format Reading=Value enthält. Wertepaare müssen durch Newline getrennt sein:

object osysvar;
string ssysvarid;
foreach (ssysvarid, dom.GetObject(ID_SYSTEM_VARIABLES).EnumUsedIDs())
{
   osysvar = dom.GetObject(ssysvarid);
   WriteLine (osysvar.Name() # "=" # osysvar.Value());
}

Script ausführen:

set d_ccu hmscript /opt/fhem/hmtest.scr
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: traxanos am 20 August 2015, 13:26:15
Ich habe leider keine CCU und hab alles an FHEM hab mich aber immer wieder geärgert das ich nicht eine CCU2 einhängen kann. So könnte man die Vorteile aus beiden Welten verbinden. Hoffe das Modul wird immer besser ausgebaut, dann überlege ich zu wechseln :D
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 August 2015, 08:57:10
Das Modul habe ich sozusagen "aus der Not heraus" entwickelt. Ich fahre schon länger zweigleisig, d.h. alles was geht mache ich mit Homematic und der CCU2. Alles was die CCU nicht kann, habe ich über FHEM realisiert. Nun gibt es aber Szenarien, die eine Kommunikation beider Systeme erforderlich machen.

Beispiel 1: Ich schalte den AV-Receiver ein. Das FHEM Pioneer AVR Modul erkennt das und schaltet über die CCU und die Schaltsteckdose den Bass ein.

Beispiel 2: Ich versorge die CCU aus FHEM mit Wetterinformationen (u.a. aus meiner Wetterstation und Wetter.com). Die CCU nutzt diese Infos z.B. für die Prüfung, ob bei Regen die Dachfenster zu sind.

Zum Thema Ausbau: Was wäre denn interessant? Ich möchte auf jeden Fall noch die Ausführung von CCU Programmen einbauen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Inputsammler am 21 August 2015, 10:00:40
Hey,

Das
Modul hört sich gut in. Ich habe auch teilweise die Ccu2 und Fhem's am laufen.
Bei mir läuft die ccu nur temporär.
Ich werde das Modul ab September mal testen.
Hab gerade wenig Zeit.

Gruß Gerd
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 August 2015, 19:11:43
Vor dem Ausprobieren das Modul nochmal runterladen. Habe einige Fehler korrigiert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: 3dmanipulator am 12 September 2015, 13:15:21
hört sich sehr interessant an. vor allem vor dem hintergrund dass die ccu2 als bausatz zur zeit billiger ist als das lan modul.

ich benutze eigentlich zwave; aber die heizkörperthermostate arbeitn da nicht so doll.

deshalb überlege ich die heizkörper komplett über homematik laufen zu lassen. läuft denn der datenaustausch zwischen fhem und der ccu2 so, dass ich als infoboard und zur gelegentlich erhöhung der temperatur auf der fhem oberfläche bleiben kann?

grüße horst
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 13 September 2015, 11:23:39
Momentan kann man nur STATE der in der CCU definierten Geräte setzen. Die Erweiterung auf andere Datapoints (zB für ein Thermostat) kann ich aber noch einbauen. Die momentan eingebauten Funktionen sind halt die, die ich selbst benötige. Da es aber doch anscheinend den ein oder anderen Interessenten gibt, werde ich das Modul noch etwas ausbauen.

Bei mir liegt der Schwerpunkt auf der CCU, d.h. ich mache nur die Dinge über FHEM, die mit der CCU nicht out of the box gehen. Für den Rest ist mir FHEM enfach zu mühsam, frickelig und zeitaufwändig, insbesondere bei großen Installationen (habe da über Jahre mit FS20 reichlich Erfahrungen gesammelt).

Momentan überlege ich, eine webbasierte Statusanzeige über das Infopanel Modul von FHEM zu realisieren. Dafür hole ich auch Infos per HMCCU aus der CCU ab. Allerdings fehlen da schon wieder so viele Funktionen, dass ich nun vor der Wahl stehe, Infopanel selbst anzupassen (was wieder viel Zeit kosten wird) oder doch auf eine professionelle Lösung wie IP Symcom zu setzen.

UPDATE: Schlechtes Wetter => Viel Zeit => Setzen und Auslesen von Datenpunkten eingebaut  :)

Damit kann nun z.B. die Solltemperatur eines Thermostaten in der CCU geändert werden.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Pfriemler am 14 September 2015, 17:16:55
Ich frage mich auch gerade ob ich nicht bei dem aktuellen Bausatzpreis für die CCU2 vieles aus FHEM ausgliedern kann. Irgendwie bin ich für mich Klick-mich-zusammen-Logik eigentlich empfänglicher als für die (mächtigere) FHEM-Variante. Aber meine meisten HomeMatic-Geräte reden ohnehin direkt miteinander.

Gehe ich recht in der Annahme, dass bei einem richtigen (also gleichen) Setzen der Zentralen-ID in CCU2 und FHEM den Status der Geräte direkt mitloggen kann und man so den Status weiter direkt in FHEM auswerten kann, ohne die CCU2 dazu zu befragen?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 14 September 2015, 19:07:21
OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 September 2015, 19:40:14
OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?

Ich glaube, der CCU2 kann man keine bestimmte HMID unterjubeln. Allerdings ist die CCU-Software mittlerweile ja quelloffen und kann so auf anderen Devices (Raspberry o.a.) installiert werden. Das lässt natürlich einiges erwarten für die Zukunft, sofern sich genügend "Freiwillige" finden, die daran arbeiten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 September 2015, 19:45:13
Ich frage mich auch gerade ob ich nicht bei dem aktuellen Bausatzpreis für die CCU2 vieles aus FHEM ausgliedern kann. Irgendwie bin ich für mich Klick-mich-zusammen-Logik eigentlich empfänglicher als für die (mächtigere) FHEM-Variante. Aber meine meisten HomeMatic-Geräte reden ohnehin direkt miteinander.

Das war auch bei mir der Grund, nach dem Wechsel von FS20 auf Homematic auch gleich die Plattform in Richtung CCU zu wechseln. Warum sich mit kryptischen "defines" rumquälen, wenn man vieles einfach per Mausklick machen kann. Natürlich hat FHEM noch seine Existenzberechtigung wenn es um das Einbinden von Nicht-Homematic Komponenten geht Habe meine Wetterstation, meinen AV-Receiver und die Anwesenheitskontrolle mit FHEM realisiert und per HMCCU Modul mit der CCU "verheiratet". Best of both worlds, wie es so schön heißt.

Zitat
Gehe ich recht in der Annahme, dass bei einem richtigen (also gleichen) Setzen der Zentralen-ID in CCU2 und FHEM den Status der Geräte direkt mitloggen kann und man so den Status weiter direkt in FHEM auswerten kann, ohne die CCU2 dazu zu befragen?

Wenn Du die ID der Zentrale verwendest sollte das funktionieren.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mgernoth am 14 September 2015, 22:13:50
Hallo,

OT: Kann man der CCU2 eigentlich auch eine HMID beibringen oder will die immer ihre "durchsetzen"?

Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.

Allerdings ist die CCU-Software mittlerweile ja quelloffen und kann so auf anderen Devices (Raspberry o.a.) installiert werden.

Quelloffen ist das leider nicht: https://github.com/eq-3/occu
Nur eine Ansammlung an Blobs für verschiedene Plattformen kompiliert.

Viele Grüße
  Michael
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Mr. P am 14 September 2015, 22:42:00
Da es aber doch anscheinend den ein oder anderen Interessenten gibt, werde ich das Modul noch etwas ausbauen.
Hej zap,

um den Kreis der Interessenten noch etwas zu erweitern:
Zwar nicht direkt für mich, aber für ein Projekt, das ich betreue, bei dem kommende Heizsaison fertig umgestellt sein soll. :-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Pfriemler am 14 September 2015, 23:39:10
Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.

Wird ja immer besser. Muss ich nicht alles neu anlernen in FHEM.
CCU2 ist soeben bestellt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 September 2015, 09:08:53
Hej zap,

um den Kreis der Interessenten noch etwas zu erweitern:
Zwar nicht direkt für mich, aber für ein Projekt, das ich betreue, bei dem kommende Heizsaison fertig umgestellt sein soll. :-)

Datenpunkte setzen geht mittlerweile (z.B. Zieltemperatur für Thermostate). Muss mich mal schlau machen, wie ich den Kram ins SVN Contrib bekomme. Macht die Updates etwas einfacher.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 15 September 2015, 09:19:57
Wird ja immer besser. Muss ich nicht alles neu anlernen in FHEM.
Ich fürchte, das wirst Du trotzdem tun müssen - woher soll die CCU2 sonst ihre Device-Übersicht her bekommen. Oder legt die CCU2 ein Device an, welches an sie adressiert und welches sie noch nicht in ihrer Liste hat?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 September 2015, 09:34:05

Quelloffen ist das leider nicht: https://github.com/eq-3/occu
Nur eine Ansammlung an Blobs für verschiedene Plattformen kompiliert.

Viele Grüße
  Michael

Das SDK inklusive der vor compilierten Bins gibt es hier: http://www.eq-3.de/Downloads/Software/Software_Development_Kit/HM-OCCU-SDK-1.0.0.tgz


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 September 2015, 09:37:05
Ich fürchte, das wirst Du trotzdem tun müssen - woher soll die CCU2 sonst ihre Device-Übersicht her bekommen. Oder legt die CCU2 ein Device an, welches an sie adressiert und welches sie noch nicht in ihrer Liste hat?

Natürlich muss man die Geräte an die CCU2 anlernen, d.h. in den Anlernmodus versetzen und in der CCU2 die Suchfunktion nach neuen Geräten starten. Ich glaube, hier ging es eher darum, die Geräte nicht neu in FHEM anlernen zu müssen.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 15 September 2015, 09:39:57
Ich hatte das irgendwie anders verstanden - wenn man bereits Geräte in fhem mit einer definierten HMID angelernt hat, und man kann der (neuen) CCU2 dann die HMID aus der fhem-Installation setzen ...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: martinp876 am 15 September 2015, 11:07:38
Eine ccu hat eine hmid. M.w. ist die nicht aenderbar. Pairt man wir diese genommen.
Hmlan ist ein io, die hmid kann man aendern. Damit kann ein hmlan als io der ccu mit deren ID genutzt werden. Fhem nutzt das hmlan identisch.
Da nun die ID der ccu unveränderlich ist müssen sich alle nach ihr richten - so man diesen betrieb will. Also alles an ccu an lernen, hmid der vccu identisch zur ccu einstellen. Fhem IOS der vccu zuordnen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 15 September 2015, 11:15:41
Ja, kann man IIRC in /etc/config/ids setzen. Danach die CCU2 rebooten.

;)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Pfriemler am 15 September 2015, 12:53:58
Nach der Änderung der HM ID in der CCU2 muss man natürlich die Geräte "anlernen", wenn das so geht wie beim Konfigurator, lernt die CCU2 die Konfig von den Geräten ohne diese zu ändern, und sie erkennt auch vorhandene Verknüpfungen. Im Grunde ein getConfig.
Die CCU2 nutzt ihre eigene Funkschnittstelle. Betrieb ausschließlich mit HMLAN ist zwar auch möglich, dann ist aber FHEM taub.

geht nich Gips nich ...

Edit: falsch verstanden: Martin meinte die Zuordnung der IOs zur vccu in FHEM. Ja natürlich, was sonst ...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 15 September 2015, 13:12:18
Ich hab' mir nun auch mal eine bestellt ;D. Einfach mal zum Experimentieren ...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: martinp876 am 15 September 2015, 18:32:59
Korrekt, beim an lernen macht die ccu ein (eigenes) getconfig. Was mich stört ist, dass ich es nicht noch einmal starten kann. Wenn ich über fhem ein Register andere ist mir nicht klar, ob die ccu das erkennt. Sollte sie ofline sein kann sie es nicht.
In fhem kann ich einfach ein getconfig machen.... Wenn viel passiert ist einfach in hminfo. Ich kann erkennen, wenn alles wieder gelesen und vollständig ist.
Vieleicht gibt es auch in der ccu etwas vergleichbares. Hier fehlen mir auch die Sicherungen und die Option, diese wieder einzuspielen..... In fhem kann man die Register sichern, kopieren, archivieren und wiederherstellen. Ich habe da gerne den Bodenkontakt, den ich in einer ccu nicht erkenne.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Pfriemler am 15 September 2015, 21:19:54
Zitat
beim an lernen macht die ccu ein (eigenes) getconfig. Was mich stört ist, dass ich es nicht noch einmal starten kann.
Der HM-Konfigurator kann das nicht, ich dachte die Zentrale kann es. Nötig hätte sie es eigentlich nicht - sie denkt ja dass sie der Chef vons Janze is und ihr nichts entgehen kann.
Zitat
Wenn ich über fhem ein Register ändere...
Habe ich dann eigentlich nicht mehr vor - alle Konfigs nur über die CCU2.
Zitat
In fhem kann man die Register sichern, kopieren, archivieren und wiederherstellen. Ich habe da gerne den Bodenkontakt, den ich in einer ccu nicht erkenne.
In zwei Monaten bin ich auch schlauer. Deine Argumente sind sehr richtig und wichtig.
Vielleicht bin ich schneller wieder bei FHEM als ich denke  ::)

Aber eigentlich diskutieren wir das Für und Wider in diesem Fred (http://forum.fhem.de/index.php/topic,36284.0.html). Hier sollten wir mal bei ZAPs Modul bleiben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 September 2015, 21:28:49
Tja, das sind eben die Vor- und Nachteile von Open Source Software. Einerseits hat man Zugriff auf das letzte Bit, andererseits verführt das auch dazu, Dinge komplizierter zu machen als eigentlich notwendig. Muss jeder für sich rausfinden, was das Beste ist.

Ich halte es nach dem Prinzip "keep it simple". Der ganze Kram muss auch vom Rest der Familie handlebar sein, wenn ich mal nicht da bin. Und das kann ich mit "Pocket Control" auf meinem iPAD in Verbindung mit der CCU gewährleisten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU Fehler zum Start
Beitrag von: harway2007 am 16 September 2015, 00:56:32
direkt nach Eingabe von
define cccu2 HMCCU 192.168.9.154
erhalte ich : Cannot load module HMCCU
(habe das Modul nach Fhem Fhem kopiert wo auch alle anderen pms sind ....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Mr. P am 16 September 2015, 01:31:06
Permissions passen?
FHEM auch neu gestartet oder zumindest das File geladen?

Gesendet von meinem SM-G800F mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU Fehler zum Start
Beitrag von: zap am 16 September 2015, 07:49:25
direkt nach Eingabe von
define cccu2 HMCCU 192.168.9.154
erhalte ich : Cannot load module HMCCU
(habe das Modul nach Fhem Fhem kopiert wo auch alle anderen pms sind ....

Falls die Berechtigungen stimmen (siehe vorherige Antwort):

Das Perl Modul XML::Simple wird benötigt. Ist das installiert? Im FHEM Log sollten Fehlermeldungen stehen. Bitte schau mal nach und poste sie hier.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 21 September 2015, 09:58:56
Das Modul funktioniert :).

Ich hätte da aber mal einen anderen Ansatz bzw. eine andere Idee:

Statt die CCU2 über das Modul zu definieren und dann letztendlich immer mit diesem einen definierten Device zu arbeiten, fände ich es deutlich besser und sinnvoller, die tatsächlich in fhem darzustellenden, zu schaltenden bzw. zu nutzenden Geräte wie bislang auch zu definieren und als Typ (und Schnittstelle) das Modul zu nehmen, welches mit der CCU2 kommuniziert.

Anders ausgedrückt:

define MeinSchalter HMCCU MeineCCU2IP:Device DeviceHMID

Das hätte den unschätzbaren Vorteil, die Geräte wie bisher auch in fhem - mit allen Events, Triggern usw. - einbinden zu können, nur dass Schaltbefehle und Requests eben nicht mehr über die IOs für CUL_HM laufen sondern über die CCU2.
Titel: Antw:HMCCU ladefehler
Beitrag von: harway2007 am 21 September 2015, 11:53:05
habe mit cpan das Modul versucht zu laden
cpan install XML::Simple dann Neustart ...
 
erhalte dann diese Logfile Meldung und den Fehler Cannot load module HMCCU:

2015.09.21 11:47:33 1: reload: Error:Modul 88_HMCCU deactivated:
 Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/i386-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 39.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 39.

2015.09.21 11:47:33 0: Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module) (@INC contains: ./FHEM/lib ./lib /etc/perl /usr/local/lib/i386-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/i386-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 39.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 39.

erbitte Hilfestellung ..
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 21 September 2015, 11:54:49
Was heißt "versucht" ?

Als root bzw. mit sudo nachinstallieren.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 September 2015, 12:37:12
Ich hätte da aber mal einen anderen Ansatz bzw. eine andere Idee:

Statt die CCU2 über das Modul zu definieren und dann letztendlich immer mit diesem einen definierten Device zu arbeiten, fände ich es deutlich besser und sinnvoller, die tatsächlich in fhem darzustellenden, zu schaltenden bzw. zu nutzenden Geräte wie bislang auch zu definieren und als Typ (und Schnittstelle) das Modul zu nehmen, welches mit der CCU2 kommuniziert.

Anders ausgedrückt:

define MeinSchalter HMCCU MeineCCU2IP:Device DeviceHMID

Das hätte den unschätzbaren Vorteil, die Geräte wie bisher auch in fhem - mit allen Events, Triggern usw. - einbinden zu können, nur dass Schaltbefehle und Requests eben nicht mehr über die IOs für CUL_HM laufen sondern über die CCU2.

mm, Geräte schalten über die CCU aus FHEM heraus geht ja im Moment schon mit HMCCU:

set MeineCCU devstate MeinSchalterKanal true

Bei Deiner Variante wäre der set Befehl minimal einfacher (sprechender?):

set MeinSchalter devstate true

Da ich XML-API verwende, muss FHEM den Status der Homematic Geräte aus der CCU aktiv pollen. Dann werden aber auch Events generiert. Es ist deutlich effektiver und Ressourcen schonender, mit einer Abfrage die Stati aller CCU Geräte zu holen. Wenn das in FHEM einzelne Geräte wären, müsste für jedes Gerät auch eine Statusabfrage an die CCU geschickt werden.

Oder meinst Du, dass die CCU FHEM automatisch bei Statusänderungen benachrichtigen soll? Dann müsste ich auf die RPC Schnittstelle wechseln. Dazu gibt es bereits das Modul HMRPC, das aber nicht mehr weiter entwickelt wird und das Protokoll auch leider nicht vollständig bzw. korrekt implementiert hat.
RPC und CCU ist ein weites Feld. Damit kann man sich die CCU abschiessen. Insofern würde ich gerne bei XML-API bleiben.

@harway2007:

Welche Fehlermeldung wirft "cpan install" ? Oder ist die Installation erfolgreich?

P.S. Bitte beachten: die aktuelle Version des Moduls gibt es ab sofort immer im SVN (Contrib Zweig, siehe Link im ersten Post).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 21 September 2015, 13:05:23
Da ich XML-API verwende, muss FHEM den Status der Homematic Geräte aus der CCU aktiv pollen. Dann werden aber auch Events generiert. Es ist deutlich effektiver und Ressourcen schonender, mit einer Abfrage die Stati aller CCU Geräte zu holen. Wenn das in FHEM einzelne Geräte wären, müsste für jedes Gerät auch eine Statusabfrage an die CCU geschickt werden.

Jain :). Das könntest Du ggf. so lösen, wie es momentan auch mit CUL_HM gelöst ist: Man definiert ein IO (oder eine vCCU mit IOs) und definiert Devices.

Adaptiert wäre das: Man definiert die CCU2 und definiert Devices, die die definierte CCU2 nutzen.

So könnte die definierte CCU2 als SPOC - so wie jetzt in Deinem Modul - für alle an ihr registrierten Devices auf einmal pollen und dann an die Devices verteilen.

Der Vorteil wäre, dass Du so, wie es halt in fhem normal ist, hättest: du kannst jedes Device "schön" in dem entsprechenden Raum und den entsprechenden Gruppen sortieren und in alle DOIFs, IFs usw. einbinden. So wird es ja bspw. nicht nur mit CUL_HM sondern auch mit im Endeffekt allen anderen Protokollen gemacht.

Zitat
Oder meinst Du, dass die CCU FHEM automatisch bei Statusänderungen benachrichtigen soll? Dann müsste ich auf die RPC Schnittstelle wechseln. Dazu gibt es bereits das Modul HMRPC, das aber nicht mehr weiter entwickelt wird und das Protokoll auch leider nicht vollständig bzw. korrekt implementiert hat.

Wenn ich ehrlich bin, wäre das im Endeffekt die perfekte Lösung. Weg vom (alleinigen) Pollen hin zu der Möglichkeit, auf "Anrufe" der CCU2 zu reagieren.

Edit:

Gerade gesehen, dass dies der Funktionalität von dem "alten" HMRPC-Modul entspricht  :o :

http://forum.fhem.de/index.php?topic=12642.0

Edit2:

Und überschneidet sich hiermit:

http://forum.fhem.de/index.php/topic,41060.msg332596.html#msg332596

Vielleicht solltet Ihr Euch zusammentun :).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 September 2015, 14:35:26
Jain :). Das könntest Du ggf. so lösen, wie es momentan auch mit CUL_HM gelöst ist: Man definiert ein IO (oder eine vCCU mit IOs) und definiert Devices.

Adaptiert wäre das: Man definiert die CCU2 und definiert Devices, die die definierte CCU2 nutzen.

So könnte die definierte CCU2 als SPOC - so wie jetzt in Deinem Modul - für alle an ihr registrierten Devices auf einmal pollen und dann an die Devices verteilen.

Der Vorteil wäre, dass Du so, wie es halt in fhem normal ist, hättest: du kannst jedes Device "schön" in dem entsprechenden Raum und den entsprechenden Gruppen sortieren und in alle DOIFs, IFs usw. einbinden. So wird es ja bspw. nicht nur mit CUL_HM sondern auch mit im Endeffekt allen anderen Protokollen gemacht.


Verstanden. Das mit den Räumen usw. hatte ich nicht bedacht. Die Erweiterung wäre ziemlich einfach. Mal sehen, wie schnell HMRPC einen stabilen Reifegrad erlangt ...

Titel: Antw: HMCCU wird jetzt geladen ...
Beitrag von: harway2007 am 22 September 2015, 00:31:38
@Ralli
hatte sudo bei cpan ... vergessen HMCCU wird jetzt geladen ...
DANKE ....

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 02 Oktober 2015, 21:06:33
Im contrib Zweig in Sourceforge (https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/) gibt es nun ein weiteres Modul 88_HMCCUDEV.pm. Dieses Modul implementiert Client Devices für die CCU. 88_HMCCU.pm ist das IO Device.

Beispiel 1:

define Fenster1 HMCCUDEV WIN-WZ-1

"WIN-WZ-1" ist der Name des Tür-/Fenstersensors in der CCU.

Beispiel 2:

define Steckdose HMCCUDEV STEHLAMPE-WZ
attr Steckdose stateval on:true,off:false
set Steckdose devstate on
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 03 Oktober 2015, 06:24:39
Top! Und vielen Dank.

Aber ich hätte zwei Vorschläge:

1)
define Fenster1 HMCCUDEV CCU2:WIN-WZ-1

... wobei CCU2 hier die über das Modul HMCCU definierte CCU2 ist. Warum? Ganz einfach, so kannst Du mehrere CCU2s in fhem integrieren. Das könnte in manchen Situationen sinnvoll sein, wenn bspw. zwei oder mehr "Kreise" genutzt werden.

2)
set Steckdose (devstate) on

... das devstate sollte/könnte eigentlich überflüssig sein. Ich würde es als sinnvoll erachten, wenn Schaltzustände an das Device unmittelbar entsprechend der Standard-Art übermittelt werden könnten (also set Steckdose on, off, 0..100). Das Attribut stateval könnte stattdessen eventmap heissen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 03 Oktober 2015, 12:12:57
Das mit den 2 CCUs ist jetzt schon möglich. Einfach im Attribut IODev ein anderes HMCCU Device angeben. Standard bei Client bzw. IO- Devices in FHEM.

Statt devstate kann man jetzt auch on und off direkt angeben. Allerdings muss man das Attribut stateval auf on:true,off:false setzen. Sonst wird on bzw off an die CCU geschickt. Die erwartet aber true oder false bei STATE. Das Attribut stateval legt gleichzeitig die möglichen set Befehle über die Texte vor den Doppelpunkten fest. "on:true,off:false,standby:lala" legt also on, off und standby als Set Befehle neben devstate und datapoint fest.

Außerdem kann man nun Devices als readonly, d.h. ohne Set Befehl anlegen. Sinnvoll z.B. für reine Sensoren. Dazu wird beim Anlegen des Devices einfach readonly an das Define Command angehängt, z.B.

define d_fenster HMCCUDEV TF-Wohnzimmer readonly


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 17 Oktober 2015, 08:28:25
Hallo zap,

bin jetzt seit längerer Zeit erst nochmal zum Experimentieren gekommen.

http://forum.fhem.de/index.php/topic,42212.msg345535.html#msg345535

Ich bin der Auffassung, dass die eierlegende Wollmilchsau das ideale wäre. Wenn in das HMCCU-Modul noch der HMRPC-Provider mit eingebaut würde und man so diese Möglichkeit (optional) mit nutzen könnte, und im Endeffekt Devices aus/mit beiden Kommunikationssträngen gefüttert und gesteuert werden könnten.

Vorteil: Ein Device definiert, welches echte Events generieren kann und alle Vorteile mit "übersetzten" set's und get's und den sonst von Dir eingebauten Benefits hat.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: dechris am 17 Oktober 2015, 20:31:15
Ich habe da mal so eine Verständnisfrage. Ich kann ja CCU2 Devices direkt über FHEM ansteuern. Würde ich denn per notify mitbekommen, wenn ein 6 Fach Taster gedrückt wurde? Würde gerne zu denn CCU2 gespeicherten Befehlen noch zusätzliche Aktionen per FHEM starten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 18 Oktober 2015, 07:07:07
Wenn per HMRPC angebunden, dann ja. Wenn per HMCCU angebunden, dann erst nach einer Zeitspanne X, wenn ein erneutes Polling durchgeführt wurde.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 18 Oktober 2015, 13:43:36
Wie ich schon an anderer Stelle geschrieben habe, glaube ich, dass die direkte Implementierung eines RPC Servers in FHEM zwar möglich, aber mit diversen Unwägbarkeiten verbunden ist (z.B. dass der ein oder andere Event von der CCU verloren geht oder FHEM "bockt").

m.E. wäre ein möglicher Kompromiss die Implementierung eines RPC Servers als separater Daeomon/Prozess, der die Requests der CCU entgegennimmt und in eine Queue (z.B. eine FIFO Pipe) schreibt. Dort könnte dann ein FHEM Modul (HMCCU) die Informationen abholen und an seine Client-Devices verteilen. Das wäre dann zwar auch wieder ein Polling-Verfahren zwischen HMCCU und der Queue, allerdings könnten die Abfragen in viel höherer Frequenz stattfinden (< 10 Sekunden) und so ein Echtzeit naher Informationsfluss zwischen CCU und FHEM ermöglicht werden.

Der Rückweg von FHEM zur CCU ist trivial bzw. mit den vorhandenen Methoden der CCU als HTTP-Request möglich, so wie das HMCCU heute schon macht.

In etwa so:

CCU ---(RPC)---> Collector-Prozess ---> Queue ---(Polling)--->FHEM
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 18 Oktober 2015, 15:41:28
m.E. wäre ein möglicher Kompromiss die Implementierung eines RPC Servers als separater Daeomon/Prozess, der die Requests der CCU entgegennimmt und in eine Queue (z.B. eine FIFO Pipe) schreibt. Dort könnte dann ein FHEM Modul (HMCCU) die Informationen abholen und an seine Client-Devices verteilen. Das wäre dann zwar auch wieder ein Polling-Verfahren zwischen HMCCU und der Queue, allerdings könnten die Abfragen in viel höherer Frequenz stattfinden (< 10 Sekunden) und so ein Echtzeit naher Informationsfluss zwischen CCU und FHEM ermöglicht werden.

Dieser Ansatz hört sich interessant an! Ggf. wäre auch da noch nicht einmal ein ständiges Polling notwendig, wenn man eine Möglichkeit findet, einen Interrupt auszulösen, sobald etwas in der Queue liegt. Aber, sei mir nicht gram, ich bin hier nur Theoretiker, mit meinen minimalsten Programmierkenntnissen kenne ich mich in der Struktur von fhem überhaupt nicht aus.

Das erinnert mich ein bisschen an die "normale" Einbindung eines IOs. CUL_HM macht es doch wahrscheinlich auch nicht anders. Die von den IOs empfangenen (und zu sendenden) Messages wandern in einen Stapel und werden der Reihe nach abgeholt und abgearbeitet.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 18 Oktober 2015, 17:44:26
Die Problematik in diesem Fall liegt tiefer in der FHEM Architektur. Für die Bearbeitung der CCU Benachrichtigungen muss FHEM bzw. das HMRPC / HMCCU Modul permanent Netzwerkverbindungen der CCU entgegennehmen und abarbeiten muss. Da FHEM nicht multithreading fähig ist, muss das alles in der großen FHEM Hauptschleife passieren, was FHEM teilweise blockiert oder zu Problemen in der CCU führt.

Ich habe jetzt mal mit einem standalone Programm experimentiert. Grundsätzlich funktioniert die Kommunikation mit der CCU, mit Events gibt es jedoch Probleme (s.a. hendryks thread). Wenn ich das zum Laufen bekommen, steht der oben skiziierten Lösung vermutlich nichts mehr im Wege.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 18 Oktober 2015, 18:52:56
 :)

Top - vielen Dank, dass Du Dich weiter darum kümmerst - ich denke, dass das der vielversprechendste Ansatz ist!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 20 Oktober 2015, 07:45:26
So, der RPC Server läuft soweit. Weiß nicht, ob ich mich darüber freuen soll, bedeutet nun noch etwas Arbeit  ;):

- Einbindung der RPC Server Ausgabe in HMCCU
- Ergänzung der Device-Names um die benutzerdefinierten Namen aus der CCU (ich mag diese LE00xyz Bezeichnungen nicht)
- Evtl. autocreate von FHEM Devices
- Handling möglicher Fehlersituationen
- ...

Um es gleich vorweg zu sagen: Vermutlich wird die neue Version von HMCCU/HMCCUDEV nur auf Linux und MacOSX laufen. Und auf XML-API will ich auch nicht verzichten, da es Informationen liefert, an die ich per RPC nur schwer oder gar nicht ran komme. Wird also so eine Art Mischbetrieb werden.

Demnächst mehr in diesem Kino.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 20 Oktober 2015, 09:02:42
zap, gaaaanz große Klasse. Vielen vielen Dank!

Und genau so (als Mischbetrieb) hatte ich mir das in meiner theoretischen Naivität vorgestellt :).

Edit:

Da hat eq-3 heute ein paar Spezifikationen neu in den Download-Bereich eingestellt, z.B.

http://www.eq-3.de/Downloads/Software/HM-CCU2-Firmware_Updates/Tutorials/HM_XmlRpc_API.pdf

Ausserdem ist die Firmware 2.15.5 der CCU2 erhältlich.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 22 Oktober 2015, 09:45:53
zap,

das hört sich echt gut an. Falls du Hilfe benötigst, kannst gerne auf mich zu kommen.

grüße
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Oktober 2015, 11:59:10
@EdgarM: Danke für das Angebot. Im Moment läuft es aber ganz gut  :)

@Ralli: Die Doku kenne ich. RPC ist auch keine Thema mehr. Den RPC-Teil habe ich fertig, d.h. ein separates Perl-Script, das als RPC Server im Hintergrund läuft und für FHEM die Nachrichten der CCU in einer Queue bereitstellt.

Einziges Fragezeichen hier: Der RPC-Init-Call, also die Registrierung der Callback-URL bei der CCU, dauert sehr lange (2-3 Minuten). Keine Ahnung warum. Wäre aber nur beim FHEM Start relevant.

Nun fehlt noch die Verbindung zu HMCCU. Nächste Woche habe ich Urlaub. Da könnte es was werden.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 22 Oktober 2015, 13:34:42
Hallo zap,

viel Erfolg ;).

Um die Devices, die man über HMCCU definiert, auch bspw. in (gemischte!) Strukturen einbinden zu können, wäre es wichtig, die wichtigsten Standard-Kommandos verwenden zu können und den state entsprechend zu setzen. Also bei mir wären das bspw.

set device on
set device off
set device toggle
set device on-for-timer
set device on-till
set device statusRequest
set device 0..100 [x y] # x y für Dimmer mit Rampe und Zeit
set device red|orange|green
set device ilum x y
set device desired-temp 5..30|on|off
set device controlMode auto|manu
usw.

Aber ich meine, das hättest Du - zumindest teilweise - auch schon eingebaut.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: philipp485 am 25 Oktober 2015, 00:19:24
Erstmal großes Lob für die Mühe! Nachdem es beim Hausbau noch an der Baugenehmigung hakt habe ich in der Zwischenzeit endlich einen kleinen Rechner als FHEM-Server aufgebaut und bin gerade am Rumspielen mit der CCU2-Einbindung. Aber leider bekomm ichs nicht ans Laufen...irgendwie scheint er die URLs zur Abfrage falsch zusammenzubauen. Wahrscheinlich hab ich nur einen kleinen (Denk-)fehler irgendwo.

Nehmen wir als Beispiel das HM-Thermometer ... meine CCU ist als "CCU2" defined.
Schicke ich nun ein "get CCU2 datapoint BidCos-RF.LEQxxxxxxx:1.TEMPERATURE" los bekomme ich den Fehler "HMCCU: CCU2 Error during CCU request".

Im FHEM-Log sehe ich als Aufruf-URL:
http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1.TEMPERATURE").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value()

Rufe ich die im Browser auf bekomme ich als Rückgabe im XML:
<r1>BidCos-RF.LEQxxxxxxx:1.TEMPERATURE</r1>

Jetzt habe ich mal etwas rumprobiert und bei Eingabe folgender URL im Browser: http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQ0799970:1.TEMPERATURE").Value() bekomme ich als Rückgabe im XML:
<r1>10.200000</r1>
also den korrekten Temperaturwert.

Hier noch der komplette Log-Auszug:

2015.10.25 00:05:08 4: FHEMWEB:192.168.0.39:54912 POST /fhem&cmd=get+CCU2+datapoint+BidCos-RF.LEQxxxxxxx%3A1.TEMPERATURE; BUFLEN:0
2015.10.25 00:05:08 5: Cmd: >get CCU2 datapoint BidCos-RF.LEQxxxxxxx:1.TEMPERATURE<
2015.10.25 00:05:08 4: HttpUtils url=http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxx:1.TEMPERATURE").Value()
2015.10.25 00:05:08 4: http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value(): HTTP response code 200
2015.10.25 00:05:08 4: HttpUtils http://192.168.0.140:8181/do.exe?r1=dom.GetObject("BidCos-RF.LEQxxxxxxx:1").DPByHssDP("LEQxxxxxxx:1.TEMPERATURE").Value(): Got data, length: 114
2015.10.25 00:05:08 5: Triggering CCU2 (1 changes)
2015.10.25 00:05:08 5: Notify loop for CCU2 Error
2015.10.25 00:05:08 1: HMCCU: CCU2 Error during CCU request
2015.10.25 00:05:08 4: name: /fhem&cmd=get+CCU2+datapoint+BidCos-RF.LEQxxxxxxx%3A1.TEMPERATURE / RL:1112 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /
2015.10.25 00:05:08 4: Connection closed for FHEMWEB:192.168.0.39:54910: EOF

Jetzt frage ich mich, was denn bei mir falsch läuft, dass das nicht klappt.  :(
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 Oktober 2015, 11:52:30
Du gibst im GET Befehl die korrekte Adresse (d.h. vollständige) Adresse eines Datenpunktes an. Das hatte ich bisher in HMCCU nicht berücksichtigt, werde es aber in der kommenden RPC-Version des Moduls einbauen. Bis dahin gilt folgendes Format für die Angabe eines Datenpunktes:

Channel-Name.Datenpunkt

In Deinem Beispiel wäre Datenpunkt=TEMPERATURE. Nun musst Du noch den Namen des Kanals in Deiner CCU rausbekommen. Wenn Du in der CCU "Einstellungen / Geräte" aufrufst, steht der in der Spalte Name. Hier nun den Namen auswählen, der auf den richtigen Kanal (beim Thermostaten HM-TC-IT-WM-W-EU ist das Kanal 1) verweist.

Bei der neuen Modulversion werde ich etwas mehr Intelligenz in die Namens-/Kanal-/Adressangabe einbauen.

Zur Verdeutlichung  ein kleiner Auszug aus meiner CCU Konfiguration:

<device name="KL-AZ-TH" ise_id="4927" unreach="false" sticky_unreach="false" config_pending="false">
  <channel name="KL-AZ-TH:0" ise_id="4928" visible="" operate="">...</channel>
  <channel name="KL-AZ-TH:1" ise_id="4957" visible="true" operate="true">
    <datapoint name="BidCos-RF.LEQ1462664:1.TEMPERATURE" type="TEMPERATURE" ise_id="4959" value="18.100000" valuetype="4" valueunit="°C" timestamp="1445769481" operations="5"/>
    <datapoint name="BidCos-RF.LEQ1462664:1.HUMIDITY" type="HUMIDITY" ise_id="4958" value="65" valuetype="16" valueunit="%" timestamp="1445769481" operations="5"/>
  </channel>

Hinter "datapoint name" steht der Name des Datenpunktes. Adressiert wird der momentan in HMCCU aber über den "channel name", den man in der CCU frei vergeben kann sowie den Teil des datapoint names hinter dem letzten Punkt (hier "TEMPERATURE" oder "HUMIDITY").

Das Ganze ist meiner Faulheit geschuldet, mir die kryptischen Datenpunktnamen merken zu müssen. Ich habe den Kanälen sprechende Namen gegeben. Das kann ich mir leichter behalten  ;)

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 05 November 2015, 21:08:35
Ich habe eine neue Version von HMCCU (IO-Device) und HMCCUDEV (Client-Devices) im Contrib Zweig abgelegt (Link siehe 1. Post).

Die Adressierung von CCU-Kanälen wurde komplett überarbeitet. Die set und get Befehle akzeptieren nun folgende Angaben:

Channel-Name[.Datapoint]
[Interface.]Channel-Address:Channel-Number[.Datapoint]

Das Modul benötigt die Perl-Module XML::Simple und File::Queue.

Das Modul HMCCU enthält bereits Attribute und Programmcode für die folgende Version, die einen RPC-Server enthalten wird. Die RPC Attribute können noch nicht verwendet werden.

Bei der Definition eines HMCCU Devices in FHEM wird die Devicelist der CCU gelesen. Daher muss nach dem Update auf die aktuelle Version FHEM neu gestartet oder das HMCCU Device neu angelegt werden. Wenn in der CCU ein neues Gerät angelegt wird, muss der Befehl get <name> devicelist in FHEM ausgeführt werden.

Bitte die Datei HMCCU_Readme.txt im Contrib Verzeichnis lesen. Dort ist auch die Verwendung von Client Devices beschrieben.

Noch was: das Attribute stateval wurde in statevals umbenannt.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 07 November 2015, 11:30:38
Hi zap,

danke schon mal für den Ausblick auf die RPC Version ;)

Abermal eine Frage:

Ich habe das neue Modul geholt, alles gelöscht und die hmccu wieder neu erstellt, neu gestartet und get hmccu devicelist augeführt.

Leider sehe ich keinerlei Information, dass etwas passiert. Sollten einträge erstellt werden dadurch? in einer Datei?

grüße
und Danke
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 07 November 2015, 15:07:40
Du musst "get devicelist" nur ausführen, wenn sich an Geräten in der CCU etwas geändert hat. Die Geräte werden beim FHEM Define automatisch gelesen.

Sehen kann man das Einlesen am Internal DevCount in der Ansicht des HMCCU Devices. Dort sollte eine Zahl > 0 stehen. Derzeit legt HMCCU nicht automatisch irgendwelche Client Devices (Modul HMCCUDEV) an.

Wenn ein HMCCU Device definiert ist, kannst Du CCU Gerätekanäle bzw. Datenpunkte auslesen, z.B.

get <devname> datapoint <addresse>.<datenpunkt>

get <devname> datapoint <channel-name>.<datenpunkt>

Im HMCCU Device wird der ausgelesene Wert dann als Reading gespeichert. Alternativ können für einzelne Geräte mit HMCCUDEV auch Client Devices angelegt werden.

Wichtig ist nur: get devicelist muss mindestens einmal ausgeführt worden sein. Sonst kennen weder HMCCU noch HMCCUDEV Befehle die Kanalnamen oder Kanaladressen. Dann geht nix. Und wenn man das HMCCU Modul reloaded, muss get devicelist ebenfalls ausgeführt werden.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Tscherno am 26 November 2015, 10:38:57
Zap! Das ist genau das Modul, welches ich vermisst habe. Ich verstehe, dass sich mit der FHEM-Architektur nicht leicht ein XML-RPC für die CCU bauen lässt, aber das hier ist als Übergangslösung perfekt. Ich habe mir eine Zeitlang OpenHAB nur aus dem Grund angeschaut, weil die eine ziemlich gute Anbindung an die CCU haben. Leider ist die Unterstützung für den RFXTRx, weswegen ich hauptsächlich zusätzlich zur CCU etwas brauche, miserabel. Ausserdem ist die Entwicklung für FHEM gefühlt wesentlich aktiver. Die Architektur von OH dahingegen ist natürlich schon nett... Allerdings bin ich mehr Freund von Perl ;) Lassen wir das, ich will hier keine Diskussion FHEM vs. OH vom Zaun brechen, vielleicht baut ja mal jemand eine Brücke...

Worum es mir eigentlich geht: Ich habe eben etwas mit deinem Modul gespielt. Lief leider erstmal nicht. Grund: Ich bekomme einen Timeout bei der Devicelist. Meine CCU ist durchaus ziemlich voll. Das Problem konnte ich schnell lösen, ich habe den Timeout beim entsprechenden GetFileFromURL auf 10 Sekunden gesetzt, das reicht mir. Vielleicht könntest Du dazu einen Parameter bei der Deklaration hinzufügen?

Mein erster Versuch war es, einen Schalter zu setzen. Ich würde nämlich als erstes Projekt gerne etwas mit Homebridge (läuft bereits) bauen um meine Homematic-Aktoren zu steuern. Der erste Versuch sieht so aus:

define CCU HMCCU 192.168.1.10
define Licht_Buero HMCCUDEV JEQ0295121 1
attr Licht_Buero IODev CCU
attr Licht_Buero room Homematic,Homekit

So weit, so gut, die Daten werden von der CCU korrekt ausgelesen, Anbindung passt scheinbar.

Bei einem "set  Licht_Buero devstate 1" crasht mir allerdings FHEM:
2015.11.26 10:29:25 4: FHEMWEB:192.168.1.23:9811 POST /fhem&fw_id=67&room=Homematic%2CHomekit&cmd=set++Licht_Buero+devstate+1; BUFLEN:0
2015.11.26 10:29:25 5: Cmd: >set  Licht_Buero devstate 1<
2015.11.26 10:29:25 4: HttpUtils url=http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1")
2015.11.26 10:29:25 4: http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1"): HTTP response code 200
2015.11.26 10:29:25 4: HttpUtils http://192.168.1.10:8181/do.exe?r1=dom.GetObject("BidCos-RF.JEQ0295121:1.STATE").State("1"): Got data, length: 115
2015.11.26 10:29:25 5: Triggering CCU (1 changes)
2015.11.26 10:29:25 5: Notify loop for CCU OK
Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 208.

Zeile 208 => usleep (100000);

Ich glaube usleep ist ein Teil von Time::HiRes welches ich nicht hatte und welches auch nicht geladen war. Ich habe die beiden usleep-Aufrufe auf sleep(1) geändert, damit klappt es.

Nächste Frage: Kann man FHEM irgendwie sagen, dass es sich dabei um einen Schalter handelt?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 November 2015, 11:57:17
Ja, Time::Hires wird benötigt. Was meinst Du mit "Schalter"? Sowas in der Form:

set Licht_Buero on

Das sollte mit der aktuellen Version schon gehen:

attr CCU statevals on:true,off:false

Danach bietet Dir das Device im Webinterface automatisch die Links on und off an.

Aber bevor Du jetzt reihenweise CCU Geräte definierst, warte mal noch 2-3 Tage. Habe die Tests für Version 2.0 gestern abgeschlossen. Die neue Version kommt ohne XML-API aus, was einige Befehle deutlich beschleunigt. Außerdem können mit der neuen Version native Homematic Scripts ausgeführt werden, was das Ganze ziemlich flexibel macht ;-)

Muss nur noch die Doku anpassen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 26 November 2015, 12:06:11
Aber bevor Du jetzt reihenweise CCU Geräte definierst, warte mal noch 2-3 Tage. Habe die Tests für Version 2.0 gestern abgeschlossen. Die neue Version kommt ohne XML-API aus, was einige Befehle deutlich beschleunigt. Außerdem können mit der neuen Version native Homematic Scripts ausgeführt werden, was das Ganze ziemlich flexibel macht ;-)

Muss nur noch die Doku anpassen.

Ich verbeuge mich ;) !
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 November 2015, 20:28:51
Neue Version mit RPC Server ist nun verfügbar (s. 1. Post in diesem Thread).
Bitte die Voraussetzungen (Perl-Pakete) insbesondere für den RPC-Server beachten (Datei HMCCU_Readme.txt).

Änderungen / Neuerungen:


Einschränkungen:

Die RPC Schnittstelle der CCU unterstützt nur BidCos Geräte. Daher aktualisiert der RPC Server z.B. keine CUxD Geräte. Diese müssen per AT Device mittels get Befehl aktualisiert werden.

Nach dem Starten des RPC-Servers vergehen exakt 3 Minuten, bis die ersten Events aus der CCU in FHEM ankommen. Das scheint eine Eigenart der CCU zu sein. Während dieser 3 Minuten reagiert das Web-Interface der CCU sehr träge bis gar nicht.

Der RPC-Server aktualisiert nur Readings/Datenpunkte von definierten Devices. Alle anderen Events werden ignoriert.

Die Kommunikation zwischen dem RPC-Server und FHEM erfolgt über eine Datei basierte Queue. Wer Angst um seine SD-Karte hat, kann die Queue in eine RAM-Disk legen. Wie das geht, ist in HMCCU_Readme.txt beschrieben.


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 26 November 2015, 23:11:26
Hi zap,

danke für die Skripte. Leider kommt es bei mir zum regelmässigem Absturz mit folgender Meldung im Log:

Beim Starten von fhem kommt folgende Info:

Use of each() on hash after insertion without resetting hash iterator results in undefined behavior,
 Perl interpreter: 0x162b010 at /usr/local/share/perl/5.20.2/File/Queue.pm line 19.

Beim Absturz das hier:

2015.11.26 23:10:17 1: PERL WARNING: Use of each() on hash after insertion without resetting hash iterator
 results in undefined behavior, Perl interpreter: 0x9c3010 at /usr/local/share/perl/5.20.2/File/Queue.pm line 19.
 at ./FHEM/88_HMCCU.pm line 1063.


Irgendeine Idee?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 November 2015, 07:59:30
Hmm, scheint ein Problem im Paket File::Queue zu sein. Ich schau mal nach, welche Version ich nutze. Dann können wir das abgleichen. Bei mir tritt dieser Fehler nicht auf.

In Zeile 1063 in HMCCU wird die File-Queue geöffnet. Werden denn die Queue Files angelegt (per Default /tmp/ccuqueue.idx und /tmp/ccuqueue.dat) und wenn ja steht was drin (more /tmp/ccuqueue.dat).

Update: Das Problem scheint wirklich in Queue.pm zu liegen (Zeile 19), da hier ein Hash während einer Iteration verändert wird => Das ist sehr "uncool". Statt

# convert to lower case
while( my($key, $val) = each %params)
{
  delete $params{$key};
  $params{ lc($key) } = $val;
}

wäre besser (Vorsicht, nicht getestet):

# convert to lower case
my @keylist = keys %params;
for my $key (@keylist) {
  my $val = $params{$key};
  delete $params{$key};
  $params{lc($key)} = $val;
}

Warum das Problem bei mir nicht auftritt, weiß ich allerdings nicht. Eventuell habe ich eine andere Version von Queue.pm oder vom Perl Interpreter. In der Queue.pm 1.01 in CPAN ist der Fehler noch drin.
Mal sehen, vielleicht veröffentliche ich hier ein Update für Queue.pm oder ich integriere die notwendigen Funktionen direkt in HMCCU nach dem Motto "wenn es gut werden soll, mach es selbst" ;-). Sind nur ein paar Zeilen Code.

Falls also der Absturz von FHEM bei Dir dadurch verursacht wird (und das ist sehr wahrscheinlich), solltest Du den RPC-Server erst wieder nutzen, wenn der Fehler in Queue.pm behoben wurde. Die anderen Funktionen von HMCCU sind davon nicht betroffen. Das Warning beim Starten von FHEM kann dann ignoriert werden.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 27 November 2015, 10:14:19
Hab es eben mal testweise in die Queue.pm eingefügt, Fehler bleibt leider bestehen. Sehr seltsam ;)

grüße

PS: Sollte die neuen Dateien heute nicht schon per update geholt werden? Habe es gestern von Hand geholt, aber ein update (force) holt die neuen Files noch nicht ab.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 November 2015, 11:51:48
Wenn sich an der Fehlermeldung (Queue.pm Zeile 19) nichts ändert, sind Deine Änderungen auch nicht aktiv. Diese Fehlermeldung verweist ja eindeutig auf das "each" in Zeile 19 von Queue.pm. Das ist nach der Änderung ja weg. Hast Du FHEM neu gestartet?

Zum Update: Soweit ich weiß, funktioniert das automatische Abholen per Update Befehl nicht bei Modulen im contrib Verzeichnis.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 27 November 2015, 14:34:12
Hi zap, der Hotfix funktioniert.

Ich habe es auf einem Raspberry neu aufgesetzt, und da ging es dann.

Jetzt versuche ich endlich mal, meine Umgebung aufzusetzen, bin froh, endlich von der CCU GUI wegzukommen.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 27 November 2015, 14:52:33
Wenn ich ne Frage zur Konfiguration habe. soll ich nen neuen Thread aufmachen oder hier fragen?

Ich frag erstmal hier, wird wohl mehrere interessieren die es benutzen möchten.

Ich habe Jetzt mal ein Thermostat eingefügt als HMCCUDEV Device, die Werte werden auch abgefragt und dargestellt:
DEF MEQ0XXXXXX

IODev d_ccu
NAME BadHeizThermostat
NR 119
STATE Initialized
TYPE HMCCUDEV
ccuaddr MEQ0182028
ccuif BidCos-RF
ccuname HeizungBad
ccutype HM-CC-RT-DN
statevals devstate
Readings
TemperaturBad.ACTUAL_TEMPERATURE 23.500.000 27.11.2015 13:48:34
TemperaturBad.BATTERY_STATE 3.000.000 27.11.2015 13:48:34
TemperaturBad.BOOST_STATE 0 27.11.2015 13:48:34
TemperaturBad.CONTROL_MODE 0 27.11.2015 13:48:34
TemperaturBad.FAULT_REPORTING 0 27.11.2015 13:48:34
TemperaturBad.PARTY_START_DAY 1 27.11.2015 13:48:34
TemperaturBad.PARTY_START_MONTH 1 27.11.2015 13:48:37
TemperaturBad.PARTY_START_TIME 0 27.11.2015 13:48:34
TemperaturBad.PARTY_START_YEAR 0 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_DAY 1 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_MONTH 1 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_TIME 0 27.11.2015 13:48:37
TemperaturBad.PARTY_STOP_YEAR 0 27.11.2015 13:48:37
TemperaturBad.PARTY_TEMPERATURE 5.000.000 27.11.2015 13:48:34
TemperaturBad.SET_TEMPERATURE 17.000.000 27.11.2015 13:48:34
TemperaturBad.VALVE_STATE 0 27.11.2015 13:48:34
state Initialized 27.11.2015 13:35:26

allerdings ist mir nicht ganz klar, wie ich jetzt einen Wert ändern kann. Alles, was ich versucht habe, bringt eine Fehlermeldung.

Kann mir jemand einen Hinweis dazu geben bitte?

grüße
und Danke
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 November 2015, 17:08:36
Die Frage kannst Du ruhig hier stellen. Aber zunächst  nochmal zum anderen Problem: Ich verwende Perl 5.14.2, also eine ältere Version als Du. Möglicherweise ist mein Perl bei dem Queue.pm Fehler etwas toleranter. Die Queue.pm Version ist die 1.01, also die mit dem Fehler. Ich werde einen Ersatz für die new() Funktion direkt in HMCCU bzw. ccurpcd.pl einbauen. Dann dürfte sich das erledigt haben.

Zu Deinem Problem mit dem Setzen von Werten: Bei dem Wandthermostat kann man nicht alle Datenpunkte setzen, einige können nur gelesen werden. Was auf jeden Fall gehen sollte ist die Einstellung der gewünschten Raumtemperatur. In Deinem Fall

set BadHeizThermostat datapoint 2.SET_TEMPERATURE 23

Bei einem HMCCUDEV Device ist die Geräteadresse ja schon durch die Definition bekannt. Du musst also nur noch die Kanalnummer und den Datenpunkt angeben. Und natürlich den Wert (hier 23 Grad). Die Angabe des Kanalnames ("TemperaturBad") ist hier nicht zulässig, da diese sowohl Geräteadresse als auch Kanalnummer enthält. Hier könnte ich dem Modul vielleicht noch etwas mehr Toleranz beibringen ;-)

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 27 November 2015, 22:55:44
Hi zap,

danke für die Antwort. Das ist aber kein Wandthermostat, sondern das am Heizkörper. Dein Befehl mit der 4 statt der 2 hat dann auch gleich funktioniert.

Danke dafür.

Jetzt kann ich endlich anfangen, das ganze sauber umzusetzen.

grüße
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 30 November 2015, 12:19:14
Hi zap,

und wieder ich :-D

Leider scheint der RPC Server ein Problem zu haben. Laut Logfile fliegt er auch die Schnauze, starten kann man ihn dennoch nicht, da er noch läuft, der Prozess wenigstens. Hier der gesamte logauszug:

29.11.2015 16:33:16 Shutdown RPC server
29.11.2015 16:33:16 RPC server terminated
29.11.2015 16:33:31 Creating file queue
29.11.2015 16:33:31 Initializing RPC server
29.11.2015 16:33:31 callback server created
29.11.2015 16:33:31 Adding callback for events
29.11.2015 16:33:31 Adding callback for new devices
29.11.2015 16:33:31 Adding callback for deleted devices
29.11.2015 16:33:31 Adding callback for modified devices
29.11.2015 16:33:31 Registering callback
29.11.2015 16:36:31 RPC callback with URL http://172.23.1.52:7401/fh initialized
29.11.2015 16:36:31 Entering server loop. Use kill -SIGINT 22030 to terminate program
29.11.2015 16:36:31 ListDevices
29.11.2015 16:36:32 NewDevice: received 91 device specifications
29.11.2015 23:30:13 Creating file queue
29.11.2015 23:30:13 Initializing RPC server
29.11.2015 23:30:14 Can't create RPC callback server on port 7401. Port in use?
29.11.2015 23:30:14 Error: Can't initialize RPC server
30.11.2015 09:57:54 Creating file queue


Vielleicht kannst du damit etwas anfangen.

PS: Mein System ist: Ubuntu VM 15.10, fhem snapshot.

grüße
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 November 2015, 14:25:38
Das sieht doch gar nicht so schlecht aus. Ich füge in das Logfile mal ein paar Kommentare ein. Dann wird vielleicht klarer was das passiert:

# RPC Server wird sauber gestoppt
29.11.2015 16:33:16 Shutdown RPC server
29.11.2015 16:33:16 RPC server terminated

# RPC Server wird gestartet, zunächst die File-Queue anlegen
29.11.2015 16:33:31 Creating file queue

# Der Server wird initialisiert
29.11.2015 16:33:31 Initializing RPC server
29.11.2015 16:33:31 callback server created

# Die Callback-Funktionen werden bei der CCU registriert
29.11.2015 16:33:31 Adding callback for events
29.11.2015 16:33:31 Adding callback for new devices
29.11.2015 16:33:31 Adding callback for deleted devices
29.11.2015 16:33:31 Adding callback for modified devices

# Die Callbacks werden initialisiert. Das dauert 3 Minuten
29.11.2015 16:33:31 Registering callback

# Callback Initialisierung war erfolgreich. Der RPC Server für FHEM wartet auf Calls von der CCU
29.11.2015 16:36:31 RPC callback with URL http://172.23.1.52:7401/fh initialized
29.11.2015 16:36:31 Entering server loop. Use kill -SIGINT 22030 to terminate program

# Die CCU hat die Methode "ListDevices" aufgerufen => Wird ignoriert
29.11.2015 16:36:31 ListDevices

# Die CCU hat Infos über 91 CCU Devices an den RPC Server geschickt => Da wird momentan nix mit gemacht
29.11.2015 16:36:32 NewDevice: received 91 device specifications

# Ab hier empfängt der RPC Server Events für CCU Devices. Das wird nicht separat geloggt.

# Hier wird jetzt versucht, bei einem vermutlich schon laufenden Server den Server nochmal zu starten. Das geht in Hose, weil der Port belegt ist
29.11.2015 23:30:13 Creating file queue
29.11.2015 23:30:13 Initializing RPC server
29.11.2015 23:30:14 Can't create RPC callback server on port 7401. Port in use?
29.11.2015 23:30:14 Error: Can't initialize RPC server
30.11.2015 09:57:54 Creating file queue

Du solltest mal prüfen, ob der Prozesse noch läuft:

ps -ef | grep ccurpcd

Du kannst den laufenden killen mit kill -SIGNIT Id. Dann wird er sauber gestoppt. Sehr zu empfehlen, sonst macht die CCU irgendwann mal die Grätsche.

Dann kannst Du noch prüfen, ob im Queue-File /tmp/ccuqueue.dat was drin steht. Das  ist ein Textfile. Hier sollten Updates von der CCU drin stehen (Events fangen mit "EV" an).

Wichtig: Es werden nur Datenpunkte von HMCCUCHN oder HMCCUDEV Devices aktualisiert.

Notiz an mich: Beim Starten vom RPC Server prüfen, ob schon einer läuft und ggf. Meldung ins Log schreiben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 November 2015, 20:20:17
Ich habe ein Update für 88_HMCCU.pm und ccurpcd.pl auf Sourceforge bereitgestellt. Zusätzlich habe ich das Modul RPCQueue.pm hochgeladen. Dieses Modul ersetzt das CPAN Modul File::Queue, das leider einen Fehler hat, der mit Perl ab Version 5.20 zum Absturz von FHEM führt. RPCQueue.pm kommt ebenfalls in das FHEM Unterverzeichnis, in dem auch die 88_HMCCU-Module liegen. RPCQueue.pm ist nichts als eine Kopie von File::Queue ohne den Bug ;-)

Neuerungen:


Links und weitere Infos wie immer im 1. Post in diesem Thread.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: MaSie am 01 Dezember 2015, 10:07:10
Ich bitte um Hilfe.

Ich habe die "88_HMCCU* and the RPC daemon ccurpcd.pl" in das Verzeichnis FHEM kopiert und die "packages LWP::UserAgent, Time::HiRes and File::Queue. The RPC server ccurpcd.pl requires the packages File::Queue, RPC::XML::Server, RPC::XML::Client, XML::Simple and IO::Socket::INET" installiert.

Dennoch bringt das Define eine Fehlermeldung.

define CCU2 HMCCU 192.168.200.58
Cannot load module HMCCU

Im Logfile steht:
2015.12.01 09:38:49 1: reload: Error:Modul 88_HMCCU deactivated:
 Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: C:/FHEM/fhem-5.6/perl/site/lib C:/FHEM/fhem-5.6/perl/vendor/lib C:/FHEM/fhem-5.6/perl/lib . ./FHEM) at ./FHEM/88_HMCCU.pm line 48.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 48.

Mein Versuch, in der "portableshell" mit "cpan install RPC::XML::Client" brachte eine Fehlermeldung nach einem umfangreichen Test-Durchlauf:
...
Stopping: 'install' failed for 'RPC::XML::Client'.

Jetzt komme ich nicht mehr weiter.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 Dezember 2015, 11:52:47
Ohne RPC::XML::Client läuft das nicht. Gibt cpan install irgendwelche anderen Fehlermeldungen aus? Auf welchem Betriebssystem installierst Du das?

BTW: Für die aktuelle Version in Sourceforge benötigst Du File::Queue nicht. Das hat einen Bug. Daher habe ich RPCQueue.pm bereitgestellt. Das kommt ins gleiche Verzeichnis wir die HMCCU Module.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: MaSie am 01 Dezember 2015, 13:32:28
Auf Windows.

Fehlermeldungen gabes eine lange Liste ..
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: MaSie am 01 Dezember 2015, 13:38:46
C:\FHEM\fhem-5.6>cpan install RPC::XML::Client
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN: CPAN::SQLite loaded ok (v0.211)
Database was generated on Tue, 01 Dec 2015 08:06:32 GMT

Running install for module 'RPC::XML::Client'
CPAN: Digest::SHA loaded ok (v5.95)
CPAN: Compress::Zlib loaded ok (v2.068)
Checksum for C:\FHEM\fhem-5.6\cpan\sources\authors\id\R\RJ\RJRAY\RPC-XML-0.79.tar.gz ok
tmp-1204 for tmp-1204: No such file or directory at C:\FHEM\fhem-5.6\perl\lib/CPAN/Distribution.pm line 468.
CPAN: Archive::Tar loaded ok (v2.04)
CPAN: File::Temp loaded ok (v0.2304)
CPAN: YAML::XS loaded ok (v0.59)
CPAN: CPAN::Meta::Requirements loaded ok (v2.133)
CPAN: Parse::CPAN::Meta loaded ok (v1.4417)
CPAN: CPAN::Meta loaded ok (v2.150005)
CPAN: Module::CoreList loaded ok (v5.20150912)
Configuring R/RJ/RJRAY/RPC-XML-0.79.tar.gz with Makefile.PL
Checking if your kit is complete...
Looks good
Generating a dmake-style Makefile
Writing Makefile for RPC::XML
Writing MYMETA.yml and MYMETA.json
  RJRAY/RPC-XML-0.79.tar.gz
  C:\FHEM\fhem-5.6\perl\bin\perl.exe Makefile.PL -- OK
Running make for R/RJ/RJRAY/RPC-XML-0.79.tar.gz
---- Unsatisfied dependencies detected during ----
----         RJRAY/RPC-XML-0.79.tar.gz        ----
    DateTime::Format::ISO8601 [requires,optional]
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=lib\Apache\RPC\status
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\identity
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\introspection
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\listMethods
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\methodHelp
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\methodSignature
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\multicall
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" etc\make_method --base=methods\status
cp lib/RPC/XML.pm blib\lib/RPC/XML.pm
cp methods\methodSignature.xpl blib\lib\RPC\XML\methodSignature.xpl
cp methods\identity.xpl blib\lib\RPC\XML\identity.xpl
cp lib/RPC/XML/Procedure.pm blib\lib/RPC/XML/Procedure.pm
cp lib/RPC/XML/Server.pm blib\lib/RPC/XML/Server.pm
cp lib/RPC/XML/Parser/XMLLibXML.pm blib\lib/RPC/XML/Parser/XMLLibXML.pm
cp methods\methodHelp.xpl blib\lib\RPC\XML\methodHelp.xpl
cp lib/Apache/RPC/Status.pm blib\lib/Apache/RPC/Status.pm
cp lib/RPC/XML/Parser.pm blib\lib/RPC/XML/Parser.pm
cp methods\multicall.xpl blib\lib\RPC\XML\multicall.xpl
cp methods\introspection.xpl blib\lib\RPC\XML\introspection.xpl
cp lib/RPC/XML/Client.pm blib\lib/RPC/XML/Client.pm
cp lib/RPC/XML/ParserFactory.pm blib\lib/RPC/XML/ParserFactory.pm
cp lib/Apache/RPC/status.xpl blib\lib/Apache/RPC/status.xpl
cp lib/Apache/RPC/Server.pm blib\lib/Apache/RPC/Server.pm
cp methods\status.xpl blib\lib\RPC\XML\status.xpl
cp methods\listMethods.xpl blib\lib\RPC\XML\listMethods.xpl
cp lib/RPC/XML/Parser/XMLParser.pm blib\lib/RPC/XML/Parser/XMLParser.pm
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" -MExtUtils::Command -e cp -- etc\make_method blib\script\make_method
pl2bat.bat blib\script\make_method
  RJRAY/RPC-XML-0.79.tar.gz
  C:\FHEM\fhem-5.6\c\bin\dmake.exe -- OK
Running make test
"C:\FHEM\fhem-5.6\perl\bin\perl.exe" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/00_load.t ..................... ok
t/10_data.t ..................... ok
t/11_base64_fh.t ................ ok
t/12_nil.t ...................... ok
t/13_no_deep_recursion.t ........ ok
t/14_datetime_iso8601.t ......... skipped: DateTime::Format::ISO8601 not available
t/15_serialize.t ................ ok
t/20_xml_parser.t ............... ok
t/21_xml_libxml.t ............... ok
t/25_parser_negative.t .......... ok
t/29_parserfactory.t ............ ok
t/30_procedure.t ................ ok
t/35_namespaces.t ............... ok
t/40_server.t ................... 24/91
t/40_server.t ................... 30/91 #   Failed test 'First live req: Check that $res is not an error'
#   at t/40_server.t line 245.

#   Failed test ''First live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server.t line 248.
#     'First live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 35/91
t/40_server.t ................... 36/91 #   Failed test 'Second live req: Check that $res is not an error'
#   at t/40_server.t line 293.

#   Failed test ''Second live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server.t line 295.
#     'Second live req: parsed $res' isn't a 'RPC::XML::response'

t/40_server.t ................... 41/91 #   Failed test 'Third live req: Check that $res is not an error'
#   at t/40_server.t line 323.

#   Failed test ''Third live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server.t line 325.
#     'Third live req: parsed $res' isn't a 'RPC::XML::response'

t/40_server.t ................... 47/91 #   Failed test 'Fourth live req: Check that $res is not an error'
#   at t/40_server.t line 368.

#   Failed test ''Fourth live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server.t line 370.
#     'Fourth live req: parsed $res' isn't a 'RPC::XML::response'

t/40_server.t ................... 52/91 #   Failed test 'RT29351 live req: $res is not an error'
#   at t/40_server.t line 417.

#   Failed test ''RT29351 live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server.t line 419.
#     'RT29351 live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server.t ................... 57/91
t/40_server.t ................... 59/91 #   Failed test ''system.listMethods response' isa 'RPC::XML::response''
#   at t/40_server.t line 475.
#     'system.listMethods response' isn't a 'RPC::XML::response'
t/40_server.t ................... 83/91
#   Failed test 'Arg-count testing of procedure types'
t/40_server.t ................... 84/91 #   at t/40_server.t line 1107.
#          got: 'parse-error,parse-error,parse-error'
#     expected: '0,1,0'
t/40_server.t ................... 89/91 # Looks like you planned 91 tests but ran 90.
# Looks like you failed 12 tests of 90 run.
t/40_server.t ................... Dubious, test returned 12 (wstat 3072, 0xc00)
Failed 13/91 subtests
        (less 43 skipped subtests: 35 okay)
t/40_server_xmllibxml.t ......... 1/62
t/40_server_xmllibxml.t ......... 14/62 #   Failed test 'First live req: Check that $res is not an error'
#   at t/40_server_xmllibxml.t line 142.

#   Failed test ''First live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server_xmllibxml.t line 145.
#     'First live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 19/62
t/40_server_xmllibxml.t ......... 20/62 #   Failed test 'Second live req: Check that $res is not an error'
#   at t/40_server_xmllibxml.t line 190.

#   Failed test ''Second live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server_xmllibxml.t line 192.
#     'Second live req: parsed $res' isn't a 'RPC::XML::response'

t/40_server_xmllibxml.t ......... 25/62 #   Failed test 'Third live req: Check that $res is not an error'
#   at t/40_server_xmllibxml.t line 220.

#   Failed test ''Third live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server_xmllibxml.t line 222.
#     'Third live req: parsed $res' isn't a 'RPC::XML::response'

t/40_server_xmllibxml.t ......... 31/62 #   Failed test 'RT29351 live req: $res is not an error'
#   at t/40_server_xmllibxml.t line 269.

#   Failed test ''RT29351 live req: parsed $res' isa 'RPC::XML::response''
#   at t/40_server_xmllibxml.t line 271.
#     'RT29351 live req: parsed $res' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 36/62
t/40_server_xmllibxml.t ......... 38/62 #   Failed test ''system.listMethods response' isa 'RPC::XML::response''
#   at t/40_server_xmllibxml.t line 323.
#     'system.listMethods response' isn't a 'RPC::XML::response'
t/40_server_xmllibxml.t ......... 62/62 # Looks like you failed 9 tests of 62.
t/40_server_xmllibxml.t ......... Dubious, test returned 9 (wstat 2304, 0x900)
Failed 9/62 subtests
        (less 33 skipped subtests: 20 okay)
t/41_server_hang.t .............. ok
t/50_client.t ................... 11/33
t/50_client.t ................... 16/33 #   Failed test 'simple_request/system.identity returns correct value'
#   at t/50_client.t line 102.
#          got: undef
#     expected: 'RPC::XML::Server/1.73'

#   Failed test 'simple_request/system.identity left $RPC::XML::ERROR empty'
#   at t/50_client.t line 104.

t/50_client.t ................... 18/33 #   Failed test ''system.identity response' isa 'RPC::XML::string''
#   at t/50_client.t line 109.
#     'system.identity response' isn't a 'RPC::XML::string'

t/50_client.t ................... 20/33 #   Failed test ''simple_request/system.bad response' isa 'HASH''
#   at t/50_client.t line 130.
#     'simple_request/system.bad response' isn't defined

t/50_client.t ................... 23/33 #   Failed test ''send_request/system.bad response' isa 'RPC::XML::fault''
#   at t/50_client.t line 153.
#     'send_request/system.bad response' isn't a 'RPC::XML::fault'

t/50_client.t ................... 25/33 #   Failed test 'fault_handler correctly set $flag'
#   at t/50_client.t line 187.

#   Failed test ''fault_handler returned value' isa 'RPC::XML::fault''
#   at t/50_client.t line 189.
#     'fault_handler returned value' isn't a 'RPC::XML::fault'
t/50_client.t ................... 28/33
t/50_client.t ................... 30/33 #   Failed test ''cmpImg return value' isa 'RPC::XML::boolean''
#   at t/50_client.t line 260.
#     'cmpImg return value' isn't a 'RPC::XML::boolean'

t/50_client.t ................... 32/33 #   Failed test ''cmpImg return value (compression)' isa 'RPC::XML::boolean''
#   at t/50_client.t line 276.
#     'cmpImg return value (compression)' isn't a 'RPC::XML::boolean'
# Looks like you failed 9 tests of 33.
t/50_client.t ................... Dubious, test returned 9 (wstat 2304, 0x900)
Failed 9/33 subtests
        (less 7 skipped subtests: 17 okay)
t/51_client_with_host_header.t .. ok
t/60_net_server.t ............... skipped: Net::Server tests not reliable on Windows platform
t/70_compression_detect.t ....... ok
t/90_rt50013_parser_bugs.t ...... ok
t/90_rt54183_sigpipe.t .......... skipped: Skipping *NIX signals-based test on Windows platform
t/90_rt54494_blessed_refs.t ..... ok
t/90_rt58065_allow_nil.t ........ ok
t/90_rt58323_push_parser.t ...... ok

Test Summary Report
-------------------
t/40_server.t                 (Wstat: 3072 Tests: 90 Failed: 12)
  Failed tests:  31-32, 37-38, 42-43, 48-49, 53-54, 59, 84
  Non-zero exit status: 12
  Parse errors: Bad plan.  You planned 91 tests but ran 90.
t/40_server_xmllibxml.t       (Wstat: 2304 Tests: 62 Failed: 9)
  Failed tests:  15-16, 21-22, 26-27, 32-33, 38
  Non-zero exit status: 9
t/50_client.t                 (Wstat: 2304 Tests: 33 Failed: 9)
  Failed tests:  16-18, 20, 23, 25-26, 30, 32
  Non-zero exit status: 9
Files=25, Tests=953, 173 wallclock secs ( 0.28 usr +  0.09 sys =  0.37 CPU)
Result: FAIL
Failed 3/25 test programs. 30/953 subtests failed.
dmake.exe:  Error code 255, while making 'test_dynamic'
  RJRAY/RPC-XML-0.79.tar.gz
  C:\FHEM\fhem-5.6\c\bin\dmake.exe test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
  reports RJRAY/RPC-XML-0.79.tar.gz
Stopping: 'install' failed for 'RPC::XML::Client'.

C:\FHEM\fhem-5.6>
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 Dezember 2015, 13:54:34
Ich befürchte, das wird nix unter Windows. Der Fehler bei der Installation ist wohl bekannt:

Zitat
To paraphrase, there seems to be a 'fork' emulation issue on Windows Perl. The failing code is trying to start a child HTTP listener, but there ends up not being any process or protocol listening on the port

Ein Tipp ist wohl, während der Installation die Firewall abzuschalten. Weiß aber nicht, ob das was bringt.

Außerdem ist es fraglich, ob der RPC Server unter Windows funktioniert, insbesondere das Starten aus dem HMCCU Modul heraus.

Bitte nicht falsch verstehen, soll jetzt nicht demotivieren. Nur um Enttäschungen zu vermeiden, wenn es dass am Ende nicht läuft.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: MaSie am 01 Dezember 2015, 14:05:01
SCHADE.

Trotzdem Dank für Deine Mühen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 01 Dezember 2015, 15:07:00
Hallo Masie,

was spricht denn dagegen, das FHEM in eine virtuelle Ubuntu umgebung zu installieren.

Vorteile: Bei änderungen / update von Windows lässt es sich einfach mitnehmen.

Nachteil: ( für manche ;) ) ist halt Linux

grüße
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 01 Dezember 2015, 16:17:06
Hi zap,

vorweg: Ich versuche ehrlich, soviel zu lesen wie ich kann, aber fhem kann durchaus komplex werden ;)

Ich kann ( wie bereits geschrieben ), die Thermostate auslesen, auch die Werte von Hand verändern.

Mein Setup ist leicht anders jetzt:

Name Heizkörper : HzB

setzen der Temperatur: set HzB datapoint 4.SET_TEMPERATURE 25

Jetzt wollte ich allerdings das Tablet UI benutzen, damit meine Frau mich nicht mehr schimpft, weil sie nichts mehr einstellen kann ;)

Dort schaffe ich es allerdings nicht, auch nur die aktuelle Temperatur anzuzeigen, geschweige denn einzustellen. Überall steht etwas von z.b. desired-temp, aber auch eine google Suche bringt mich immer nur auf die gleichen Seiten, allerdings finde ich keine Beschreibung, wie ich an diese Eigenschaften komme. Auch _Clima ist so ein Treffer, der bei mir nirgendwo was auslöst ;)

Vielleicht kannst Du mir bei meinem Verständnissproblem helfen.

gruß und Danke ( und sorry, für das ständige Fragen )

PS: Wenn erwünscht, würde ich auch eine Beschreibung machen, wie das Modul installiert und eingestellt wird, da in der Wiki ja noch kein Eintrag vorhanden ist.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 Dezember 2015, 16:45:32
@EdgarM: Zu Deiner Frage später.

Zunächst eine allgemeine Info: Habe ein Update für 88_HMCCU.pm und 88_HMCCUDEV.pm auf Sourceforge bereitgestellt (Link siehe wie immer 1. Post in diesem Thread).

Neu: Der Befehl get channel bei HMCCU und bei HMCCUDEV akzeptiert nun die Angabe mehrerer Kanäle. Bei einem HMCCUDEV Device kann man nun folgende Abfrage absetzen:

get mydevice channel 0.^UNREACH 1

Mit diesem Befehl wird der Datenpunkt 'UNREACH' von Kanal 0 und alle Datenpunkte von Kanal 1 gelesen.

Für das IO Device sieht der analoge Befehl so aus:

get mydevice channel LEQ1234567:0.^UNREACH LEQ1234567:1

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 Dezember 2015, 20:17:18
Hi zap,

vorweg: Ich versuche ehrlich, soviel zu lesen wie ich kann, aber fhem kann durchaus komplex werden ;)

Das stimmt. Deshalb mache ich nur die Dinge, die mit der CCU nicht gehen, mit FHEM.

Zitat
Ich kann ( wie bereits geschrieben ), die Thermostate auslesen, auch die Werte von Hand verändern.

D.h. Du hast Readings mit den Werten in Deinen Devices. Das hört sich schon mal gut an.

Zitat
Jetzt wollte ich allerdings das Tablet UI benutzen, damit meine Frau mich nicht mehr schimpft, weil sie nichts mehr einstellen kann ;)

Dort schaffe ich es allerdings nicht, auch nur die aktuelle Temperatur anzuzeigen, geschweige denn einzustellen. Überall steht etwas von z.b. desired-temp, aber auch eine google Suche bringt mich immer nur auf die gleichen Seiten, allerdings finde ich keine Beschreibung, wie ich an diese Eigenschaften komme. Auch _Clima ist so ein Treffer, der bei mir nirgendwo was auslöst ;)

Das mit der Frau kenne ich. Die Darstellung auf einem Tablet ist auch der Grund für die Entwicklung von HMCCU. Allerdings lasse ich es etwas einfacher angehen. Tablet UI ist sicher mit das komplexeste Frontend, aber hat auch die meisten Möglichkeiten. Ich habe mich allerdings noch nicht damit beschäftigt, daher kann ich Dir kaum helfen. Im Zweifel solltest Du Fragen dazu im Bereich "Frontends" stellen.

Ich habe mir mal einige der HTML Beispiel Templates von Tablet-UI angeschaut. Da gibt es Einträge wie:

<div data-type="label" data-devices="xyz" data-get="reading" ...

Damit wird anscheinend ein Textfeld zum Anzeigen eines Readings definiert. Bei data-devices müsste vermutlich "HzB" stehen und bei Reading eben der Name des Wertes, der angezeigt werden soll. Nach diesem Schema scheinen viele Elemente bei Tablet-UI definiert zu werden. Aber wie gesagt: ich kenne mich damit nicht wirklich aus. Ich verwende für die Darstellung das Modul INFOPANEL, das aber lange nicht so flexibel ist wie Tablet UI.

Was ich allerdings nicht verstehe: Warum kann Deine Frau das Thermostat nicht per Hand bedienen? Im Zweifel mach es wie ich und kopple das Thermostat am Heizkörper mit einem Wandthermostat. Damit kann man sehr komfortabel die Heizkörper bedienen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: EdgarM am 01 Dezember 2015, 21:24:52
Hi zap,

die Regierung bestimmt, was wir tun ;)

Wir haben nur ein Wandthermostat im Wohnzimmer, in den restlichen Zimmern lediglich Heizungsthermostate. Früher(TM) haben wir den Hauptzulauf an oder ausgemacht, jetzt bleibt der immer an. Deswegen müßte man alle Heizungen von Hand ändern, und das wäre dann schon nervig. Und mein Hauptargument für SmartHome war ja, dass man das einfach und zentral machen kann. ... Irgendwann :-D

Ich mache es jetzt einfach mal so wie du. Ich fange gerade an, mich in RSS einzulesen, vielleicht verstehe ich dann genug für den nächsten Schritt Und meine Frau kann dann schon mal damit spielen ;)

Danke für Deine freundliche Unterstützung.

grüße
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: chavalaloco am 02 Dezember 2015, 22:31:16
Hi Leute
Ich bin mit meinem Latein am Ende wenn ich die CCU definieren möchte, bekomme ich immer die Fehlermeldung "Cannot load module HMCCU".
Rechte passen, XML::Simple ist auch installiert.
Ich komme nicht mehr weiter, bitte helft mir :D.
In meinem Log steht folgendes:

reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.

Gruß Chavalaloco
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 03 Dezember 2015, 07:47:57
reload: Error:Modul 88_HMCCU deactivated:
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.
Glob not terminated at ./FHEM/88_HMCCU.pm line 26.

Das ist krass. Die Meldung kommt vom Perl Lexer und besagt eigentlich, dass ein '<' als Start eines HTML-Tags erkannt wurde aber das abschließende '>' fehlt. Nun ist Zeile 26 in 88_HMCCU.pm eine Kommentarzeile. In der wird zwar '<' als Kennzeichnung eines Parameters verwendet. Aber 1. mit abschließendem '>' und 2. in einem Kommentar. Das sollte Perl also eigentlich ignorieren.

Seltsam ist auch, dass das Problem anscheinend nur bei Dir auftritt (wobei ich nicht weiß, wie viele Leute das Modul verwenden). Ich vermute, dass die Datei irgendwie korrupt ist.

Hier nochmal die Zeile mit dem Fehler:
#  get <name> parfile [<parfile>]

Frage: Ich nehme an, Du hast die aktuelle Version des Modules aus Sourceforge runter geladen?

Bitte: Kannst Du mit die Datei mal per Mail schicken oder die ersten 30 Zeilen hier posten (bitte nicht die ganze Datei posten).

Wenn Du selbst testen möchtest, wirf einfach alle Kommentarzeilen am Anfang der Datei raus und versuche es nochmal.

BTW: XML::Simple wird nicht mehr benötigt. Bitte aber darauf achten, dass folgende Dateien im FHEM-Modulverzeichnis ( /FHEM) liegen:

88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 04 Dezember 2015, 19:26:08
Ich habe im FHEM Sourceforge Repository die Version 2.2 der HMCCU Module bereitgestellt.

Die Module unterstützen nun das Auslesen und Setzen von Konfigurationsparametern von CCU Geräten und Kanälen. Der Zugriff erfolgt mit RPC (putParamset, getParamset). Daher werden nur BidCos Devices unterstützt.

Folgende Befehle sind für HMCCU-Devices nun verfügbar:

get devname config {devicename|deviceaddress|channelname|channeladdress}
get devname configdesc {devicename|deviceaddress|channelname|channeladdress}
set devname config {devicename|deviceaddress|channelname|channeladdress} parameter=value [...]

Für HMCCUDEV-Devices (Geräteadresse über Definition bekannt):

get devname config [channelnumber]
get devname configdesc [channelnumber]
set devname config [channelnumber] parameter=value [...]

Für HMCCUCHN-Devices (Geräteadresse und Kanalnummer über Definition bekannt):

get devname config
get devname configdesc
set devname config parameter=value [...]

Zu beachten:


Beispiel: Temperaturwerte für bestimmte Tageszeiten in einem Thermostaten setzen

set CCU config KL-SZ-TH P1_TEMPERATURE_FRIDAY_1=17.000000 P1_TEMPERATURE_FRIDAY_2=21.000000

Beispiel für Parameter-Readings:

R-KL-SZ-TH.LOCAL_RESET_DISABLE 0 2015-12-04 17:28:30
R-KL-SZ-TH.LOW_BAT_LIMIT 2.200000 2015-12-04 17:28:30
R-KL-SZ-TH.MANU_MODE_PRIORITIZATION 1 2015-12-04 17:28:30
R-KL-SZ-TH.MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE 0 2015-12-04 17:28:30
R-KL-SZ-TH.MODUS_BUTTON_LOCK 0 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_1 420 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_10 1440 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_11 1440 2015-12-04 17:28:30
R-KL-SZ-TH.P1_ENDTIME_FRIDAY_12 1440 2015-12-04 17:28:30

Hinweis: Die Datei HMCCU_Readme.txt ist noch nicht aktualisiert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 Dezember 2015, 19:42:22
Neue Version von 88_HMCCU.pm eingecheckt. Es steht nun der Befehl "get deviceinfo" zur Verfügung. Der Befehl gibt eine Liste aller Kanäle und Datenpunkte eines CCU Devices aus. Sehr hilfreich bei der Definition und Nutzung von HMCCU Client-Devices in FHEM.

Beispiel:

get CCU deviceinfo KEQ0038200

Ausgabe:

Channel KEQ0038200:0 ST-WZ-Bass:0
  DP BidCos-RF.KEQ0038200:0.UNREACH = false
  DP BidCos-RF.KEQ0038200:0.STICKY_UNREACH = false
  DP BidCos-RF.KEQ0038200:0.CONFIG_PENDING = false
  DP BidCos-RF.KEQ0038200:0.LOWBAT = false
  DP BidCos-RF.KEQ0038200:0.DUTYCYCLE = false
  DP BidCos-RF.KEQ0038200:0.RSSI_DEVICE = 1
  DP BidCos-RF.KEQ0038200:0.RSSI_PEER = 207
Channel KEQ0038200:1 ST-WZ-Bass:1
  DP BidCos-RF.KEQ0038200:1.STATE = false
  DP BidCos-RF.KEQ0038200:1.ON_TIME =
  DP BidCos-RF.KEQ0038200:1.INHIBIT = false
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 08 Dezember 2015, 19:52:47
Gute Idee!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: AHA1805 am 09 Dezember 2015, 17:35:59
Hallo,

ich verfolge der Beitrag schon eine weile.
Ich finde die Idee super, das würde heißen man muss das HM Protokoll nicht regenerieren.

Ich hätte drei Fragen dazu.
* Wie ist die Reaktionszeit in FHEM wenn ein Sensor  (Taster) gedrückt wird welcher über die CCU eingebunden wurde?
D.h. kann ich diese noch in notify einbinden und in "Echtzeit " damit andere Aktoren schalten.
*Wie ist die Reaktionszeit beim Schalten von Aktoren die mit der CCU gepaired sind und über FHEM schalten möchte?
*Wie würde die Pflege des Moduls aussehen, der Support von Martin für HM ist sensationell.

Ich will hiermit aber niemanden kritisieren :-)

Schöne Grüße
Hannes

Gesendet von meinem SM-T715 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 09 Dezember 2015, 18:46:50
* Wie ist die Reaktionszeit in FHEM wenn ein Sensor  (Taster) gedrückt wird welcher über die CCU eingebunden wurde?
D.h. kann ich diese noch in notify einbinden und in "Echtzeit " damit andere Aktoren schalten.

Es gibt bei Einsatz von HMCCU zwei Möglichkeiten, in FHEM vom Drücken eines Tasters zu erfahren:

1) Man definiert ein AT Device und fragt regelmäßig den Zustand eines CCU Gerätes ab. Bei einem Intervall von wenigen Sekunden würde die Zustandsänderung entsprechend schnell in FHEM ankommen.

2) Man nutzt den HMCCU RPC-Server. Dieser Server wird von der CCU sofort benachrichtigt, wenn sich ein Status ändert. Da ich den RPC-Server als externen Prozess implementieren musste (FHEM ist für eine direkte Implementierung nicht so gut geeignet), gibt es auch hier eine Zeitdifferenz. Der RPC-Server schreibt Ereignisse von der CCU (z.B. das Drücken eines Tasters) in eine Queue. Diese Queue wird von HMCCU in definierbaren Intervallen abgefragt. Derzeit sind 3, 5 oder 10 Sekunden vorgesehen. Über den attr Befehl können aber auch andere Intervalle eingestellt werden. Ich würde hier aber nicht unter 2 Sekunden gehen. D.h. FHEM erfährt spätestens 2 Sekunden nach dem Drücken des Tasters davon.
Achtung! Die RPC Schnittstelle der CCU hat den Nachteil, dass sie nur BidCos Devices unterstützt. Wenn Du also CUxD einsetzt, funktioniert die Benachrichtigung über den RPC-Server nicht. Für diese Geräte bleibt nur der AT Befehl.

Zitat
*Wie ist die Reaktionszeit beim Schalten von Aktoren die mit der CCU gepaired sind und über FHEM schalten möchte?

Es gib keine wahrnehmbare Verzögerung. Das Ausführen des Schaltbefehls erfolgt sofort per Homematic Script.

Zitat
*Wie würde die Pflege des Moduls aussehen, der Support von Martin für HM ist sensationell.

Ich habe das Modul entwickelt, da ich es selbst benötige. Alles was von der CCU nicht unterstützt wird, mache ich mit FHEM (und nur das). Da ich gerne eine FHEM basierte einheitliche Bedienoberfläche auf einem Tablet einsetzen möchte, brauchte ich eine Möglichkeit, von FHEM aus mit der CCU zu kommunizieren.

Fehler versuche ich zeitnah zu beheben, da sie vermutlich auch mich direkt betreffen. Ich kann hier aber keine Reaktionszeit garantieren, da ich einen relativ stressigen Job und einige zeitaufwändige Hobbies habe und die Entwicklung nur nebenher läuft.

Über funktionale Erweiterungen würde ich erst mal nachdenken, ob sie für alle Nutzer sinn machen und sie dann (bei vertretbarem Aufwand) umsetzen. Aber da das Ganze Open Source ist, steht es jedem frei, den Code an die eigenen Bedürfnisse anzupassen.
Titel: wie erfährt FHEM, wenn ein Homatic Taster gedrückt wird?
Beitrag von: mifh am 13 Dezember 2015, 20:52:37
Hallo,

HMCU ist ja genau, was ich gesucht hatte. Ich habe einen raspberry mit fhem laufen, über den ich ein paar Funktsteckdosen, Rolldaären usw ansteuere. Alles nur in Senderichtung: 433Mhz Sender oder FS20 UART Sender. Klappt soweit gut. Jetzt will ich auch ein paar Sensoren (Taster, Fensterkontake usw anschließen). Ich habe mir dazu gerade eine Homatic CCU2 zugelegt und geschaut, wie ich die an meinen PI mit fhem anschließen kann.

Das Anlernen eines Tasters HM-PB-2-WM55 an die CCU hat auch geklappt. Das Auslösen des Tasters soll an FHEM weitergereicht werden und dort halt Vorgänge auslösen. Dazu habe ich HMCCU auf dem PI installiert (btw: die Dokumentation liest sich gut!).

Ich kann auch problemlos eine Systemvariable von FHEM auf der CCU schalten.
Den in der CCU angelernten Taster sehe ich auch in FHEM, soweit so gut.

Aber wie kriege ich ein event mit, wenn der Taster ausgelöst wird?
Mit at abfragen, wird ja wohl nichts werden, der Zustandswechsel ist ja nicht dauerhaft.
Also RPC-Server? Den kriege ich nicht so recht ans Laufen. Wenn ich den anschalte, startet er brav und schreibt ein langweiliges Logfile ohne aufregende Einträge:
13.12.2015 19:49:39 Creating file queue
13.12.2015 19:49:39 Initializing RPC server
13.12.2015 19:49:40 callback server created
13.12.2015 19:49:40 Adding callback for events
13.12.2015 19:49:40 Adding callback for new devices
13.12.2015 19:49:40 Adding callback for deleted devices
13.12.2015 19:49:40 Adding callback for modified devices
13.12.2015 19:49:40 Registering callback
Außerdem scheint er FHEM lahmzulegen. Wenn der RPC-Server läuft, bringt ein
get d_ccu devicelist
den gesamten FHEM-Prozess ohne relevante Einträge im fhem.log ins Nirwana (web-Oberfläche ist tot, kein CPU-Verbrauch). Das File in /tmp enthält nur 1 Byte.

Meine Konfiguration:
define d_ccu HMCCU hm-ccu2
attr d_ccu ccureadings 1
attr d_ccu parfile /opt/fhem/scripts/hmvalues.txt
# hängt, wenn aktiviert
#attr d_ccu rpcinterval 3
#attr d_ccu rpcserver on
attr d_ccu statevals on:true,off:false
attr d_ccu stripchar :
attr d_ccu substitute false:closed,true:open
attr d_ccu verbose 5

define d_hm_dw_window HMCCUDEV T1 readonly
attr d_hm_dw_window IODev d_ccu
attr d_hm_dw_window alias T1
attr d_hm_dw_window ccureadings 1
attr d_hm_dw_window room test
attr d_hm_dw_window substitute false:closed,true:open
attr d_hm_dw_window verbose 5

Was mache ich falsch?

Ach ja, alle 10 Minuten beschwert fhem sich über die leere Parameterfile hmvalues.txt
2015.12.13 20:15:00 1: HMCCU: d_ccu Empty parameter file
2015.12.13 20:15:00 3: at_ccu: HMCCU: d_ccu Empty parameter file
2015.12.13 20:25:00 1: HMCCU: d_ccu Empty parameter file
2015.12.13 20:25:00 3: at_ccu: HMCCU: d_ccu Empty parameter file

Wozu dient diese Datei und wie fülle ich sie?

Noch eine kleine Beobachtung: ich mache gerne ein tail -f auf eine log-Datei. Mache ich das für ccurpcd.log, merkt fhem wohl, dass da jemand einen Finder auf der Datei hat und meckert:
2015.12.13 19:40:17 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 32656

Das Vorhandensein einer Daemon-Instanz über ein filehandle auf der Logdatei zu ermitteln, ist kreativ, aber eher unüblich. Da könnte ein Satz in der Doku helfen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: AHA1805 am 14 Dezember 2015, 13:45:59
Hallo zap,

Danke für die schnelle Antwort.

Gruß Hannes

Gesendet von meinem SM-T715 mit Tapatalk

Titel: Antw:wie erfährt FHEM, wenn ein Homatic Taster gedrückt wird?
Beitrag von: zap am 14 Dezember 2015, 15:26:44
Aber wie kriege ich ein event mit, wenn der Taster ausgelöst wird?

Habe leider keinen Taster, kann es daher nicht testen. RPC Server dürfte beim Schalten einen Event liefern. Die Frage ist, ob es einen Datenpunkt gibt, in dem die CCU den letzten Schaltvorgang speichert. Dann könnte man auch AT nutzen. Die Datenpunkte bekommst Du mit get d_ccu deviceinfo Device-Name/Device-Address

Zitat
Also RPC-Server? Den kriege ich nicht so recht ans Laufen. Wenn ich den anschalte, startet er brav und schreibt ein langweiliges Logfile ohne aufregende Einträge (...) Außerdem scheint er FHEM lahmzulegen. Wenn der RPC-Server läuft, bringt ein
get d_ccu devicelist
den gesamten FHEM-Prozess ohne relevante Einträge im fhem.log ins Nirwana (web-Oberfläche ist tot, kein CPU-Verbrauch). Das File in /tmp enthält nur 1 Byte.

Die Einträge in ccurpcd.log sollten so aussehen, wenn der RPC-Server erfolgreich gestartet wurde:

13.12.2015 19:42:49 Creating file queue
13.12.2015 19:42:49 Initializing RPC server
13.12.2015 19:42:49 callback server created
13.12.2015 19:42:49 Adding callback for events
13.12.2015 19:42:49 Adding callback for new devices
13.12.2015 19:42:49 Adding callback for deleted devices
13.12.2015 19:42:49 Adding callback for modified devices
13.12.2015 19:42:49 Registering callback
13.12.2015 19:45:50 RPC callback with URL http://192.168.1.12:7401/fh initialized
13.12.2015 19:45:50 Entering server loop. Use kill -SIGINT 18261 to terminate program
13.12.2015 19:45:50 ListDevices
13.12.2015 19:45:52 NewDevice: received 176 device specifications
13.12.2015 19:53:29 Received 250 events from CCU since last check

Bitte beachten: zwischen "Registering callback" und "RPC callback with ..." vergehen immer exakt 3 Minuten. Während dieser 3 Minuten sollte man die Finger von der CCU Oberfläche lassen und auch keinen HMCCU Befehl von FHEM aus absetzen. Das geht meistens in die Hose ;-). (die RPC Schnittstelle ist ein "zartes Pflänzchen", das sehr sensibel reagiert). Die letzte Meldung "Received 250 ..." kommt alle 250 events von der CCU um anzuzeigen, dass der RPC-Server noch lebt.

Probiere mal folgendes: Stoppe FHEM. Stoppe den RPC-Server, wenn er noch läuft mit kill -SIGINT Prozess-Id. Warte bis er nicht mehr läuft (kann einige Sekunden dauern). Starte nun FHEM mit rpcserver = off bzw. auskommentiertem Attribut. Starte nun den RPC-Server aus FHEM heraus mit attr d_ccu rpcserver on. Warte 3-4 Minuten. Deine Client-Devices sollten nun aktualisiert werden. Falls nicht, prüfe mal ccurpcd.log, ob alles wie oben gelistet aussieht.

Zitat
Ach ja, alle 10 Minuten beschwert fhem sich über die leere Parameterfile hmvalues.txt

Ich nehme an, Du hast einen AT definiert mit dem Befehl "get d_ccu parfile". Mit einer solchen Parameterdatei kannst Du Batch mäßig eine ganze Liste von Kanälen/Datenpunkten auf einmal abfragen. Der Aufbau der Datei ist im Readme beschrieben. Sieht im Prinzip so aus:

{Channel-Name|Channel-Address}[.Datapoint_Expression] [Substitute_Rule]

Also z.B.

# Hole alle Datenpunkte die TEMP enthalten
LEQ1234567:1.TEMP
# Hole alle Datenpunkte, die mit RSSI beginnen
LEQ1212121:0.^RSSI.*
# Hole den Datenpunkt STATE und ersetze die Werte
LEQ3234355:1.^STATE$ true:on,false:off
# Hole alle Datenpunkte
LEQ3434545:2
usw.

Zitat
Noch eine kleine Beobachtung: ich mache gerne ein tail -f auf eine log-Datei. Mache ich das für ccurpcd.log, merkt fhem wohl, dass da jemand einen Finder auf der Datei hat und meckert:
2015.12.13 19:40:17 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 32656

Das interpretierst Du falsch. So eine innovative Prozess-Erkennung per Filehandle würde ich mir zwar zutrauen, aber ganz so fies bin ich dann doch nicht ;-)

Die Fehlermeldung besagt nur, dass Du versucht hast, per attr rpcserver on den RPC-Server zu starten, obwohl noch ein Prozess aktiv ist, dessen PID HMCCU nicht kennt. Gründe dafür können sein, dass zwischenzeitlich FHEM abgeschmiert war und neu gestartet wurde, oder dass HMCCU neu geladen wurde, oder dass der RPC-Server manuell von Linux aus gestartet wurde. Kann auch sein, dass der RPC-Server nicht beendet wird, wenn man FHEM anhält. In diesem Fall sorry, muss ich mal testen.

Noch ein paar allgemeine Anmerkungen:

- get devicelist ist nur erforderlich, wenn das Modul HMCCU per reload neu geladen wird oder sich ein Gerät in der CCU geändert hat. Beim define eines HMCCU Device wird get devicelist automatisch ausgeführt. Die erfolgreiche Ausführung ist am Internal "devcount" im HMCCU Device zu erkennen (>0).

- Das Attribut substitute arbeitet im Zusammenhang mit dem RPC-Server leider nicht korrekt bzw. wird ignoriert. Fix dafür inklusive einer deutlichen funktionalen Erweiterung der Ersetzung von Werten heute oder morgen per Update.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 14 Dezember 2015, 21:11:09
Hallo Zap

Das war ja eine fixe Antwort, danke sehr. Das stellt die meisten Profisupporter doch in den Schatten :)

Die Idee mit dem Datenpunkt probiere ich mal aus. Wäre ja schon etwas unelegant, sich die Werte per AT herzupollen und dann auf Änderung zu vergleichen. Aber wenn es ginge...

Vielen Dank für den Hinweis mit dem parfile. Jetzt habe auch ich verstanden, wozu das da ist :)

Leider kriege ich den RPCserver immer noch nicht ans Laufen. Ich habe das so gemacht, wie von Dir beschrieben: FHEM stoppen, Neustart ohne RPC Server, RPC Server manuell starten, Finger weg von FHEM und CCU.
Ich habe das mal mitprotokolliert:

pi@pi3 /opt/fhem $ ps aux | grep perl
fhem      2454  1.2  5.3  25472 23748 ?        S    19:49   0:11 perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
pi        3039  0.0  0.4   4144  1868 pts/0    S+   20:04   0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ ps aux | grep perl
pi        3041  0.0  0.4   4144  1832 pts/0    S+   20:04   0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ /etc/init.d/fhem start
Starting fhem...
Can't open ./log/fhem-2015-12.log: Keine Berechtigung at fhem.pl line 2174.
pi@pi3 /opt/fhem $ !ps
ps aux | grep perl
pi        3048  0.0  0.4   4144  1888 pts/0    S+   20:05   0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ sudo /etc/init.d/fhem start
Starting fhem...
pi@pi3 /opt/fhem $ ps aux | grep perl         
fhem      3052  106  2.4  14520 10864 pts/0    R    20:05   0:03 perl fhem.pl fhem.cfg
pi        3054  0.0  0.3   4144  1772 pts/0    S+   20:05   0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ ps aux | grep perl
fhem      3052 39.1  5.2  27044 23160 pts/0    S    20:05   0:10 perl fhem.pl fhem.cfg
fhem      3059 87.0  3.8  20300 17020 pts/0    R    20:05   0:07 /usr/bin/perl ./FHEM/ccurpcd.pl hm-ccu2 2001 /tmp/ccuqueue ./log/ccurpcd.log
pi        3065  0.0  0.4   4144  1864 pts/0    S+   20:05   0:00 grep --color=auto perl
pi@pi3 /opt/fhem $ date
Mo 14. Dez 20:06:06 CET 2015
pi@pi3 /opt/fhem $ cd log
pi@pi3 /opt/fhem/log $ ls -l
insgesamt 1780
-rw-r--r-- 1 fhem dialout   2085 Dez 14 20:05 ccurpcd.log
-rw-r--r-- 1 fhem dialout   6508 Dez 14 20:04 eventTypes.txt
-rw-r--r-- 1 fhem dialout 183926 Okt 31  2014 fhem-2014-10.log
-rw-r--r-- 1 fhem dialout  68297 Nov 30  2014 fhem-2014-11.log
-rw-r--r-- 1 fhem dialout 464297 Dez 31  2014 fhem-2014-12.log
-rw-r--r-- 1 fhem dialout  46116 Jan 31  2015 fhem-2015-01.log
-rw-r--r-- 1 fhem dialout  28078 Feb 28  2015 fhem-2015-02.log
-rw-r--r-- 1 fhem dialout  78534 Mär 31  2015 fhem-2015-03.log
-rw-r--r-- 1 fhem dialout  69695 Apr 30  2015 fhem-2015-04.log
-rw-r--r-- 1 fhem dialout  28717 Mai 31  2015 fhem-2015-05.log
-rw-r--r-- 1 fhem dialout  50367 Jun 30 22:43 fhem-2015-06.log
-rw-r--r-- 1 fhem dialout  43131 Jul 31 22:43 fhem-2015-07.log
-rw-r--r-- 1 fhem dialout  58450 Aug 31 19:24 fhem-2015-08.log
-rw-r--r-- 1 fhem dialout  39423 Sep 30 22:55 fhem-2015-09.log
-rw-r--r-- 1 fhem dialout   5134 Okt 31 22:43 fhem-2015-10.log
-rw-r--r-- 1 fhem dialout  84598 Nov 30 22:43 fhem-2015-11.log
-rw-r--r-- 1 fhem dialout 462448 Dez 14 20:05 fhem-2015-12.log
-rw-r--r-- 1 fhem dialout   3550 Dez 14 20:04 fhem.save
-rw-r--r-- 1 fhem root       847 Sep  3 05:54 report_snd_jl2.log
pi@pi3 /opt/fhem/log $ cat ccurpcd.log
13.12.2015 16:25:35 Creating file queue
13.12.2015 16:25:35 Initializing RPC server
13.12.2015 16:25:36 callback server created
13.12.2015 16:25:36 Adding callback for events
13.12.2015 16:25:36 Adding callback for new devices
13.12.2015 16:25:36 Adding callback for deleted devices
13.12.2015 16:25:36 Adding callback for modified devices
13.12.2015 16:25:36 Registering callback
13.12.2015 19:41:56 Creating file queue
13.12.2015 19:41:56 Initializing RPC server
13.12.2015 19:41:58 callback server created
13.12.2015 19:41:58 Adding callback for events
13.12.2015 19:41:58 Adding callback for new devices
13.12.2015 19:41:58 Adding callback for deleted devices
13.12.2015 19:41:58 Adding callback for modified devices
13.12.2015 19:41:58 Registering callback
13.12.2015 19:49:39 Creating file queue
13.12.2015 19:49:39 Initializing RPC server
13.12.2015 19:49:40 callback server created
13.12.2015 19:49:40 Adding callback for events
13.12.2015 19:49:40 Adding callback for new devices
13.12.2015 19:49:40 Adding callback for deleted devices
13.12.2015 19:49:40 Adding callback for modified devices
13.12.2015 19:49:40 Registering callback
13.12.2015 20:08:07 Creating file queue
13.12.2015 20:08:07 Initializing RPC server
13.12.2015 20:08:08 callback server created
13.12.2015 20:08:08 Adding callback for events
13.12.2015 20:08:08 Adding callback for new devices
13.12.2015 20:08:08 Adding callback for deleted devices
13.12.2015 20:08:08 Adding callback for modified devices
13.12.2015 20:08:08 Registering callback
14.12.2015 19:32:43 Creating file queue
14.12.2015 19:32:43 Initializing RPC server
14.12.2015 19:32:43 Can't connect to CCU
14.12.2015 19:32:43 Error: Can't initialize RPC server
14.12.2015 20:05:43 Creating file queue
14.12.2015 20:05:43 Initializing RPC server
14.12.2015 20:05:45 callback server created
14.12.2015 20:05:45 Adding callback for events
14.12.2015 20:05:45 Adding callback for new devices
14.12.2015 20:05:45 Adding callback for deleted devices
14.12.2015 20:05:45 Adding callback for modified devices
14.12.2015 20:05:45 Registering callback


Wie Du siehst, kommt der nicht über das hinaus: Kein RPC callback with URL http://192.168.1.12:7401/fh initialized zu sehen.
14.12.2015 20:05:43 Creating file queue
14.12.2015 20:05:43 Initializing RPC server
14.12.2015 20:05:45 callback server created
14.12.2015 20:05:45 Adding callback for events
14.12.2015 20:05:45 Adding callback for new devices
14.12.2015 20:05:45 Adding callback for deleted devices
14.12.2015 20:05:45 Adding callback for modified devices
14.12.2015 20:05:45 Registering callback

Sieht ja so aus, als würde die CCU an dieer Stelle nicht antworten:
 $client->send_request ("init",$callbackurl,"CB1");



An der CCU sollte der RPC Dienst laufen. Kann man das irgendwo prüfen? In der Anleitung schlägst Du das vor:

http://hm-ccu2/config/xmlapi/devicelist.cgi?show_internal=1

Das beantwortet die CCU mit einem 404.

Hast Du irgend eine Idee dazu?


Gruß
Michael
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 Dezember 2015, 21:32:47
Ja, der RPC Server wird tatsächlich nicht richtig initialisiert. Muss ich mir mal anschauen ... wird aber heute nix mehr.

Könnte natürlich sein, dass der RPC Prozess auf der CCU abgeschmiert ist. Werde in der kommenden Version einen Check einbauen.

Die Test-URL hat nichts mit dem RPC Server zu tun. Das ist ein XML-API Aufruf zum Auflisten aller CCU Geräte. Damit das geht, muss das XML-API Addon auf der CCU installiert sein. Das und andere Software gibt es z.B. unter homematic-inside.de

BTW: Beim Runterfahren von fhem wird ein laufender RPC-Server tatsächlich nicht gestoppt. Fixe ich noch, hat aber nichts mit Deinem Problem zu tun.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 14 Dezember 2015, 21:35:14
Kleiner Nachtrag:
Ich habe eben mal die CCU auf Werkseinstellungen zurückgesetzt und jetzt scheitn sich was zu tun:
14.12.2015 20:48:20 Creating file queue
14.12.2015 20:48:20 Initializing RPC server
14.12.2015 20:48:22 callback server created
14.12.2015 20:48:22 Adding callback for events
14.12.2015 20:48:22 Adding callback for new devices
14.12.2015 20:48:22 Adding callback for deleted devices
14.12.2015 20:48:22 Adding callback for modified devices
14.12.2015 20:48:22 Registering callback http://192.168.1.25:7401/fh
14.12.2015 21:13:38 RPC callback with URL http://192.168.1.25:7401/fh initialized
14.12.2015 21:13:38 Entering server loop. Use kill -SIGINT 5167 to terminate program

Ich lerne mal den Taster wieder an und schaue weiter.

Gruß Michael
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 Dezember 2015, 22:10:48
Du kannst auf der CCU prüfen, ob der RPC Prozess läuft:

ps -ef | grep rfd

Außerdem sollte folgender Befehl die Prozess-ID des RPC Prozesses liefern:

fuser 2001/tcp

Wenn hier keine Zahl ausgegeben wird, läuft kein RPC Prozess. Dann einfach die CCU mal neu starten.

Wie man per SSH auf die CCU Command Line kommt, steht hier:

http://www.homematic-inside.de/tecbase/homematic/generell/item/zugriff-auf-das-dateisystem-der-ccu-2
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 Dezember 2015, 18:05:44
Ich habe gerade eine neue Version der Module sowie des RPC-Servers eingecheckt.

Bugfixes:


Erweiterungen:

Der RPC-Server prüft nun beim Starten, ob die RPC-Schnittstelle der CCU erreichbar ist. Falls nicht, wird der Start abgebrochen.

Attribut ccureadingfilter: Legt einen regulären Ausdruck für Datenpunkte fest. Nur wenn ein Datenpunkt zu diesem Ausdruck passt, wird er als Reading gespeichert. Dies reduziert die Anzahl der Readings deutlich.

Beispiel: attr my_dev ccureadingfilter (^STATE$|TEMPERATURE)

Attribut stripnumber: Legt fest, in welchem Format Fließkommazahlen als Reading gespeichert werden. 0=Wie von CCU geliefert, 1=Mit maximal einer Null nach dem Komma, 2=Ohne Null nach dem Komma.

Attribut substitute: Hier gibt es die größten Änderungen. Die bisherige Variante hatte den Nachteil, dass die Ersetzungsregeln immer auf alle gelesenen Datenpunkte angewendet wurden. Nun kann man für bestimmte Datenpunkte eigene Regeln angeben. Das Format ist:

subst_rule[;...]
substrule := [datapoint!]regexp1:substtext1[,...]

Beispiel: Für STATE alle logischen Werte durch on/off ersetzen, für LOWBAT alle durch yes/no ersetzen, für alle anderen durch open/closed ersetzen.

attr mydev substitute STATE!(0|false):off,(1|true):on;LOWBAT!(0|false):no,(1|true):yes;(0|false):closed,(1|true):open

Die Angabe von 0/1 neben true/false ist erforderlich, da die get Befehle für logische Werte true/false liefern während der RPC-Server 0/1 liefert.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 16 Dezember 2015, 21:11:05
Hallo Zap,

ich bin mal wieder am probieren.
Kannst Du Dir evtl. die Sache mit der Startprüfung des ccurpcd.pl noch mal anschauen?
Wenn ich ein tail-f auf dem logfile laufen lassen, kann ich den Prozess reproduzierbar nicht anstarten:
015.12.16 21:04:24 1: HMCCU: Stopping RPC server
2015.12.16 21:04:42 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 18647
2015.12.16 21:05:00 1: HMCCU: d_ccu Channel name or address invalid
2015.12.16 21:05:00 3: at_ccu: HMCCU: d_ccu Channel name or address invalid
2015.12.16 21:05:33 1: HMCCU: Externally launched RPC server detected. Kill process manually with command kill -SIGINT 18647
^C
pi@pi3 /opt/fhem/log $ ps aux | grep 18647
pi       18647  0.0  0.3   3936  1472 pts/2    S+   21:00   0:00 tail -f ccurpcd.log
pi       18906  0.0  0.4   4144  1856 pts/3    S+   21:06   0:00 grep --color=auto 18647
pi@pi3 /opt/fhem/log $

Die angemeckerte PID ist dabei kein ccurpcd.pl, sondern eben das tail -f.

Gruß
Michael
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 16 Dezember 2015, 21:43:15
Mist. An sowas habe ich nicht gedacht. Mein Fehler. Liegt an der Art und Weise, wie ich auf einen laufenden Prozess prüfe.
Wird korrigiert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 17 Dezember 2015, 14:28:40
Neue Versionen von 88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm und ccurpcd.pl eingecheckt.

Fixes:

Neue Funktionen:

Erweiterte Formatierung des Internals STATE analog zum Standardattribut 'stateFormat'. Leider unterstützt stateFormat keine Readings mit Doppelpunkt im Namen. Daher gibt es nun für HMCCUDEV und HMCCUCHN das Attribut 'ccustate'. Die Syntax ist identisch zu 'stateFormat', es können jedoch keine Perl-Ausdrücke angegeben werden. Zusätzlich zu 'ccustate' muss noch das Attribut 'stateFormat' auf "{HMCCU_State()}" gesetzt werden. Die Funktion HMCCU_State() wertet 'ccustate' aus und ersetzt Readings durch Werte. Außerdem wird geprüft, ob das Reading 'state' auf 'Error' steht. In diesem Fall wird STATE ebenfalls auf 'Error' gesetzt.

Beispiel:

attr my_dev ccustate T: KLIMA_WOHN:1.TEMPERATURE° H: KLIMA_WOHN:1.HUMIDITY%
attr my_dev stateFormat {HMCCU_State($name)}

Update: Da gerade an anderer Stelle die Diskussion hinsichtlich Sonderzeichen in Readingnames hochkocht, werde ich in der nächsten Version den Doppelpunkt in Readingnames durch ein anderes Zeichen ersetzen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 19 Dezember 2015, 17:22:14
Diese Kommunkation scheint ja ein ziemlich sensibles Kerlchen zu sein.

der ccurpcd schafft es bei mir immer noch nicht aus der Initialisierung raus. So sieht das Logfile aus:
19.12.2015 16:52:29 Creating file queue
19.12.2015 16:52:29 Initializing RPC server
19.12.2015 16:52:31 callback server created
19.12.2015 16:52:31 Adding callback for events
19.12.2015 16:52:31 Adding callback for new devices
19.12.2015 16:52:31 Adding callback for deleted devices
19.12.2015 16:52:31 Adding callback for modified devices
19.12.2015 16:52:31 Registering callback
Dabei bleibt es dann, bis ich den Prozess mit attr attr d_ccu rpcserver off beende.
Dann (und erst dann) fängt der rfd auf der CCU  in /var/log/messages an zu meckern:
ec 19 16:57:58 homematic-ccu2 user.err rfd: XmlRpc transport error calling system.listMethods({"CB1"}) on http://192.168.1.25:7401/fh:
Dec 19 16:57:58 homematic-ccu2 user.err rfd: XmlRpc transport error calling listDevices({"CB1"}) on http://192.168.1.25:7401/fh:
Da der Logeintrag "RPC callback with URL ..." nicht kommt, scheint der ccurpcd ja in dem $client->send_request ("init",$callbackurl,"CB1"); zu hängen.
Ach ja, die drei Minuten warte ich brav ab und das XML-API Addon habe ich auch installiert.

Bediene ich den Taster, ist die Fehlermeldung im message.log auf der CCU entsprechend länger (wieder erst nach dem Beenden!):
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB1","MEQ0399400:1","PRESS_SHORT",true}]}) on http://192.168.1.25:7401/fh:
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpc transport error
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB1","MEQ0399400:1","INSTALL_TEST",true}]}) on http://192.168.1.25:7401/fh:
Dec 19 17:17:33 homematic-ccu2 user.err rfd: XmlRpc transport error



Kleiner Nachtrag: Weil ich langsam das Problem im Umfeld Raspberry/Perl-Libs vermute, habe ich den ccurpcd mal auf meinem ubuntu-Rechner ausgeführt. Außer der xml-rpc lib braucht der Prozess ja nix. Das hat geklappt, nach 3 Minuten ging er in die Bearbeitungsschleife.
Ich habe dann mal auf dem Rapsberry ein apt-get remove librpc-xml-perl; apt-get automrevmoce; apt-get install librpc-xml-perl gemacht und den ccurpcd ebenfalls direkt gestartet. Hat leider nichts geholfen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 19 Dezember 2015, 22:20:49
Du hast jetzt aber auf dem Raspi nicht noch das Modul HMRPC aktiv, oder? Was liefert der Befehl

netstat -an | grep 7401

Der rfd auf der CCU erreicht den ccurpcd anscheinend nicht, obwohl zu diesem Zeitpunkt der Listener schon auf Port 7401 lauschen sollte und auch der Handler für listdevices regisitriert ist.

Seltsam, dass es auf Ubuntu läuft und auf dem Raspi nicht.

Der Server ist jedenfalls korrekt bei der CCU registriert, sonst würde die nicht versuchen, Events zu schicken. In einem vorherigen Post hatte das doch schon mal funktioniert. Hast Du was geändert?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 20 Dezember 2015, 12:12:21
Danke für den Tipp.

Ich habe keine Ahnung, warum es lt. logfile nach dem Neuaufsetzen der CCU zweimal geklappt hat und nun nicht.
Auf dem Port 7401 lauscht sonst niemand. Meiner Meinung nach müsste dann auch das Anlegen des callbackservers fehlschlagen.
Die CCU hängt durchaus am callbackserver, so interpretiere ich das zumindest (ich habe den ccurpcd.pl in c.pl umbenannt, Deine Prüfung, ob der Prozess schon läuft schlägt z.B. auch zu, wenn man den Prozess mit sudo startet  :D):
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl
pi       11017  0.0  0.4   4144  1884 pts/3    S+   11:34   0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ !netstat
netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log &
[1] 11023
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401                               
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl                                     
root     11023  0.0  0.5   5140  2620 pts/3    S    11:35   0:00 sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
root     11024 18.4  3.9  20684 17520 pts/3    S    11:35   0:08 perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
pi       11044  0.0  0.4   4144  1868 pts/3    S+   11:36   0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ cat ccurpcd.log
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl
pi       11017  0.0  0.4   4144  1884 pts/3    S+   11:34   0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ !netstat
netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log &
[1] 11023
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401                               
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ ps aux | grep perl                                     
root     11023  0.0  0.5   5140  2620 pts/3    S    11:35   0:00 sudo perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
root     11024 18.4  3.9  20684 17520 pts/3    S    11:35   0:08 perl c.pl hm-ccu2 2001 /tmp/ccuqueue ccurpcd.log
pi       11044  0.0  0.4   4144  1868 pts/3    S+   11:36   0:00 grep --color=auto perl
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp      262      0 192.168.1.25:7401       192.168.1.30:53035      VERBUNDEN 
pi@pi3 /opt/fhem/tmp/fhem-code/fhem/contrib/HMCCU $ cat ccurpcd.log
19.12.2015 18:12:54 Creating file queue
19.12.2015 18:12:54 Initializing RPC server
19.12.2015 18:12:54 callback server created
19.12.2015 18:12:54 Adding callback for events
19.12.2015 18:12:54 Adding callback for new devices
19.12.2015 18:12:54 Adding callback for deleted devices
19.12.2015 18:12:54 Adding callback for modified devices
19.12.2015 18:12:54 Registering callback
19.12.2015 18:16:56 Creating file queue
19.12.2015 18:16:56 Initializing RPC server
19.12.2015 18:16:56 callback server created
19.12.2015 18:16:56 Adding callback for events
19.12.2015 18:16:56 Adding callback for new devices
19.12.2015 18:16:56 Adding callback for deleted devices
19.12.2015 18:16:56 Adding callback for modified devices
19.12.2015 18:16:56 Registering callback
19.12.2015 18:19:57 RPC callback with URL http://192.168.1.24:7401/fh initialized
19.12.2015 18:19:57 Entering server loop. Use kill -SIGINT 20537 to terminate program
19.12.2015 18:19:57 ListDevices
19.12.2015 18:19:57 NewDevice: received 56 device specifications
19.12.2015 19:06:28 Shutdown RPC server
19.12.2015 19:06:28 RPC server terminated
19.12.2015 20:29:31 Creating file queue
19.12.2015 20:31:59 Error: ccurpcd.pl is already running (PID=7809)
19.12.2015 20:34:04 Error: ccurpcd.pl is already running (PID=7825)
19.12.2015 20:35:00 Error: ccurpcd.pl is already running (PID=7834)
19.12.2015 20:36:36 Creating file queue
19.12.2015 20:36:36 Initializing RPC server
19.12.2015 20:36:38 callback server created
19.12.2015 20:36:38 Adding callback for events
19.12.2015 20:36:38 Adding callback for new devices
19.12.2015 20:36:38 Adding callback for deleted devices
19.12.2015 20:36:38 Adding callback for modified devices
19.12.2015 20:36:38 Registering callback
19.12.2015 21:01:23 Creating file queue
19.12.2015 21:01:23 Initializing RPC server
19.12.2015 21:01:24 callback server created
19.12.2015 21:01:24 Adding callback for events
19.12.2015 21:01:24 Adding callback for new devices
19.12.2015 21:01:24 Adding callback for deleted devices
19.12.2015 21:01:24 Adding callback for modified devices
19.12.2015 21:01:24 Registering callback
19.12.2015 21:01:25 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
19.12.2015 21:13:14 Creating file queue
19.12.2015 21:13:14 Initializing RPC server
19.12.2015 21:13:15 callback server created
19.12.2015 21:13:15 Adding callback for events
19.12.2015 21:13:15 Adding callback for new devices
19.12.2015 21:13:15 Adding callback for deleted devices
19.12.2015 21:13:15 Adding callback for modified devices
19.12.2015 21:13:15 Registering callback
19.12.2015 21:13:15 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:17:23 Creating file queue
20.12.2015 11:17:23 Initializing RPC server
20.12.2015 11:17:25 callback server created
20.12.2015 11:17:25 Adding callback for events
20.12.2015 11:17:25 Adding callback for new devices
20.12.2015 11:17:25 Adding callback for deleted devices
20.12.2015 11:17:25 Adding callback for modified devices
20.12.2015 11:17:25 Registering callback
20.12.2015 11:17:25 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:17:25 RPC callback with URL http://192.168.1.25:7401/fh initialized
20.12.2015 11:17:25 Entering server loop. Use kill -SIGINT 10888 to terminate program
20.12.2015 11:19:01 Shutdown RPC server
20.12.2015 11:19:01 RPC server terminated
20.12.2015 11:19:38 Creating file queue
20.12.2015 11:19:38 Initializing RPC server
20.12.2015 11:19:40 callback server created
20.12.2015 11:19:40 Adding callback for events
20.12.2015 11:19:40 Adding callback for new devices
20.12.2015 11:19:40 Adding callback for deleted devices
20.12.2015 11:19:40 Adding callback for modified devices
20.12.2015 11:19:40 Registering callback
20.12.2015 11:19:40 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:35:43 Creating file queue
20.12.2015 11:35:43 Initializing RPC server
20.12.2015 11:35:44 callback server created
20.12.2015 11:35:44 Adding callback for events
20.12.2015 11:35:44 Adding callback for new devices
20.12.2015 11:35:44 Adding callback for deleted devices
20.12.2015 11:35:44 Adding callback for modified devices
20.12.2015 11:35:45 Registering callback
20.12.2015 11:35:45 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:19:38 Creating file queue
20.12.2015 11:19:38 Initializing RPC server
20.12.2015 11:19:40 callback server created
20.12.2015 11:19:40 Adding callback for events
20.12.2015 11:19:40 Adding callback for new devices
20.12.2015 11:19:40 Adding callback for deleted devices
20.12.2015 11:19:40 Adding callback for modified devices
20.12.2015 11:19:40 Registering callback
20.12.2015 11:19:40 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
20.12.2015 11:35:43 Creating file queue
20.12.2015 11:35:43 Initializing RPC server
20.12.2015 11:35:44 callback server created
20.12.2015 11:35:44 Adding callback for events
20.12.2015 11:35:44 Adding callback for new devices
20.12.2015 11:35:44 Adding callback for deleted devices
20.12.2015 11:35:44 Adding callback for modified devices
20.12.2015 11:35:45 Registering callback
20.12.2015 11:35:45 nach listmethods. Sende jetzt:inithttp://192.168.1.25:7401/fhCB1
192.168.1.25 ist der pi, .30 die CCU.
Du siehst in dem Log-Ausschnitt eine Stelle, wo er die Serverloop erreicht. Da habe ich das send_request("init",... auskommentiert. Dann ist der Server auch da und per brwoeser ansrepchbar (gibt ein 403). Aber natürlich liefert die CCU keine Daten an.
Für mich sieht das so aus:
- unter ubuntu hängt das Hochfahren ziemlich genau 3 Minuten in dem send_request("init" fest, dann geht es weiter, der Server lauscht auf dem Port und die CCU kann senden.
- auf dem pi kommt der Prozess nie aus send_request("init" zurück, daher kann die CCU auch nichts senden und hängt ihrerseits (timeouts scheint es da nicht zugeben oder die sind sehr lang). Wenn ich den ccurpcd dann töte, fällt die Verbindung zusammen und der rfd beschwert sich im Log file.

Ich denke, ich werde das noch mal auf einem anderen Raspberry ausprobieren. Vielleicht habe ich auf diesem hier irgendwas im Netzwerkbereich oder in der Perlinstallation kaputt gespielt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 20 Dezember 2015, 13:20:28
Wenn ich heute noch dazu komme, suche ich Dir mal die Versionen der relevanten Perl-Module raus, die ccurpcd.pl verwendet.

Update: Direkt von CPAN installiert. RPC::XML Version 0.79
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 20 Dezember 2015, 17:42:29
Das wäre toll, denn es ist wohl ein Konfigurationsproblem. Auf einem anderem Raspberry haut es hin.
Ich musste nur die rpc-xml Library installieren. An der hing allerdings noch ziemlich viel Kram dran.
Und so sieht es dann aus:
pi@pi2:/tmp$ tail -f *.log
20.12.2015 17:30:31 Creating file queue
20.12.2015 17:30:31 Initializing RPC server
20.12.2015 17:30:33 callback server created
20.12.2015 17:30:33 Adding callback for events
20.12.2015 17:30:33 Adding callback for new devices
20.12.2015 17:30:33 Adding callback for deleted devices
20.12.2015 17:30:33 Adding callback for modified devices
20.12.2015 17:30:33 Registering callback
20.12.2015 17:33:34 RPC callback with URL http://192.168.1.29:7401/fh initialized
20.12.2015 17:33:34 Entering server loop. Use kill -SIGINT 5147 to terminate program
20.12.2015 17:33:34 ListDevices
20.12.2015 17:33:35 NewDevice: received 56 device specifications

Weiter komme ich auf diesem Pi nicht, denn da läuft kein fhem drauf.
Mal sehen, wie ich die Perl-Installation auf dem anderen Pi wieder sauber kriege.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 20 Dezember 2015, 18:48:47
Im Zweifel erst mal versuchen, RPC::XML neu zu installieren. Aktuelle Version ist 0.79
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mifh am 20 Dezember 2015, 19:57:45
Interessant.
Auf den Rapsberrys bin ich bei Version 0.76, auf ubuntu bei 0.78.
Die Lib habe ich auch schon de-installiert und neu installiert. Ich habe in der Zwischenzeit sogar einen ganzen Haufen perl-libs mal auf Verdacht deinstalliert. Hat nix gebracht.
Naja, dann habe ich ja endlich den Grund, mal Jessie auszuprobieren. Die meisten meiner PIs sind noch auf Wheezy...

Und wenn alle Stricke reißen, über ein auslesen per at kriege ich das auf jeden Fall hin, das habe ich schon probiert. Aber das wäre irgendwie unsportlich und außerdem will ich in Zukunft noch mehr über die CCU laufen lassen.

Danke erst Mal, ich denke, in der nächsten Woche komme ich nicht so viel voran  ;)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Dezember 2015, 19:14:47
Ich habe gerade eine neue Version eingecheckt. In naher Zukunft lässt FHEM keine Reading Names mit Doppelpunkten mehr zu. Daher werden Readings von Homematic CCU Devices ab sofort in folgendem Format gespeichert (abhängig vom Attribut ccureadingformat):

ccureadingformat = 'name': Channel-Name.Datapoint

ccureadingformat = 'address': Interface.Device-Address.Channel-Number.Datapoint

Die Doppelpunkte sowohl im CCU Channel-Name als auch zwischen Device-Address und Channel-Number werden also durch Punkte ersetzt.

Grundsätzlich könnte man für alle Client Devices das Attribut ccureadingformat auf 'datapoint' setzen und damit das Dilemma mit den Doppelpunkten vermeiden. Aber leider gibt es CCU Geräte, die in verschiedenen Kanälen Datenpunkte mit gleichem Namen verwenden. Daher ist die zusätzliche Angabe des Kanals im Reading Name für eine eindeutige Unterscheidung erforderlich.

Ich habe außerdem eine Funktion zur Berechnung des Taupunktes eingebaut, die in Verbindung mit dem Attribut userReadings verwendet werden kann.

Beispiel: Ein Device speichert Temperatur und Luftfeuchte in den Readings WOHNEN_TH.1.TEMPERATURE und WOHNEN_TH.1.HUMIDITY. Dann wird mit folgendem Befehl der Taupunkt im Reading DEWPOINT gespeichert:

attr mydev userReadings DEWPOINT {HMCCU_Dewpoint($name,"WOHNEN_TH.1.TEMPERATURE", "WOHNEN_TH.1.HUMIDITY","n/a")}

Außerdem wurde die Prüfung auf einen bereits laufenden RPC Server Prozess nochmals optimiert und liefert nun hoffentlich eindeutige Ergebnisse.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Dezember 2015, 20:39:18
Hallo,

ich wollte nach der Anleitung das Modul nutzen aber bei mir scheitert es schon bei der Installation der Module.

Wenn ich
cpan install RPC::XML::Clientaufrufe, bekomme ich die folgende Fehlermeldung:
Could not get valid metadata. Error is: CPAN::Meta::Converter version 2.141170 required--this is only version 2.140640 at /root/.cpan/build/Module-Build-0.4214-jUVRMT/blib/lib/Module/Build/Base.pm line 4702.Ich habe jetzt stundenlang versucht, alle Module zu aktualisieren, aber irgendwie scheint nichts zu funktionieren.
Kann mir hier bitte jemand weiterhelfen? Ich verzweifle noch.
Vielen Dank!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Dezember 2015, 20:46:46
CPAN selbst scheint zu alt zu sein. Das solltest Du zunächst aktualisieren.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Dezember 2015, 20:49:33
Da muss ich dummerweise mal fragen wie ich es aktualisiere.^^
Ich stehe gerade etwas auf dem Schlauch und google konnte mir da auch nicht helfen.

Danke. :)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Dezember 2015, 20:56:23
Versuch mal

cpan CPAN::Meta

oder

cpan CPAN::Meta::Converter
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Dezember 2015, 21:00:49
Habe ich ausgeführt.
Wenn ich dann aber wieder versuche RPC::XML::Client zu installieren, bekomme ich wieder die gleiche Fehlermeldung. wie oben beschrieben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Dezember 2015, 21:06:59
Was ist mit cpan install RPC::XML
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Dezember 2015, 21:10:40
Hatte ich auch schon probiert.
Aber hatte nichts gebracht. Ich sitze jetzt schon seit 14 Uhr daran. Habe auch ein komplett neues System aufgesetzt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Dezember 2015, 21:13:54
Kannst Du irgendein anderes Perl Modul installieren?

Probier mal File::Queue. Wird zwar momentan nicht von HMCCU verwendet, da es ein Bug hat, aber schadet auch nicht.

Keine Ahnung, woher der Fehler kommt. Ich konnte auf meinem Raspberry das problemlos installieren. Vielleicht kann einer der anderen HMCCU Tester mal schreiben, wie er RPC::XML installiert hat.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Dezember 2015, 21:19:12
Okay, ich hatte gerade nochmal parallel das Modul Module::Build installiert und bekomme auch die gleiche Fehlermeldung. Da scheint irgendwas mit meinem CPAN nicht in Ordnung zu sein... oder?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Dezember 2015, 21:28:57
Scheint so. Wenn Du unbedingt die RPC-Module haben willst kannst Du Dir natürlich die .pm Dateien vom CPAN Archiv direkt runterladen und in die Perl Lib Verzeichnisse installieren. Das ist aber übles Gefrickel und Du musst wissen was Du tust. Empfehlen kann ich das nicht wirklich. Bei RPC XML funktioniert das, da es sich um reinen Perl Code handelt.

Womit wir wieder bei der Frage wären, wie man CPAN neu installiert. Google schweigt sich hier aus. CPAN ist ja eigentlich nur ein Perl-Modul.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Dezember 2015, 21:39:28
Hm.. ich brauche es ja um das DEVICE anlegen zu können.
Wenn ich das Modul weglasse, bekomme ich ja bei Ausführung von

define CCU2 HMCCU homematic-ccu2
die folgende Fehlermeldung in der FHEM-Log

2015.12.22 21:08:26 1: reload: Error:Modul 88_HMCCU deactivated:
 Can't locate RPC/XML/Client.pm in @INC (you may need to install the RPC::XML::Client module) (@INC contains: /etc/perl /usr/local/lib/arm-linux-gnueabihf/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/lib/arm-linux-gnueabihf/perl5/5.20 /usr/share/perl5 /usr/lib/arm-linux-gnueabihf/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl . /opt/fhem/FHEM) at /opt/fhem/FHEM/88_HMCCU.pm line 55.
BEGIN failed--compilation aborted at /opt/fhem/FHEM/88_HMCCU.pm line 55.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 09:26:13
Das Modul kann nicht weggelassen werden.

Was extrem merkwürdig ist: es wird ja angemeckert, dass CPAN::Meta::Converter veraltet ist. Auf der offiziellen CPAN Seite

http://search.cpan.org/~dagolden/CPAN-Meta-2.140640/lib/CPAN/Meta/Converter.pm

wird aber genau die Version angeboten, die Du installiert hast. Allerdings gibt es hier

http://search.cpan.org/~dagolden/CPAN-Meta-2.141170/

die verlangte Version. Du könntest Dir also von dem letzten Link die Version runterladen und die vorhandenen Module damit überschreiben (mach vorher eine Kopie).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 10:12:57
Hey, ich hatte jetzt in der Zwischenzeit noch Make und einen C Compiler installiert.

apt-get install make

apt-get install gcc

apt-get install python-dev

apt-get install expat

cpan install HTTP::Daemon

Und endlich lässt es sich installieren und läuft. :)

Vielen Dank für deine Hilfe. :D
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 10:44:05
Make ist natürlich zwingend erforderlich. Da wäre ich anhand der Fehlermeldung aber nie drauf gekommen  ;)

Bevor Du irgendwelche HMCCU Devices definierst, zieh Dir die neue Version der Module von gestern Abend. Ich musste die Reading-Namen ändern, da FHEM zukünftig für Identifier keine Doppelpunkte mehr zulassen wird.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 10:50:08
Ja, ich bin auch nur durch Zufall darauf gekommen als er bei einer anderen Abhängigkeit wegen "Make" gemeckert hatte. ;)

Ich konnte jetzt die HMCCU anlegen und er zeigt mir auch als Status "Ok" an. Aber get devicelist bringt mir keine Ergebnisse. Habe gerade die CCU neu gestartet. Allerdings hängt dort so viel dran dass das mittlerweile ca. 20 Minuten dauert bis die wieder hochgefahren ist.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 11:47:13
So, CCU ist neu gestartet und der RPC-Serve läuft auch. Aber get devicelist bringt mir immer noch keine Ergebnisse.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 12:16:58
Das sieht doch gut aus. DevCount = 290 ist das Ergebnis von "get devicelist". Der Befehl produziert keine Ausgabe. Du kannst aber mal versuchen, noch ein "dump" anzuhängen, also get xxx devicelist dump. Falls ich das nicht wieder ausgebaut habe, sollte dann eine Liste aller Devices und Channels im FHEM Fenster angezeigt werden.

Bei einem define mit HMCCU wird get devicelist automatisch ausgeführt.

Ansonsten kannst Du los legen und mal per HMCCUDEV ein CCU Geräte oder per HMCCUCHN einen CCU Kanal definieren. Die Datenpunkte sollten dann automatisch vom ccurpcd aktualisiert werden.

Autocreate gibt's (noch) nicht.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 23 Dezember 2015, 12:30:34
Für autocreate einfach ein return "UNDEFINED NeuerDeviceName ModulName Def" zurückgeben ;).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 12:47:13
Für autocreate einfach ein return "UNDEFINED NeuerDeviceName ModulName Def" zurückgeben ;).

Von wo zurückgeben?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 23 Dezember 2015, 12:54:16
An fhem - aus Deinem Modul (bzw. dem RPCd), was mit mit dem noch nicht definierten Gerät noch nichts anfangen kann.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 13:13:01
Hmm, der spärlichen "Doku" entnehme ich, dass das was mit einer Parse Funktion zu zu hat, die unter bestimmten Bedingungen aufgerufen wird. Und die gibt das diesen String zurück.

Von neuen Devices erfährt HMCCU aus einer zeitgesteuerten Funktion, die die Event-Queue auswertet. Da bringt das Zurückgeben dieses Strings nichts. Außerdem gibt es noch 2 Probleme zu lösen:

1. Die RPC Schnittstelle schickt beim NewDevice Event nur die Adresse des Gerätes mit. Leider hat die CCU keinen API Call eingebaut, mit dem ich von der Adresse zum Namen des Gerätes komme. Da bleibt nur das erneute Einlesen aller Geräte. Daher ignoriert HMCCU derzeit die NewDevice Events.

2. Ich habe Bedenken, per autocreate für jedes CCU Device (und vielleicht noch für jeden Kanal?) ein FHEM Device anlegen zu lassen. Das wird schnell unübersichtlich (habe fast 300 Kanäle)  und wahrscheinlich benötigt auch nicht jeder alle CCU Devices in FHEM
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 14:29:17
Hey, also das mit der Ausgabe hat funktioniert.

Ich habe jetzt auch mein erstes Device angelegt (Homematic Thermostat). Aber wie bekomme ich z.B. die Temperatur-Daten in die Readings?

Viele Grüße

Thomas.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 15:59:09
Okay, es hat etwas gedauert aber die Readings sind jetzt mittlerweile gefüllt. :)
Aber die Daten sind schon über eine Stunde alt. Es aktualisert sich in FHEM nichts wenn ich am Thermostat die Temperatur ändere.
Wie werden die Events getriggert?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 18:47:06
Die CCU schickt die Events an den ccurpcd.pl Prozess. Der schreibt die Events in eine File Queue, standardmäßig /tmp/ccuqueue.dat (und .idx). In HMCCU sorgt dann eine Timer gesteuerte Funktion dafür (alle 3-10 Sekunden, einstellbar), dass die Events aus der File Queue gelesen und an die Client devices in Form von Readings verteilt werden. Zumindest einmal scheint dieser Prozess bei Dir ja funktioniert zu haben. Bei mir vergehen zwischen Aktion in CCU und Reaktion in FHEM nur wenige Sekunden.

Du kannst prüfen, ob Der ccurpcd Events empfängt, indem Du Dir den Zeitstempel der Datei /tmp/ccuqueue.dat anschaust. Der sollte bei Deiner Anzahl an CCU Kanälen nicht älter als 1 Minute sein, denn irgendwas schickt die CCU immer, gerade wenn man Wandthermostate im Einsatz hat. Wenn die Größe der Datei ccuqueue.dat >0 ist, stehen Events drin, die man sich auch z.B. per "tail ccuqueue.dat" anschauen kann. Der RPC Server empfängt immer Events für alle Geräte der CCU, auch wenn für diese kein Device in FHEM existiert.

Falls gar nichts funktioniert wären die letzten Zeilen der Datei /opt/fhem/log/ccurpcd.log interessant. Außerdem eventuelle Meldungen von HMCCU im fhem Log (z.B. dass seit einiger Zeit keine Events von der CCU kamen).

Noch was: nach dem Starten des RPC Servers vergehen exakt 3 Minuten, bevor die ersten Events von der CCU eintreffen. Warum dass so ist, kann vermutlich nur EQ3 beantworten.


Bei mir läuft der RPC Server seit ca. 3 Wochen stabil ohne Performance Probleme.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 18:55:49
Hey Zap,

schon mal vielen Dank für deinen wirklich guten Support.
Ich habe mir die Datei angesehen und sie ist leer (0KB Größe) aber der Zeitstempel aktualisiert sich ca. alle 5 Sekunden. Scheint also kein Zugriffsproblem zu sein.

In der Log steht folgendes:

23.12.2015 17:45:21 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 17:45:21 Entering server loop. Use kill -SIGINT 1403 to terminate program
23.12.2015 17:45:21 ListDevices
23.12.2015 17:45:23 NewDevice: received 140 device specifications
23.12.2015 17:53:36 Received 250 events from CCU since last check
23.12.2015 18:38:49 Creating file queue
23.12.2015 18:38:49 Initializing RPC server
23.12.2015 18:38:50 callback server created
23.12.2015 18:38:50 Adding callback for events
23.12.2015 18:38:50 Adding callback for new devices
23.12.2015 18:38:50 Adding callback for deleted devices
23.12.2015 18:38:50 Adding callback for modified devices
23.12.2015 18:38:50 Registering callback
23.12.2015 18:41:50 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 18:41:50 Entering server loop. Use kill -SIGINT 1403 to terminate program
23.12.2015 18:41:50 ListDevices
23.12.2015 18:41:52 NewDevice: received 140 device specifications
23.12.2015 18:50:59 Received 250 events from CCU since last check

Ich kann in der Log aber nichts Auffälliges feststellen.
Ich hatte FHEM jetzt zwischendrin ein paar Mal neu gestartet.

Wenn ich
get HM_KU_Thermostat channel 4manuell in FHEM aufrufe, bekomme ich auch die korrekten Daten die ich vorher über die CCU-Weboberfläche gesetzt habe.
Das Problem liegt also irgendwie in der automatischen Übertragung bzw. Aktualisierung.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Dezember 2015, 21:50:20
Wenn sich der Zeitstempel aktualisiert, dürfte alles in Ordnung sein. HMCCU liest ja alle paar Sekunden Events aus der Datei und leert sie dadurch. Auch der Eintrag "received 250 events since last check" im Log passt. Der ccurpcd schreibt immer nach 250 events diese Meldung ins Log. Werden gar keine Readings aktualisiert?

Was mir in dem Logauszug auffällt: es fehlt zwischendrin eine "RPC server terminated" Meldung (nach 17:53). Wenn der ccurpcd korrekt beendet wird, muss er eine entsprechende Meldung ins Log schreiben, also per "attr rpcserver off" oder beim Stoppen von Fhem. Hast Du den Prozess mal anderweitig abgeschossen? Das sollte man nicht zu oft machen, da in diesem Fall der RPC Server nicht korrekt von der CCU abgemeldet wird.

Hast Du ein Wandthermostat? Definiere das mal als HMCCUDEV Device oder einen Tür/Fenster Sensor. Die schicken bei mir sofort Feeback, wenn ich ein Fenster öffne. Auch Temperatur und Feuchte werden alle paar Minuten aktualisiert.

Hast Du bei Deinen Devices irgendwelche Attribute gesetzt? ccureadings darf nicht gesetzt sein oder muss 1 sein.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 Dezember 2015, 22:08:21
Hey,
ja ich hatte immer den Pi neu gestartet anstatt die Prozesse zu killen.

Jetzt habe ich mal den RPC Server über das Attribute off gesetzt, FHEM neu gestartet und dann den RPC Server wieder per Attribute aktiviert.

23.12.2015 21:25:55 Received 250 events from CCU since last check
23.12.2015 21:52:36 Shutdown RPC server
23.12.2015 21:53:31 Creating file queue
23.12.2015 21:53:31 Initializing RPC server
23.12.2015 21:53:31 callback server created
23.12.2015 21:53:31 Adding callback for events
23.12.2015 21:53:31 Adding callback for new devices
23.12.2015 21:53:31 Adding callback for deleted devices
23.12.2015 21:53:31 Adding callback for modified devices
23.12.2015 21:53:31 Registering callback
23.12.2015 21:56:31 RPC callback with URL http://192.168.178.58:7401/fh initialized
23.12.2015 21:56:31 Entering server loop. Use kill -SIGINT 1398 to terminate program
23.12.2015 21:56:31 ListDevices
23.12.2015 21:56:33 NewDevice: received 140 device specifications
23.12.2015 22:02:47 Shutdown RPC server
23.12.2015 22:02:47 RPC server terminated
23.12.2015 22:04:08 Creating file queue
23.12.2015 22:04:08 Initializing RPC server
23.12.2015 22:04:08 callback server created
23.12.2015 22:04:08 Adding callback for events
23.12.2015 22:04:08 Adding callback for new devices
23.12.2015 22:04:08 Adding callback for deleted devices
23.12.2015 22:04:08 Adding callback for modified devices
23.12.2015 22:04:08 Registering callback

Ein Wandthermostat habe ich leider nicht.

Aber auch der Fenstersensor aktualisiert sich nich von alleine.
Ich habe die Daten auch manuell abfragen müssen.
Und nachdem ich dann das Fenster geöffnet habe (ca. 2 min auf gelassen) und dann wieder geschlossen, kam auch keine Aktualisierung in der Zwischenzeit.


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 Dezember 2015, 08:40:28
Ich lade die Tage mal eine Version mit erweiterter Logging Funktion hoch, damit wir das Problem eingrenzen können. In der Zwischenzeit könntest Du bitte mal die Definition der Devices mit Attributen posten oder mir per Forum Mail schicken?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 Dezember 2015, 10:09:18
Hallo Zap,

die Definition der Devices sieht so aus

#HMCCU
define CCU2 HMCCU homematic-ccu2
attr CCU2 ccureadingfilter .*
attr CCU2 rpcserver on

#Küche - Thermostat
define HM_KU_Thermostat HMCCUDEV LEQ1076554 4
attr HM_KU_Thermostat IODev CCU2
attr HM_KU_Thermostat statechannel 4

#Küche - Fenster
define HM_KU_Fenster HMCCUDEV MEQ0752141 1
attr HM_KU_Fenster IODev CCU2
attr HM_KU_Fenster statechannel 1

Viele Grüße und frohe Weihnachten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 Dezember 2015, 11:25:10
Ich habe jetzt auch nochmal einen Schalter eingebunden aber auch von dem bekomme ich keine automatischen Events in FHEM.
Die Einrichtung mache ich gerade bei meinen Eltern. Leider bin ich nur über Weihnachten hier und muss danach wieder fahren.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 Dezember 2015, 19:31:52
Weihnachtsupdate von 88_HMCCU.pm eingecheckt. Bitte unbedingt die neue Version aus Sourceforge installieren! Behebt einen Bug beim Update von Client Devices, der unter bestimmten Konstellationen auftreten kann.

In HMCCU Device das Loglevel auf 1 setzen. Bei Loglevel = 2 werden alle Events vom RPC Server protokollert (nur für Fehlersuche geeignet, produziert je nach Anzahl der CCU Devices viele Logeinträge).

Vergesst das mit dem Logging, muss erst die Module auf Verbose / Log3 umstellen, bevor ich das wieder aktiviere.

@Tom_Tom: Deine Konfig passt soweit. Attribut ccureadingfilter ist per default .*, kann also auch weggelassen werden. Ich würde das Attribut immer nur bei Client-Devices setzen, da sich die sinnvollen Readings je nach Gerätetyp unterscheiden.

Einige Beispiele für den Einsatz der Module:

Definition eines Heizungsthermostaten (Einstellung der Zieltemperatur mit set devstate):

define HM_KL_AZ_HZ HMCCUDEV KL-AZ-HZ
attr HM_KL_AZ_HZ IODev d_ccu
attr HM_KL_AZ_HZ ccureadingfilter (LOWBAT|TEMPERATURE)
attr HM_KL_AZ_HZ ccustate T: KL-AZ-HZ.4.ACTUAL_TEMPERATURE° D: KL-AZ-HZ.4.SET_TEMPERATURE°
attr HM_KL_AZ_HZ stateFormat {HMCCU_State($name)}
attr HM_KL_AZ_HZ statechannel 4
attr HM_KL_AZ_HZ statedatapoint SET_TEMPERATURE
attr HM_KL_AZ_HZ stripnumber 1

Definition eines Wandthermostaten (Ohne Einstellmöglichkeit der Zieltemperatur, nur Auswertung Temperatur und Luftfeuchte):

define HM_KL_AZ_TH HMCCUDEV KL-AZ-TH
attr HM_KL_AZ_TH IODev d_ccu
attr HM_KL_AZ_TH ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SET_TEMPERATURE|^LOWBAT$)
attr HM_KL_AZ_TH ccustate T: KL-AZ-TH.1.TEMPERATURE° H: KL-AZ-TH.1.HUMIDITY% D: KL-AZ-TH.2.SET_TEMPERATT
URE° P: DEWPOINT°
attr HM_KL_AZ_TH devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_KL_AZ_TH stateFormat {HMCCU_State($name)}
attr HM_KL_AZ_TH statechannel 2
attr HM_KL_AZ_TH statedatapoint TEMPERATURE
attr HM_KL_AZ_TH stripnumber 1
attr HM_KL_AZ_TH substitute LOWBAT!(0|false):no,(1|true):yes
attr HM_KL_AZ_TH userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}

Definition eines Readonly Fenstersensors:

define HM_TF_SZ_Fenster1 HMCCUCHN TF-SZ-Fenster1:1 readonly
attr HM_TF_SZ_Fenster1 IODev d_ccu
attr HM_TF_SZ_Fenster1 devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr HM_TF_SZ_Fenster1 substitute STATE!(0|false):closed,(1|true):open;;LOWBAT!(0|false):no,(1|true):yes

Definition einer Schaltsteckdose (ein/ausschalten mit set devstate on/off):

define HM_ST_WZ_Bass HMCCUDEV ST-WZ-Bass
attr HM_ST_WZ_Bass IODev d_ccu
attr HM_ST_WZ_Bass ccureadingfilter (STATE|LOWBAT|ON_TIME)
attr HM_ST_WZ_Bass ccureadings 1
attr HM_ST_WZ_Bass devStateIcon on:10px-kreis-gruen off:10px-kreis-rot Initialized:10px-kreis-gelb
attr HM_ST_WZ_Bass statechannel 1
attr HM_ST_WZ_Bass statevals on:true,off:false
attr HM_ST_WZ_Bass substitute STATE!true:on,false:off,1:on,0:off;;LOWBAT!true:yes,false:no
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 Dezember 2015, 20:45:59
Hey, ich habe das Weihnachtsupdate installiert, aber leider auch ohne Erfolg.
Habe das System neu gestartet, den RPC Server per attribute gestartet (hat auch eine Prozess-ID und läuft).
Anschließend ca. 5 Minuten gewartet, aber keine Daten kamen.
Dann habe ich get devicelist ausgeführt, einige Minuten gewartet, aber nichts passiert.
Dann im angelegten Device (Thermostat) get channel 4 ausgeführt und die korrekten Readings bekommen.
Ich habe dann am Thermostat die Temperatur verstellt. Diese wird mir auch in der Homematic-Oberfläche korrekt angezeigt. Jedoch leider immer noch nicht in FHEM.

FHEM - Log-Eintrag aktualisiert sich permanent. Aber die Änderungen die ich mache (egal ob am Thermostat oder in der HM-Web-Oberfläche) werden nicht empfangen.

2015.12.25 20:33:28 1: HMCCU: RPC server started with pid 1861
2015.12.25 20:35:19 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:24 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:29 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:34 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:39 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:44 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:49 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:54 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:35:59 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:04 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:09 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:14 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:36:32 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.CONTROL_MODE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.FAULT_REPORTING
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.BATTERY_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.VALVE_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.BOOST_STATE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.ACTUAL_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.SET_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_TEMPERATURE
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_TIME
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_DAY
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_MONTH
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_START_YEAR
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_TIME
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_DAY
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_MONTH
2015.12.25 20:38:01 1: HMCCU: Readingname = HM-CC-RT-DN LEQ1076554.4.PARTY_STOP_YEAR
2015.12.25 20:54:17 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:22 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:27 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:32 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:37 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:42 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:47 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:52 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:54:57 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:02 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:07 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:12 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:18 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:23 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:28 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:33 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:38 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:43 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:48 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:53 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:55:58 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:03 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:08 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:13 1: HMCCU: Received no events from CCU since 180 seconds
2015.12.25 20:56:18 1: HMCCU: Received no events from CCU since 180 seconds

Sorry dass ich dir keine positive Nachricht hinterlassen kann.

Viele Grüße, Thomas.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 Dezember 2015, 21:11:14
Hey, ich habe jetzt mal statt des DNS Namens der CCU die IP-Adresse eingetragen und schon geht es. :)
Darauf wäre ich vorher nie gekommen, da er ja die ganze Zeit als Status "Ok" angezeigt hatte.

Viele Grüße und noch schöne Weihnachten :)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 25 Dezember 2015, 22:19:50
Guten Abend zusammen, ich habe jetzt meine "Entwicklungs-/Bastelumgebung" soweit aufgebaut.
Wenn ich via FHEm meinen Aktor in der CCU schalte, schaltet der zwar noch, FHEM stürzt aber ab.
Das Log verweist auf:

http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/88_HMCCUDEV.pm#l236

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


Meine Config:

Zitat
define CCU HMCCU 192.168.20.XXX
attr CCU ccureadings 1
attr CCU rpcserver on

define ccu.AZ.Aktor.Tuer.1 HMCCUDEV XXXXXXXXX 1
attr ccu.AZ.Aktor.Tuer.1 IODev CCU
attr ccu.AZ.Aktor.Tuer.1 statechannel 1
attr ccu.AZ.Aktor.Tuer.1 statevals on:true,off:false
attr ccu.AZ.Aktor.Tuer.1 substitute true:on,false:off,1:on,0:off



Kann mir jemand weiter helfen?

BTW: Ich kann Systemvariablen via FHEM setzen, also die Richtung funktioniert einwandfrei, so wie ich das verstehe, wartet FHEM vergeblich auf eine Bestätigung, dass die Aktion durchgeführt wurde und gibt dann enttäuscht auf?







EDIT #1:

Nach frischer Energie bin ich auf den Trichter gekommen, dass die Funktion usleep() in Time::HiRes steckt; das werde ich noch mal drüber bügeln und berichten.
-> Bringt nix!

EDIT #2:

Edit: Bringt doch was, wenn man es dann in der 88_HMCCUDEV.pm noch "used"
->
Zitat
use Time::HiRes qw( sleep);
noch in den Header und jetzt lüppt et. 8)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 13:56:23
Nach meiner kleinen Odyssee im Post darüber habe ich jetzt noch folgende Fragen:

#1 Ich habe vor alle Homematic-Komponenten an der CCU anzumelden und Änderungen an FHEM "gepusht" zu bekommen -> Das funktioniert im Moment so "lala" für mich zeitlich willkürlich.
-> Ich habe es soweit verstanden, dass der RCP-Server quasi die Events gepusht bekommt, diese in die Queue steckt und FHEM sich alle X Zeiteinheiten dort das neuste rausbekommt.

Kann ich jetzt dieses X möglichst klein bestimmen? Ich hätte z.B. einige zeitkritische Sachen die ich gerne direkt in FHEM hätte. Z.B. sobald bei Abwesenheit die Tür auf geht möchte ich bei Dunkelheit Licht einschalten. Diese Logik möchte ich aber (gerne) in FHEM implementieren.(Ich finde das geklicke nicht so schön und es sollen noch IT-Devices mit an gehen).


#2 Das RCPServer Attribut der CCU steht immer wieder auf off, müsste das nicht on sein?
-> Selbst wenn ich es manuell auf on setze ist es einige Minuten später wieder off?!

#3 Eine Mischung aus #1-> Wieso ist der "state" in FHEM nachdem ich ihn via FHEM gesetzt habe bei einem Schaltaktor z.B. "OK" und nich "On" oder "Off"? das müsste mit einem get doch machbar sein oder? Bzw. ist wahrscheinlich schon so eingebaut aber funktioniert bei mir nicht?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 16:01:56
Edit: Bringt doch was, wenn man es dann in der 88_HMCCUDEV.pm noch "used"
-> noch in den Header und jetzt lüppt et. 8)

Keine Ahnung, warum bei mir usleep ohne use Timer::Hires funktioniert. Aber danke für den Hinweis. Baue es ein und checke die neuen Versionen von 88_HMCCUCHN und 88_HMCCUDEV heute noch ein.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 16:18:07
#1 Ich habe vor alle Homematic-Komponenten an der CCU anzumelden und Änderungen an FHEM "gepusht" zu bekommen -> Das funktioniert im Moment so "lala" für mich zeitlich willkürlich.
-> Ich habe es soweit verstanden, dass der RCP-Server quasi die Events gepusht bekommt, diese in die Queue steckt und FHEM sich alle X Zeiteinheiten dort das neuste rausbekommt.

Ja, so funktioniert das. Das X kannst Du per Attribut rpcinterval setzen. Im FHEM GUI lässt das Werte von 3, 5 und 10 Sekunden zu. Default ist 5. Wenn Du das Kommando attr ... direkt eintippst, kannst Du auch andere Werte einsetzen. Wird m.W. nicht geprüft. Bitte beachten: In den ersten drei Minuten nach Starten des RPC Servers kommen keine Events!

Zitat
#2 Das RCPServer Attribut der CCU steht immer wieder auf off, müsste das nicht on sein?
-> Selbst wenn ich es manuell auf on setze ist es einige Minuten später wieder off?!

Da stimmt was nicht. HMCCU prüft alle X Sekunden (siehe oben #1), ob der RPC-Server noch läuft. Wenn nicht setzt er das Attribut auf "off". Außerdem wird das Internal RPCPID in HMCCU auf 0 gesetzt und RPCPRC auf "none". Scheint so, als würde der RPC Server abschmieren. Schau Dir bitte mal die ccurpcd.log und das fhem log an (grep HMCCU). Läuft der RPC Server noch (ps -ef | grep ccurpcd)

Zitat
#3 Eine Mischung aus #1-> Wieso ist der "state" in FHEM nachdem ich ihn via FHEM gesetzt habe bei einem Schaltaktor z.B. "OK" und nich "On" oder "Off"? das müsste mit einem get doch machbar sein oder? Bzw. ist wahrscheinlich schon so eingebaut aber funktioniert bei mir nicht?

Im HMCCU oder in einem HMCCUDEV/HMCCUCHN Device? In HMCCU ist das so. Dafür ist das IO Device auch nicht gedacht. Da bekommt state immer den Status (also OK/Error) des letzten Befehls. In einem HMCCUCHN oder HMCCUDEV Device sollte state allerdings tatsächlich den Status des Gerätes annehmen. Dazu solltest Du zunächst mit "attr statechannel" den Kanal definieren, der den Status liefert bzw. den Status setzt. Wenn der zugehörige Datenpunkt nicht "STATE" heißt, kannst Du den mit dem Attribut "statedatapoint" bestimmen. Hier nochmal zwei Beispiele:

Zunächst eine einfache Schaltsteckdose (nur die State relevanten Attribute):

define HM_ST_WZ_Bass HMCCUDEV ST-WZ-Bass
# Der folgende Kanal enthält den Datenpunkt STATE
attr HM_ST_WZ_Bass statechannel 1
# Im set devstate Befehl werden on/off in true/false übersetzt und an die CCU geschickt
attr HM_ST_WZ_Bass statevals on:true,off:false
# Im get devstate Befehl (und bei Events) werden true/1/false/0 durch on/off ersetzt und in state gespeichert
attr HM_ST_WZ_Bass substitute STATE!true:on,false:off,1:on,0:off;;LOWBAT!true:yes,false:no

Ein Heizthermostat mit SET_TEMPERATURE als State-Datenpunkt:

define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ
attr HM_G_AZ_HZ statechannel 4
attr HM_G_AZ_HZ statedatapoint SET_TEMPERATURE
# Bei Anzeige der Zieltemperatur in state soll nur eine Nachkommastelle angezeigt werden
attr HM_G_AZ_HZ stripnumber 1
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 17:29:47
Ok, nach einigen Boots scheint der RCP durch zu laufen.
Wenn ich in der HMCCU ein get devicelist mache, was passiert dann?
Werden die Devices dann irgendwo aufgelistet?
Bei mir nicht :(

In den Bildern habe ich das jetzt mal umgesetzt, in dem Reading scheint der STATE anzukommen,
aber leider nicht als "State"... HILFE! :o ;)

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 26 Dezember 2015, 17:33:00
Hallo Zusammen,

ich versuche gerade die Daten in der TabletUI anzuzeigen. Aber ich weiß nicht so recht was ich abfragen muss.
Kann mir jemand helfen?

<div data-type="thermostat"
data-device="HM_KU_Thermostat"
data-get="datapoint 4.SET_TEMPERATURE"
data-set="datapoint 4.SET_TEMPERATURE"
data-temp="HM-CC-RT-DN%20LEQ1076554.4.ACTUAL_TEMPERATURE"
data-min="0"
data-max="50"
class="cell">
</div>

Ich habe jetzt alle möglichen Kombinationen ausprobiert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 17:45:33
Hallo Zusammen,

ich versuche gerade die Daten in der TabletUI anzuzeigen. Aber ich weiß nicht so recht was ich abfragen muss.
Kann mir jemand helfen?

<div data-type="thermostat"
data-device="HM_KU_Thermostat"
data-get="datapoint 4.SET_TEMPERATURE"
data-set="datapoint 4.SET_TEMPERATURE"
data-temp="HM-CC-RT-DN%20LEQ1076554.4.ACTUAL_TEMPERATURE"
data-min="0"
data-max="50"
class="cell">
</div>

Ich habe jetzt alle möglichen Kombinationen ausprobiert.

In "data-get" und "data-temp" kommt nur das Reading rein, während in "data-set" der Befehl angegeben werden muss. Bei mir sieht ein Wandthermostat (Vorsicht, andere Kanäle als das Heizkörperthermostat) in Tablet-UI so aus:

<div data-type="thermostat"
   data-device="HM_KL_SZ_TH"
   data-get="KL-SZ-TH.2.SET_TEMPERATURE"
   data-temp="KL-SZ-TH.1.TEMPERATURE"
   data-set="datapoint 2.SET_TEMPERATURE"

Und so sehen meine Readings aus:

Readings:
     2015-12-26 17:47:16   DEWPOINT        11.4
     2015-12-26 17:47:16   KL-SZ-TH.1.HUMIDITY 63
     2015-12-26 17:47:16   KL-SZ-TH.1.TEMPERATURE 18.6
     2015-12-26 17:46:55   KL-SZ-TH.2.SET_TEMPERATURE 21.0
     2015-12-26 17:47:16   state           18.6

Ein Problem in Deinem Fall könnte das Leerzeichen im Readingname von "data-temp" sein. Hast Du mal %20 durch ein einfaches Blank ersetzt?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 17:55:25
Wenn ich in der HMCCU ein get devicelist mache, was passiert dann?
Werden die Devices dann irgendwo aufgelistet?
Bei mir nicht :(

get devicelist erzeugt keine Ausgabe. Es wird lediglich das Internal "DevCount" im IO Device auf die Anzahl der von der CCU gelesenen Geräte und Kanäle gesetzt. Mit get devicelist dump erfolgt eine Auflistung aller Kanäle im FHEM Fenster.

get devicelist wird beim Define des IO Devices automatisch ausgeführt. Nach einem Reload von 88_HMCCU muss es manuell ausgeführt werden. Ebenso, wenn in der CCU ein neues Gerät angelernt wurde oder sich an einem vorhandenen Gerät etwas geändert hat.

Zitat
In den Bildern habe ich das jetzt mal umgesetzt, in dem Reading scheint der STATE anzukommen,
aber leider nicht als "State"... HILFE! :o ;)

mmm, darüber muss ich etwas nachdenken ... aber mach schon mal beim Attribut substitute aus den 2 Semikolon vor LOWBAT eins. Die zwei Semikolon kommen daher, dass ich meine Beispiele aus der fhem.cfg kopiert habe.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 17:58:21
Alles klar, das mit dem dump habe ich wohl überlesen in der Doku  :-X

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 ccm?


Kann ich verhindern, dass das:
"2015.12.26 16:33:42 1: HMCCU: Received no events from CCU since 180 seconds"
nicht jede Sekunde geloggt wird?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 18:04:43
Alles klar, das mit dem dump habe ich wohl überlesen in der Doku  :-X

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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 18:09:26
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?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 18:26:18
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?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 26 Dezember 2015, 18:26:35
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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 18:28:25
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...


Zitat
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?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 19:16:40
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).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 19:21:07
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...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Dezember 2015, 19:26:33
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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 26 Dezember 2015, 20:18:02
Ich mal wieder,

ich habe die Doku und den Thread durchforstet, Systemvariablen werden nicht gepusht oder?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Dezember 2015, 10:54:01
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?
 
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 27 Dezember 2015, 11:36:57
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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: RainerG am 27 Dezember 2015, 17:55:13
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:
Zitat
Undefined subroutine &main::usleep called at ./FHEM/88_HMCCUDEV.pm line 238
Die Änderungen von zap aus Antwort #143 sind eingespielt!
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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Dezember 2015, 18:02:45
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).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Dezember 2015, 18:10:15
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.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Dezember 2015, 18:42:20
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:

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):

/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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: RainerG am 27 Dezember 2015, 20:48:33
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.
Leider muß es noch eine Ursache geben:
Deine Dateien sind ok und Time::HiRes scheint auch richtig installiert zu sein:
Zitat
cpan[1]> install Time::HiRes
Reading '/root/.cpan/Metadata'
  Database was generated on Sun, 27 Dec 2015 05:17:02 GMT
Time::HiRes is up to date (1.9728).
Und trotzdem schmiert FHEM weiter ab.
Habt Ihr noch Ideen? - Danke Rainer
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: hometux am 28 Dezember 2015, 02:42:57
Hallo Rainer,
Ich hatte das gleiche Problem. Die Perl Version ist zu alt und hat das Time::HiRes Modul noch nicht standardmäßig mitgeliefert.

Die einfachste Lösung besteht darin, die Anweisung usleep(100000) durch ein sleep (1) zu ersetzen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 28 Dezember 2015, 09:28:54
Hallo Rainer,
Ich hatte das gleiche Problem. Die Perl Version ist zu alt und hat das Time::HiRes Modul noch nicht standardmäßig mitgeliefert.

Die einfachste Lösung besteht darin, die Anweisung usleep(100000) durch ein sleep (1) zu ersetzen.

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.

Aufpassen beim Neustart von FHEM bei aktivem RPC-Server: Nicht mit /etc/init.d/fhem restart neu starten. Dabei wird zwischen Stop und Start nicht lange genug gewartet und der RPC-Server wird versucht zu starten, bevor er richtig beendet wurde. Also immer erst Stop, warten bis der RPC-Server nicht mehr läuft und dann Start.

UPDATE: Neue Version von 88_HMCCU.pm eingecheckt. In allen Reading Names, die auf CCU Geräten oder Kanälen basieren werden alle Zeichen ersetzt, die keine gültigen Zeichen für FHEM Reading Names sind. Konkret: Doppelpunkte werden durch Punkte ersetzt. Alle Zeichen, die nicht zum Ausdruck [A-Za-z\d_\.-] passen, werden durch Unterstriche ersetzt.
Titel: zweiter RPC Prozess für Homematic Wired Komponenten?
Beitrag von: hometux am 29 Dezember 2015, 18:19:22
Hallo zap,

Erst einmal ganz vielen Dank für die schon super gute Funktionalität. HMCCU schließt m.E. die entscheidende Lücke in der HM-Unterstützung.

Ich nutze neben den drahtlosen Komponten auch verschiedene Wired Komponenten. Dafür stellt die CCU eine zweite RPC Schnittstelle unter der Portnummer 2000 zur Verfügung.

Ich habe einmal probehalber die Portnummer für den RPC Port auf 2000 gesetzt. Das funktioniert auch grundsätzlich, natürlich nun ohne die Wireless Komponenten. Probleme scheint es beim HM-Input Modul mit vielen Kanälen zu geben. Diese werden offenbar nicht einzeln ausgewertet und aktualisieren immer gemeinsam- das muss ich allerdings noch genauer untersuchen.

Meine konkrete Frage: spricht etwas prinzipiell dagegen, 2 RPC-Prozesse gleichzeitig laufen zu lassen (gegen Port 2000 und 2001 der ccu)? Im Moment ist das ja offenkundig programmtechnisch geblockt.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 29 Dezember 2015, 18:49:43
Hallo zusammen, zunächst einmal meine Variante aus der CCU heraus Fhem-Befehle auszuführen, für alle die es interessiert:
-> Für "komplexere" Dinge wie z.B. Wetterberichte, die ich nicht unbedingt via http aufrufen will...

1. In der CCU gibt es zwei Systemvariablen,
Fhem.A.value und Fhem.A.state

Das A steht für einen Index und ist einfach nur falls ich mal mehrere "interfaces" brauche, genau wie Fhem.A.state
(Die Überlegung ist halt, wenn ein CCU-Programm abläuft checkt es: ist ...A.state=readyToReceive? Wenn ja, dann Befehl in Fhem.A.value, ansonsten versuche es entsprechend mit Fhem.B)

2. Mein Fhem holt sich sekündlich via RCP die Variablen aus der CCU ab, darunter auch Fhem.A.value, und speichert mir das in den Fhem-Dummy CCU.CMD.A
-> Auf Änderungen des States von A reagiert ein notify, dies führt dann "doCmd("A")" aus.

das sieht so aus:
Zitat
sub
doCmd($){
   my ($i) =@_;
   my $cmd=Value("CCU.CMD.".$i);
   fhem ($cmd);
   fhem ("set CCU var Fhem.".$i."state 1");

}

Es guckt also in den Dummy Befehl A, nimmt den Inhalt, führt ihn aus und setzt in der CCU das Interfaces A wieder auf readyToReceive(1).


Das wäre vielleicht noch etwas für das Modul?


Ansonsten vielen Dank für den Nerv, zap! +1

Ich habe jetzt mal scharf nachgedacht was da lost ist, und mein Problem ist glaube ich folgendes:
CCU und Raspberry hängen am gleichen Netzteil, wenn ich nun das Netzteil rausziehe, der Raspberry hochfährt ist der deutlich vor der CCU fertig, die CCU kann dem Raspberry also nicht antworten :D und der get devicelist wartet vergeblich auf eine Antwort...

Vielleicht könnte man in das Modul noch einbauen, dass es den start so lange verzögert bis die CCU hochgefahren ist? Keine Ahnung was man da als Indikator nimmt, bzw. wie man dann ALLES umbauen müsste, damit die CCU-Geschichten erst "defined" werden wenn die CCU am start ist?

VG

Bei mir läuft der Spaß jetzt eigentlich ganz gut! Noch mal +1 :D
Super, Super, Super, Danke!





PS: Ich habe einen 4-Fach Aktor, und einige 2-Fach Aktoren definiert, da funktioniert der Status per RCP nicht so schön, alle Devices des Aktors bekommen den gleichen State, das statechannel-Attribut habe ich gesetzt... ?! -> Anscheinend bekommen alle Kanäle des Aktors den State der letzten "Schaltung"
Titel: Antw:zweiter RPC Prozess für Homematic Wired Komponenten?
Beitrag von: zap am 30 Dezember 2015, 09:05:12
Probleme scheint es beim HM-Input Modul mit vielen Kanälen zu geben. Diese werden offenbar nicht einzeln ausgewertet und aktualisieren immer gemeinsam- das muss ich allerdings noch genauer untersuchen.

Du meinst das HMCCU Modul? Die Auswertung der Events von der CCU läuft ja zeitgesteuert in dem mit rpcinterval festgelegten Intervall. Dabei werden immer bis zu 20(?) Events aus der Queue gleichzeitig ausgewertet. Diese Limitierung habe ich drin, um FHEM nicht auszubremsen. Das kann bei sehr vielen Kanälen aber dazu führen, dass Events erst beim 2. Intervall ausgewertet werden. Ich denke, ich kann den Wert etwas nach oben korrigieren. An der Gleichzeitigkeit vieler Events aufgrund der zeitgesteuerten Auswertung wird sich dadurch aber nicht viel ändern.

Zitat
Meine konkrete Frage: spricht etwas prinzipiell dagegen, 2 RPC-Prozesse gleichzeitig laufen zu lassen (gegen Port 2000 und 2001 der ccu)? Im Moment ist das ja offenkundig programmtechnisch geblockt.

Prinzipiell spricht nichts gegen 2 Prozesse. Habe das nicht berücksichtigt, da ich keine wired Komponenten habe. Die CCU2 unterstützt seit kurzem aber auch Homematic IP (noch in Beta). Ich vermute mal, dass hierfür auch ein separater Port verwendet werden wird. Ich ziehe also die Unterstützung mehrerer RPC-Server in Erwägung, da ich plane, einige IP-Komponenten einzusetzten (z.B. die schicken Steckdosen) ...  ;)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 Dezember 2015, 09:16:01
Hallo zusammen, zunächst einmal meine Variante aus der CCU heraus Fhem-Befehle auszuführen, für alle die es interessiert:
-> Für "komplexere" Dinge wie z.B. Wetterberichte, die ich nicht unbedingt via http aufrufen will...

Eine alternative Möglichkeit zum Ausführen beliebiger FHEM Befehle aus der CCU heraus habe ich in HMCCU_Readme.txt in Abschnitt 6.2 beschrieben. Aber Deine Variante geht natürlich auch.

Zitat
Vielleicht könnte man in das Modul noch einbauen, dass es den start so lange verzögert bis die CCU hochgefahren ist? Keine Ahnung was man da als Indikator nimmt, bzw. wie man dann ALLES umbauen müsste, damit die CCU-Geschichten erst "defined" werden wenn die CCU am start ist?

Eine Wartefunktion wäre keine große Sache. Allerdings wird das natürlich den Start von FHEM ausbremsen. Die Frage ist, wie lange man FHEM warten lässt. Das könnte man über einen weiteren Parameter im define von HMCCU bestimmen mit Default = 0, d.h. gar nicht warten. Ich denke mal drüber nach. Du könntest auch das fhem Startscript /etc/init.d/fhem anpassen und dort in einer Schleife per ping checken, ob die CCU da ist.

Zitat
PS: Ich habe einen 4-Fach Aktor, und einige 2-Fach Aktoren definiert, da funktioniert der Status per RCP nicht so schön, alle Devices des Aktors bekommen den gleichen State, das statechannel-Attribut habe ich gesetzt... ?! -> Anscheinend bekommen alle Kanäle des Aktors den State der letzten "Schaltung"

Poste mal bitte die Definitionen. Sollte nicht so sein.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: lukasbastelpeter am 30 Dezember 2015, 10:32:22
zunächst hier die defs:
Zitat
define CCU HMCCU 192.168.XXX.XXX
attr CCU alias CCU-IO
attr CCU event-on-change-reading state
attr CCU group IOs
attr CCU loglevel 6
attr CCU room System
attr CCU rpcinterval 1
attr CCU rpcserver on

2-Fach Aktor
define F.DeckenLampe.Tuer HMCCUDEV XXXXX 1
attr F.DeckenLampe.Tuer userattr Licht Licht_map structexclude
attr F.DeckenLampe.Tuer IODev CCU
attr F.DeckenLampe.Tuer Licht F.Licht
attr F.DeckenLampe.Tuer alias Deckenlampe Tür
attr F.DeckenLampe.Tuer group Licht
attr F.DeckenLampe.Tuer room Flur
attr F.DeckenLampe.Tuer statechannel 1
attr F.DeckenLampe.Tuer statevals on:true,off:false
attr F.DeckenLampe.Tuer substitute true:on,false:off,1:on,0:off
define F.DeckenLampe.Innen HMCCUDEV XXXXX 2
attr F.DeckenLampe.Innen userattr Licht Licht_map structexclude
attr F.DeckenLampe.Innen IODev CCU
attr F.DeckenLampe.Innen Licht F.Licht
attr F.DeckenLampe.Innen alias Deckenlampe Innen
attr F.DeckenLampe.Innen group Licht
attr F.DeckenLampe.Innen room Flur
attr F.DeckenLampe.Innen statechannel 2
attr F.DeckenLampe.Innen statevals on:true,off:false
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off


4-Fach Aktor:
define SZ.BettLampe.Tuer HMCCUDEV XXX 4
attr SZ.BettLampe.Tuer userattr Licht Licht_map structexclude
attr SZ.BettLampe.Tuer IODev CCU
attr SZ.BettLampe.Tuer Licht SZ.Licht
attr SZ.BettLampe.Tuer alias Bettlampe Tür
attr SZ.BettLampe.Tuer group Licht
attr SZ.BettLampe.Tuer room Schlafzimmer
attr SZ.BettLampe.Tuer statechannel 4
attr SZ.BettLampe.Tuer statevals on:true,off:false
attr SZ.BettLampe.Tuer substitute true:on,false:off,1:on,0:off
define SZ.BettLampe.Fenster HMCCUDEV XXX 3
attr SZ.BettLampe.Fenster userattr Licht Licht_map structexclude
attr SZ.BettLampe.Fenster IODev CCU
attr SZ.BettLampe.Fenster Licht SZ.Licht
attr SZ.BettLampe.Fenster alias Bettlampe Fenster
attr SZ.BettLampe.Fenster group Licht
attr SZ.BettLampe.Fenster room Schlafzimmer
attr SZ.BettLampe.Fenster statechannel 3
attr SZ.BettLampe.Fenster statevals on:true,off:false
attr SZ.BettLampe.Fenster substitute true:on,false:off,1:on,0:off
define SZ.Standby.Tag HMCCUDEV XXX 1
attr SZ.Standby.Tag IODev CCU
attr SZ.Standby.Tag alias Standby: Ladegeräte Wecker
attr SZ.Standby.Tag group Energie Management
attr SZ.Standby.Tag room Schlafzimmer
attr SZ.Standby.Tag statechannel 1
attr SZ.Standby.Tag statevals on:true,off:false
attr SZ.Standby.Tag substitute true:on,false:off,1:on,0:off
define SZ.Standby.Nacht HMCCUDEV XXX 2
attr SZ.Standby.Nacht IODev CCU
attr SZ.Standby.Nacht alias Standby: Sonos
attr SZ.Standby.Nacht group Energie Management
attr SZ.Standby.Nacht room Schlafzimmer
attr SZ.Standby.Nacht statechannel 2
attr SZ.Standby.Nacht statevals on:true,off:false
attr SZ.Standby.Nacht substitute true:on,false:off,1:on,0:off



Der Timer wäre als Reading ganz nett, ich hatte zwischenzeitlich überlegt den FHEM start abhängig vom Ping der CCU zu machen, bis jetzt bin ich in der Phase, in der mich ein Stromausfall nicht interessiert, aber wenn das mal passiert und alles gleichzeitig wieder an geht, steht man da :)...

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 Dezember 2015, 11:55:27
zunächst hier die defs:

2-Fach Aktor
define F.DeckenLampe.Tuer HMCCUDEV XXXXX 1
attr F.DeckenLampe.Tuer statechannel 1
attr F.DeckenLampe.Tuer statevals on:true,off:false
attr F.DeckenLampe.Tuer substitute true:on,false:off,1:on,0:off
define F.DeckenLampe.Innen HMCCUDEV XXXXX 2
attr F.DeckenLampe.Innen statechannel 2
attr F.DeckenLampe.Innen statevals on:true,off:false
attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off

Alles klar, ich nehme an, die beiden XXXXX beim ersten und zweiten Device sind identisch, oder? In dem Fall hast Du zwar 2 Client Devices definiert, allerdings mit der gleichen CCU Geräteadresse, d.h. es handelt sich um das gleiche Gerät. Die Aktualisierung der Readings erfolgt bei Client Devices vom Typ HMCCUDEV über die Geräteadresse, nicht über die Kanaladresse. Daher überschreiben sich die STATEs gegenseitig.

Wie heißen denn die Datenpunkte bei den beiden Kanälen, die jeweils in STATE landen sollen? Ggf. geht was über das Attribut statedatapoint.

Ansonsten: Versuche es mal bitte mit HMCCUCHN. Die Defines sehen dann so aus:

define F.DeckenLampe.Tuer HMCCUCHN Name/Adresse_Channel1
define F.DeckenLampe.Innen HMCCUCHN Name/Adresse_Channel2

Dann werden die Client-Devices bei der Aktualisierung getrennt betrachtet (hoffentlich, sonst ist es ein Bug).

BTW: Statt

attr F.DeckenLampe.Innen substitute true:on,false:off,1:on,0:off

geht auch

attr F.DeckenLampe.Innen substitute (true|1):on,(false|0):off
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 30 Dezember 2015, 12:59:41
Hallo Zap,

sorry dass ich mich jetzt erst wieder melde.
Zitat
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.
Ich hatte die Umstellung auf "address" vorgenommen und es hat super funktioniert. Was leider nicht funktioniert hatte, war das Schalten des Thermostates. Mein TabletUI hat zwar die Schaltung abesetzt (sieht man ja an der kurzen Toast message) aber direkt darauf kam als Toast message "Error: error". Das Thermostat hat die Daten trotzdem empfangen und die Wunschtemperatur geändert, aber FHEM ist danach komplett abgestürzt. Allerdings hatte ich keine Fehlermeldung im Log. Da ich selbst keine CCU2 habe, kann ich das erst in ein paar Monaten wieder weiter basteln und testen. Bis dahin hast du sicher wieder ein paar neue Versionen eingecheckt. ;)
Finde das Modul aber bisher echt klasse.  :D
VG, Thomas
Titel: Auswertung von HM-Devices mit mehreren separaten Kanälen
Beitrag von: hometux am 31 Dezember 2015, 14:11:47
Hallo tux,

Meine Beobachtung bei HMWired (es handelt sich übrigens um das 12-fach Input-Modul HMW-Sen-SC-12-DR, bei dem die einzelnen Kanäle :1 bis :12 ausgelesen werden) und die von lukasbastelpeter laufen wohl in dieselbe Richtung.

Ich habe die einzelnen Kanäle aktuell als einzelne HMCCUDEV Devices definiert und beobachte eine gemeinsame Aktualisierung, sobald ein Eingang aktualisiert wird. Allerdings ist dann jeweils auch der gelesene Status für die betroffenen Geräte identisch. Das Verhalten tritt vermutlich nur bei Ereignissen auf, die über den RPC Prozess einlaufen. Aktualisiere ich die Werte manuell über getstate, sehe ich keinen Fehler.

Du hattest ja zu HMCCUCHN geschrieben:
Zitat
"Dann werden die Client-Devices bei der Aktualisierung getrennt betrachtet (hoffentlich, sonst ist es ein Bug)."

Ich hatte das schon versucht, und die Ports als HMCCUCHN oder auch probehalber als HMCCUDEV readonly definiert, das hat bisher jedoch nicht funktioniert. Möglicherweise gibt es hier noch ein Problem mit dem statedatapoint SENSOR. Darauf deutet für mich der folgende Eintrag aus dem Logfile hin:

(bei Definition als HMCCUCHN)
Zitat
2015.12.29 20:23:54 1: HMCCU: Error URL = http://XXX.168.178.5:8181/do.exe?r1=dom.GetObject("BidCos-Wired.LEQXXX4691:1.SENSOR").State()
2015.12.29 20:23:54 1: HMCCUCHN: Fenster_OG_Schlafzimmer Execution of CCU script failed
---
(bei Definition als HMCCUDEV readonly)
Zitat
2015.12.29 20:27:52 1: HMCCU: Error URL = http://XXX.168.178.5:8181/do.exe?r1=dom.GetObject("BidCos-Wired.LEQXXX4691:1.SENSOR").State()
2015.12.29 20:27:52 1: HMCCUDEV: Fenster_OG_Schlafzimmer Execution of CCU script failed

Das abweichende Verhalten zwischen den Einstellungen HMCCUDEV und HMCCUCHN deutet für mich in Richtung Bug hin.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mw77 am 31 Dezember 2015, 18:49:55
Hallo hometux,
ich verwende das selbe Homematic wired Modul.
Zitat
(bei Definition als HMCCUCHN)
Zitat
2015.12.29 20:23:54 1: HMCCUCHN: Fenster_OG_Schlafzimmer Execution of CCU script failed
Den gleichen Fehler hatte ich auch, habe jetzt bei attr substitute 0:closed,1:open,false:closed,true:open, seit dem läuft es.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 Januar 2016, 17:04:38
Hallo hometux,
ich verwende das selbe Homematic wired Modul.Den gleichen Fehler hatte ich auch, habe jetzt bei attr substitute 0:closed,1:open,false:closed,true:open, seit dem läuft es.

Das kann nicht die Lösung des Fehlers sein. Die Ersetzung per substitute greift erst nach der erfolgreichen Ausführung des GET Befehls.

@hometux: Reden wir hier von einem GET oder SET? Bitte führe mal den Befehl "get deviceinfo" bei dem HMCCUDEV Device aus. Funktioniert der? Wie sieht die Ausgaben aus?

Gibt es eine Fehlermeldung in /var/log/messages der CCU?

Für die korrekte Aktualisierung eines Aktors mit mehreren Schaltkanälen müssen auf jeden Fall für jeden Schaltkanal HMCCUCHN Devices definiert werden, da diese vom RPC-Server über ihre Kanaladresse aktualisiert werden. HMCCUDEV Devices werden hingegeben über die Geräteadresse aktualisiert. Da diese für alle Schaltkanäle identisch ist, überschreiben sich die Statusänderungen gegenseitig.

Titel: [gelöst] Geräte mit mehreren unabhängigen Kanälen
Beitrag von: hometux am 03 Januar 2016, 15:35:11
Das Problem ist gelöst und funktioniert jetzt einwandfrei, vielen Dank an alle.

Wie zap schon geschrieben hat, muss bei Geräten die mehrere Kanäle verwenden, jeder Kanal als HMCCUCHN definiert werden. Verwendet man stattdessen (fälschlich) HMCCUDEV, so werden die Kanäle nicht separat ausgewertet. Bei den HM-Wired Geräten mit 12 Eingängen z.B. führt dies zu falschen Auslesewerten und unbefriedigenden Ergebnissen.

Mein zwischenzeitlicher Fehler war, dass ich Geräte einfach von HMCCUDEV auf HMCCUCHN umdefiniert habe. Das funktioniert aber nicht sofort (stattdessen tritt die oben beschriebene Fehlermeldung im Log auf), sondern erst nachdem die Geräteinfo der CCU neu gelesen wurde. Für das HMCCUCHN Device gibt es dazu allerdings keinen Befehl get deviceinfo. Man muss über HMCCU aktualisieren.

Ergänzend ist vielleicht der Hinweis interessant, dass es (natürlich) für HMCCUCHN kein statechannel attribut mehr gibt. Definiert man zusätzlich die Geräte als readonly gibt es auch kein attribut statevals.

Insgesamt jedenfalls eine tolle Sache. Das einzige was ich mir im Moment noch vorstellen könnte, ist eine bequemere Art, beim Start von fhem alle aktuellen Gerätestati auf einmal einzulesen.

Titel: Antw:[gelöst] Geräte mit mehreren unabhängigen Kanälen
Beitrag von: zap am 03 Januar 2016, 16:20:37
Das Problem ist gelöst und funktioniert jetzt einwandfrei, vielen Dank an alle.

Wie zap schon geschrieben hat, muss bei Geräten die mehrere Kanäle verwenden, jeder Kanal als HMCCUCHN definiert werden. Verwendet man stattdessen (fälschlich) HMCCUDEV, so werden die Kanäle nicht separat ausgewertet. Bei den HM-Wired Geräten mit 12 Eingängen z.B. führt dies zu falschen Auslesewerten und unbefriedigenden Ergebnissen.

Das führt nur dann zu Problemen, wenn mehrere Kanäle die gleichen Datenpunkte verwenden. Leider ist das bei praktisch allen Homematic Geräten mit mehreren Ein- oder Ausgängen so. Ein Schließerkontakt hat z.B. 3 Kanäle, wobei jeder einen STATE Datenpunkt hat. In dem Fall kann in HMCCUDEV eben nicht entschieden werden, welcher jetzt der ist, der in das FHEM Device STATE übernommen werden soll.

Zitat
Mein zwischenzeitlicher Fehler war, dass ich Geräte einfach von HMCCUDEV auf HMCCUCHN umdefiniert habe. Das funktioniert aber nicht sofort (stattdessen tritt die oben beschriebene Fehlermeldung im Log auf), sondern erst nachdem die Geräteinfo der CCU neu gelesen wurde. Für das HMCCUCHN Device gibt es dazu allerdings keinen Befehl get deviceinfo. Man muss über HMCCU aktualisieren.

Das muss was anderes gewesen sein. Der Befehl get deviceinfo listet einfach nur alle Kanäle und Datenpunkte eines CCU Gerätes auf. Da passiert sonst nix, nur reine Bildschirmausgabe. Da HMCCUCHN sich nur auf einen Kanal bezieht, gibt es natürlich keine DeviceInfo.

Zitat
Insgesamt jedenfalls eine tolle Sache. Das einzige was ich mir im Moment noch vorstellen könnte, ist eine bequemere Art, beim Start von fhem alle aktuellen Gerätestati auf einmal einzulesen.

Das geht derzeit nur per "get parfile" im HMCCU Modul. Zugegeben, das ist umständlich und man muss immer das Parfile aktuell halten. Muss ich mal drüber nachdenken. Das Problem ist, dass die Module beim Starten von FHEM nicht wissen, wann alles korrekt definiert und initialisiert ist (z.B. wann alle Attribute definiert sind).

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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:

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:

Wenn es funktioniert oder auch nicht wäre Feedback schön. Bei Fehlern möglichst mit der ccurpcd.log
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: FitzZZ am 05 Januar 2016, 20:16:00
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
Titel: Erster Testlauf für Update
Beitrag von: hometux am 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.

Zitat
2016.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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag 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.




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!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag 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.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: FitzZZ am 05 Januar 2016, 23:15:57
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.
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! :-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 06 Januar 2016, 07:45:33
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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag 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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 06 Januar 2016, 17:28:50
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.

Titel: Multi-Threaded RPC Dienst funktioniert jetzt
Beitrag von: hometux am 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.
Titel: Antw:Multi-Threaded RPC Dienst funktioniert jetzt
Beitrag von: zap am 06 Januar 2016, 21:10:00
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.
Titel: Neuer RPC Prozess
Beitrag 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.




Titel: Antw:Neuer RPC Prozess
Beitrag von: zap am 07 Januar 2016, 08:11:45
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.
Titel: Neuer Multi-Threaeded rpc Prozess.
Beitrag von: hometux am 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:
Zitat
define 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:
Zitat
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

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:
Zitat
define 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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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:

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".

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 Januar 2016, 19:29:46
Ich habe eine neue Version von 88_HMCCU.pm eingecheckt (Link siehe 1. Post).

Es gibt nun ein neues Attribut "ccutrace", das eine bessere Fehleranalyse ermöglicht. Mit dem Attribut wird ein regulärer Ausdruck für CCU Geräteadressen und/oder CCU Gerätenamen festgelegt. Bei Ausführung der Befehle "get datapoint", "get devstate", "get update" oder "get deviceinfo" werden für die festgelegten Geräte ausführliche Informationen in das FHEM Logfile geschrieben (Loglevel 1).

@hometux: In Deinem Fall solltest Du das Attribut wie folgt setzen:

attr ccu ccutrace (LEQXXX6818|name_in_ccu)

XXX und name_in_ccu durch entsprechende Werte ersetzen.

Dann "get Verschluss_Schwingtor update" und "get Verschluss_Schwingtor deviceinfo" ausführen (für HMCCUDEV Device) und die Ausgabe in fhem Log per Forum-Mail an mich (damit Du die Orginaladressen und Namen nicht hier im Forum posten musst).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 Januar 2016, 20:53:04
Neue Version der Module 88_HMCCU* sowie vom RPC-Server ccurpcd.pl eingecheckt.

Fehlerbehebungen:



Neue Funktionen:



Beispiel für HMCCUDEV/HMCCUCHN Devices:

get mydevice update State

Beispiel für globales Update aller Devices (Vorsicht, stresst die CCU bei vielen Devices, die Angabe .* ist notwendig, da man beim update Befehl von HMCCU einen Device-Filter angeben kann):

get myIOdevice update .* State

Es wäre schön, wenn mal jemand mit BidCos und Wired Devices den Parallelbetrieb von 2 RPC-Servern testen könnte, d.h. die automatische Aktualisierung der Readings in FHEM (ich habe keine Wired Komponenten).

P.S. Die Doku HMCCU_Readme.txt habe ich noch nicht aktualisiert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 Januar 2016, 16:10:54
Kleiner Bugfix für 88_HMCCU.pm eingecheckt. Befehl "get devstate" sollte nun wieder funktionieren. Sorry. Hatte gestern Abend alles getestet bis auf get devstate. Und genau da einen riesen Bock eingebaut ;-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: hometux am 16 Januar 2016, 10:42:48
Hallo zap,

Das neue Release sieht richtig gut aus! get devstate funktioniert wie erwartet und der rpc Dienst arbeitet mit Wired und Wireless Port gleichzeitig.

Herzlichen Dank!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 16 Januar 2016, 18:38:03
Habe gerade neue Versionen der Module (88_HMCCU*) eingecheckt. Ich nenne die Version jetzt mal die "Rauchmelder Version". hometux weiß, wovon ich rede ;-)

Hintergrund: Aus mir unerfindlichen Gründen funktioniert die Homematic Script Funktion EnumUsedIds() bei Rauchmeldern für die Datenpunkte im Kanal 1 (hier liegt STATE) nicht. Das hatte Auswirkungen auf die Befehle "get update", "get channel" und "get deviceinfo". Der Fehler tritt interessanterweise auch bei XML-API auf. Das habe ich nun behoben, d.h. diese Funktion wird einfach nicht mehr verwendet. Ich denke, das ist ein Bug in der CCU Software.

Außerdem habe ich noch eine neue Funktion eingebaut: HMCCU berücksichtigt nun auch RPC Delete Device Events. D.h. wenn in der CCU ein Gerät gelöscht wird, das in FHEM als Device vorhanden ist, wird dieses Device als "Deleted" markiert und kann nicht mehr für Set/Get Aktionen verwendet werden. Das FHEM Device bleibt jedoch bis zum nächsten Restart (ohne Funktion) erhalten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: christoph_j am 20 Januar 2016, 22:23:43
Hallo zap,

welche Attribute müssen gesetzt werden, um den HM-LC-BL1-FM Funk-Jalousieaktor aus FHEM mit dem HMCCUDEV bedienen zu können? Mir fehlt die Möglichkeit per Schieberegler die Position bestimmen zu können.

Gruß,
Christoph
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 Januar 2016, 09:52:22
Hmm, damit habe ich mich noch nicht beschäftigt. Ich nutze Tablet-UI. Dort genügt es, im Widget den entsprechenden Datenpunkt anzugeben.

HMCCU ist sehr generisch gehalten, d.h. die verschiedenen Homematic Typen erfahren keine Sonderbehandlung wie z.B. un CUL_HM.

Ich weiß nicht, was hier mit FHEM Bordmitteln wie webCmd usw. möglich ist.

Der Kanal und Datenpunkt, über den die Steuerung erfolgt, ist Dir bekannt?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: christoph_j am 21 Januar 2016, 12:29:06
Hallo zap,

ja, dass ist mir bekannt. Funktioniert auch mit set super, hatte gedacht ich hätte was übersehen.

Gruß,
Christoph
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 Januar 2016, 19:08:33
Ich habe gerade eine neue Version von 88_HMCCUDEV.pm eingecheckt. Das ist ein erster Versuch, für einen Datenpunkt eines Devices alternative Steuerelemente (z.B. Slider) bereitzustellen. Es gibt nun ein neues Attribut "controldatapoint". Damit wird eine Datenpunkt festgelegt, der mit dem Befehl "set xxx control Wert" gesetzt werden kann. Format des Datenpunktes ist Kanalnummer.Datenpunkt.

Beispiel: Bei einem Heizungsthermostaten soll ein Slider zur Einstellung der Zieltemperatur angezeigt werden.

1) Zunächst das Attribut "controldatapoint" auf den Kanal/Datenpunkt setzen, mit dem die Zieltemperatur eingestellt wird:

attribute mydev controldatapoint 2.SET_TEMPERATURE

2) Webcmd und WidgetOverride definieren:

attribute mydev webCmd control
attribute mydev widgetOverride control:slider,10,1,30

Der Befehl "set mydev control nn" setzt den Datenpunkt 2.SET_TEMPERATURE auf den gewünschten Wert nn.

Analoge Vorgehensweise für einen Rolladenaktor. Da ich mich mit dem webCmd-Konstrukt nicht auskenne, weiß ich leider nicht, wie man den Slider dazu bringt, immer den aktuell eingestellten Wert anzuzeigen. Bei mir zeigt er immer irgendeinen Wert an. Wenn ich den Slider bewege, wird aber der eingestellte Datenpunkt korrekt gesetzt. Vielleicht hat ja jemand einen Tipp ...

So richtig überzeugt mich die antiquierte FHEM Oberfläche nicht. Möglicherweise werfe ich das Feature wieder raus.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: christoph_j am 21 Januar 2016, 21:43:28
Hallo zap,

vielen Dank für die schnelle Unterstützung. Leider funktioniert das Modul noch nicht richtig mit dem Rolladenaktor. Die Werte für den Rolladenaktor müssen im Wertebereich von 0 bis 1 liegen, der Slider übermittelt aber nur Werte von 1 bis 100.

Hier mein Code:
define Rolladen.Wohnzimmer HMCCUDEV Rolladen_Wohnzimmer 1
attr Rolladen.Wohnzimmer IODev CCU2
attr Rolladen.Wohnzimmer controldatapoint 1.LEVEL
attr Rolladen.Wohnzimmer statechannel 1
attr Rolladen.Wohnzimmer statedatapoint LEVEL
attr Rolladen.Wohnzimmer webCmd control
attr Rolladen.Wohnzimmer widgetOverride control:slider,0,0.000001,1

Danke,
Christoph
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Januar 2016, 07:27:18
Hallo zap,

vielen Dank für die schnelle Unterstützung. Leider funktioniert das Modul noch nicht richtig mit dem Rolladenaktor. Die Werte für den Rolladenaktor müssen im Wertebereich von 0 bis 1 liegen, der Slider übermittelt aber nur Werte von 1 bis 100.

Hier mein Code:

attr Rolladen.Wohnzimmer widgetOverride control:slider,0,0.000001,1

Hat vermutlich mit den Werten <1 zu tun. Lies mal das hier:

http://forum.fhem.de/index.php/topic,44104.msg359791.html#msg359791

und versuche mal folgendes (auf jeden Fall bei Start und Ende die ".0" mit angeben:

attr Rolladen.Wohnzimmer widgetOverride control:slider,0.0,0.01,1.0

BTW: Bist Du sicher, dass Du so kleine Schritte einstellen möchtest? m.E. sollten ganze Prozentschritte reichen (s. Beispiel).

Wie gesagt, kenne mich damit nicht wirklich aus und habe derzeit keinen Rolladen-Aktor im Einsatz.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: christoph_j am 22 Januar 2016, 10:12:54
Hallo zap,

jetzt funktioniert es. Am ende fehlte noch ne 1:

attr Rolladen.Wohnzimmer widgetOverride control:slider,0.00,0.01,1.00,1
Das sind jetzt 100 Positionen die eingestellt werden können.

Gruß,
Christoph
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 Januar 2016, 19:38:05
Die 3 HMCCU Module unterstützen nun FHEM Widgets (z.B. Slider Controls). Dazu wurde in HMCCUDEV und HMCCUCHN ein neues Attribut "controldatapoint" eingeführt. Mit diesem Attribut wird der Datenpunkt festgelegt, der mit dem Widget geändert werden soll. Wenn dieses Attribut gesetzt ist, wird beim Aktualisieren des Datenpunkts ein Reading "control" gesetzt. Dies ist erforderlich, damit das Widget den aktuellen Wert anzeigt.

Beispiel: Ein Wandthermostat hat im Kanal 2 einen Datenpunkt SET_TEMPERATURE, mit dem die Zieltemperatur gesetzt wird. Die Einstellung soll mit einem Slider in 1 Grad Schritten zwischen 10 und 25 Grad erfolgen:

attr mydev controldatapoint 2.SET_TEMPERATURE
attr mydev webCmd control
attr mydev widgetOverride control:slider,10,1,25

Bitte beachten: Bei Devices vom Typ HMCCUCHN muss für "controldatapoint" nur ein Datenpunkt angegeben werden, da der Kanal bereits durch das Device vorgegeben ist.

Der Screenshot zeigt 3 Wandthermostate mit den aktuellen Werten für Temperatur, Luftfeuchte, Zieltemperatur und Taupunkt sowie einem Slider zum Einstellten der Zieltemperatur.
Titel: Ruchmelder-"Edition" funktioniert.
Beitrag von: hometux am 26 Januar 2016, 16:53:14
Hall zap,

Mit dem RM-Release werden bei mir seit ca. einer Woche die Rauchmelder richtig ausgelesen - Vielen Dank!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: luke666s am 28 Januar 2016, 16:07:16
Danke erstmal für die klasse Arbeit...
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".
Wo finde ich die scripte auf dem raspi?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 28 Januar 2016, 18:01:26
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:

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:

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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: luke666s am 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....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: luke666s am 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 :)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: luke666s am 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)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: luke666s am 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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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:

# 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.)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: luke666s am 29 Januar 2016, 21:59:22
die beiträge kannte ich schon  8) das paket war schon installiert und PRC::XML ist v1.60 laut cpan

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...
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#
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag 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....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 31 Januar 2016, 12:14:08
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:


Entwicklung unter MacOSX, Kontakt zu Linux vermeide ich wenn es geht aufgrund negativer Erfahrungen mit der Library- bzw.  Version- bzw. Dependency-Hölle ;-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: dferch am 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:

<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:

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):

set HM_BZ_Thermostat datapoint MANU_MODE 4.5

Im Logfile steht dann:

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:

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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: dferch am 07 Februar 2016, 20:11:05
Hi Zap,

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

Manueller Modus
set HM_BZ_Thermostat datapoint MANU_MODE 4.5
Automatik Modus
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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 07 Februar 2016, 20:41:18
Ich muss mir das morgen trotzdem nochmal anschauen. Das Setzen des Datenpunktes wird nämlich immer mit State() ausgeführt. Nach jedem Set wird aber nochmal per get der Wert abgefragt (ein Überbleibsel aus der Vor-RPC-Server Ära). Und hier kommt das Attribut ccuget zum Einsatz. Vermutlich hat das Setzen also vorher auch schon funktioniert, nur das Abfragen nicht. Wenn ich das richtig verstehe, erfolgt das Abfragen per Datenpunkt CONTROL_MODE erfolgt.

Habe zwar einige Thermostate, fahre meine aber immer im Auto Mode. Daher muss ich es mir erst mal anschauen ....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 Februar 2016, 07:43:40
So, habe mit jetzt mal die Doku zu den Datenpunkten des Thermostaten angeschaut. Unter

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

steht folgende Tabelle:

Name            Typ      Zugriff
----------------------------------------------
CONTROL_MODE       option   lesend
FAULT_REPORTING    option   lesend
BATTERY_STATE      float    lesend
VALVE_STATE        integer  lesend
BOOST_STATE        integer  lesend
ACTUAL_TEMPERATURE float    lesend
SET_TEMPERATURE    float    lesend/schreibend
AUTO_MODE          action   schreibend
MANU_MODE          float    schreibend
BOOST_MODE         action   schreibend
COMFORT_MODE       action   schreibend
LOWERING_MODE      action   schreibend

Bedeutet: Den aktuellen Modus liest Du über CONTROL_MODE aus. Gesetzt wird er aber über AUTO_MODE, MANU_MODE, BOOST_MODE, COMFORT_MODE und LOWERING_MODE. Damit ist auch klar, wie der Fehler im Log zustande kam. Der AUTO_MODE wurde zwar gesetzt, allerdings ist der folgende Lesebefehl für die Verifikation fehlgeschlagen, da AUTO_MODE nur schreibenden Zugriff erlaubt.

Ich werfe diese Leseverifikation in der nächsten Version raus oder mache sie zumindest optional per Attribut einstellbar. Wenn der RPC-Server aktiv ist, braucht man das nicht.

Alle weiteren Parameter (wie z.B. Zeiten, Wochenprogramm, usw.) können nur über "set config" eingestellt werden. Dabei gibt es aber gerade bei den Zeiteinstellungen vieles zu beachten, da man immer komplette Wochenprogramme übertragen muss.


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 Februar 2016, 15:51:02
Ich habe gerade die Version 2.7 eingecheckt. Achtung! Die Source-Forge Adresse hat sich geändert (als Vorbereitung für eine zukünftige Installation per "update"). Sie lautet jetzt

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/FHEM/

Neue / geänderte Funktionen:


Events:

"RPC server restarting" - Der RPC-Server wird gerade neu gestartet.
"RPC server starting" - Der RPC-Server wird gerade gestartet.
"RPC server running" - Der RPC-Server wurde gestartet. Darauf könnte man mit einem "get update" reagieren, um einmalig alle Gerätestati zu aktualisieren.
"RPC server stopped" - Der RPC-Server wurde gestoppt.
"No events from CCU since 300 seconds" - In den letzten 5 Minuten gab es keine Updates von den CCU. Darauf könnte man mit einem "set restartrpc" reagieren, da evtl. die CCU neu gestartet wurde und deshalb keine Events mehr geschickt werden.
"nn devices deleted in CCU" - In der CCU wurden nn Geräte gelöscht. Darauf könnte man mit einem "get devicelist" reagieren.
"nn devices added in CCU" - In der CCU wurden nn Geräte angelernt. Reaktion wie oben (get devicelist).

Vorgehensweise für das Update:


Abkündigung:

Das Attribut ccustate wird in einer der nächsten Versionen wegfallen. Ebenso die dazu gehörende Funktion HMCCU_State(). Durch die Umbenennung der Readingnames in FHEM konforme Namen sind diese Funktionen nicht mehr notwendig. Falls jemand Einwände hat, bitte melden.


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 02 März 2016, 18:31:06
Neue Version der Module im Contrib Pfad eingecheckt. Eigentlich sollte ab dieser Version der FHEM Update-Mechanismus unterstützt werden. Leider habe ich übersehen, dass der beim contrib Verzeichnis nicht greift. Werde daher demnächst auf Github umziehen. Bis dahin bitte weiter den Download Link aus dem 1. Beitrag verwenden.

Zunächst ein wichtiger Hinweis: EQ3 hat eine neue CCU-Firmware mit Homematic IP Unterstützung veröffentlicht. Leider hatte ich noch keine Zeit, die zu testen. Aufgrund der Vielzahl von Änderungen (auch bei der RPC Schnittstelle) könnte es zu Problemen im Zusammenspiel mit HMCCU kommen. Im Zweifel also bitte mit dem CCU Update noch ein paar Tage warten.
Wenn möglich wird die nächste Version von HMCCU Homematic IP unterstützen!


Nun zu den Neuerungen:


Beispiel für ein CCU Gruppendevice bestehend aus einem Wand- und einem Heizkörperthermostaten:

# G-AZ-HZ=Gruppenname in CCU.
# KL-AZ-HZ=CCU-Name Heizkörperthermostat
# KL-AZ-TH=CCU-Name Wandthermostat.
# Explizite Angabe der echten CCU Geräte mit group= notwendig! Alternativ kann mit groupexp= ein
# regulärere Ausdruck für die CCU Gerätenamen angegeben werden
define HM_G_AZ_HZ HMCCUDEV G-AZ-HZ group=KL-AZ-HZ,KL-AZ-TH

# Nur einige Datenpunkte als Readings speichern. ccureadingfilter erlaubt jetzt die Angabe von CCU Channel names
attr HM_G_AZ_HZ ccureadingfilter G-AZ-HZ:1!(CONTROL_MODE|SET_TEMPERATURE),^KL-AZ!(^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT$|^VALVE|^CONTROL)

# Nach Setzen der Zieltemperatur Wert per Abfrage verifizieren
attr HM_G_AZ_HZ ccuverify 1

# Steuerung der Zieltemperatur per Slider Widget ermöglichen
attr HM_G_AZ_HZ controldatapoint 1.SET_TEMPERATURE
attr HM_G_AZ_HZ webCmd control
attr HM_G_AZ_HZ widgetOverride control:slider,10,1,25

# Datenpunkte der echten Geräte auf die Datenpunkte der Gruppe mappen
attr HM_G_AZ_HZ mapdatapoints KL-AZ-TH:2.SET_TEMPERATURE=G-AZ-HZ:1.SET_TEMPERATURE,KL-AZ-TH:2.CONTROL_MODE=G-AZ-HZ:1.CONTROL_MODE

# Für den Befehl get devstate
attr HM_G_AZ_HZ statechannel 1
attr HM_G_AZ_HZ statedatapoint SET_TEMPERATURE

# Bei Zahlen 1 Stelle hinter dem Komma als Reading speichern
attr HM_G_AZ_HZ stripnumber 1

# Werte aus CCU in Readings ersetzen
attr HM_G_AZ_HZ substitute LOWBAT!(0|false):no,(1|true):yes;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST

# Userreadings
# Funktion HMCCU_Dewpoint() berechnet den Taupunkt aus Temperatur und Luftfeuchte
# Funktion HMCCU_AggReadings() aggregiert die Werte identischer Datenpunkte. Hier werden alle LOWBAT Datenpunkte
# der echten Geräte UND verknüpft. Wenn alle "no" sind, ist das Ergebnis auch "no". Wenn mindestens einer "yes" ist,
# ist das Ergebnis "yes".
attr HM_G_AZ_HZ userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}, LOWBAT_STATE:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","cnt","yes","")}

Virtuelle Devices ohne Gegenstück in der CCU (ohne CCU Gerätegruppe) definieren:

define myvirtdev HMCCUDEV virtual group=Dev[,...]
define myvirtdev HMCCUDEV virtual groupex=DevExp

Virtuelle Devices sind immer read only.

BTW: So ein Gruppen-Device "schmiegt" sich sehr harmonisch in ein FHEM Tablet UI Thermostat Widget ein (das war der Hauptgrund, dass ich das implementiert habe):

      <div data-type="thermostat" data-device="HM_G_AZ_HZ"
        data-get="G-AZ-HZ.1.SET_TEMPERATURE"
        data-set="datapoint 1.SET_TEMPERATURE"
        data-valve="KL-AZ-HZ.4.VALVE_STATE"
        data-unit="%B0"
        class="large">
      </div>
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: dferch am 02 März 2016, 21:29:07
Hi Zap,

vielen Dank für die neuen Funktionen im Modul. Hab auch virtuelle Gruppen in Benutzung und fange gerade mit TabletUI an. Probiere die neuen Funktionen am Wochenende mal aus.

Viele Grüße,
David
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 März 2016, 17:45:54
So, nach einem schweißtreibenden Update meiner CCU auf 2.17.14 (Homematic IP Unterstützung) hier einige Infos zum Thema bzw. HM-IP:


Die 2.17.14 Firmware ist m.E. übles Gefrickel. Ich habe das Update nach der empfohlenen Methode durchgeführt, d.h. Backup, dann Factory Reset, dann 2.17.14 einspielen, dann Restore. Läuft alles, Performance ist ok. Allerdings werden immer wieder Fehler ins Log geschrieben. Ich habe eine simple IP Steckdose angelernt (HMIP-PS). Sollte von 2.17.14 unterstützt werden. Bedienung ist zwar möglich, allerdings wird im WebUI die Steckdose als "unbekanntes Gerät vom Typ DEVICE" dargestellt.

Ich denke, wer nicht unbedingt HM-IP benötigt, sollte mit dem Update noch warten. Ich werde es drauf lassen. Brauche schließlich was zum Entwickeln.

P.S. Habe durch die HM-IP Testerei endlich den Grund gefunden, warum der RPC Server nach dem Starten 3 Minuten Bedenkzeit benötigt, bis er seine Arbeit aufnimmt. Was soll ich sagen: der Grund war eher vor dem Bildschirm zu suchen. Zu meiner Verteidigung kann ich nur vorbringen, dass die Doku an dieser Stelle unscharf (oder beschissen) ist. Wie auch immer: Vor dem HM-IP Release wird es noch ein Update für den RPC-Server geben, damit wenigstens das mal richtig funktioniert.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 11 März 2016, 17:59:43
Hast Du nun 2.17.4 oder 2.17.14 drauf? Das ist ein himmelweiter Unterschied!

RPC-Server: system.multicall? Oder was war das Problem?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 März 2016, 18:27:42
Hast Du nun 2.17.4 oder 2.17.14 drauf? Das ist ein himmelweiter Unterschied!

RPC-Server: system.multicall? Oder was war das Problem?

2.17.14, habe gerade meinen vorherigen Beitrag korrigiert.

Nein, Multicall war nicht das Problem. Das wird von RPC::XML::Server unterstützt. Das Problem ist das Handshaking, also der Verbindungsaufbau mit der CCU. Ich hatte das Init als Request losgeschickt. Und dann hat es 3 Minuten gedauert, bis dieser Request zurückkam. Danach habe ich den Server-Loop gestartet, um CCU Events entgegen zu nehmen.
Der Denkfehler: Der Init-Request ist deshalb nicht gleich zurückgekehrt, weil die CCU während der Initialisierung eine Anfrage an dem RPC-Server schickt. Zu dem Zeitpunkt lief aber auf HMCCU Seite noch nix. Daher hat die CCU 3 Minuten auf eine Antwort gewartet. Dann hat ein Timeout zugeschlagen und der Init-Call kam zurück.
Jetzt mache ich es anders. Der RPC Server wird gestartet. Dann wird erst der Init-Request an die CCU geschickt. Jetzt klappt Init und auch Stop ohne Verzögerung.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: jojojo am 12 März 2016, 21:16:05
Ich habe Probleme mit dem RPC-Server.

Wenn ich ihn über attr d_ccu rpcserver on starte,
wird die Verbindung zur CCU korrekt initialisert.
Aber nach exakt einer Minute erscheint im FHEM-Log, das der Server wieder gestoppt wurde.

z.B.
2016.03.12 21:06:59 0: HMCCU: RPC server started with pid 29873
2016.03.12 21:07:59 0: HMCCU: All RPC servers stopped

In Wirklichkeit läuft der RPC-Server aber weiter, und empfängt auch weiter Daten von der CCU,
die nach ccuqueue_2001.dat geschrieben werden.
Nur FHEM bekommt da nichts von mit, weil es davon ausgeht, das der RPC-Server nicht läuft.
Irgendeine Idee, an welcher Stelle ich den Fehler suchen muss?

Danke und Gruß
Jürgen
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: jojojo am 12 März 2016, 22:34:23
Ok, habe das Problem gefunden.
Es ist die Funktion HMCCU_CheckProcess in 88_HMCCU.pm
Dort wird mit "ps -ef" die Prozessliste ermittelt.

Ich habe aber FHEM in einer Jail unter freeBSD laufen,
dort liefert ps -ef was anderes als unter Linux.
Deswegen findet FHEM die ProzessID nicht.

Nach anpassen der Funktion läuft es.

Viele Grüße
Jürgen
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 13 März 2016, 09:53:04
Hallo,
bitte poste hier mal Deine Änderungen. Ich wollte heute sowieso eine neue Version einchecken, die das Starten des RPC-Servers optimiert (3 Minuten Pause entfällt). Da kann ich das einbauen.

Bin auch nicht sehr glücklich mit der ps -ef Lösung. Momentan wird nur Debian und MacOS berücksichtigt.

Ich prüfe derzeit die Umstellung auf Proc::Processtable. Hat eben den Nachteil, dass ein weiteres Perl Modul installiert werden muss. Dafür ist das dann Plattform unabhängig.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: jojojo am 13 März 2016, 11:01:44
Hier die Änderungen.

sub HMCCU_CheckProcess ($$)
{
        my ($hash, $port) = @_;
        my $name = $hash->{NAME};

        my $modpath = AttrVal ('global', 'modpath', '/usr/local/fhem');
        my $rpcserver = $modpath."/FHEM/ccurpcd.pl";

### ps -a
        my $pdump = `ps -a | grep $rpcserver | grep -v grep`;       
        my @plist = split "\n", $pdump;

        foreach my $proc (@plist) {
                # Remove leading blanks, fix for MacOS. Thanks to mcdeck
                $proc =~ s/^\s+//;
                my @procattr = split /\s+/, $proc;

### Indizes anpassen
               return $procattr[0] if ($procattr[0] != $$ && $procattr[4] =~ /perl$/ &&
                   $procattr[5] eq $rpcserver && $procattr[7] eq "$port");
        }

        return 0;
}

Ich muss aber dazu sagen, ich bin kein freeBSD-Experte.
Auf der Maschine bin ich auch nur Gast mit meiner jail :)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 13 März 2016, 18:43:27
Eine neue Version von HMCCU steht ab sofort im contrib Verzeichnis (Link siehe erster Beitrag).

Fehlerbehebung:


Die neue Version ist kompatibel mit der aktuellen CCU2 Firmware 2.17.14. Homematic-IP wird allerdings noch nicht unterstützt. Hier bitte ich noch um ein paar Tage Geduld. Ich kann aber jetzt schon sagen, dass HMCCU Homematic-IP unterstützen und damit diesen Gerätezweig für FHEM erschließen wird.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: jojojo am 13 März 2016, 19:21:33
Ja, was soll ich sagen. Funktioniert  :)

An der Stelle auch nochmal ein dickes Danke für das Modul.

Viele Grüße
Jürgen
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 16 März 2016, 19:25:48
Ich habe gerade die Version 3.0 eingecheckt. Diese Version unterstützt nun Homematic IP.

Voraussetzung (nur bei Verwendung von Homematic IP): CCU2 Firmware 2.17.15

Die Get/Set Befehle unterstützen HM-IP Geräte. Damit auch Updates/Events von HM-IP Geräten automatisch an FHEM geschickt werden, muss ein zweiter RPC-Server konfiguriert werden. Dies erfolgt mit dem Befehl attr rpcport. Mit diesem Attribut wird eine Liste der Interfaces festgelegt, die HMCCU unterstützen soll:
Beispiel: RPC-Server für BidCos-RF und HMIP-RF konfigurieren:

attr my_ccu rpcport 2001,2010

Nach der Konfiguration die RPC-Server mit attr rpcserver on starten. HMCCU startet für jeden rpcport automatisch einen Prozess.

Weitere Neuerungen in dieser Version:
Für die Installation der CCU Firmware 2.17.15 geht man am besten wie folgt vor:
Wenn CUxD installiert werden soll, muss es unbedingt die Version 1.5.1 sein!

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 22 März 2016, 11:31:54
Hallo zap,

bekommst Du über die XML-RPC-Schnittstelle der CCU eine HMIP-Steckdose geschaltet?

Ich kann mit dem HMRPC-Modul machen was ich will, ich bekomme immer ein -5 (Invalid parameter or value). Der Aufruf ist korrekt, im Log der CCU steht nix besonderes, eine Dubug von einem CCU-internen Schaltvorgang bestätigt mir, dass die Syntax richtig ist.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 März 2016, 12:14:45
In HMCCU wird XML-RPC nur für das Setzen/Lesen von Geräteparametern verwendet. Alles andere läuft über Homematic Script. Damit funktioniert das Ein-/Ausschalten von HM-IP Steckdosen einwandfrei. Der RPC-Server liefert dann den neuen Status zurück.

Ich teste mal heute abend, ob ich per RPC Parameter der Steckdose lesen bzw. verändern kann. Getestet habe ich das bei HM-IP noch nicht (shame on me).

Würde mich aber nicht wundern, wenn EQ-3 hier noch ein gewisses Defizit hätte ;-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 März 2016, 18:51:29
Hallo zap,

bekommst Du über die XML-RPC-Schnittstelle der CCU eine HMIP-Steckdose geschaltet?

Ich kann mit dem HMRPC-Modul machen was ich will, ich bekomme immer ein -5 (Invalid parameter or value). Der Aufruf ist korrekt, im Log der CCU steht nix besonderes, eine Dubug von einem CCU-internen Schaltvorgang bestätigt mir, dass die Syntax richtig ist.

So, gerade getestet. Das Setzen eines MASTER Parameters der Steckdose Typ HMIP-PS (z.B. LONG_PRESS_TIME=0.5) funktioniert bei mir ohne Code Änderung. Ich gehe davon aus, dass dann auch das Setzen eines VALUES funktioniert. Aber wie gesagt, das kann ich nicht testen, da ich dafür Homematic Script verwende.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 22 März 2016, 20:15:40
Problem gefunden und gelöst.

Der XML-RPC-Server für HMIP ist etwas zickiger weniger tolerant als für Standard-Homematic.

Will sagen: nach wie vor kann auf der Standard-Homematic-Schnittstelle ein setValue oder ein putParamset für eine Variable, deren Typ Boolean ist, der XML-Request ohne große Verrenkungen gesendet werden. Im Standard-XML-Request ist zwar der Variablen-Typ mit String angegeben, das interessiert die Schnittstelle aber nicht. Auf der HMIP-Schnittstelle sieht das hingegen anders aus. Hier möchte die Schnittstelle im XML-Request tatsächlich auch den Variablen-Typ Boolean definiert haben. Das gleiche gilt auch für die Float und die Integer.

Siehe auch https://forum.fhem.de/index.php/topic,41060.msg429362.html#msg429362 .
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 März 2016, 19:57:04
Hallo Zusammen,

ich habe gerade mal wieder mein FHEM sowie die HMCCU files geupdated und nun sehe ich dass die get- und set-Befehle aus dem CCU-device HMCCU entfernt wurden.
Auch der RPCState bleibt im Status "starting".
Hat jemand eine Idee?
Die CCU2 hat noch die Firmware 2.15.5.

Vielen Dank

Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 März 2016, 20:26:13
Okay, wenn ich die Portangabe weglase und die Definition nur so lautet, kann ich wieder get und set ausführen.
define CCU2 HMCCU 192.168.178.42
attr CCU2 rpcserver on
Allerdings bekommt der RPC Server immer nach starting den Status stopped.
Ein anschließendes get CCU2 devicelist dump liefert aber dennoch ca. 190 Ergebnisse.

VG, Thomas.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 März 2016, 21:24:13
Solange der RPC Server startet, stoppt oder neu startet, werden die Set und Get Befehle deaktiviert. Da. Wenn in diesem Zustand trotzdem per Eingabefeld ein Befehl abgsetzt wird, wird er ignoriert und STATE des IO Devices geht auf "busy". Das habe ich eingebaut, da CCU Zugriffe während der o.g. Phasen sehr unzuverlässig sind. Allerdings sollte in der aktuellen Version das Starten nur noch 10 Sekunden dauern.

Bitte schau Dir mal das FHEM Logfile sowie das Logfile des RPC Servers an (ccurpc*log) und poste evtl. Fehlermeldungen. Der RPC Server wird offensichtlich nicht richtig gestartet.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 23 März 2016, 21:33:57
Hi Zap,

anbei das FHEM-Log:

2016.03.23 21:06:25 0: HMCCU: RPC server started with pid 1577
2016.03.23 21:06:25 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001
2016.03.23 21:06:25 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
...
2016.03.23 21:06:35 2: HMCCU: Can't open file queue /tmp/ccuqueue_2001
2016.03.23 21:06:35 0: HMCCU: All RPC servers stopped
2016.03.23 21:06:59 0: Server shutdown
2016.03.23 21:06:59 1: HMCCU: Deregistering RPC server http://192.168.178.58:7401/fh2001
2016.03.23 21:06:59 0: HMCCU: RPC server not running

Es gibt aber 2 Dateien /tmp - Verzeichnis - beide Dateien auch mit aktuellem Änderungs-Timestamp.
ccuqueue_2001.dat
ccuqueue_2001.idx

Logfile des RPC-Servers:

23.03.2016 14:18:27 Creating file queue
23.03.2016 15:05:43 Creating file queue
23.03.2016 15:11:10 Creating file queue
23.03.2016 15:21:16 Creating file queue
23.03.2016 15:26:39 Creating file queue
23.03.2016 15:33:51 Creating file queue
23.03.2016 15:55:14 Creating file queue
23.03.2016 20:04:40 Creating file queue
23.03.2016 20:18:39 Creating file queue
23.03.2016 20:20:07 Creating file queue
23.03.2016 21:06:25 Creating file queue

Ich hoffe, du kannst damit mehr anfangen als ich...? ;)

LG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mAr86sEb05 am 23 März 2016, 22:30:13
ich kann dir bestimmt helfen, da ich das gleiche Problem hatte. Schau mal bitte nach welche Rechte die Dateien ccuqueue_2001.dat ccuqueue_2001.idx haben
--w---x--T 1 fhem dialout 0 Mär 22 13:06 /tmp/ccuqueue_2001.dat
--w---x--T 1 fhem dialout 1 Mär 22 13:06 /tmp/ccuqueue_2001.idx
so sahen meine aus

richtig
-rw-r--r-- 1 fhem dialout 0 Mar 22 17:09 /tmp/ccuqueue_2001.dat
-rw-r--r-- 1 fhem dialout 1 Mar 22 17:09 /tmp/ccuqueue_2001.idx

Lösung
chmod 744 /tmp/ccu*

update :

da diese Dateien bei dir auch warscheinlich im tmp ordner liegen und bei einen Geräteneustart gelöscht werden empfiehlt es sich den chmod Befehl in rc.local zu schreiben
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 23 März 2016, 23:58:26
Hallo,

ich habe eine CCU2 mit verschiedenen Aktoren und Sensoren im Einsatz.
Jetzt versuche ich gerade, einen Heizkörperthermostat in Fhem mit HMCCU (auf einem Raspberry Pi) einzurichten:

define CCU2 HMCCU homematic.fritz.box
attr CCU2 ccureadings 1
attr CCU2 group Zentrale
attr CCU2 room HomeMatic
attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue
attr CCU2 rpcserver on

define HKT_Arbeitszimmer HMCCUDEV HM-CC-RT-DN_xxxxxxxxxx 4
attr HKT_Arbeitszimmer IODev CCU2
attr HKT_Arbeitszimmer controldatapoint HM-CC-RT-DN_xxxxxxxxxx.SET_TEMPERATURE
attr HKT_Arbeitszimmer group Arbeitszimmer
attr HKT_Arbeitszimmer room HomeMatic
attr HKT_Arbeitszimmer statechannel 4
attr HKT_Arbeitszimmer statedatapoint ACTUAL_TEMPERATURE
attr HKT_Arbeitszimmer webCmd control
attr HKT_Arbeitszimmer widgetOverride control:slider,10,1,25

Ich wollte damit gerne den aktuellen Temperaturwert angezeigt bekommen und gleichzeitig den Sollwert für die Temperatur einstellen können. (Den Code habe ich in der HMCCU_README.txt grfunden.)

Die Installation hat soweit funktioniert, die Readings werden angezeigt. Aber die Tempetratur läßt sich nicht ändern.

Die Anzeige sieht so aus:

Arbeitszimmer
HKT_Arbeitszimmer 19.600000 control

Zentrale
CCU2 OK

Wenn ich nun control drücke, erscheint folgende Meldung:

HMCCUDEV: CCU busy

Hat vielleicht einer eine Idee, was ich falsch mache?

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 07:27:54
@cho: Versuch mal das (ich glaube, bei einem Heizkörperthermostat ist der Datenpunkt SET_TEMPERATURE in Kanal 4, ansonsten korrigieren):

attr HKT_Arbeitszimmer controldatapoint 4.SET_TEMPERATURE

Das Attribut controldatapoint erwartet folgende Syntax: Kanalnummer.Datenpunkt (also nicht Kanal.Datenpunkt, Kanal würde ja auf Kanaladresse:Kanalnummer verweisen).

@ALL (insbesondere cho, mAr86sEb05, ToM_ToM):

Mit der Version 3.0 habe ich die Filequeue Funktionen in HMCCU integriert, um die Abhängigkeit von RPCQueue los zu werden. Dabei scheint mir ein Fehler unterlaufen zu sein, der sich nur bemerkbar macht, wenn die Queue-Dateien in /tmp neu angelegt werden. Ich muss das allerdings heute Abend nochmal bei mit nachvollziehen. Ob Ihr betroffen seid, könnt Ihr wie von mAr86sEb05 oben beschrieben prüfen.

Hintergrund: Wenn die Queue-Dateien in /tmp bei Euch nicht "rw" für den User fhem gesetzt haben, wird der RPC-Server nicht korrekt gestartet bzw. HMCCU bekommt nicht mit, dass er gestartet wurde, da es keinen Zugriff auf die Queue hat. In diesem Fall wartet HMCCU endlos auf einen Event "IN|INIT". Da beim Starten des RPC-Servers alle Set/Get Befehle deaktiviert werden, kommt es zu der Meldung "CCU busy".

Sorry dafür. Ich hoffe, ich kann heute Abend einen Fix bereit stellen.

Temporärer Workaround:
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 24 März 2016, 09:37:22
Hallo zap,
vielen Dank für die schnelle Antwort!

Für das Problem mit der ccuqueue Datei hatte ich schon folgenden Workaround gefunden:
- neues Verzeichnis /opt/fhem/tmp anlegen und hier .dat/.idx manuell mit rw Rechten versehen
- in Fhem mit "attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue" bekannt geben
- damit gibt es dann auch keine Probleme beim Reboot

ps ax | grep ccurpc findet entsprechend:
4251  ?  S  1:34  /usr/bin/perl ./FHEM/ccurpcd.pl homematic.fritz.box 2001 /opt/fhem/tmp/ccuqueue_2001 ./log/ccurpcd_2001.log

Das ccurpcd_2001.log sieht so aus:
24.03.2016 09:31:17 RPC server terminated
24.03.2016 09:31:49 Creating file queue
24.03.2016 09:31:49 Initializing RPC server
24.03.2016 09:31:49 Callback server created listening on port 7401
24.03.2016 09:31:49 Adding callback for events
24.03.2016 09:31:49 Adding callback for new devices
24.03.2016 09:31:49 Adding callback for deleted devices
24.03.2016 09:31:49 Adding callback for modified devices
24.03.2016 09:31:49 Adding callback for replaced devices
24.03.2016 09:31:49 Adding callback for readded devices
24.03.2016 09:31:49 Entering server loop. Use kill -SIGINT 712 to terminate program

Das fhem-2016-03.log ist sauber ohne Fehlermeldung.
Den controldatapoint habe ich wie angegeben geändert.
Aber ich bekomme nach wie vor die Meldung CCU busy.
Ich warte jetzt erst einmal auf Deinen Fix.

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mAr86sEb05 am 24 März 2016, 10:34:20
ich habe die Dateien in einer Ramdisk tmpfs da ich eine SSD als Festplatte habe und bei jedem Statuswechsel werden die Dateien neu geschrieben bzw gelesen und aus der Ramdisk fliegen sie nach jeden Neustart des Servers raus
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 10:48:13

Das fhem-2016-03.log ist sauber ohne Fehlermeldung.
Den controldatapoint habe ich wie angegeben geändert.
Aber ich bekomme nach wie vor die Meldung CCU busy.
Ich warte jetzt erst einmal auf Deinen Fix.

Viele Grüße
Christian

Bitte schau nochmal, ob im fhem log beim Starten des RPC-Servers irgendwelche Meldungen von HMCCU auftauchen. Insbesondere ""HMCCU: Received IN event. RPC server initialized."

Kannst Du nur den Control Befehl nicht ausführen? Was wird im HMCCU Device im Internal RPCState angezeigt ("starting", "running", ...) ?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 11:02:37
Hallo mAr86sEb05, hallo zap,

vielen Dank für eure Antworten.
Ich habe das jetzt mal so gemacht wie aufgeführt.
Der eintrag in der rc.local greift nach dem Neustart nicht da der Inahlt des tmp - Verzeichnis ja beim Neustart gelöscht wird.
Nach dem Starten des RPC Servers werden die Dateien mit falschen CHMOD angelegt. Ich korrigiere die dann sofort und der RPC-Server bleibt nun nicht mehr im Status "Starting" hängen sondern geht nach einigen Sekunden in den Status "Stopped".

@zap: Du schreibst hier was von FHEM-User... Bei mir läuft alles als root, um diverse Probleme zu umgehen. Ich hoffe, das stellt hier kein Problem da...?

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mAr86sEb05 am 24 März 2016, 11:16:30
aber der fhem service (etc/init.d/fhem) sollte da schon ausgeführt worden sein, zumindest ist das bei mir so
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 15:01:38
Okay, also bei mir läuft der RPC-Server nun endlich nachdem ich den Owner der 2 Dateien im /tmp-Verzeichnis von fhem auf root geändert habe.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 24 März 2016, 15:07:40
Hallo zap,

die Frage nach dem RPCState hat mich auf die richtige Spur gebracht:

Nach dem OS Reboot bleibt er im Status Starting hängen. In den Logfiles finden sich aber keine Einträge dazu.
Mit rpcserver=off und rpcserver=on kann ich ihn dann manuell starten. Und damit funktioniert auch das Einstellen der Temperatur wie gewünscht.
Nur nach dem nächsten OS Reboot startet er (auch nach längerer Zeit) nicht automatisch.

Die Frage wäre jetzt also, was muss ich für das automatische Starten beim Reboot konfigurieren?

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 15:39:58
Ich wollte jetzt mein Thermostat anbinden. Die Readings zeigen mir auch sämtliche Werte korrekt an.

Aber wenn ich

get HM_KU_Thermostat deviceinfo
ausführe, bekomme ich die Fehlermeldung:
HMCCUDEV: HM_KU_Thermostat Execution of CCU script or command failed

Woran kann das liegen? Wird das vielleicht auch mit Version 3 behoben sein? :)

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 16:02:38
Zunächst die gute Nachricht für Euch (weniger gut für mich, weil es Arbeit bedeutet ;-). Ich kann das Rechteproblem bei den Queue-Files bei mir nachvollziehen. Habe es nicht bemerkt, da mein Raspi seit ca. 6 Monaten nicht mehr neu gestartet wurde und daher auch die Dateien nicht neu angelegt wurden. Lösung ist in Arbeit.

Ich behebe jetzt erst mal das Problem. Dann schauen wir mal, ob die anderen Effekte immer noch auftreten.

@ToM_ToM: schick mir bitte mal die Ausgabe von "list HM_KU_Thermostat" und das gleiche nochmal für "list <hmccu_device>". Gerne auch per Forum Mail.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 16:11:36
Hey zap, habe dir eine Forum-Mail gesendet.

list HM_KU_Thermostat" und "list <hmccu_device>...?

Also das Zweite ist doch im Prinzip nur die Syntax des Ersten.

Oder wolltest du es für die CCU?
Falls ja, habe ich es vorsichtshalber mitgesendet. ;)

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 17:46:07
Danke, passt so. Problem gefunden. Du hast Post.

Umlaute in CCU Gerätenamen sind keine gute Idee ;-)

Anderer Fehler ist auch gefunden. Update checke ich demnächst ein.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 18:02:48
Ich habe gerade einen Bugfix für 88_HMCCU.pm eingecheckt. Der Fix behebt einen Fehler, der das Starten des RPC-Servers verhindert hat. Die Berechtigungen für die Queue-Files wurden falsch gesetzt.

Es genügt, die Datei 88_HMCCU.pm zu installieren.

Danach am besten FHEM anhalten, die alten Queue-Files löschen (normalerweise /tmp/ccuqueue*) und dann FHEM wieder starten. Vorher mit "ps ax | grep ccurpc" noch prüfen, dass kein alter RPC server mehr läuft.

Sorry nochmal für die Probleme. Was für ein blöder Fehler  :'(

@cho: Bitte mal testen, ob Deine RPC Startprobleme damit behoben sind.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 24 März 2016, 18:56:53
Hallo zap,

Danke für den Fix. Das Problem mit der ccuqueue ist jetzt bei mir behoben.
Aber der automatische Start des RPC Servers funktioniert noch nicht.

Mir ist aber noch etwas dazu eingefallen: Ich habe einen Raspberry Pi 3 laufen.
Beim Installieren von Fhem musste ich in der /etc/init.d/fhem vor dem Starten von Fhem ein sleep 10 einfügen. Ansonsten lief Fhem in alle möglichen Fehler.

Kann es sein, dass der Pi 3 "zu schnell" ist, und deshalb der Autostart des RPC Servers nicht funktioniert?
Das spätere manuelle Starten macht ja keine Probleme.

Kann ich zum Testen irgendwo irgendwie in Deinem Modul eine zusätzliche Verzögerung einfügen?

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 24 März 2016, 19:01:04
Sieh Dir mal die /etc/init.d/fhem an. Dort solltest Du in der Zeile

# Required-Start:       $local_fs $remote_fs

noch ein $network anfügen, so dass im Endeffekt

# Required-Start:       $local_fs $remote_fs $network

da steht.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 24 März 2016, 20:05:15
Der Tipp mit dem $network hat funktioniert.
Danke dafür! Ich habe mein sleep 10 jetzt wieder gelöscht.

Aber das Problem mit dem RPC Server löst es nicht.
Im fhem log steht immer noch nicht "HMCCU: Received IN event. RPC server initialized."
Und im RPCState steht "starting".

Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 20:41:47
Hallo zap,

ich habe gerade das Update auf deine neue Datei gemacht.
Allerdings legt der die Dateien bei mir wieder mit CHMOD rw-r--r-- an und Owner ist wieder fhem.
Somit bleibt das der Prozess-State bei "Starting" hängen.

Ist es nicht möglich, die Dateien mit vollen Schreibrechten zu erstellen? Oder siehst du da ein Sicherheitsproblem?

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 20:43:26
@cho: Zu schnell kannst Du ausschließen. Läuft bei mir auch auf nem Core i7 iMac. Der ist schneller ;-) Tritt das problem nur auf, wenn Du den Raspi neu startest oder auch bei einem Start von FHEM aus bereits laufendem Linux heraus?

Ich denke, wir müssen das in Deinem Fall systematisch angehen:

Setze zunächst mal in HMCCU das Attribut rpcserver auf off und speichere die fhem Konfiguration hab.
Dann stoppe FHEM.
Dann prüfen, ob noch ein RPC Server läuft: ps ax | grep ccurpcd
Falls noch ein Prozess läuft manuell stoppen: kill -SIGINT processid
Nun FHEM starten
Prüfen, was im HMCCU Device im Internal DevCount angezeigt wird. Muss grösser 0 sein
Prüfen, dass das Internal RPC State "stopped" anzeigt und RPCPID 0
Das Attribut verbose auf 2 setzen
Mit Attribut rpcserver on den RPC Server starten
Nach 10-11 Sekunden die Ansicht aktualisieren. Die Set und Get Befehle sollten wieder angezeigt werden und in RPCPID die ProzessID stehen. rPCstate muss "running" zeigen

Fallls das nichts bringt, schicke mit die Ausgabe von "list <hmccudev>" sowie die Ausgabe von folgendem Unix Befehl:

grep "HMCCU" <fhemlogfile> | tail -100

Sowie das ccurpcd_*log File.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 20:48:43

Ist es nicht möglich, die Dateien mit vollen Schreibrechten zu erstellen? Oder siehst du da ein Sicherheitsproblem?

VG, Thomas

Lässt sich schon machen, wenn Du Dich bis morgen gedulden kannst. Allerdings verstehe ich es nicht: wenn die Datei den Owner fhem bekommt, müsste eigentlich auch Dein FHEM mit diesem User laufen. Du hast aber glaube ich vorhin mal geschrieben, dass es mit root läuft. Dann müsste aber das Schreiben erst recht funktionieren.

Aber wie gesagt: ich ändere die Flags.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 21:06:55
Hi zap,

ich habe mein FHEM jetzt soweit umgestellt dass es durch einen User namens fhem gestartet wird.

- dann System neu gebootet mit rpcserver = off.
- anschließend attr rpcserver on gesetzt
Dateien im tmp Verzeichnis werden erzeugt und auch alle paar Sekunden aktualisiert,
RPCPID ist vorhanden aber RPCState bleibt weiterhin auf "Starting".

Clients :HMCCUDEV:HMCCUCHN:
DEF 192.168.178.42
DelDevices 0
DevCount 290
NAME CCU2
NR 34
NewDevices 0
RPCPID 1435
RPCPRC /opt/fhem/FHEM/ccurpcd.pl
RPCState starting
STATE OK
TYPE HMCCU
host 192.168.178.42
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mAr86sEb05 am 24 März 2016, 21:18:35
jetzt bekomme ich den Fehler im Log HMCCU: 500 Can't connect to 172.27.217.18:8181
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 21:20:35
@Thomas: Steht im fhem log folgende Meldung?

HMCCU: Received IN event. RPC server initialized."

Wenn ja, bist Du schon der zweite mit diesem Effekt

Werden die Readings der CCU Devices aktualisiert?

Die FHEM Anzeige hast Du mal aktualisiert?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 21:22:54
jetzt bekomme ich den Fehler im Log HMCCU: 500 Can't connect to 172.27.217.18:8181

Und die CCU läuft? Benutzt Du WLAN oder Ethernet?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 21:25:20
Hi zap,

nein das FHEM-LOG sieht gut aus.

2016.03.24 21:20:52 0: HMCCU: RPC server started with pid 1948
2016.03.24 21:20:52 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001
2016.03.24 21:20:52 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
2016.03.24 21:21:02 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:07 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:12 2: HMCCU: Received no events from CCU since 300 seconds

Und auch die Readings im Device alle paar Minuten aktualisiert.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: mAr86sEb05 am 24 März 2016, 21:29:11
hat sich erledigt hatte das $network in die init.d eingefügt es scheint das auch das Problem mit dem configfile: Invalid or unknown CCU device name or address
statefile: Please define BM_Ein first
weg ist
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 21:33:33
Hi zap,

nein das FHEM-LOG sieht gut aus.

2016.03.24 21:20:52 0: HMCCU: RPC server started with pid 1948
2016.03.24 21:20:52 1: HMCCU: Registering callback http://192.168.178.58:7401/fh2001 with ID CB2001
2016.03.24 21:20:52 1: HMCCU: RPC callback with URL http://192.168.178.58:7401/fh2001 initialized
2016.03.24 21:21:02 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:07 2: HMCCU: Received no events from CCU since 300 seconds
2016.03.24 21:21:12 2: HMCCU: Received no events from CCU since 300 seconds

Und auch die Readings im Device alle paar Minuten aktualisiert.

VG, Thomas

 Nein sieht leider nicht gut aus. Es feht das "received IN event. RPC server initialized

Bitte schick mal die letzten Zeilen aus dem ccurpcd_*log
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 21:48:32
hat sich erledigt hatte das $network in die init.d eingefügt es scheint das auch das Problem mit dem configfile: Invalid or unknown CCU device name or address
statefile: Please define BM_Ein first
weg ist

D.h. Bei Dir läuft jetzt alles, auch der RPC Server (RPCState "running"). Das wäre mal ein Lichtblick. Bei anderen Usern bleibt der Server auf "starting"

BTW: vergesst die Meldungen "Received no events from CCU ...". Das ist auch noch en Bug. Hat aber keine Auswirkungen. Ist einfach nur ne Falschmeldung
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 21:54:57
Habe jetzt mal die Firmware der CCU aktualisiert und alles nochmal von vorne gestartet.
Aber es bleibt weiterhin der Status bei "Starting"
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 22:05:38
Was steht in ccurpcd_2001.log ? Daraus kann man ersehen, ob die CCU überhaupt etwas schickt.

Und bitte daran denken: Nach dem Start des RPC Servers mindestens 10 Sek warten, dann die FHEM Ansicht aktualisieren.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 22:11:19
Hey, in der Log steht

24.03.2016 22:08:51 Creating file queue
24.03.2016 22:08:51 Initializing RPC server
24.03.2016 22:08:51 Callback server created listening on port 7401
24.03.2016 22:08:51 Adding callback for events
24.03.2016 22:08:51 Adding callback for new devices
24.03.2016 22:08:51 Adding callback for deleted devices
24.03.2016 22:08:51 Adding callback for modified devices
24.03.2016 22:08:51 Adding callback for replaced devices
24.03.2016 22:08:51 Adding callback for readded devices
24.03.2016 22:08:51 Entering server loop. Use kill -SIGINT 1478 to terminate program

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 22:17:09
Wie vermutet: die CCU schickt nichts. Das müsste am Ende so aussehen:

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

Mal ins Blaue geraten: wenn Du nicht das Attribut rpcport gesetzt hast, setze es mal bitte auf 2001.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 22:26:23
Hi zap,

richtig geraten. ;) Das Attribut hatte ich nicht gesetzt.
Habe den RPCServer gestoppt, Attribut gesetzt, RPCServer wieder gestartet, aber bleibt leider wieder im Status "Starting" hängen.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 März 2016, 22:33:00
Ok, dann muss ich morgen eine Version mit ein paar zusätzlichen log statements einchecken, damit der Startvorgang granularer dargestellt wird.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 24 März 2016, 22:51:47
Okay,

wenn ich dir noch behilflich sein kann, sag Bescheid. ;)

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 24 März 2016, 23:44:19
Tritt das problem nur auf, wenn Du den Raspi neu startest oder auch bei einem Start von FHEM aus bereits laufendem Linux heraus?

> ich habe bisher immer nur den Raspi - also Linux und Fhem - gebootet

Ich denke, wir müssen das in Deinem Fall systematisch angehen:

> für einen sauberen Start habe ich die log Files gelöscht und den Raspi rebootet

Setze zunächst mal in HMCCU das Attribut rpcserver auf off und speichere die fhem Konfiguration hab.
Dann stoppe FHEM.

> RPCState=stopped

Dann prüfen, ob noch ein RPC Server läuft: ps ax | grep ccurpcd
Falls noch ein Prozess läuft manuell stoppen: kill -SIGINT processid

> es wird nur noch der grep Prozeß selber angezeigt, kill nicht notwendig

Nun FHEM starten

> sudo /etc/init.d/fhem start

Prüfen, was im HMCCU Device im Internal DevCount angezeigt wird. Muss grösser 0 sein

> CCU2 DevCount=134

Prüfen, dass das Internal RPC State "stopped" anzeigt und RPCPID 0

> RPCstate=stopped und RPCPID=0

Das Attribut verbose auf 2 setzen
Mit Attribut rpcserver on den RPC Server starten
Nach 10-11 Sekunden die Ansicht aktualisieren. Die Set und Get Befehle sollten wieder angezeigt werden und in RPCPID die ProzessID stehen. rPCstate muss "running" zeigen

> RPCstate=running, RPCPID=947, Set und Get passt

Fallls das nichts bringt, schicke mit die Ausgabe von "list <hmccudev>" sowie die Ausgabe von folgendem Unix Befehl:

> siehe extra File

grep "HMCCU" /opt/fhem/log/fhem-2016-03.log | tail -100

> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1138, <$fh> line 52.
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1138, <$fh> line 52.
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2646, <$fh> line 52.
> Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2646, <$fh> line 52.
> 2016.03.24 23:09:04 0: HMCCU: RPC server started with pid 710
> 2016.03.24 23:09:04 1: HMCCU: Registering callback http://192.168.178.125:7401/fh2001 with ID CB2001
> 2016.03.24 23:09:04 1: HMCCU: RPC callback with URL http://192.168.178.125:7401/fh2001 initialized
> 2016.03.24 23:11:17 1: HMCCU: Deregistering RPC server http://192.168.178.125:7401/fh2001
> 2016.03.24 23:11:17 0: HMCCU: Stopping RPC server with PID 710
> 2016.03.24 23:11:20 0: HMCCU: All RPC servers stopped
> 2016.03.24 23:22:24 0: HMCCU: RPC server started with pid 947
> 2016.03.24 23:22:24 1: HMCCU: Registering callback http://192.168.178.125:7401/fh2001 with ID CB2001
> 2016.03.24 23:22:24 1: HMCCU: RPC callback with URL http://192.168.178.125:7401/fh2001 initialized
> 2016.03.24 23:22:34 0: HMCCU: Received IN event. RPC server initialized.

Sowie das ccurpcd_2001.log File.

> 24.03.2016 23:08:47 RPC server terminated
> 24.03.2016 23:09:04 Creating file queue
> 24.03.2016 23:09:04 Initializing RPC server
> 24.03.2016 23:09:17 Callback server created listening on port 7401
> 24.03.2016 23:09:17 Adding callback for events
> 24.03.2016 23:09:17 Adding callback for new devices
> 24.03.2016 23:09:17 Adding callback for deleted devices
> 24.03.2016 23:09:17 Adding callback for modified devices
> 24.03.2016 23:09:17 Adding callback for replaced devices
> 24.03.2016 23:09:17 Adding callback for readded devices
> 24.03.2016 23:09:17 Entering server loop. Use kill -SIGINT 710 to terminate program
> 24.03.2016 23:11:17 RPC server terminated
> 24.03.2016 23:22:23 Creating file queue
> 24.03.2016 23:22:23 Initializing RPC server
> 24.03.2016 23:22:23 Callback server created listening on port 7401
> 24.03.2016 23:22:23 Adding callback for events
> 24.03.2016 23:22:23 Adding callback for new devices
> 24.03.2016 23:22:23 Adding callback for deleted devices
> 24.03.2016 23:22:23 Adding callback for modified devices
> 24.03.2016 23:22:23 Adding callback for replaced devices
> 24.03.2016 23:22:23 Adding callback for readded devices
> 24.03.2016 23:22:23 Entering server loop. Use kill -SIGINT 947 to terminate program
> 24.03.2016 23:22:24 ListDevices
> 24.03.2016 23:22:25 NewDevice: received 114 device specifications
> 24.03.2016 23:29:24 Received 250 events from CCU since last check
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 10:28:38
@cho: sieht schon mal gut aus. D.h. wenn Du den RPC Server aus FHEM heraus startest läuft er und Readings werden regelmäßig aktualisiert (bitte melden, wenn ich das falsch interpretiert habe).

Nächster Test:

- Bitte die FHEM-Config mit rpcserver=on speichern. Dann FHEM beenden mit /etc/init.d/fhem stop.
- Prüfen, dass der RPC-Server nicht mehr läuft mit "ps ax | grep ccurpcd"
- FHEM starten: /etc/init.d/fhem start => RPC-Server muss mit gestartet werden
- FHEM Logfile und ccurpcd Logfile prüfen, ob es so aussieht wie bei Deinem manuellen Test

Wenn das auch funktioniert, hängt es mit dem Booten zusammen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 12:15:58
Hallo zap,

der RPC Server wird nicht mit gestartet (auch nach längerem warten nicht).
Entsprechend bleibt RPCstate auf starting stehen und in der fhem log fehlt der Eintrag:

0: HMCCU: Received IN event. RPC server initialized.

Das rpcccud log sieht jetzt so aus:

24.03.2016 23:22:23 Creating file queue
24.03.2016 23:22:23 Initializing RPC server
24.03.2016 23:22:23 Callback server created listening on port 7401
24.03.2016 23:22:23 Adding callback for events
24.03.2016 23:22:23 Adding callback for new devices
24.03.2016 23:22:23 Adding callback for deleted devices
24.03.2016 23:22:23 Adding callback for modified devices
24.03.2016 23:22:23 Adding callback for replaced devices
24.03.2016 23:22:23 Adding callback for readded devices
24.03.2016 23:22:23 Entering server loop. Use kill -SIGINT 947 to terminate program
24.03.2016 23:22:24 ListDevices
24.03.2016 23:22:25 NewDevice: received 114 device specifications
24.03.2016 23:29:24 Received 250 events from CCU since last check
25.03.2016 11:51:51 RPC server terminated
25.03.2016 11:52:51 Creating file queue
25.03.2016 11:52:51 Initializing RPC server
25.03.2016 11:52:51 Callback server created listening on port 7401
25.03.2016 11:52:51 Adding callback for events
25.03.2016 11:52:51 Adding callback for new devices
25.03.2016 11:52:51 Adding callback for deleted devices
25.03.2016 11:52:51 Adding callback for modified devices
25.03.2016 11:52:51 Adding callback for replaced devices
25.03.2016 11:52:51 Adding callback for readded devices
25.03.2016 11:52:51 Entering server loop. Use kill -SIGINT 5123 to terminate program
25.03.2016 11:59:32 Received 250 events from CCU since last check

Allerdings hat er dann aber doch etwas gelesen.
Denn in den Readings finde ich Zeilen mit dem Zeitstempel 2016-03-25 12:12:06

Viele Grüße
Christian

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 12:23:54
Hallo Cho, das ist das Gleiche wie bei mir auch. Hatte ich gestern hier gepostet.

zap arbeitet schon daran, herauszufinden woran das liegt.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 12:42:43
Hallo,

jetzt kapier ich gerade gar nichts mehr. Also wenn Ihr den RPC Server wie hier (https://forum.fhem.de/index.php/topic,40189.msg429646.html#msg429646) beschrieben manuell aus FHEM heraus startet: Funktioniert es dann oder nicht?

@cho: In Deinem vorletzten Post war die Meldung "HMCCU: Received IN event. RPC server initialized." doch drin

@ToM_ToM: Geht es bei Dir bei manuellem Start aus FHEM unter den im Link oben beschriebenen Voraussetzungen?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 12:54:40
Hallo zap,

habe es exakt so wie in dem Link beschrieben, durchgeführt. Und es geht leider auch damit nicht.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 13:07:32
Hallo zap,

bei mir startet der RPC Server nur manuell, also mit attr off und attr on.
Dabei ist es egal, ob ich vorher das OS reboote oder nur das Fhem.

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 13:17:21
Hallo zap,

bei mir startet der RPC Server nur manuell, also mit attr off und attr on.
Dabei ist es egal, ob ich vorher das OS reboote oder nur das Fhem.

Viele Grüße
Christian

Ok, dann gehe ich mal davon aus, dass Du und ToM_ToM unterschiedliche Probleme habt. In Deinem Fall könnte es sein, dass die Reihenfolge einiger Befehle in fhem.cfg falsch ist. Bitte führe mal folgenden Befehl aus:

egrep "(define|attr) xxxx" fhem.cfg

Wobei "xxxx" durch den Namen des HMCCU Device in FHEM zu ersetzen ist. Bei mir sieht das (nur als Beispiel) so aus:

define d_ccu HMCCU homematic
attr d_ccu ccureadingformat name
attr d_ccu ccureadings 0
attr d_ccu devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
attr d_ccu event-on-change-reading .*
attr d_ccu icon rc_HOME
attr d_ccu room Homematic
attr d_ccu rpcinterval 5
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on
attr d_ccu statevals on:true,off:false
attr d_ccu stripchar :
attr d_ccu stripnumber 1
attr d_ccu updatemode client
attr d_ccu verbose 2

Was mich dabei interessiert ist die Reihenfolge der Befehle.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 13:41:22
Bei mir sind das viel weniger Einträge:

define CCU2 HMCCU homematic.fritz.box
attr CCU2 ccureadings 1
attr CCU2 group Zentrale
attr CCU2 room 1 HomeMatic
attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 updatemode hmccu
attr CCU2 verbose 2
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 13:42:54
Hey cho,

übernimm mal die Konfiguration wie von zap.

Das hat bei mir dann funktioniert.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 14:05:29
Hi ToM_ToM,

vielen Dank für den Tipp, jetzt funktioniert es!

Hi zap,

ich habe Deine abweichenden Einstellungen einzeln getestet.
Erfolg hat dann der Eintrag "attr d_ccu rpcport 2001,2010" gebracht.
"attr d_ccu rpcport 2001" alleine hat nichts gebracht. Es liegt also am Port 2010.

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 14:07:50
Bei mir sind das viel weniger Einträge:

define CCU2 HMCCU homematic.fritz.box
attr CCU2 ccureadings 1
attr CCU2 group Zentrale
attr CCU2 room 1 HomeMatic
attr CCU2 rpcqueue /opt/fhem/tmp/ccuqueue
attr CCU2 rpcserver on
attr CCU2 updatemode hmccu
attr CCU2 verbose 2

Nicht alles von mir übernehmen. Aber setze mal folgende Attribute:

attr CCU2 rpcport 2001
attr CCU2 rpcinterval 5

Wenn Du den rpcport auf 2001,2010 setzt, werden 2 RPC-Server gestartet (1x Funk normal, 1x Homematic IP). Wenn Du kein Homematic IP hast, brauchst Du den 2010 nicht.
Ich würde Dir empfehlen, das Attribut updatemode auf "client" oder "both" zu setzen. Mit "hmccu" werden bei interaktiven Updates keine Client-Devices aktualisiert. Bei hmccu oder both könnten sehr viele Readings im HMCCU Device entstehen. Kannst Du nutzen, dann würde ich aber empfehlen, mit ccureadingfilter die Readings einzuschränken.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 14:18:28
ich habe Deine abweichenden Einstellungen einzeln getestet.
Erfolg hat dann der Eintrag "attr d_ccu rpcport 2001,2010" gebracht.
"attr d_ccu rpcport 2001" alleine hat nichts gebracht. Es liegt also am Port 2010.

Das ist krass! Schön, dass es läuft. Verstehe ich aber nicht. Aber zumindest weiß ich jetzt mal, wo ich suchen muss.

Hier mal eine Beschreibung, was die einzelnen Attribute bedeuten:

# Reading-Namen werden aus dem CCU Kanalnamen gebildet (Alternative "address")
attr d_ccu ccureadingformat name

# Speichere keine Readings im HMCCU Device (dafür gibt es die Client-Devices mit HMCCUDEV und HMCCUCHN)
attr d_ccu ccureadings 0

# Immer eine gute Idee, um FHEM etwas zu entlasten. Sollte man bei jedem HMCC* Device setzen
attr d_ccu event-on-change-reading .*

# Das Intervall, in dem die Queue mit den Statusinfos der CCU gelesen wird
attr d_ccu rpcinterval 5

# Die CCU-Ports (2001=BidCos-RF, 2000=BidCos-Wired, 2010=Homematic-IP)
attr d_ccu rpcport 2001,2010

# Ersetze bei Set-Befehlen on durch true und off durch false (CCU kann mit on/off nichts anfangen)
attr d_ccu statevals on:true,off:false

# Zahlenwerte in Readings nach der 1. Nachkommastelle abschneiden
attr d_ccu stripnumber 1

# Nur Readings der Client-Devices werden aktualisiert (sonst werden im HMCCU-Device sehr viele Readings auflaufen)
attr d_ccu updatemode client

Achtung! Viele der Attribute (statevals, stripnumber, ccureadingformat) müssen in den Client-Devices explizit nochmal gesetzt werden. Die Client-Devices "erben" keine Attribute vom HMCCU- bzw. IO-Device.

Das war ne schwere Geburt. So und jetzt suche ich den Fehler, zum Glück ist heute schlechtes Wetter ;-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 14:27:40
Hi zap,

vielen Dank noch einmal für Deine Unterstützung und investierte Zeit!!!

Ich habe übrigens nur BidCos-RF (also kein IP).

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 14:35:31
Vielleicht könnt Ihr mir noch einen Gefallen tun. Bitte prüft mal, wie viele RPC-Server laufen:

ps ax | grep ccurpc

oder in FHEM im HMCCU-Device mit "get nnnn rpcstate"

Falls Ihr SSH Zugriff auf Eure CCU habt, würd mich noch folgende Ausgabe auf der CCU interessieren:

netstat -an | grep LISTEN

Also ich habe bei mir jetzt mal testweise die Attribute rpcinterval und rpcport gelöscht. Es funktioniert bei mir trotzdem. Das wird immer seltsamer
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 14:51:10
na klar:

ps ax | grep ccurpc

> 713 ?        S      0:03 /usr/bin/perl ./FHEM/ccurpcd.pl homematic.fritz.box 2001 /opt/fhem/tmp ccuqueue_2001 ./log/ccurpcd_2001.log
> 718 ?        S      0:02 /usr/bin/perl ./FHEM/ccurpcd.pl homematic.fritz.box 2010 /opt/fhem/tmp/ccuqueue_2010 ./log/ccurpcd_2010.log
> 1326 pts/0    S+     0:00 grep --color=auto ccurpc


oder in FHEM im HMCCU-Device mit "get nnnn rpcstate"

> RPC process(es) running with pid(s) 713,718

Falls Ihr SSH Zugriff auf Eure CCU habt, würd mich noch folgende Ausgabe auf der CCU interessieren:

netstat -an | grep LISTEN

> tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
> tcp        0      0 0.0.0.0:7410            0.0.0.0:*               LISTEN     
> tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN     
> tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
> tcp6       0      0 :::22                   :::*                    LISTEN     

Dafür hätte ich aber auch noch eine Frage:
Ist es möglich, beim dem HMCCU Device in der Übersicht anstelle dem STATE OK den RPCState anzuzeigen?

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 14:54:27
Hallo zap,

ps ax | grep ccurpc

root@bananapi ~ # clear
root@bananapi ~ # ps ax | grep ccurpc
 8187 pts/0    S      0:03 /usr/bin/perl /opt/fhem/FHEM/ccurpcd.pl 192.168.178.42 2001 /tmp/ccuqueue_2001 /opt/fhem/log/ccurpcd_2001.log
 9070 pts/0    S+     0:00 grep --color=auto ccurpc
root@bananapi ~ #

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 14:58:47
und das mit rpcport=2001,2010 ?? Wenn ja, hast Du vieleicht ccuflags auf "singlerpc" gesetzt?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 15:10:06
wo kann ich das nachsehen?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 15:20:31
wo kann ich das nachsehen?

Wieviele RPC-Server laufen? Ich denke, bei Dir dürften es 2 sein (ps ax | grep ccurpc). Du hattest Deine Einstellungen ja schon gepostet.

Nein, bei ToM_ToM interessieren mich rpcport und ccufliags, weil bei ihm nur 1 Server läuft. Du hast ja geschrieben, dass es bei Dir nur mit rpcport=2001,2010 funktioniert. Wenn das bei ToM_ToM mit rpcport=2001 funktioniert, wäre das interessant.



Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 15:32:35
Habe jetzt mal meine Config angepasst und bei mir läuft es auch nur mit dem Port 2001.

#HMCCU
define CCU2 HMCCU 192.168.178.42
# Reading-Namen werden aus dem CCU Kanalnamen gebildet (Alternative "address")
attr CCU2 ccureadingformat name
# Speichere keine Readings im HMCCU Device (dafür gibt es die Client-Devices mit HMCCUDEV und HMCCUCHN)
attr CCU2 ccureadings 0
attr CCU2 devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
# Immer eine gute Idee, um FHEM etwas zu entlasten. Sollte man bei jedem HMCC* Device setzen
attr CCU2 event-on-change-reading .*
attr CCU2 icon rc_HOME
# Das Intervall, in dem die Queue mit den Statusinfos der CCU gelesen wird
attr CCU2 rpcinterval 5
# Die CCU-Ports (2001=BidCos-RF, 2000=BidCos-Wired, 2010=Homematic-IP)
attr CCU2 rpcport 2001
attr CCU2 rpcserver on
# Ersetze bei Set-Befehlen on durch true und off durch false (CCU kann mit on/off nichts anfangen)
attr CCU2 statevals on:true,off:false
attr CCU2 stripchar :
# Zahlenwerte in Readings nach der 1. Nachkommastelle abschneiden
attr CCU2 stripnumber 1
# Nur Readings der Client-Devices werden aktualisiert (sonst werden im HMCCU-Device sehr viele Readings auflaufen)
attr CCU2 updatemode client
attr CCU2 verbose 2
#Achtung! Viele der Attribute (statevals, stripnumber, ccureadingformat) müssen in den Client-Devices explizit nochmal gesetzt werden. Die Client-Devices "erben" keine Attribute vom HMCCU- bzw. IO-Device.

Gibt es eigentlich eine Art Wiki in der viele der gängigen Komponenten als Beispile schon angelegt sind?

Also Thermostat, Fenstersensor, Schalter, etc.

Momentan muss ich viel durch ausprobieren herausfinden und starte dann den RPC-Server immer neu - funktioniert ja jetzt super. ;)
Aber eine Beispielsammlung wäre toll.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 15:40:40
Möglicherweise hat cho vergessen die FHEM Config zu speichern, nachdem er rpcport auf 2001 gesetzt hatte.

Das Wiki steht ganz oben auf meiner TODO Liste. Im Moment teste ich die nächste Version, die ohne den ccurpcd auskommen soll. Hier gibt es aber noch große Probleme mit Timeouts.
Aber ich werde mal einige meiner Definitionen hier bereitstellen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 15:44:09
Hallo zap,

das kann ich leider ausschliessen (vergessen zu speichern).
Und ich habe gerade noch einmal ein paar Varianten getestet.

funktioniert nicht:

ohne Angabe von rpcport
rpcport=2001
rpcport=2000
rpcport=2010

funktioniert:

rpcport=2001,2010
rpcport=2001,2000
rpcport=2000,2010
rpcport=2010

Es scheint also immer zu funktionieren, wenn entweder 2 Ports angegeben werden - wobei egal ist welche - oder der Port 2010 einzeln angegeben ist.

Vielleicht hilft Dir das ja weiter.

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 16:09:20
Einige Beispiele für Gerätedefinitionen:

https://forum.fhem.de/index.php/topic,51339.0.html
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 16:43:51
Es scheint also immer zu funktionieren, wenn entweder 2 Ports angegeben werden - wobei egal ist welche - oder der Port 2010 einzeln angegeben ist.


Wenn Du BidCos-RF und kein Homematic IP verwendest, wird Dir 2010 alleine nichts bringen, da über diesen Port nur Homematic IP Geräte aktualisiert werden.

Da 2001 anscheinend bei Dir gar nicht geht, vermute ich, dass die Ursache auf CCU Seite liegt. Werden denn BidCos-RF Client Device Readings bei Dir aktualisiert? Vorsicht: Nach dem Starten des RPC-Servers werden automatisch einmalig alle Geräte aktualisiert. Daher sind kurz darauf erst mal die Timestamps aktuell. Die Frage ist, ob nach 1-3 Minuten auch noch einzelne Readings aktualisiert werden.

Den netstat Befehl vorhin hättest Du auf der CCU ausführen sollen (ssh root@homematic.fritz.box). Im Zweifel empfehle ich Dir, die CCU mal neu zu starten. Ich vermute dass der Prozess für den Port 2001 nicht mehr (richtig) läuft.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 16:51:27
Hey zap,

vielen Dank für die Beispiele.

Übrigens ist mir gerade noch was anderes aufgefallen. Nachdem ich nun mehrfach meinen Pi neu gestartet habe, bleibt der Status wieder in "Starting" hängen.
Obwohl ich vor jedem reboot per Attribute off, den Server beendet habe.

Werde wohl dann die CCU nochmal durchbooten müssen.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 17:30:50
Hallo zap,

oh, das war mein Fehler - Entschuldigung!
netstat auf der CCU gibt folgendes aus:

tcp        0      0 0.0.0.0:9292            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:1999            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:2001            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8181            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:2010            0.0.0.0:*               LISTEN     
unix  2      [ ACC ]     SEQPACKET  LISTENING        267 /run/udev/control

Mit den Ports hast Du recht. Da habe ich von der Anzeige "running" täuschen lassen.
Meine Aussage bezog sich nur auf den Wechsel der Anzeige von "starting" auf "running".

Die Steuerung der CCU funktioniert übrigens problemlos, mit der aktuellen Enstellung 2001,2010.
Und das sowohl beim Lesen (Fensterkontakte, Thermostate) als auch beim Schreiben (Thermostate).

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 März 2016, 18:06:07
Das Setzen und Lesen per get/set Befehl ist vom RPC-Server völlig unabhängig.

Zu netstat: Da beide Ports auftauchen, scheint alles in Ordnung zu sein. Trotzdem rätselhaft, warum 2001 alleine nicht funktioniert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 25 März 2016, 18:43:00
Hey, jetzt habe ich das gleiche Problem dass ich den Server nicht mehr zum Laufen bekommen habe.
Auch nach Neustart der CCU nicht.

Erst als ich auch die Ports von 2001 auf 2001,2010 geändert habe, ging es wieder.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 25 März 2016, 18:50:33
Hi zap,

bei mir scheint es jetzt mit der Angabe der beiden Ports stabil zu laufen.
Falls Du noch irgendwelche Infos von mir brauchst oder ich etwas testen soll, gib mir einfach Bescheid.

Kannst Du mir bitte noch meine Frage von weiter oben beantworten:
Ist es möglich, beim dem HMCCU Device in der Übersicht anstelle dem STATE (OK) den RPCState (starting/running/stopped) anzuzeigen?

Danke und Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 26 März 2016, 06:36:40
Verwende dafür das Attribut stateFormat.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 März 2016, 09:12:49
RPCState ist ein Internal. Du musst stateFormat wie folgt setzen:

{ $defs{$name}{RPCState} }

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 26 März 2016, 09:50:10
Danke!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 26 März 2016, 17:47:01
Hallo Zusammen,

irgendwie geht nachdem ich meinen Pi heute neugestartet habe, auch der RPC-Server nicht wenn beide Ports angegeben sind.
Das muss doch irgendein anderes Problem sein. Werde die CCU wohl später wieder neu starten müssen.

Aber mal eine andere Frage. Ist es möglich dass die Config die ganzen mühevoll angelegten Devices auch nach einem Neustart behält und ich die nicht alle wieder neu hinzufügen muss?
Zum Glück habe ich gestern ein Backup meiner alten Config gemacht.

Viele Grüße und schon Mal ein frohes Osterfest vorab, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 März 2016, 22:19:14
Mein Problem ist, dass ich dieses Verhalten überhaupt nicht nachvollziehen kann. Egal, ob ich einen oder zwei Ports angebe, es wird immer alles korrekt gestartet, auch bei einem Reboot. Von anderen Usern weiß ich, dass es bei ihnen auch läuft.

Und was meinst Du mit Speichern? Man legt die Devices in FHEM an und speichert mit Save. Allerdings: wenn beim Starten von FHEM das HMCCU IO-Device nicht angelegt werden kann, werden auch die Client Devices nicht angelegt. In dem Fall sollten aber einige Fehlermeldungen im FheM Log stehen. In der Oberfläche fehlen dann die Devices.

Die Definitionen sind aber trotzdem noch in fhem.cfg vorhanden. Du darfst nur nicht den Fehler machen, Save zu drücken. Dann wird der fehlerhafte Zustand in fhem.cfg gespeichert und alles ist weg.

Wenn Du die CCU neu startest geht alles wieder? Seltsam.

Du hast nicht noch eines der anderen HM RPC Module gleichzeitig aktiv? Das geht auf keinen Fall.

Verwendest Du auch die aktuelle Version von ccurpcd.pl? Einige Funktionen sind von dort in 88_HMCCU.pm gewandert.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 26 März 2016, 23:18:13
Hallo zap,

ich versuche gerade, Gruppen einzurichten. Aber ich blicke es leider nicht.

Auf der CCU2 habe ich z.B. eine Gruppe INT0000001 eingerichtet, zu der ein Wandthermostat (HM-TC-IT-WM-W-EU_aaa), zwei Heizkörperthermostate (HM-CC-RT-DN_bbb und HM-CC-RT-DN_ccc) und ein Fensterkontakt (HM-Sec-SCo_ddd) gehören.

Auf der CCU2 habe ich auf diese Gruppen datumsabhängig Wochenprogramme per TCL Skript so eingespielt

> xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]

(vereinfachtes Beispiel für einen Wochentag)
Diese würde ich jetzt gerne auf Fhem und HMCCU übertragen.

Die Gruppe lege ich dann in Fhem so an

> define GR_INT0000001 HMCCUDEV INT0000001 group=HM-TC-IT-WM-W-EU_aaa,HM-CC-RT-DN_bbb,HM-CC-RT-DN_ccc,HM-Sec-SCo_ddd

Wenn ich danach dann

> set GR_INT0000001 config P1_ENDTIME_SATURDAY_1=1440 P1_TEMPERATURE_SATURDAY_1=18.0

ausführe, bekomme ich aber diese Fehlermeldung im WebUI

> HMCCUDEV: GR_INT0000001 Execution of CCU script or command failed

und diese Einträge im fhem log

> 2016.03.26 23:11:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2939.
> 2016.03.26 23:11:46 1: HMCCUDEV: GR_INT0000001 Execution of CCU script or command failed

Ich denke mal, ich mache nur einen Anfängerfehler.
Aber wie geht es richtig?

Viele Grüße
Christian
[/list][/list][/list]
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 März 2016, 09:47:03
Es gibt nur wenige MASTER Parameter, die direkt im Device liegen. Bei den meisten muss man nach "config" im set Befehl noch eine Kanalnummer angeben.

Aber: das scheint nicht das einzige Problem zu sein. Der Fehler im Log bedeutet, dass die grundlegende URL für die Verbindung zur CCU nicht richtig zusammen gebaut wird. In dem Fall wird der Befehl nie funktionieren. Hast Du im HMCCU Device ein Internal "host" mit dem Namen der CCU?

Aber bevor Du jetzt hier ne Menge Zeit investierst, lass mich das heute abend mal testen. Ich habe das Thema Config Parameter (v.a. die Temperaturen und Zeiten bei Themostaten) bisher etwas vernachlässigt, da ich das immer direkt in der CCU einstelle und dann maximal noch das Wochenprogramm per FHEM auswähle.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 27 März 2016, 10:09:00
Ja, hab ich:

Internals
Clients :HMCCUDEV:HMCCUCHN:
DEF homematic.fritz.box
DelDevices 0
DevCount 134
NAME CCU2
NR 33
NewDevices 0
RPCPID 714,719
RPCPRC ./FHEM/ccurpcd.pl
RPCState running
STATE running
TYPE HMCCU
host homematic.fritz.box

Attributes
ccureadings 0 
group Zentrale
room 1 HomeMatic
rpcport 2010,2001
rpcqueue /opt/fhem/tmp/ccuqueue
rpcserver on
stateFormat { $defs{$name}{RPCState} }
updatemode both

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 März 2016, 11:07:09
Gerade nochmal kurz  remote getestet und dabei mein FHEM abgeschossen. Da ist wohl ein größerer Bug drin. Erst mal bitte nicht mehr testen. Muss das heute Abend mal analysieren ...

Grundsätzlich: Es ist denkbar, dass das Setzen und Lesen von Config Parametern bei Gruppen gar nicht geht, da die RPC-Schicht der CCU gar keine Gruppen kennt. Die gibt es nur in der Logik-Schicht. In dem Fall müsste man die Parameter über das Wand-Thermostat (sofern vorhanden) oder das Heizkörper-Thermostat setzen. Wenn es ein Wand-Thermostat in einer Gruppe gibt, ist das der Master, d.h. gibt die Werte für die Gruppe vor.

UPDATE: Morgen gibt es eine neue Version mit funktionierendem set/get config.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 28 März 2016, 18:43:48
Ich habe die Version 3.1 der Module eingecheckt (Link siehe 1. Beitrag). Bitte unbedingt alle Dateien 88_HMCCU* sowie ccurpcd.pl updaten!

Änderungen:

Queue-Files

Die Queue-Files werden nun mit der Berechtigung 0666 (-rw-rw-rw-) angelegt.

Statusanzeige RPC-Server

Im HMCCU-Device wird der Status des RPC-Servers nun auch im Reading "rpcstate" angezeigt. Um diesen Status in STATE zu übernehmen, kann das Attribut "stateFormat" auf "rpcstate" gesetzt werden.

Start RPC Server:

Der RPC Server wird nicht mehr über "attr rpcserver" gestartet. Dazu gibt es nun in HMCCU den Befehl "set rpcserver on/off". Das Attribut rpcserver dient nur noch dazu festzulegen, ob der RPC Server beim Starten von FHEM automatisch gestartet wird.
Beim Starten von FHEM wird der RPC Server erst gestartet, wenn FHEM den globalen Event "INITIALIZED" triggert. Das könnte dazu beitragen, dass die Startprobleme bei einigen Benutzern behoben werden.

Setzen von Config-Parametern:

Das Setzen von Config-Parametern sollte nun funktionieren. Folgendes Beispiel setzt 3 Zeitintervalle für ein Wandthermostat. Das Thermostat ist als HMCCUDEV Device mit dem Namen HM_KL_SZ angelegt:

set HM_KL_SZ P1_ENDTIME_SATURDAY_1=420 P1_ENDTIME_SATURDAY_2=1260 P1_ENDTIME_SATURDAY_3=1440

Beim Setzen der Zeiten für ein Thermostat sollte immer ein kompletter Tag definiert werden.

Wichtig zu wissen für das Setzen und Lesen von Config-Parametern:

Sonstiges

Die Warnung "experimental::smartmatch" sollte nun nicht mehr im Log auftauchen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 28 März 2016, 23:14:50
Hallo zap,

vielen Dank für das Update!
Der RPC Server startet bei mir jetzt - auch wenn ich nur Port 2001 angebe.
Und das setzen der Statusanzeige ist so auch viel einfacher.

Ich bekomme beim Booten allerdings immernoch diese Warnungen im fhem log:

Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 52.

Das Setzen der Config Parameter funktioniert bei mir jetzt auch.
Schade, dass das nur für die Geräte selber funktioniert, nicht aber für Gruppen.
Wie gesagt, auf der CCU2 funktioniert es via TCL Skript auch bei Gruppen:

load tclrpc.so
xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]

Aber das scheint dann ja leider über eine andere RPC Schnittstelle zu laufen?

Ich habe die Wochenprogramme bisher immer auf Gruppenebene gesetzt. Die Gruppe hat die Einstellungen dann vererbt: Gruppe -> Wandthermostat, Wandthermostat -> Heizkörper Thermostat bzw. Gruppe -> Heizkörper Thermostat.
Ich frage mich gerade, was passiert, wenn ich die Wochenprogramme nur noch an die Wandthermostat und Heizkörper Thermostate übertrage. Die Gruppen (mit dann abweichenden Wochenprogrammen) bleiben ja bestehen. Nicht, daß die Gruppen dann meine neu übertragenen Wochenprogramme auf den Geräten wieder überschreiben. Das muss ich jetzt erst einmal testen und beobachten.

Viele Grüße
Christian

[/list][/list][/list]
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 29 März 2016, 07:38:44
Schön, dass es nun läuft. Möglicherweise hattest Du beim letzten Mal den RPC-Server ccurpcd.pl nicht mit aktualisiert(?). Aber egal. Würde mich interessieren, ob auch bei ToM_ToM das jetzt rund läuft.

Ich bekomme beim Booten allerdings immernoch diese Warnungen im fhem log:

Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Ich hatte gestern Abend nochmal ein Update von 88_HMCCU.pm nachgeschoben. Kannst Du bitte prüfen, ob am Anfang der Datei (nach dem Kommentar-Header) folgende Zeile vorhanden ist:
no if $] >= 5.017011, warnings => 'experimental::smartmatch';

Zitat
Schade, dass das nur für die Geräte selber funktioniert, nicht aber für Gruppen.
Wie gesagt, auf der CCU2 funktioniert es via TCL Skript auch bei Gruppen:

load tclrpc.so
xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]

Aber das scheint dann ja leider über eine andere RPC Schnittstelle zu laufen?
Definitiv, die CCU schickt auch keine Aktualisierungen für Gruppen an den RPC-Server. Ist die Datei "xmlrpc" standardmäßig auf der CCU vorhanden? Dann schaue ich mir das mal an.

Zitat
Ich frage mich gerade, was passiert, wenn ich die Wochenprogramme nur noch an die Wandthermostat und Heizkörper Thermostate übertrage. Die Gruppen (mit dann abweichenden Wochenprogrammen) bleiben ja bestehen. Nicht, daß die Gruppen dann meine neu übertragenen Wochenprogramme auf den Geräten wieder überschreiben. Das muss ich jetzt erst einmal testen und beobachten.
Wenn ein Wandthermostat in der Gruppe ist und man ändert Parameter des Wandthermostats, ändern sich auch die Gruppen-Parameter. Ich verstehe das so, dass eine Gruppe keine eigenen Parameter hat sondern die des Wandthermostats bzw. des Heizkörperthermostats verwendet und darstellt. Für diese Theorie spricht auch, dass die Meldung kommt "Daten werden an das Gerät übertragen" sobald man im CCU WebUI einen Gruppenparameter ändert.

P.S. wo kommt eigentlich dieses "list, list, list" am Ende des Beotrags her. Ich bekomme das nicht weg.
[/list][/list][/list]
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 29 März 2016, 10:27:14
Hallo Zusammen,

bei mir läuft es jetzt seit einigen Tagen wunderbar, weshalb ich mich kaum traue, zu aktualisieren. ;)
Da ich das Ganze bei meinen Eltern eingerichtet habe, morgen wieder abreise und nur ca. alle 5 Monate dazu komme daran weiterzubasteln, bin ich gerade froh dass es so gut läuft.
Ich kann die Heizungsthermostate schalten, Klimasensoren abfragen... - alles wunderbar.

Hier übrigens ein Beispiel für nen Klimasensor:

define HM_DB_Klimasensor HMCCUDEV LEQXXXXXXXX 1
attr HM_DB_Klimasensor IODev CCU2
attr HM_DB_Klimasensor ccureadingfilter (LOWBAT|HUMIDITY|TEMPERATURE|CONTROL)
attr HM_DB_Klimasensor ccureadingformat name
attr HM_DB_Klimasensor event-on-change-reading .*
attr HM_DB_Klimasensor statechannel 1
attr HM_DB_Klimasensor stripnumber 1
attr HM_DB_Klimasensor substitute LOWBAT!(0|false):no,(1|true):yes

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 29 März 2016, 11:45:19
In dem Fall würde ich vielleicht auch nach dem Prinzip "never touch a running system" verfahren. Das Setzen von Config-Parametern (z.B. Heizzeiten) wird mit der alten Version aber nicht funktionieren. Da ist ein Bug drin.

P.S. Schon mal über einen VPN-Tunnel zwecks Remote-Zugriff nachgedacht?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 29 März 2016, 14:10:00
Hallo zap,

VPN ist an sich kein Thema, allerdings müsste ich das Tablet dann auch über VPN konfigurieren. Und soweit ich weiß, geht das per TeamViewer nur mit der kommerziellen Version.
Naja ich habe auch mit meinem System daheim schon genug Arbeit. ;)
Heizdaten an sich setze ich aktuell nicht. von daher passt es.

Kennst du diese Lautsprecher von Homematic die man in die Steckdose steckt und die dann mp3-files von einer darin enthaltenen SD-Karte abspielen?
Mich würde noch interessieren wie man so ein Gerät anspricht. :)
Aber das mache ich dann beim nächsten Mal.

Habe es übrigens jetzt doch mal gewagt das Update durchzuführen und bisher läuft es super. :)
Kann nur sagen, super Arbeit von dir.

VG, Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 29 März 2016, 19:30:34
Hallo zap,

ob ich beim letzten mal vergessen hatte, die ccurpcd.pl zu aktualisieren, kann ich nicht mehr überprüfen. Ich glaube es aber eigentlich nicht. Wie auch immer, jetzt funktioniert es ja.

Ich habe gerade auch noch einmal nachgesehen. Ich habe Dein letztes Update 3.1 mit der 88_HMCCU.pm mit der Zeile "no if..." laufen. Sind die Warnungen eigentlich problematisch?

Die Datei "xmlrpc" ist standardmäßig auf der CCU vorhanden. Ich weiß dazu auch nur, dass auf der CCU2 für Gruppen ein eigener XML-RPC-Server mit der Adresse http://127.0.0.1:9292/groups läuft. Die Info findet man in verschieden Foren Beiträgen, z.B. hier:

http://homematic-forum.de/forum/viewtopic.php?f=26&t=20875#p189304

P.S. Wo das "list, list, list" herkommt, kann ich Dir leider auch nicht sagen. Es war nach dem Speichern ("Schreiben") einfach da und ließ sich über "Ändern" auch nicht wieder löschen?

Viele Grüße
Christian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 März 2016, 07:28:53
Ich habe gerade auch noch einmal nachgesehen. Ich habe Dein letztes Update 3.1 mit der 88_HMCCU.pm mit der Zeile "no if..." laufen. Sind die Warnungen eigentlich problematisch?
Nein, kein Problem. Sind nur Warnungen. Dann ersetzte ich mal "~~" durch "grep" in der nächsten Version. Dann ist das erledigt.

Zitat
Die Datei "xmlrpc" ist standardmäßig auf der CCU vorhanden. Ich weiß dazu auch nur, dass auf der CCU2 für Gruppen ein eigener XML-RPC-Server mit der Adresse http://127.0.0.1:9292/groups läuft. Die Info findet man in verschieden Foren Beiträgen, z.B. hier:

Vielen Dank für den Hinweis.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 30 März 2016, 13:42:51
Hallo,
nachdem ich mich entschieden habe meine Anforderungen über HMCCU einzupflegen habe ich begonnen das Modul zu installieren. Klappte soweit auh ganz gut allerdings bekomme ich es nicht gestartet. Wahrscheinlich habe ich doch irgendetwas überlesen :-(
Die Fehler im Log lauten - was hab ich verbockt ? (ich hoffe ist okay hier die Frage zu stellen):

2016.03.30 13:37:08 1: Including fhem.cfg
2016.03.30 13:37:08 1: reload: Error:Modul 88_HMCCU deactivated:
 Can't modify constant item in predecrement (--) at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 4317, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4318, near "/div><div id="l438" class="code_block"> <span class="p">}</span"
syntax error at ./FHEM/88_HMCCU.pm line 4320, near ""l440" class"
syntax error at ./FHEM/88_HMCCU.pm line 4322, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4325, near "</div"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ""l446" class"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ">)"
Unmatched right curly bracket at ./FHEM/88_HMCCU.pm line 4328, at end of line
./FHEM/88_HMCCU.pm has too many errors.

2016.03.30 13:37:08 0: Can't modify constant item in predecrement (--) at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 2, near "Server:"
syntax error at ./FHEM/88_HMCCU.pm line 4317, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4318, near "/div><div id="l438" class="code_block"> <span class="p">}</span"
syntax error at ./FHEM/88_HMCCU.pm line 4320, near ""l440" class"
syntax error at ./FHEM/88_HMCCU.pm line 4322, near ">)"
syntax error at ./FHEM/88_HMCCU.pm line 4325, near "</div"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ""l446" class"
syntax error at ./FHEM/88_HMCCU.pm line 4326, near ">)"
Unmatched right curly bracket at ./FHEM/88_HMCCU.pm line 4328, at end of line
./FHEM/88_HMCCU.pm has too many errors.

2016.03.30 13:37:08 1: Including /opt/fhem/FHEM/dsHutAktorM1.cfg
2016.03.30 13:37:08 1: Including /opt/fhem/FHEM/dsTeich.cfg
2016.03.30 13:37:08 1: Including /opt/fhem/FHEM/dsH20detect.cfg
2016.03.30 13:37:08 1: Including /media/usbhdd/FHEM/FHEM_Statefile/fhem.save
2016.03.30 13:37:16 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1483.
2016.03.30 13:37:16 1: PERL WARNING: Use of uninitialized value $val in substitution (s///) at fhem.pl line 1484.
2016.03.30 13:37:16 1: PERL WARNING: Use of uninitialized value $val in concatenation (.) or string at fhem.pl line 1485.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 März 2016, 15:05:52
Ich vermute, da ist beim Download von Sourceforge etwas schief gegangen. In Sourceforge die Datei anzeigen lassen und dann "Download this file" klicken.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 30 März 2016, 15:40:49
Jo scheint so. Hab sie runtergalden und nun hab ich anderen Fehler (ich habe aber alle cpan Module installiert wie in der Anleitung):

2016.03.30 15:34:57 1: reload: Error:Modul 88_HMCCU deactivated:
 Can't locate RPC/XML/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.

2016.03.30 15:34:57 0: Can't locate RPC/XML/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 72, <$fh> line 32.

2016.03.30 15:34:58 1: Including /opt/fhem/FHEM/dsHutAktorM1.cfg
2016.03.30 15:34:58 1: Including /opt/fhem/FHEM/dsTeich.cfg
2016.03.30 15:34:59 1: Including /opt/fhem/FHEM/dsH20detect.cfg
2016.03.30 15:34:59 1: Including /media/usbhdd/FHEM/FHEM_Statefile/fhem.save
2016.03.30 15:34:59 1: configfile: Cannot load module HMCCU
FunkSchaltaktor_Leistung: unknown IODev specified
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 März 2016, 16:00:09
RPC::XML::Client ist nicht installiert (ggf. auch der Rest von RPC).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 30 März 2016, 17:06:41
Ja da magst du wohl recht haben. Die Logs besagen mir, dass bei der Installation von den CPAN Modulen was schief läuft. Fehlermeldungen ala "cannot find tar file". Irgendwas kollidiert da grad gewaltig.

Using Tar:/bin/tar xf "libwww-perl-6.15.tar":
Couldn't untar libwww-perl-6.15.tar: 'Cannot allocate memory'
  ETHER/libwww-perl-6.15.tar.gz
  Had problems unarchiving. Please build manually
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 März 2016, 18:38:06
Die Meldung "cannot allocate memory" liest sich nicht gut.

Entweder der Speicher ist aus oder ein Filesystem ist voll. Das tar braucht jedenfalls irgendwo temporären Platz um was auszupacken.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 30 März 2016, 19:11:11
Yep sehe ich genauso :-( Da hab ich wohl momentan zu viele "Testsysteme" laufen :-( Speicher voll ? Filesystem hat noch genug

Kann man da noch was frei schaufeln ?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 März 2016, 20:02:00
Dass das physikalische Memory fast voll ist, heißt bei Unix gar nichts. Swap ist auch noch genügend vorhanden. Sieht bei mir auf dem Raspi auch nicht anders aus. Aber Du kannst für die Dauer der Installation mal ein paar Dinge stoppen.
Oder Du schaust mal, ob Du ein Linux Paket für RPC findest. Lässt sich vielleicht einfacher installieren.

Das könnte passen: librpc-xml-perl
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 30 März 2016, 21:21:08
Uh, das ist ein guter Hinweis .... bin ich gar nicht selbst drauf gekommen. Werde es morgen ausprobieren --> heute habe ich anscheinend schon eckige Augen :-)
DANKE zap !
Ich werde berichten
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 31 März 2016, 09:45:05
Guten Morgen!
hat natürlich geklappt ! Nun sind alle Module installiert.

Beim ersten define liest er ja nun alle Geräte ein und anscheinend stockt er bei einem:

FunkSchaltaktor_Leistung: unknown IODev specified

kennt er den nicht oder was sagt mir das ?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 31 März 2016, 09:49:55
Du musst zuerst das IO Device definieren:

define my_ccu HMCCU host_or_ip

Die Liste der Geräte wird nur bei der Definition des IO Device eingelesen.

Wenn das passiert ist, kannst du mit den Modulen HMCCUDEV und HMCCUCHN die Devices für die einzelnen Homematic Komponenten anlegen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 31 März 2016, 09:58:12
Okay, hab auch jetzt einen Beitrag gelesen wo die "attr" drin sind.

Da ich ein bestehendes System habe mit ca. 30 Aktoren muss ich die alle erstmal über HMCCUDEV und HMCCUCHN definieren ?

Den rpcserver bekomme ich erstmal nicht gestartet da läuft er auf den fehler --> please define rpcserver first. Owohl im log steht:
2016.03.31 09:36:43 0: Server started with 173 defined entities (fhem.pl:11144/2016-03-29 perl:5.014002 os:linux user:fhem pid:21877)
2016.03.31 09:37:53 0: HMCCU: RPC server not running

die Definition lautet:
# IO Device definieren
define d_HMCCU2 HMCCU 192.168.40.xxx
attr d_HMCCU2 ccureadings 1
attr d_HMCCU2 room 90_System
attr d_HMCCU2 rpcserver on

UPDATE 10:40:
rpcserver läuft erstmal --> datei war nicht ausführbar gemacht von mir. Ich teste weiter !
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 31 März 2016, 11:54:45
In der aktuellen Version wird der RPC-Server nicht mehr direkt nach Ausführung von "attr rpcserver on" gestartet. Dieses Attribut sorgt nur noch dafür, dass der RPC-Server beim Starten von FHEM automatisch gestartet wird.

Manuell kann der RPC-Server mit dem Befehl "set rpcserver on" (im IO Device) gestartet werden.

Und ja: Du musst für alle Geräte, die Du per FHEM ansprechen willst, ein Device mit HMCCUDEV oder HMCCUCHN definieren.

Schau Dir mal die HMCCU_Readme.txt an (ist im 1. Beitrag verlinkt). Die ist zwar nicht brandaktuelle (z.B. Starten des RPC Servers ist noch nicht aktualisiert), aber grundsätzlich ein guter Einstieg (hoffe ich).

Auf autocreate von Devices habe ich bewusst verzichtet. Viele Nutzer haben eine sehr große Homematic Umgebung (ich z.B. ;-). Da wollte ich nicht unkontrolliert Devices in FHEM anlegen lassen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 31 März 2016, 12:42:53
Ja, das habe ich auch festgestellt dass der rpc-server nicht automatisch startet --> steht ja auch in der Readme so, allerdings wusste ich nicht genau wie ich den starte. Dann hab ichs gelesen --> in fhem manuell starten oder in die "Oberfläche" von HMCCU und dann dort über die Vorauswahlen konfigurieren und bestätigen!

Es gibt also kein Autocreate wie es zB bei der HM_CUL gemacht wurde ?
Mhhh okay verstehe ich gerade wenn man viele devices hat. Dann wäre aber eine kleine Liste gut welche Parameter man denn setzen kann. bei der HM_CUL waren Dinge dabei wie

.devInfo, actCycle, actStatus, alias, autoReadReg, expert, firmware, group, model, peerIDs, room, serialNr, subType
die Abfrage in FHEM mit "attr xyz ?" ergibt (ist es das was man an Parametern hat?):
choose one of verbose room group comment alias eventMap userReadings IODev ccureadingfilter ccureadingformat ccureadings ccuget ccuverify disable mapdatapoints statevals substitute statechannel statedatapoint controldatapoint stripnumber event-on-change-reading event-on-update-reading event-aggregator event-min-interval stateFormat cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride userattr
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 31 März 2016, 17:01:18
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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 31 März 2016, 20:52:28
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:

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" ?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 April 2016, 09:11:01
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".

Zitat
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.

Zitat
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".
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 01 April 2016, 10:37:28
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 !
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 01 April 2016, 11:51:23
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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 01 April 2016, 13:06:13
- 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 !
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 01 April 2016, 20:59:43
Nachtrag:
Der rpcserver scheint sich nach einiger Zeit zu beenden. Im Log steht folgendes nachdem einige Perl Warnungen ausgegeben werden:

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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 02 April 2016, 14:44:17
Der Prozess-Check schlägt fehl. Welches Betriebssystem verwendest Du? Wie sieht die Ausgabe von folgendem Befehl aus:

ps ax | grep fhem | grep -v grep
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 03 April 2016, 08:32:32
Moment läuft der rpcserver nicht und trotzdem habe ich diese Einträge (grübelgrübel):

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

der Befehl
ps -ef | grep ccurpcd.plbringt folgendes Ergebnis:
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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 03 April 2016, 10:42:28
Der RPC Server läuft, aber HMCCU merkt das nicht. Bitte mal folgenden Befehl ausführen und die Ausgabe posten:

ps ax | grep ccurpcd
Welches Berriebssystem?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 03 April 2016, 11:20:00
Betriebssystem ist Debian Wheezy 7.9
proc ergibt:

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:

  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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 03 April 2016, 13:51:01
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:

{`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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 03 April 2016, 19:55:55
Hallo anbei das Ergebnis der Abfrage:

  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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 04 April 2016, 07:47:21
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?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 04 April 2016, 07:57:04
Blöd ist: Du bist der einzige mit diesem Problem.

 :o immer ich  :o

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 ???  :o :o :o

ERGÄNZUNG 08.08:
Den Prozess bekomme ich aus FHEM nicht mehr gestoppt --> siehe Filelog Eintrag:
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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 05 April 2016, 05:26:15
Hallo zusammen,

bin ganz neu in der FHEM Welt und habe auch so meine Spässe mit dem rpc Dämon. Auch bei mir beendet sich
der RPC Prozess automatisch. Zusätzlich wirft er mir jetzt seit gestern aber 21.51 Uhr noch einen Fehler im Log aus, mit dem ich nichts anfangen kann.

Würde mich über Unterstützung sehr freuen.

Hier das Log:

2016.04.04 05:17:27 1: Including fhem.cfg
2016.04.04 05:17:27 3: telnetPort: port 7072 opened
2016.04.04 05:17:29 3: WEB: port 8083 opened
2016.04.04 05:17:29 3: WEBphone: port 8084 opened
2016.04.04 05:17:29 3: WEBtablet: port 8085 opened
2016.04.04 05:17:29 2: eventTypes: loaded 6 events from ./log/eventTypes.txt
2016.04.04 06:13:08 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 06:13:33 1: Including ./log/fhem.save
2016.04.04 06:13:33 1: in INITIALIZED
2016.04.04 06:13:33 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 06:13:33 1: usb create starting
2016.04.04 06:13:34 3: Probing CUL device /dev/ttyAMA0
2016.04.04 06:13:35 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 06:13:35 1: usb create end
2016.04.04 06:13:35 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.04 06:13:35 0: Featurelevel: 5.7
2016.04.04 06:13:35 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 835)
2016.04.04 06:13:35 3: ipc fronthem:127.0.0.1:52477 (ws): ws alive with pid 987
2016.04.04 06:13:44 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 06:13:46 0: HMCCU: RPC server started with pid 1177
2016.04.04 06:13:46 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 06:13:46 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 06:13:56 0: HMCCU: All RPC servers stopped
2016.04.04 06:17:35 1: in ATTR
2016.04.04 06:17:37 1: in SAVE
2016.04.04 06:18:00 1: HMCCUDEV: Rollo_wohnzimmer_vorn Usage: get Rollo_wohnzimmer_vorn channel {channel-number}[.{datapoint-expr}] [...]
2016.04.04 06:25:39 1: HMCCU: Error URL = http://192.168.178.101:8181/do.exe?r1=dom.GetObject("BidCos-RF.KEQ0879052:1.STATE").Value()
2016.04.04 06:25:39 1: HMCCUDEV: Rollo_wohnzimmer_vorn Execution of CCU script or command failed
2016.04.04 20:37:18 1: HMCCU: Error URL = http://192.168.178.101:8181/do.exe?r1=dom.GetObject("BidCos-RF.KEQ0879052:1.STATE").Value()
2016.04.04 20:37:18 1: HMCCUDEV: Rollo_wohnzimmer_vorn Execution of CCU script or command failed
2016.04.04 20:37:33 1: in SHUTDOWN
2016.04.04 20:37:33 0: Server shutdown
2016.04.04 20:37:33 0: HMCCU: RPC server not running
2016.04.04 20:37:39 1: Including fhem.cfg
2016.04.04 20:37:39 3: telnetPort: port 7072 opened
2016.04.04 20:37:39 3: WEB: port 8083 opened
2016.04.04 20:37:39 3: WEBphone: port 8084 opened
2016.04.04 20:37:39 3: WEBtablet: port 8085 opened
2016.04.04 20:37:39 2: eventTypes: loaded 16 events from ./log/eventTypes.txt
2016.04.04 20:37:40 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 20:37:45 1: Including ./log/fhem.save
2016.04.04 20:37:45 1: in INITIALIZED
2016.04.04 20:37:45 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 20:37:46 1: usb create starting
2016.04.04 20:37:46 3: Probing CUL device /dev/ttyAMA0
2016.04.04 20:37:46 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 20:37:46 1: usb create end
2016.04.04 20:37:46 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.04 20:37:46 0: Featurelevel: 5.7
2016.04.04 20:37:46 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 22719)
2016.04.04 20:37:46 3: ipc fronthem:127.0.0.1:54530 (ws): ws alive with pid 22722
2016.04.04 20:37:56 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 20:37:58 0: HMCCU: RPC server started with pid 22733
2016.04.04 20:37:58 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 20:37:58 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 20:38:08 0: HMCCU: All RPC servers stopped
2016.04.04 20:40:07 1: in ATTR
2016.04.04 20:42:14 1: in ATTR
2016.04.04 20:43:18 1: in ATTR
2016.04.04 20:43:22 1: HMCCUDEV: Rollo_wohnzimmer_vorn Invalid name or address
2016.04.04 20:43:26 1: HMCCUDEV: Rollo_wohnzimmer_vorn Invalid name or address
2016.04.04 20:45:27 1: in DELETEATTR
2016.04.04 20:45:36 1: in SAVE
2016.04.04 20:46:06 1: in DELETEATTR
2016.04.04 20:46:09 1: in DELETED
2016.04.04 20:46:22 0: HMCCU: RPC server not running
2016.04.04 20:46:25 1: in DELETED
2016.04.04 20:47:51 1: in DEFINED
Quantifier follows nothing in regex; marked by <-- HERE in m/* <-- HERE / at ./FHEM/88_HMCCU.pm line 2636.
2016.04.04 20:51:23 1: Including fhem.cfg
2016.04.04 20:51:23 3: telnetPort: port 7072 opened
2016.04.04 20:51:24 3: WEB: port 8083 opened
2016.04.04 20:51:24 3: WEBphone: port 8084 opened
2016.04.04 20:51:24 3: WEBtablet: port 8085 opened
2016.04.04 20:51:25 2: eventTypes: loaded 16 events from ./log/eventTypes.txt
2016.04.04 20:51:37 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 20:52:02 1: Including ./log/fhem.save
2016.04.04 20:52:02 1: in INITIALIZED
2016.04.04 20:52:02 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 20:52:02 1: usb create starting
2016.04.04 20:52:03 3: Probing CUL device /dev/ttyAMA0
2016.04.04 20:52:03 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 20:52:03 1: usb create end
2016.04.04 20:52:03 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.04 20:52:03 0: Featurelevel: 5.7
2016.04.04 20:52:03 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 910)
2016.04.04 20:52:03 3: ipc fronthem:127.0.0.1:59342 (ws): ws alive with pid 1041
2016.04.04 20:52:12 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 20:52:14 0: HMCCU: RPC server started with pid 1233
2016.04.04 20:52:14 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 20:52:14 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 20:52:25 0: HMCCU: All RPC servers stopped
2016.04.04 20:53:46 1: in DELETED
2016.04.04 21:00:04 1: in DEFINED
2016.04.04 21:01:53 1: in ATTR
2016.04.04 21:02:18 1: in SAVE
2016.04.04 21:02:27 1: in SAVE
2016.04.04 21:02:45 1: in ATTR
2016.04.04 21:02:47 1: in SAVE
2016.04.04 21:22:45 1: in ATTR
2016.04.04 21:23:09 1: in ATTR
2016.04.04 21:23:12 1: in SAVE
2016.04.04 21:25:17 1: in ATTR
2016.04.04 21:42:53 1: HMCCU: d_ccu Usage: set d_ccu rpcserver {on|off}
2016.04.04 21:43:27 1: in SHUTDOWN
2016.04.04 21:43:27 0: Server shutdown
2016.04.04 21:43:27 0: HMCCU: RPC server not running
2016.04.04 21:43:33 1: Including fhem.cfg
2016.04.04 21:43:33 3: telnetPort: port 7072 opened
2016.04.04 21:43:34 3: WEB: port 8083 opened
2016.04.04 21:43:34 3: WEBphone: port 8084 opened
2016.04.04 21:43:34 3: WEBtablet: port 8085 opened
2016.04.04 21:43:34 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.04 21:43:34 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 21:43:39 1: Including ./log/fhem.save
2016.04.04 21:43:39 1: in INITIALIZED
2016.04.04 21:43:39 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 21:43:39 1: usb create starting
2016.04.04 21:43:39 3: Probing CUL device /dev/ttyAMA0
2016.04.04 21:43:39 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 21:43:39 1: usb create end
2016.04.04 21:43:39 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.04 21:43:39 0: Featurelevel: 5.7
2016.04.04 21:43:39 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2477)
2016.04.04 21:43:39 3: ipc fronthem:127.0.0.1:59601 (ws): ws alive with pid 2479
2016.04.04 21:43:49 1: PERL WARNING: Can't exec "./FHEM/ccurpcd.pl": Keine Berechtigung at ./FHEM/88_HMCCU.pm line 1359.
Died at ./FHEM/88_HMCCU.pm line 1362.
2016.04.04 21:43:51 0: HMCCU: RPC server started with pid 2492
2016.04.04 21:43:51 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
2016.04.04 21:43:51 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 21:44:01 0: HMCCU: All RPC servers stopped
2016.04.04 21:56:47 1: in SHUTDOWN
2016.04.04 21:56:47 0: Server shutdown
2016.04.04 21:56:47 0: HMCCU: RPC server not running
2016.04.04 21:56:53 1: Including fhem.cfg
2016.04.04 21:56:53 3: telnetPort: port 7072 opened
2016.04.04 21:56:54 3: WEB: port 8083 opened
2016.04.04 21:56:54 3: WEBphone: port 8084 opened
2016.04.04 21:56:54 3: WEBtablet: port 8085 opened
2016.04.04 21:56:54 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.04 21:56:54 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.04 21:56:58 1: Including ./log/fhem.save
2016.04.04 21:56:58 1: in INITIALIZED
2016.04.04 21:56:58 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.04 21:56:58 1: usb create starting
2016.04.04 21:56:58 3: Probing CUL device /dev/ttyAMA0
2016.04.04 21:56:58 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.04 21:56:59 1: usb create end
2016.04.04 21:56:59 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.04 21:56:59 0: Featurelevel: 5.7
2016.04.04 21:56:59 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2802)
2016.04.04 21:56:59 3: ipc fronthem:127.0.0.1:59635 (ws): ws alive with pid 2803
2016.04.04 21:57:10 0: HMCCU: RPC server started with pid 2811
2016.04.04 21:57:10 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
Glob not terminated at /opt/fhem/FHEM/RPCQueue.pm line 26.
Compilation failed in require at ./FHEM/ccurpcd.pl line 41.
BEGIN failed--compilation aborted at ./FHEM/ccurpcd.pl line 41.
2016.04.04 21:57:10 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.04 21:57:20 0: HMCCU: All RPC servers stopped
2016.04.05 05:20:10 1: in SHUTDOWN
2016.04.05 05:20:10 0: Server shutdown
2016.04.05 05:20:10 0: HMCCU: RPC server not running
2016.04.05 05:20:16 1: Including fhem.cfg
2016.04.05 05:20:16 3: telnetPort: port 7072 opened
2016.04.05 05:20:16 3: WEB: port 8083 opened
2016.04.05 05:20:16 3: WEBphone: port 8084 opened
2016.04.05 05:20:16 3: WEBtablet: port 8085 opened
2016.04.05 05:20:16 2: eventTypes: loaded 19 events from ./log/eventTypes.txt
2016.04.05 05:20:16 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 40.
2016.04.05 05:20:20 1: Including ./log/fhem.save
2016.04.05 05:20:20 1: in INITIALIZED
2016.04.05 05:20:20 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
2016.04.05 05:20:20 1: usb create starting
2016.04.05 05:20:20 3: Probing CUL device /dev/ttyAMA0
2016.04.05 05:20:20 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.05 05:20:20 1: usb create end
2016.04.05 05:20:20 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.05 05:20:20 0: Featurelevel: 5.7
2016.04.05 05:20:20 0: Server started with 13 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 11440)
2016.04.05 05:20:20 3: ipc fronthem:127.0.0.1:60599 (ws): ws alive with pid 11441
2016.04.05 05:20:32 0: HMCCU: RPC server started with pid 11453
2016.04.05 05:20:32 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001
Glob not terminated at /opt/fhem/FHEM/RPCQueue.pm line 26.
Compilation failed in require at ./FHEM/ccurpcd.pl line 41.
BEGIN failed--compilation aborted at ./FHEM/ccurpcd.pl line 41.
2016.04.05 05:20:32 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.05 05:20:42 0: HMCCU: All RPC servers stopped


Viele Grüße
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 05 April 2016, 05:42:01
@zap:
heute Nacht stieg der rpcserver grundlos wieder aus. Einzige Fehlermeldung im Log:

2016.04.05 02:40:17 2: HMCCU: Unknown RPC event type [EV]
 :-\
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 05 April 2016, 07:20:45
@zap:
heute Nacht stieg der rpcserver grundlos wieder aus. Einzige Fehlermeldung im Log:

2016.04.05 02:40:17 2: HMCCU: Unknown RPC event type [EV]

Ist der RPC Server wirklich abgebrochen? Dann müsste es noch eine Meldung wie "All RPC servers stopped" geben bzw. mit dem Befehl "get rpcstate" für das HMCCU IO-Device dürften keine Prozesse mehr angezeigt werden.
Diese "unknown RPC event type" Meldung hatte ich auch schon mal, als nachts mein DSL Anschluss resettet wurde. Führt aber normalerweise nicht dazu, dass der RPC server abbricht. Der unbekannte Event wird verworfen und der Server läuft weiter.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 05 April 2016, 07:31:00
Hallo zusammen,

bin ganz neu in der FHEM Welt und habe auch so meine Spässe mit dem rpc Dämon. Auch bei mir beendet sich
der RPC Prozess automatisch. Zusätzlich wirft er mir jetzt seit gestern aber 21.51 Uhr noch einen Fehler im Log aus, mit dem ich nichts anfangen kann.

Würde mich über Unterstützung sehr freuen.

Zuerst hattest Du wohl die Execute-Rechte für ccurpcd.pl nicht gesetzt, das dann aber nachgeholt. Die letzten Einträge deuten darauf hin, dass beim Laden von RPCQueue.pm ein Fehler auftritt. Ich vermute, da ist beim Download der Datei aus Sourceforge etwas schief gelaufen. Entweder nochmal runterladen oder mal hier die ersten 30 Zeilen reinstellen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 05 April 2016, 07:56:48
Ist der RPC Server wirklich abgebrochen? Dann müsste es noch eine Meldung wie "All RPC servers stopped" geben bzw. mit dem Befehl "get rpcstate" für das HMCCU IO-Device dürften keine Prozesse mehr angezeigt werden.
Diese "unknown RPC event type" Meldung hatte ich auch schon mal, als nachts mein DSL Anschluss resettet wurde. Führt aber normalerweise nicht dazu, dass der RPC server abbricht. Der unbekannte Event wird verworfen und der Server läuft weiter.

Also, komplette Kommunikation auch mit dem CCU IO device war tot. Prozesse liefen komplett nicht mehr  :-\
Bevor ich alles manuell neustartete habe ich mich für ein RPi-reboot entschieden. Momentan hab ich fhem nicht gestartet sondern gestoppt, da ich immer Probleme habe wenn ich fhem starte insb. den rpcserver aktiviere. das mache ich jetzt nur noch "on demand".

Ebenso habe ich überprüft wann mein DSL Anschluss neu gestartet wird und das ist imer so gegen 03:30 nachts. gegengeprüft wann ich eine neue IP bekommen habe --> 03:31 !
Absturz des Prozesses war um 02.40 laut Logfile.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 05 April 2016, 07:58:41
Hier das Log:

Hi Nic,
sieht nach fehlerhaften Download der Dateien aus. Hatte ich auch. In der tat musst du jedes File anklicken und dann per "save file as" (links ziemlich Weit obene) das File runterladen.
Anscheinend geht mit der Formatierung irgendwas "kaputt".
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 05 April 2016, 08:15:16
In den nächsten 1-2 Wochen wird es ein Update geben, das wahlweise ohne den externen RPC-Server auskommt (verwendet dann einen internen Sub-Prozess).

Wenn das bei allen stabil läuft, werfe ich den externen RPC-Server komplett raus. Das ist dann die Voraussetzung, dass das Modul in den offiziellen FHEM Modulzweig reinkommt. Dann ist das manuelle Runterladen Geschichte.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 05 April 2016, 17:07:12
Hi zap,
wenn ich das richtig verstehe und interpretiere, dann warte ich mal auf dieses neue Update. Vielleicht klappt es mit diesem internen Prozess ja besser (da hat man ja alles selber in der Hand).

So lange keine Experimente mehr bei mir :-) hatte schon etwas geschockt heute morgen das Ganze "ertragen müssen"  ;D

Und ..... so viel Zeit muss sein ..... wie immer tolle Kommunikation / Hilfestellung von Dir zap :-) DANKE
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 05 April 2016, 21:03:35
Hallo zusammen,

der erneute download der Dateien hat mich ein bisschen weiter gebracht.

Der RPC Server läuft jetzt:

05.04.2016 20:54:53 Creating file queue
05.04.2016 20:54:53 Initializing RPC server
05.04.2016 20:54:54 Callback server created listening on port 7401
05.04.2016 20:54:54 Adding callback for events
05.04.2016 20:54:54 Adding callback for new devices
05.04.2016 20:54:54 Adding callback for deleted devices
05.04.2016 20:54:54 Adding callback for modified devices
05.04.2016 20:54:54 Adding callback for replaced devices
05.04.2016 20:54:54 Adding callback for readded devices
05.04.2016 20:54:54 Entering server loop. Use kill -SIGINT 1229 to terminate program
05.04.2016 20:56:41 RPC server terminated
05.04.2016 20:56:41 RPC server received 92 (93) events

Dafür startet FHEM nicht mehr :-(

Das Log sagt folgendes:
2016.04.05 20:58:33 1: Including fhem.cfg
2016.04.05 20:58:33 3: telnetPort: port 7072 opened
2016.04.05 20:58:44 3: WEB: port 8083 opened
2016.04.05 20:58:44 3: WEBphone: port 8084 opened
2016.04.05 20:58:44 3: WEBtablet: port 8085 opened
2016.04.05 20:58:44 2: eventTypes: loaded 11 events from ./log/eventTypes.txt
2016.04.05 20:58:46 2: fronthem: ipc listener opened at port 16384
Undefined subroutine &main::HMCCU_IsValidDevice called at ./FHEM/88_HMCCUDEV.pm line 99, <$fh> line 40.



Könnt Ihr mir noch einmal helfen und mir einen Tip geben, was jetzt schief läuft?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 06 April 2016, 07:44:26
Ich verstehe den Zusammenhang zwischen beiden Logs nicht. Um 20:54 wurde der RPC-Server gestartet, allerdings nicht richtig initialisiert (Meldungen "New Devices" und "ListDevice" fehlen). Um 20:56 wurde er beendet. Hast Du ihn da manuell gestoppt oder hast Du FHEM runtergefahren oder wurde er automatisch beendet?

Zum Fehler beim Starten von FHEM: Kommt daher, dass das Modul HMCCU nicht geladen wurde und ein Gerät mit dem Modul HMCCUDEV angelegt werden soll. Gibt es weiter vorne im Log noch andere Meldungen?

Bitte schicke mir mal die Ausgabe von folgendem Befehl (auszuführen im Verzeichnis, in dem die Datei fhem.cfg liegt):

grep HMCCU fhem.cfg

Idealerweise alle Einträge (defines, attr) aus der fhem.cfg, die sich auf Geräte der Module HMCCU, HMCCUDEV, HMCCUCHN beziehen. Bitte in der Reihenfolge, wie sie in der fhem.cfg auftauchen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: bunni am 06 April 2016, 18:16:18
Hallo,
trotz aller Bemühungen, ist es mir nicht gelungen das HMCCU in Fhem zu integrieren, vom Verzeichnis ./contrib habe ich das Modul in ./FHEM kopiert, doch es taucht immer noch nicht in
der Commandref auf, hat jemand eine Lösung für mein Problem?

Fhem Version 5.7
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 06 April 2016, 18:54:42
Mach einfach mal ein update von FHEM. Am Ende des Updates baut FHEM die lokale Commandref neu zusammen. Das wird mit dem Perl-Script commandref_join.pl gemacht. Ob und wie man das manuell ausführt, weiß ich nicht.

Jedenfalls nach dem Update hast Du in der lokalen Commandref die Einträge für HMCCU, HMCCUDEV und HMCCUCHN.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: bunni am 06 April 2016, 19:07:48
Update und darauffolgend shutdown restart habe ich schon durchgeführt, leider ohne Erfolg! Auch der komplette Neustart von Ubuntu brachte keinen Erfolg!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 06 April 2016, 19:33:53
Nochmal zu Deinem vorherigen Post: Du hast das Modul aus ./contrib nach ./FHEM kopiert? Wie kam es denn nach contrib?

Du solltest auf jeden Fall die Dateien aus folgendem Sourceforge Verzeichnis runterladen und im Unterverzeichnis FHEM ablegen:

https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/HMCCU/FHEM/

Dazu klickst Du jede Datei einzeln an und klickst dann links oben auf "Download this file" (88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl)
Wenn Du dann alles im FHEM-Verzeichnis hast, musst Du noch für die Datei die Execute Rechte setzen:

chmod +x ccurpcd.pl
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: bunni am 06 April 2016, 19:58:17
Ok, werde es so wie Du es mir erklärt hast machen! Bin gespannt ob es klappt!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 07 April 2016, 14:00:39
Ich kann bestätigen, dass die Installationsanleitung (gemäß HMCCU_README.txt Kapitel 1.2 HMCCU Requirements & Installation) grundsätzlich funktioniert. Mir sind beim installieren aber folgende Dinge aufgefallen, die zu Fragen meinerseits geführt haben und ggf. in der Anleitung ergänzt werden könnten:

Wie soll ich Module wie LWP::UserAgent, Time::HiRes, RPC::XML::Client installieren? Die Antwort ist zwar durch weitere Recherche ermittelbar, ein Hinweis im Readme wäre aber wünschenswert. Ich habe es dann mit "sudo cpan install LWP::UserAgent" usw. gemacht. Da kommt ein ganzer Haufen an Modulen mit und das dauert, bis man alle benötigten Komponenten installiert hat bestimmt eine gefühlte Ewigkeit.... (Bemerkung: RPC::XML::Server hat bei mir auch gleich den RPC::XML::Client installiert. Also scheint es eine gewisse Empfehlung für die Reihenfolge der zu installierenden Komponenten zu geben...)

Eindeutiger fände ich im Readme folgende Beschreibung:

sudo cpan install Time::HiRes
sudo cpan install LWP::UserAgent
sudo cpan install RPC::XML::Server
sudo cpan install RPC::XML::Client
sudo cpan install IO::Socket::INET

am Besten noch in der Reihenfolge, wie es den meisten Sinn macht. Statt des mich in die Irre führenden Textes :"The FHEM module requires the packages LWP::UserAgent, Time::HiRes, RPC::XML::Client  and RPCQueue." Dann braucht man nicht nach einem package "RPCQueue" zu suchen.

Die Sonderstellung des "Moduls RPCQueue": Das ist nicht mit cpan zu installieren, sondern damit ist wohl die Datei "RPCQueue.pm" gemeint. Die ist natürlich nicht mit cpan zu installieren. Es gibt im Readme hierzu folgenden Hinweis, den ich erst spät gesehen habe; "NOTE: RPCQueue.pm is a bug fixed copy of File::Queue and part of the HMCCU installation
package. It's not available via CPAN!".

Leider läuft die Installation bei mir noch nicht, da der rpcserver nicht startet und ich bekomme beim "shutdown restart" von FHEM folgende Meldungen im fhem.log:


2016.04.07 13:24:56 0: Server shutdown
2016.04.07 13:24:57 1: PERL WARNING: Use of uninitialized value $pid in numeric gt (>) at ./FHEM/88_HMCCU.pm line 1431.
2016.04.07 13:24:58 0: HMCCU: RPC server not running


und weiter unten im fhem.log finde ich dann:


2016.04.07 13:28:47 1: HMCCU: 500 Can't connect to meineCCU2-IP-Adresse:8181 (Die Wartezeit für die Verbindung ist abgelaufen)
...
2016.04.07 13:29:28 0: HMCCU: Autostart of RPC server after FHEM initialization in 10 seconds
...
2016.04.07 13:32:17 0: HMCCU: All RPC servers stopped
...


Ein manueller Versuch, den rpcserver mittels "set myCCU2 rpcserver on" zu starten brachte dann folgende Logmeldungen:



2016.04.07 13:37:30 1: HMCCU: myCCU2 Start of RPC server failed
2016.04.07 13:37:42 0: HMCCU: All RPC servers stopped
2016.04.07 13:37:45 1: FHEMWEB SSL/HTTPS error:
2016.04.07 13:39:55 1: Can't connect to CCU port 2001
2016.04.07 13:39:56 1: HMCCU: myCCU2 Start of RPC server failed
2016.04.07 13:40:08 0: HMCCU: All RPC servers stopped


Habe ich noch etwas übersehen? Was kann/muss ich tun?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 07 April 2016, 18:23:49
Sorry für die ungenaue Beschreibung bei den notwendigen Modulen. Die Module LWP::Useragent und IO::Socket::Inet werden von vielen FHEM-Modulen benötigt. Bei denen ist die Wahrscheinlichkeit hoch, dass sie schon installiert sind. Viele User bevorzugen auch die Installation der fertigen Debian-Pakete gegenüber CPAN. Aber ich werde die Anleitung nochmal überarbeiten. Vielleicht komme ich auch endlich mal dazu, den ein oder andern Wiki Artikel zu schreiben (so viele Hobbies, so wenig Zeit ;-)

Zu Deinem Problem: Kannst Du bitte mal den define Befehl von dem HMCCU Device posten? Wenn Du hier den Hostname der CCU statt der IP-Adress verwendest, muss dieser auflösbar sein (entweder per DNS oder mittels Eintrag in /etc/hosts). Ich vermute mal, die CCU ist unter dem angegebenen Namen nicht erreichbar.

Kannst Du aber auch mal per ping testen. Wenn also das define so aussieht

define myCCU HMCCU CCUName

muss folgender Befehl funktionieren:

ping CCUName

Das Warning beim Shutdown ist nicht so tragisch. Das kommt daher, dass vorher kein RPC-Server gelaufen ist. Werde ich in der nächsten Version korrigieren.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 07 April 2016, 19:37:12
Missverständnis: Mein define erfolgt mit der IP-Adresse, nicht mit dem logischen Namen, der über /etc/hosts aufgelöst werden soll....

define myCCU2 HMCCU 192.168.179.16

Anbei die komplette Definition als list myCCU2:

Internals:
   Clients    :HMCCUDEV:HMCCUCHN:
   DEF        192.168.179.16
   DelDevices 0
   DevCount   -1
   NAME       myCCU2
   NR         1232
   NTFY_ORDER 50-myCCU2
   NewDevices 0
   RPCPID     0
   RPCPRC     none
   RPCState   stopped
   STATE      Error
   TYPE       HMCCU
   host       192.168.179.16
   Readings:
     2016-04-07 13:40:08   rpcstate        stopped
     2016-04-07 13:39:56   state           Error
   Hmccu:
     eventtime  0
     rpccount   0
     updatetime 0
     Rpc:
       Cb2001:
Attributes:
   room       07_Settings
   rpcserver  on


Ping liefert auch vernünftige Werte, siehe beigefügter Screen-Shot.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 07 April 2016, 19:54:10
Nutzt Du wireless Komponenten, Wired oder Homematic-IP ? Der Port 2001 ist für wireless.

Vielleicht hilft es, wenn Du das Attribut rpcport auf 2001 setzt (nur ne Vermutung, wäre ein Bug in HMCCU, aber wer weiß ...)

Außerdem habe ich das nie mit der IP-Adresse als Parameter getestet. Du könntest also mal einen Eintrag für 192.168.179.16 in der /etc/hosts machen und dann den festgelegten Namen im define verwenden.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 07 April 2016, 20:14:49
Zitat
Ich verstehe den Zusammenhang zwischen beiden Logs nicht. Um 20:54 wurde der RPC-Server gestartet, allerdings nicht richtig initialisiert (Meldungen "New Devices" und "ListDevice" fehlen). Um 20:56 wurde er beendet. Hast Du ihn da manuell gestoppt oder hast Du FHEM runtergefahren oder wurde er automatisch beendet?

Zum Fehler beim Starten von FHEM: Kommt daher, dass das Modul HMCCU nicht geladen wurde und ein Gerät mit dem Modul HMCCUDEV angelegt werden soll. Gibt es weiter vorne im Log noch andere Meldungen?

Bitte schicke mir mal die Ausgabe von folgendem Befehl (auszuführen im Verzeichnis, in dem die Datei fhem.cfg liegt):

Code: [Auswählen]
grep HMCCU fhem.cfg

Idealerweise alle Einträge (defines, attr) aus der fhem.cfg, die sich auf Geräte der Module HMCCU, HMCCUDEV, HMCCUCHN beziehen. Bitte in der Reihenfolge, wie sie in der fhem.cfg auftauchen.

So, jetzt habe ich die fhem.cfg als ausgemistet und alles nochmal neu angelegt - funktioniert jetzt soweit. Aber schon wieder ist das nächste  Problem aufgetaucht.

Bei jedem Klick auf "on" oder "off" bekomme ich jetzt die Fehlermeldung HMCCUDEV: CCU busy

Das Log ist zugefüllt von folgendem Eintrag:

2016.04.07 20:10:29 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.07 20:10:34 2: HMCCU: Received no events from CCU since 300 seconds

Habt Ihr eine Idee, woran das liegen könnte?
Grüße
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 07 April 2016, 20:18:37
Danke für die schnelle Hilfe... Geholfen hat nun wirklich:

Definition meiner CCU2 in /etc/hosts

danach in fhem Modifikation des define in "define myCCU2 HMCCU myCCU2" und neues straten des rpcserver über "set myCCU2 rpcserver on".... Dann steht im fhem-logfile:


2016.04.07 20:05:31 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/88_HMCCU.pm line 1724.
2016.04.07 20:05:53 0: HMCCU: RPC server started with pid 14898
2016.04.07 20:05:53 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.07 20:05:53 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized


Folgendes Ergebnis bei list myCCU2:

Internals:
   Clients    :HMCCUDEV:HMCCUCHN:
   DEF        myCCU2
   DelDevices 0
   DevCount   79
   NAME       myCCU2
   NR         1232
   NTFY_ORDER 50-myCCU2
   NewDevices 0
   RPCPID     14898
   RPCPRC     ./FHEM/ccurpcd.pl
   RPCState   starting
   STATE      OK
   TYPE       HMCCU
   host       myCCU2
   Readings:
     2016-04-07 20:05:53   rpcstate        starting
     2016-04-07 20:05:54   state           OK
.....


Ist normal, dass "rpcstate" bei "starting" verbleibt? Ich hätte nun "started" erwartet....

Scheint jetzt dank deiner Hilfe zu laufen.... Du könntest nun auch den Fall berücksichtigen, dass man das define mit der IP-Adresse macht.... Nur so als Anregung....

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 07 April 2016, 21:28:40
Anscheinend habt Ihr ähnliche Probleme: der RPC Server startet nicht. Ist mir ein Rätsel, wieso das bei manchen Usern problemlos läuft und bei anderen nicht. Schaut Euch bitte mal die Datei ccurpcd_2001.log im FHEM Logverzeichnis an. Da sollten am Ende Einträge wie ListDevices, Newdevices stehen. Außerdem sollten in /tmp Dateien ccuqueue_2001.dat und .idx stehen, die permanent aktualisiert werden.

Wächst die .dat Datei oder bleibt die bei 0 Byte und nur der Zeitstempel wird aktualisiert?

@Achiim: hier findest Du eine funktionierende Config eines anderen Users, der bei HMCCU die IP angibt.

https://forum.fhem.de/index.php/topic,40189.msg429972.html#msg429972

bitte mal unbedingt das Attribut rpcport auf 2001 setzen. Ich vermute, da geht beim Setzen des Defaultwertes etwas schief.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 07 April 2016, 22:15:40
Hier der Ihnalt meiner ccurpcd_2001.log

07.04.2016 20:06:07 Creating file queue
07.04.2016 20:06:07 Initializing RPC server
07.04.2016 20:06:12 Callback server created listening on port 7401
07.04.2016 20:06:12 Adding callback for events
07.04.2016 20:06:12 Adding callback for new devices
07.04.2016 20:06:12 Adding callback for deleted devices
07.04.2016 20:06:12 Adding callback for modified devices
07.04.2016 20:06:12 Adding callback for replaced devices
07.04.2016 20:06:12 Adding callback for readded devices
07.04.2016 20:06:12 Entering server loop. Use kill -SIGINT 14898 to terminate program
07.04.2016 20:23:34 RPC server terminated
07.04.2016 20:23:34 RPC server received 0 (1) events
07.04.2016 20:27:10 Creating file queue
07.04.2016 20:27:10 Initializing RPC server
07.04.2016 20:27:21 Callback server created listening on port 7401
07.04.2016 20:27:21 Adding callback for events
07.04.2016 20:27:21 Adding callback for new devices
07.04.2016 20:27:21 Adding callback for deleted devices
07.04.2016 20:27:21 Adding callback for modified devices
07.04.2016 20:27:21 Adding callback for replaced devices
07.04.2016 20:27:21 Adding callback for readded devices
07.04.2016 20:27:21 Entering server loop. Use kill -SIGINT 15705 to terminate program
07.04.2016 20:37:40 Creating file queue
07.04.2016 20:37:40 Initializing RPC server
07.04.2016 20:37:49 Callback server created listening on port 7401
07.04.2016 20:37:49 Adding callback for events
07.04.2016 20:37:49 Adding callback for new devices
07.04.2016 20:37:49 Adding callback for deleted devices
07.04.2016 20:37:49 Adding callback for modified devices
07.04.2016 20:37:49 Adding callback for replaced devices
07.04.2016 20:37:49 Adding callback for readded devices
07.04.2016 20:37:49 Entering server loop. Use kill -SIGINT 15790 to terminate program
07.04.2016 20:56:25 RPC server terminated
07.04.2016 20:56:25 RPC server received 86 (87) events


Hinweis:
Ich habe fhem zwischen durch neu gestart mit "shutdown restart" und mit "service fhem stop"  und anschließendem "service fhem start".....

Der rpcserver läuft noch nicht stabil bei mir....

Und hier der Inhalt von ccuqueue_2001.dat:

EV|MEQ0714259:1|LEVEL|1.000000
EV|MEQ0714259:1|WORKING|0
EV|MEQ0714259:1|DIRECTION|0
EV|MEQ0714259:1|ERROR_REDUCED|0
EV|MEQ0714259:1|ERROR_OVERLOAD|0
EV|MEQ0714259:1|ERROR_OVERHEAT|0
EV|MEQ0714259:1|LEVEL_REAL|1.000000
EV|MEQ0714259:2|LEVEL_REAL|1.000000
EV|MEQ0714259:3|LEVEL_REAL|1.000000
EX|SHUTDOWN|15790|CB2001


Die Datei ccuqueue_2001.idx ist 1Byte lang. Und es steht eine "0" drin.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 07 April 2016, 22:29:20
Ok, die Events von der CCU kommen, aber der Init nicht. Deshalb wechselt der Status nicht von Starting auf Running. Das ist ein Timing Problem. Abhilfe morgen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 07 April 2016, 22:39:48
Ich habe noch einen Hinweis:

Wenn ich den rpcserver mit "set myCCU2 rpcserver on" starte, erhalte ich folgende fhem-log-Einträge:


2016.04.07 22:34:08 0: HMCCU: RPC server started with pid 16659
2016.04.07 22:34:08 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.07 22:34:08 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.07 22:34:19 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.07 22:34:22 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pids 16659 f=1
2016.04.07 22:34:22 0: HMCCU: RPC server(s) with PID(s) 16636 shut down. f=1
2016.04.07 22:34:23 0: HMCCU: All RPC servers stopped


Das sieht für mich so aus, alsob er den soeben gestarteten Prozess nicht als den eigenen erkennt und sich selbt dann wieder beendet...

Hinweis 1:
Das Attribut rpcport habe ich, wie gewünscht, auf 2001 gesetzt. Keine Änderung des Verhaltens.

Hinweis 2:
Ich habe das define meiner HMCCU wieder zurück auf die IP-Adresse umgestellt. Das klappt auch, bis auf die Tatsache, dass der rpcserver im Status "starting" verbleibt.

Hinweis 3:
Im Zustand "starting" fehlen in der FHEM-Web-Oberfläche dann die get und set Kommandos. Blendest Du die aus, solange der rpcserver nicht gestartet ist? Oder was ist das für ein Phänomen? Siehe screen-shot..
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 08 April 2016, 06:16:18
So, sorry, war gestern schon im Bett  ;D

Das ist meine ccurpcd_2001.log:

05.04.2016 20:50:54 Creating file queue
05.04.2016 20:50:54 Initializing RPC server
05.04.2016 20:50:54 Callback server created listening on port 7401
05.04.2016 20:50:54 Adding callback for events
05.04.2016 20:50:54 Adding callback for new devices
05.04.2016 20:50:54 Adding callback for deleted devices
05.04.2016 20:50:54 Adding callback for modified devices
05.04.2016 20:50:54 Adding callback for replaced devices
05.04.2016 20:50:54 Adding callback for readded devices
05.04.2016 20:50:54 Entering server loop. Use kill -SIGINT 1233 to terminate program
05.04.2016 20:52:07 RPC server terminated
05.04.2016 20:52:07 RPC server received 90 (91) events
05.04.2016 20:52:36 Creating file queue
05.04.2016 20:52:36 Initializing RPC server
05.04.2016 20:52:36 Callback server created listening on port 7401
05.04.2016 20:52:36 Adding callback for events
05.04.2016 20:52:36 Adding callback for new devices
05.04.2016 20:52:36 Adding callback for deleted devices
05.04.2016 20:52:36 Adding callback for modified devices
05.04.2016 20:52:36 Adding callback for replaced devices
05.04.2016 20:52:36 Adding callback for readded devices
05.04.2016 20:52:36 Entering server loop. Use kill -SIGINT 1509 to terminate program
05.04.2016 20:52:52 RPC server terminated
05.04.2016 20:52:52 RPC server received 0 (1) events
05.04.2016 20:54:53 Creating file queue
05.04.2016 20:54:53 Initializing RPC server
05.04.2016 20:54:54 Callback server created listening on port 7401
05.04.2016 20:54:54 Adding callback for events
05.04.2016 20:54:54 Adding callback for new devices
05.04.2016 20:54:54 Adding callback for deleted devices
05.04.2016 20:54:54 Adding callback for modified devices
05.04.2016 20:54:54 Adding callback for replaced devices
05.04.2016 20:54:54 Adding callback for readded devices
05.04.2016 20:54:54 Entering server loop. Use kill -SIGINT 1229 to terminate program
05.04.2016 20:56:41 RPC server terminated
05.04.2016 20:56:41 RPC server received 92 (93) events
05.04.2016 22:24:56 Creating file queue
05.04.2016 22:24:56 Initializing RPC server
05.04.2016 22:24:56 Callback server created listening on port 7401
05.04.2016 22:24:56 Adding callback for events
05.04.2016 22:24:56 Adding callback for new devices
05.04.2016 22:24:56 Adding callback for deleted devices
05.04.2016 22:24:56 Adding callback for modified devices
05.04.2016 22:24:56 Adding callback for replaced devices
05.04.2016 22:24:56 Adding callback for readded devices
05.04.2016 22:24:56 Entering server loop. Use kill -SIGINT 2165 to terminate program
05.04.2016 22:29:04 Received 250 events from CCU since last check
05.04.2016 22:33:38 RPC server terminated
05.04.2016 22:33:38 RPC server received 490 (490) events
05.04.2016 22:35:03 Creating file queue
05.04.2016 22:35:03 Initializing RPC server
05.04.2016 22:35:03 Callback server created listening on port 7401
05.04.2016 22:35:03 Adding callback for events
05.04.2016 22:35:03 Adding callback for new devices
05.04.2016 22:35:03 Adding callback for deleted devices
05.04.2016 22:35:03 Adding callback for modified devices
05.04.2016 22:35:03 Adding callback for replaced devices
05.04.2016 22:35:03 Adding callback for readded devices
05.04.2016 22:35:03 Entering server loop. Use kill -SIGINT 1241 to terminate program
05.04.2016 22:40:37 Received 250 events from CCU since last check
05.04.2016 22:43:41 RPC server terminated
05.04.2016 22:43:41 RPC server received 427 (427) events
05.04.2016 22:44:04 Creating file queue
05.04.2016 22:44:04 Initializing RPC server
05.04.2016 22:44:04 Callback server created listening on port 7401
05.04.2016 22:44:04 Adding callback for events
05.04.2016 22:44:04 Adding callback for new devices
05.04.2016 22:44:04 Adding callback for deleted devices
05.04.2016 22:44:04 Adding callback for modified devices
05.04.2016 22:44:04 Adding callback for replaced devices
05.04.2016 22:44:04 Adding callback for readded devices
05.04.2016 22:44:04 Entering server loop. Use kill -SIGINT 2073 to terminate program
05.04.2016 22:48:36 Received 250 events from CCU since last check
07.04.2016 20:19:53 RPC server terminated
07.04.2016 20:19:53 RPC server received 32642 (32642) events
07.04.2016 20:20:18 Creating file queue
07.04.2016 20:20:18 Initializing RPC server
07.04.2016 20:20:18 Callback server created listening on port 7401
07.04.2016 20:20:18 Adding callback for events
07.04.2016 20:20:18 Adding callback for new devices
07.04.2016 20:20:18 Adding callback for deleted devices
07.04.2016 20:20:18 Adding callback for modified devices
07.04.2016 20:20:18 Adding callback for replaced devices
07.04.2016 20:20:18 Adding callback for readded devices
07.04.2016 20:20:18 Entering server loop. Use kill -SIGINT 22416 to terminate program
07.04.2016 20:24:51 Received 250 events from CCU since last check
07.04.2016 20:35:49 RPC server terminated
07.04.2016 20:35:49 RPC server received 826 (826) events
07.04.2016 20:37:04 Creating file queue
07.04.2016 20:37:04 Initializing RPC server
07.04.2016 20:37:04 Callback server created listening on port 7401
07.04.2016 20:37:04 Adding callback for events
07.04.2016 20:37:04 Adding callback for new devices
07.04.2016 20:37:04 Adding callback for deleted devices
07.04.2016 20:37:04 Adding callback for modified devices
07.04.2016 20:37:04 Adding callback for replaced devices
07.04.2016 20:37:04 Adding callback for readded devices
07.04.2016 20:37:04 Entering server loop. Use kill -SIGINT 1250 to terminate program
07.04.2016 20:42:17 Received 250 events from CCU since last check
 

Hier die ccuqueue_2001.dat:

cat ccuqueue_2001.dat
EV|LEQ0002140:2|ACTUAL_TEMPERATURE|18.000000
EV|LEQ0002140:2|ACTUAL_HUMIDITY|52.000000
EV|LEQ0002140:2|SET_TEMPERATURE|4.500000
EV|HEQ0508540:1|TEMPERATURE|19.100000
EV|HEQ0508540:1|HUMIDITY|65

Die ccuqueue_2001.idx: hat bei mir auch 1 byte und enthält auch bei mir nur eine 0.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 08 April 2016, 08:50:54
Hallo Achiim,

ich hatte vor einiger Zeit ähnliche Probleme wie du.
Jedoch ging bei mir auschließlich define HMCCU mit der IP-Adresse und nicht mit dem Namen.

Zitat
Hinweis 3:
Im Zustand "starting" fehlen in der FHEM-Web-Oberfläche dann die get und set Kommandos. Blendest Du die aus, solange der rpcserver nicht gestartet ist? Oder was ist das für ein Phänomen? Siehe screen-shot..
Solange dein RPCServer nicht ordnungsgemäß läuft, hast du die "get" und "set" Befehle nicht zur Verfügung.

Kleiner Tipp meinerseits: Oftmals hilft folgendes:

Viele Grüße
Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 April 2016, 09:05:51
@Nic0205, Achiim: Die Ursache für Eure Probleme dürfte die gleiche sein. Kurze Erläuterung zum Start des RPC-Servers:

1. Befehl "set rpcserver on" wird abgesetzt
2. HMCCU startet ccurpcd.pl als separaten Prozess. In diesem Prozess wird ein RPC-Server initialisiert, der auf einem TCP-Port LISTENed und auf Daten der CCU wartet.
3. HMCCU wartet nach Step 2 für 2 Sekunden und regisitriert dann den RPC-Server bei der CCU, damit die weiß, wo sie ihre Events hinschicken soll.
4. Die CCU schickt nun diverse Anfragen an den RPC-Server (u.a. ListDevices). Wenn HMCCU dieses "ListDevices" empfängt, wechselt der Status von "starting" auf "running".

Das Problem tritt vermutlich zwischen Step 2 und 3 auf. Die CCU schickt schon ihre Initilaisierungs-Events, der RPC-Server ist aber noch nicht im LISTENing Mode. Daher geht z.B. "ListDevices" ins Leere und der Status bleibt "running". Die später gesendeten normalen Events für die Geräte kommen dann an.

@Achiim: Die get/set Befehle blende ich aus, so lange der RPCState nicht "stopped" oder "running" ist. Grund: während der Initialisierung der Verbindung ist die CCU stark ausgelastet, sodass Befehle nicht zuverlässig ausgeführt werden. Normalerweise geht der Start aber so schnell, dass das nicht relevant ist.

Die Fehlermeldung "Externally launched ..." besagt, dass noch ein ccurpcd.pl Prozess läuft. Vermutlich hast Du FHEM neu gestartet während der RPCState noch "starting" war. Der Prozess wurde dann nicht korrekt beendet. Ich werde die Stop Prozedur des RPC-Servers so ändern, dass grundsätzlich alle Prozesse gekillt werden.

Noch ein Tipp:
Um einen RPC-Server Prozess (ccurpcd.pl) sauber zu beenden, kann man von der Unix-Kommandozeile aus folgenden Befehl nutzen:

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

Port ist der RPC-Port (bei wireless 2001), pid die Prozess-ID (siehe Log oder ps ax | grep ccurpcd)

Der Vorteil: Bei dieser Methode wird der RPC-Server bei der CCU sauber abgemeldet. Normalerweise wechselt dann auch der Status in HMCCU wieder von "Starting" auf "Stopped".

Wie gesagt: Die Timing Probleme versuche ich noch heute zu beheben. Ist nur etwas aufwändig, da bei mir schon die neue Version läuft (ist aber noch nicht für die Allgemeinheit tauglich). Muss jetzt erst die alte wieder aktivieren, das Problem beheben, testen ...



Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 08 April 2016, 12:53:55
Danke für die Unterstützung und wertvollen Tipps. Aber ich komme nicht weiter..
Ich glaube es bestehen zwei Probleme:

Problem 1:
Wie es zap beschreibt, das Timeingproblem beim Start des rpcserver. Hier warte ich ab, ob die von zap angekündigte neue Version eine Besserung bringt.

Problem 2:
Ich habe die von Euch beschriebenen Tipps angewand, aber ich bringe den rpcserver nicht dazu nach dem Start bestehen zu bleiben. Er beendet sich immer wieder (von selbst?)....
Ich habe meine CCU und FHEM wie angeraten neu gestartet, kontrolliert dass kein rpcserver Prozess in Linux läuft und dann über "set myCCU2 rpcserver on" den RPC-Server gestartet und im FHEM-Log sehe ich folgendes:

2016.04.08 11:56:22 0: HMCCU: RPC server started with pid 4246
2016.04.08 11:56:22 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.08 11:56:23 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 11:56:42 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.08 11:56:44 1: HMCCU: Externally launched RPC server(s) detected. Kill process(es) manually with command kill -SIGINT pid for pids 4246 f=1
2016.04.08 11:56:44 0: HMCCU: RPC server(s) with PID(s) 4175 shut down. f=1
2016.04.08 11:56:44 0: HMCCU: All RPC servers stopped

a) der RPC server wird mit der PID 4246 gestartet
b) es wird ein "Externally launched RPC server(s) detected" und zwar mit der PID 4246

Das ist der der gerade gestartete Prozess und kein "Externally launched RPC server"..

Danach werden alle Prozesse wieder beendet und der RPC-Server ist wieder weg.

Hat das auch mit dem Timeing zu tun oder ist das ein anderes Problem?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 08 April 2016, 15:30:11
Ich habe einen ersten Teilerfolg erzielt...

Ich hatte bisher nur meine CCU2 definiert mit: "define myCCU2 HMCCU 192.....". Nachdem ich nun auch ein erstes Device definiert habe mit: "define d_Stehlampe HMCCUDEV MEQ... 1" habe sogar Statuswerte von diesem Gerät erhalten, obwohl definitiv kein rpcserver lief.

Internals:
   CFGFN
   DEF        MEQ0714259 1
   IODev      myCCU
   NAME       d_Stehlampe
   NR         1392
   STATE      Error
   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-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.DIRECTION 0
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERHEAT false
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_OVERLOAD false
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.ERROR_REDUCED false
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.INHIBIT false
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL 0.000000
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.LEVEL_REAL 0.000000
     2016-04-08 13:36:03   HM-LC-Dim1T-Pl-3_MEQ0714259.1.WORKING false
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.DIRECTION 0
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERHEAT false
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_OVERLOAD false
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.ERROR_REDUCED false
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.INHIBIT false
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL 0.000000
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.LEVEL_REAL 0.000000
     2016-04-08 13:36:22   HM-LC-Dim1T-Pl-3_MEQ0714259.2.WORKING false
     2016-04-08 13:43:23   state           Error
Attributes:
   IODev      myCCU
   room       HMCCU
   statechannel 1
   statevals  on:true,off:false
   substitute true:on,false:off,1:on,0:off

Ich habe dann die CCU neu gestartet und den RPS-Server dann mit "set myCCU rpcserver on" gestartet. Dann ist er tatsächlich losgelaufen und oben geblieben. Siehe Logfile-Auszug.

2016.04.08 15:04:52 0: HMCCU: RPC server started with pid 4320
2016.04.08 15:04:52 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001
2016.04.08 15:04:54 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.08 15:05:04 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:10 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:16 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:05:57 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:06:56 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:07:57 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:45 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:51 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:08:57 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:15 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:21 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:27 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:44 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:50 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:09:56 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:02 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:08 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:14 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:20 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:26 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:38 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:44 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:50 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:10:56 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:01 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:07 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:14 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:20 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:26 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:33 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:39 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:46 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:52 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:11:58 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:03 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:09 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:14 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:20 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:26 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:32 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.08 15:12:38 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.04.08 15:12:39 0: HMCCU: RPC server(s) with PID(s) 4320 shut down. f=1
2016.04.08 15:12:39 0: HMCCU: All RPC servers stopped

Der Status des RPC-Server in "starting" verbleibt, habe ich dann den rpcserver mit "ccurpcd.pl shutdown <ccuhost_or_ip> <port> <pid>" beendet. Das sieht man auch um Log "...4320 shut down..."

Kann das sein, dass ohne die Definition eines Devices der RPC-Server nicht läuft?

Die Meldung mit den 300s kommt alle 6 Sekunden. Hier könnte der Code auch noch optimiert werden.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 April 2016, 16:46:02
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:

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:

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!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 08 April 2016, 18:08:57
Leider noch keine entscheidende Änderung:

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

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:

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:

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:

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....  8))

BTW:  :)  :) Was sind eigentlich readded devices? Sterben die nach dem Lesen? Das ist dem "ccurpcd_2001.log" zu entnehmen..."Adding callback for readded devices"  ;) ;) ;D
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 April 2016, 19:01:25
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).



Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 08 April 2016, 19:14:19
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"....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 08 April 2016, 20:33:14
Hallo zap,

bei mir sieht es sehr ähnlich aus. Ich habe die gleiche Hardwarebasis (Pi 2B) und folgende Logs:
rpc-log
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
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 set kueche_wandleuchte on  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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 08 April 2016, 22:00:46
@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.



Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 08 April 2016, 22:04:57
Hallo zap,

so ist die Definition:

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

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 09 April 2016, 01:26:34
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...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 09 April 2016, 09:50:12
zum Stand der Dinge:


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:

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:

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
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 09 April 2016, 12:33:10
Hallo zap,

so ist die Definition:

   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:

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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 09 April 2016, 12:56:40
Das "Timing-Problem" beim Start sollte noch gelöst werden

Ist in Arbeit.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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:

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

Im Log steht dann:

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:

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

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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 09 April 2016, 13:15:11
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.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 09 April 2016, 15:17:58
Danke für deine Hilfe. Mit der Definition des "statedatapoint" hat es geklappt. Das sieht bei mir jetz so aus

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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 09 April 2016, 16:54:20
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.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 09 April 2016, 22:11:57
Hallo zap,

ich sage mal fast...  ::)

Ich habe den Test nur auf dem PI2 gemacht.

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....  ;D

Ich habe es gleich nochmal versucht. Das Verhalten scheint reproduzierbar.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 09 April 2016, 22:55:32
Verständnisfrage: Das Ergebnis von get d_Stehlampe deviceinfo wird in einem Fenster angezeigt als:

CHN MEQ0714259:0 HM-LC-Dim1T-Pl-3 MEQ0714259:0
  DPT {b} BidCos-RF.MEQ0714259:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.DUTYCYCLE = false [RE]
  DPT {8} BidCos-RF.MEQ0714259:0.RSSI_DEVICE = 1 [RE]
  DPT {8} BidCos-RF.MEQ0714259:0.RSSI_PEER = 44 [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.DEVICE_IN_BOOTLOADER = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:0.UPDATE_PENDING = false [RE]
  DPT {8} BidCos-RF.MEQ0714259:0.AES_KEY = 0 [R]
CHN MEQ0714259:1 WZ-Stehlampe-1
  DPT {6} BidCos-RF.MEQ0714259:1.LEVEL = 1.000000 [RWE]
  DPT {b} BidCos-RF.MEQ0714259:1.OLD_LEVEL =  [W]
  DPT {f} BidCos-RF.MEQ0714259:1.LEVEL_REAL = 1.000000 [RE]
  DPT {f} BidCos-RF.MEQ0714259:1.RAMP_TIME =  [W]
  DPT {f} BidCos-RF.MEQ0714259:1.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0714259:1.RAMP_STOP =  [W]
  DPT {b} BidCos-RF.MEQ0714259:1.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:1.ERROR_REDUCED = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:1.ERROR_OVERLOAD = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:1.ERROR_OVERHEAT = false [RE]
  DPT {i} BidCos-RF.MEQ0714259:1.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQ0714259:1.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0714259:1.WORKING = false [RE]
CHN MEQ0714259:2 HM-LC-Dim1T-Pl-3 MEQ0714259:2
  DPT {6} BidCos-RF.MEQ0714259:2.LEVEL = 0.000000 [RWE]
  DPT {b} BidCos-RF.MEQ0714259:2.OLD_LEVEL =  [W]
  DPT {f} BidCos-RF.MEQ0714259:2.LEVEL_REAL = 1.000000 [RE]
  DPT {f} BidCos-RF.MEQ0714259:2.RAMP_TIME =  [W]
  DPT {f} BidCos-RF.MEQ0714259:2.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0714259:2.RAMP_STOP =  [W]
  DPT {b} BidCos-RF.MEQ0714259:2.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:2.ERROR_REDUCED = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:2.ERROR_OVERLOAD = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:2.ERROR_OVERHEAT = false [RE]
  DPT {i} BidCos-RF.MEQ0714259:2.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQ0714259:2.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0714259:2.WORKING = false [RE]
CHN MEQ0714259:3 HM-LC-Dim1T-Pl-3 MEQ0714259:3
  DPT {6} BidCos-RF.MEQ0714259:3.LEVEL = 0.000000 [RWE]
  DPT {b} BidCos-RF.MEQ0714259:3.OLD_LEVEL =  [W]
  DPT {f} BidCos-RF.MEQ0714259:3.LEVEL_REAL = 1.000000 [RE]
  DPT {f} BidCos-RF.MEQ0714259:3.RAMP_TIME =  [W]
  DPT {f} BidCos-RF.MEQ0714259:3.ON_TIME =  [W]
  DPT {b} BidCos-RF.MEQ0714259:3.RAMP_STOP =  [W]
  DPT {b} BidCos-RF.MEQ0714259:3.INHIBIT = false [RWE]
  DPT {b} BidCos-RF.MEQ0714259:3.ERROR_REDUCED = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:3.ERROR_OVERLOAD = false [RE]
  DPT {b} BidCos-RF.MEQ0714259:3.ERROR_OVERHEAT = false [RE]
  DPT {i} BidCos-RF.MEQ0714259:3.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQ0714259:3.INSTALL_TEST =  [W]
  DPT {b} BidCos-RF.MEQ0714259:3.WORKING = false [RE]

Wie kann ich das in Verbindung bringen zu den in der CCU angezeigten Werten?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 00:11:08
Den Slider habe ich nun so definiert:

define d_Stehlampe HMCCUDEV MEQ0714259 1
attr d_Stehlampe IODev myCCU2
attr d_Stehlampe ccureadings 1
attr d_Stehlampe controldatapoint 1.LEVEL
attr d_Stehlampe event-on-change-reading .*
attr d_Stehlampe statechannel 1
attr d_Stehlampe statedatapoint LEVEL
attr d_Stehlampe statevals on:1.0,off:0.0
attr d_Stehlampe stripnumber 1
attr d_Stehlampe substitute 1.0:on,0.0:off
attr d_Stehlampe webCmd control
attr d_Stehlampe widgetOverride control:slider,0,0.25,1,1

substitute hat noch keine Wirkung.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 10:57:28
Heute habe ich meinen PI2 mit der Testversion von gestern (neues 88_HMCCU.pm und ccurpcd.pl ) neu gestartet und im FHEM-Log folgendes entdeckt:

2016.04.10 10:32:06 0: Server shutdown
2016.04.10 10:32:08 0: HMCCU: RPC server not running
Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug

Keine Ahnung, ob das eine Meldung von HMCCU ist....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 14:25:31
Solange der RPCServer auf meiner zentralen FHEM-Installation nicht läuft, habe ich mir wie folgt beholfen... Auch wenn's vielleicht etwas übertrieben erscheint....  ::) ::) ::)

1 Ich habe meine programmierbare  HM Fernbedienung (HM-RC-Dis-H-x-EU) über die CCU2 angemeldet, da ich mit der Konfiguration dieser über FHEM nicht klar kam. Dort habe ich mir zwei Funktionen (Rolladen hoch und Rolladen runter) auf die Fernbedienung gelegt.

2 Die CCU2 meldet nun über den registrierten rpcserver, der bei mir leider nur im Keller auf dem piKeller (PI3) läuft, jeden Tastendruck der Fernbedienung.

3 Über eine FHEM2FHEM-Verbingung habe ich mein FHEM auf dem piHägelesweg mit dem FHEM auf dem piKeller gekoppelt. Alle Ereignisse der Fernbedienung werden darüber zum zentralen FHEM übermittelt.

4 Über ein notify werden nun auf dem piHägelesweg alle Tastendrücke der HM-Fernbedienung registriert und ich steuere je nach gedrückter Taste den Rademacherrolladen im Wohnzimmer.


Kaum zu glauben, aber das funktioniert.... Herzlichen Dank für dieses tolle Modul ---> und es stimmt was zap uns hier verspricht: "best of both worlds approach"

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 10 April 2016, 18:47:57
Hallo Achiim,

gerade nach Hause gekommen. Muss Deine Posts erst mal sortieren ...

Also der SL Event ist neu. Damit meldet ccurpcd.pl an HMCCU, dass er kurz davor ist, den RPC Server Loop zu starten. Eigentlich sollte HMCCU den Event kennen, vielleicht habe ich aber auch die falsche Version angehängt. Bist Du sicher, dass Du die Version 3.1b runtergeladen, installiert und auch in FHEM geladen hast?? Bei mir funktioniert das nämlich und die Meldung "unknown event" kommt auch nicht.

HMCCU bzw. HMCCUDEV/CHN liefern die offiziellen Datenpunkt-Namen, die man auch folgendem Dokument entnehmen kann:

http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf

Leider unterscheiden sich die Bezeichnungen in der CCU Weboberfläche von den Datenpunktnamen. Bei einigen kann man den Zusammenhang ableiten, bei anderen hilft nur ausprobieren. Dein Screenshot zeigt übrigens nicht die Datenpunkte sondern die Konfigurationsparameter. Diese werden mit get/set config gelesen oder gesetzt. Die Werte aus den Datenpunkten findest Du in der CCU z.B. unter "Status und Bedienung/Geräte".

Die Ausgabe von get deviceinfo ist übrigens sehr hilfreich, wenn man die interessanten Datenpunkte herausfinden möchte, um z.B. das Attribut ccureadingfilter zu setzen. Insbesondere die Angaben in den eckigen Klammern sind nützlich: R=Read, W=Write, E=Event. Bei einem Datenpunkt, der kein W hat, ist ein set Befehl sinnlos. Umgekehrt: Fehlt das R, kann man diesen Datenpunkt bei get ignorieren.

Ein gutes Beispiel sind Thermostate: Hier gibt es den Datenpunkt CONTROL_MODE, mit dem man den aktuellen Steuermodus auslesen kann [RE]. Eingestellt wird der Modus aber über MANU_MODE oder AUTO_MODE, beide [W].

Die folgende Meldung hat nichts mit HMCCU zu tun (ich schreibe immer "HMCCU:" davor):

Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug

zum substitute beim Dimmer: Das kann nicht funktionieren, da substitute Fließkommazahlen ignoriert (sonst hat das unangenehme Seiteneffekte auf alle nummerischen Readings). Aber ich überlege mal, was man da machen kann. Blöd ist halt, dass der Dimmer kein STATE mit true oder false für ein / aus hat.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 20:12:47
Also:

Ich habe die Versions geprüft und habe unterschiedliche Angaben gefunden ....

In FHEM kommt mit ... "version 88_*"

File           Rev   Last Change

88_HMCCU.pm    11140 2016-03-28 16:57:53Z fhemzap
No Id found for 88_HMCCUDEV.pm


In der von Dir gestern gelieferten 88_HMCCU.pm steht:

#  88_HMCCU.pm
#
#  $Id: 88_HMCCU.pm 11140 2016-03-28 16:57:53Z fhemzap $
#
#  Version 3.1b
#
#  Module for communication between FHEM and Homematic CCU2.
#  Supports BidCos-RF, BidCos-Wired, HmIP-RF.
#
#  (c) 2016 zap (zap01 <at> t-online <dot> de)
#

Im Code von 88_HMCCU.pm  ist nur eine Stelle, die aus SL reagiert:

elsif ($Tokens[0] eq 'SL') {
#### RPC Server going to start server loop ###
Log3 $name, 0, "HMCCU: Received SL event. RPC server ".$Tokens[2]." starting server loop.";
$hash->{hmccu}{rpc}{$Tokens[2]}{loop} = 1;
InternalTimer (gettimeofday()+$HMCCU_INIT_INTERVAL1, 'HMCCU_RPCRegisterCallback', $hash, 0);
return;
}

Das scheint alles okay und auch an der richtigen Stelle installiert zu sein... dann probiere ich es eben nochmal....

2016.04.10 20:07:05 0: HMCCU: RPC server started with pid 2552
2016.04.10 20:07:29 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.10 20:07:34 1: HMCCU: Registering callback http://192.168.178.21:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.04.10 20:07:35 1: HMCCU: RPC callback with URL http://192.168.178.21:7401/fh2001 initialized
2016.04.10 20:07:40 0: HMCCU: Received IN event. RPC server CB2001 initialized.

Und siehe da... der RPC-Server läuft und läuft und läuft.....

Ich habe nix geändert... Einfach nochmal probiert und es tut....  :o 8)

War wohl irgendwie mein Fehler.... Gestern ist es spät geworden... Danke.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 20:20:52
Datenpunkte? Also für meine Stehlampe finde ich in der CCU unter "Status und Bedienung/Geräte":
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 20:39:58
Bezogen auf die komische Meldung
Signal 18 (CONT) caught by ps (procps-ng version 3.3.3).
ps:display.c:59: please report this bug
habe ich folgenden Hinweis gefunden:

https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1055551 (https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1055551)

Kann es sein dass die Meldung indirekt von Dir ist, da Du vermutlich mit ps prüfst, ob noch ein rpcserver läuft...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 10 April 2016, 21:57:48
Benutzt Du denn zsh statt bash? Nur da soll dieser Fehler auftreten.
Aber grundsätzlich: ja, ich nutze ps für die Prozessprüfung.

Zu den Datenpunkten: ja das meine ich. Das ansteigende Dreieck ist der Datenpunkt LEVEL. Du solltest Dir mal die PDF anschauen, die ich verlinkt hatte. Da wird für jedes Gerät jeder Datenpunkt mit Funktion beschrieben. Darauf greifst Du mit "get datapoint" oder "set datapoint" zu. set devstate ist nur ein Sonderfall von set datappoint eben für den statedatapoint.

Daneben gibt es noch die Config-Parameter. Hier werden interne Parameter der Geräte festgelegt, die keinen direkten Effekt auslösen sondern das generelle Verhalten eines Gerätes beeinflussen.

In der CCu werden die Datenpunkte möglichst einfach und grafisch dargestellt. Letztendlich greift die Weboberfläche aber auch nur auf Datenpunkte und Config Parameter zu.

Danke nochmal fürs Testen. Werde das morgen einchecken.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 10 April 2016, 23:28:18
Langsam verstehe ich die Bedeutung der Readings.... Aber intuitiv ist anders.... Das liegt aber eher an eQ3...


Noch eine Kleinigkeit..

Wie angeraten nutzte ich den ccureadingfilter und zwar mit der Einstellung: "^WZ-Stehlampe-1!(LEVEL|ON_TIME|RAMP_TIME|RAMP_STOP). Dieser Filter zeigt etwas mehr als ich erwartet hätte. Warum kommen auch die Readings "WZ-Stehlampe-1.LEVEL_REAL" und "WZ-Stehlampe-1.OLD_LEVEL" durch? Siehe screenshot.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 April 2016, 07:39:15
Langsam verstehe ich die Bedeutung der Readings.... Aber intuitiv ist anders.... Das liegt aber eher an eQ3...

Die Reading-Namen werden aus den Datenpunkt-Namen oder den Namen der Config-Parameter gebildet (dann mit "R_" davor, weil das CUL_HM auch so macht). Vielleicht noch gut zu wissen: Der RPC-Server aktualisiert nur Datenpunkte, keine Config-Parameter (kein Fehler sondern "ist halt so (EQ3)"). Aber ich denke, im täglichen Betrieb wird man die Config-Parameter eher selten nutzen. Wenn ich da was einstellen muss, mache ich das direkt in der CCU.

Zitat
Wie angeraten nutzte ich den ccureadingfilter und zwar mit der Einstellung: "^WZ-Stehlampe-1!(LEVEL|ON_TIME|RAMP_TIME|RAMP_STOP). Dieser Filter zeigt etwas mehr als ich erwartet hätte. Warum kommen auch die Readings "WZ-Stehlampe-1.LEVEL_REAL" und "WZ-Stehlampe-1.OLD_LEVEL" durch? Siehe screenshot.

Der reguläre Ausdruck LEVEL matched alle Datenpunkte, die LEVEL enthalten. So dürfte es funktionieren:

^WZ-Stehlampe-1!(^LEVEL$|ON_TIME|RAMP_TIME|RAMP_STOP)

Wenn Du sowieso nur einen Kanal (hier WZ-Stehlampe-1) betrachtest, kannst Du "^WZ-Stehlampe-1!" auch weglassen. Dann bezieht sich der Filter auf alle Kanäle.

Eine weitere Vereinfachung, wenn Du bei einem Gerät nur einen Kanal verwendest, wäre HMCCUCHN statt HMCCUDEV effizienter. Dann sparst Du Dir z.B. bei set datapoint die Angabe der Kanalnummer.

In HMCCUDEV:

set xyz datapoint 1.LEVEL 0.5

In HMCCUCHN:

set xyz datapoint LEVEL 0.5


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: tuppertasse am 11 April 2016, 08:23:51
In den nächsten 1-2 Wochen wird es ein Update geben, das wahlweise ohne den externen RPC-Server auskommt (verwendet dann einen internen Sub-Prozess).

Hi zap,
klappt das diese Woche mit deinem angekündigten Update ?
frage nur nach, da ich das wenn sofort ausprobieren wollte :-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 10:23:15
Verständnisfrage:

Wie definiere ich eine Rauchmeldergruppe? Gemäß Anleitung (Readme) finde ich folgendes:

Define a new client device group:
   define <name> HMCCUDEV <ccu-group-device> [<state-channel>] [readonly]
      {group={<device>|<channel>}[,...]|groupexp=<expression>}

meine Interpretation dieser Syntax war wie folgt:

define d_Rauchmelderteam HMCCUDEV *MEQ0257246 1 group=MEQ0257246,NEQ0197808
oder
define d_Rauchmelderteam HMCCUDEV Rauchmeldeteam 1 group=MEQ0257246,NEQ0197808

Beides liefert in FHEM: Invalid or unknown CCU device name or address

Update: Oh, da war ein Schreibfehler drin... Jetzt mit "r"

define d_Rauchmelderteam HMCCUDEV Rauchmelderteam 1 group=MEQ0257246,NEQ0197808

liefert in FHEM: CCU device address not found for Rauchmelderteam


Die devicelist der HMCCU (get myCCU devicelist dump) sieht wie folgt aus:

Rauchmelderteam
Rauchmelderteam:0
Rauchmelderteam:1
HM-RCV-50 BidCoS-RF
HM-RCV-50 BidCoS-RF:0
HM-RCV-50 BidCoS-RF:1
HM-RCV-50 BidCoS-RF:10
HM-RCV-50 BidCoS-RF:11
HM-RCV-50 BidCoS-RF:12
HM-RCV-50 BidCoS-RF:13
HM-RCV-50 BidCoS-RF:14
HM-RCV-50 BidCoS-RF:15
HM-RCV-50 BidCoS-RF:16
HM-RCV-50 BidCoS-RF:17
HM-RCV-50 BidCoS-RF:18
HM-RCV-50 BidCoS-RF:19
HM-RCV-50 BidCoS-RF:2
HM-RCV-50 BidCoS-RF:20
HM-RCV-50 BidCoS-RF:21
HM-RCV-50 BidCoS-RF:22
HM-RCV-50 BidCoS-RF:23
HM-RCV-50 BidCoS-RF:24
HM-RCV-50 BidCoS-RF:25
HM-RCV-50 BidCoS-RF:26
HM-RCV-50 BidCoS-RF:27
HM-RCV-50 BidCoS-RF:28
HM-RCV-50 BidCoS-RF:29
HM-RCV-50 BidCoS-RF:3
HM-RCV-50 BidCoS-RF:30
HM-RCV-50 BidCoS-RF:31
HM-RCV-50 BidCoS-RF:32
HM-RCV-50 BidCoS-RF:33
HM-RCV-50 BidCoS-RF:34
HM-RCV-50 BidCoS-RF:35
HM-RCV-50 BidCoS-RF:36
HM-RCV-50 BidCoS-RF:37
HM-RCV-50 BidCoS-RF:38
HM-RCV-50 BidCoS-RF:39
HM-RCV-50 BidCoS-RF:4
HM-RCV-50 BidCoS-RF:40
HM-RCV-50 BidCoS-RF:41
HM-RCV-50 BidCoS-RF:42
HM-RCV-50 BidCoS-RF:43
HM-RCV-50 BidCoS-RF:44
HM-RCV-50 BidCoS-RF:45
HM-RCV-50 BidCoS-RF:46
HM-RCV-50 BidCoS-RF:47
HM-RCV-50 BidCoS-RF:48
HM-RCV-50 BidCoS-RF:49
HM-RCV-50 BidCoS-RF:5
HM-RCV-50 BidCoS-RF:50
HM-RCV-50 BidCoS-RF:6
HM-RCV-50 BidCoS-RF:7
HM-RCV-50 BidCoS-RF:8
HM-RCV-50 BidCoS-RF:9
AZ-Rauchmelder
AZ-Rauchmelder:0
AZ-Rauchmelder:1
HM-RC-Dis-H-x-EU MEQ0670565
HM-RC-Dis-H-x-EU MEQ0670565:0
Stehlampe an-dim:1
HM-RC-Dis-H-x-EU MEQ0670565:10
HM-RC-Dis-H-x-EU MEQ0670565:11
HM-RC-Dis-H-x-EU MEQ0670565:12
HM-RC-Dis-H-x-EU MEQ0670565:13
HM-RC-Dis-H-x-EU MEQ0670565:14
HM-RC-Dis-H-x-EU MEQ0670565:15
HM-RC-Dis-H-x-EU MEQ0670565:16
HM-RC-Dis-H-x-EU MEQ0670565:17
HM-RC-Dis-H-x-EU MEQ0670565:18
HM-RC-Dis-H-x-EU MEQ0670565:19
Stehlampe aus-dim:2
HM-RC-Dis-H-x-EU MEQ0670565:20
WZ-Rolladen-hoch:3
WZ-Rolladen-runter:4
HM-RC-Dis-H-x-EU MEQ0670565:8
HM-RC-Dis-H-x-EU MEQ0670565:9
HM-LC-Dim1T-Pl-3 MEQ0714259
HM-LC-Dim1T-Pl-3 MEQ0714259:0
WZ-Stehlampe-1
HM-LC-Dim1T-Pl-3 MEQ0714259:2
HM-LC-Dim1T-Pl-3 MEQ0714259:3
SZ-Rauchmelder
SZ-Rauchmelder:0
HM-Sec-SD NEQ0197808:1

Leider gibt es die Option "dump" in der FHEM-Oberfläche für "devicelist" nicht, sodass man das über die Komandozeile eingeben muss, wenn man eine Liste der in HMCCU bekannten Geräte haben will.

Hinweis:
In der CCU sieht die Definition der Rauchmeldergruppe so wie auf dem Screenshot aus.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 April 2016, 12:06:05
Hi zap,
klappt das diese Woche mit deinem angekündigten Update ?
frage nur nach, da ich das wenn sofort ausprobieren wollte :-)

Das Timing Problem mit dem RPC-Server Start hat mich ziemlich viel Zeit und Nerven gekostet. Ich muss die Änderungen jetzt erst mal in meine (eigentlich schon lauffähige) neue Version integrieren, damit nach dem nächsten Update das Problem nicht wieder da ist. Mal sehen ;-)
Hängt auch vom Wetter ab: Schlechtes Wetter => FHEM Entwicklung. Gutes Wetter => Mountain Bike.

@Achiim: Muss ich mir zuhause mal anschauen. Habe keine Rauchmeldergruppe, nur Heizungsgruppen. Wenn Du die Adresse der Gruppe verwendest, muss jedenfalls der "*" weggelassen werden.

Prinzipiell sehen Deine defines aber gut aus.

Was sagt denn "get myCCU deviceinfo Rauchmelderteam" ?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 13:58:37
Auf ... get myCCU deviceinfo Rauchmelderteam .... kommt:

CHN *MEQ0257246:1 Rauchmelderteam:1
  DPT {b} BidCos-RF.*MEQ0257246:1.STATE = false [RE]
  DPT {b} BidCos-RF.*MEQ0257246:1.INSTALL_TEST =  [E]
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 15:12:07
Problem scheint gelöst zu sein. Ich habe es virtuell definiert. Dann hat es sich anlegen lassen mit ... define d_Rauchmelderteam virtual 1 group=AZ-Rauchmelder,SZ-Rauchmelder ... ging es und zeigt mir folgende Werte an:

Internals:
   CFGFN
   DEF        virtual 1 group=AZ-Rauchmelder,SZ-Rauchmelder
   IODev      myCCU
   NAME       d_Rauchmelderteam
   NR         4295
   STATE      false
   TYPE       HMCCUDEV
   ccuaddr    VIR0000001
   ccudevstate Active
   ccugroup   MEQ0257246,NEQ0197808
   ccuif      VirtualDevices
   ccuname    none
   ccutype
   channels   0
   statevals  readonly
   Readings:
     2016-04-11 15:08:24   AZ-Rauchmelder.0.CONFIG_PENDING false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.DEVICE_IN_BOOTLOADER false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.DUTYCYCLE false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.LOWBAT false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.RSSI_DEVICE 1
     2016-04-11 15:08:24   AZ-Rauchmelder.0.RSSI_PEER 37
     2016-04-11 15:08:24   AZ-Rauchmelder.0.STICKY_UNREACH false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.UNREACH false
     2016-04-11 15:08:24   AZ-Rauchmelder.0.UPDATE_PENDING false
     2016-04-11 15:08:24   AZ-Rauchmelder.1.INSTALL_TEST N/A
     2016-04-11 15:08:24   AZ-Rauchmelder.1.STATE false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.CONFIG_PENDING false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.DEVICE_IN_BOOTLOADER false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.DUTYCYCLE false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.LOWBAT false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.RSSI_DEVICE 1
     2016-04-11 15:08:25   SZ-Rauchmelder.0.RSSI_PEER 53
     2016-04-11 15:08:25   SZ-Rauchmelder.0.STICKY_UNREACH false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.UNREACH false
     2016-04-11 15:08:25   SZ-Rauchmelder.0.UPDATE_PENDING false
     2016-04-11 15:08:25   SZ-Rauchmelder.1.INSTALL_TEST N/A
     2016-04-11 15:08:25   SZ-Rauchmelder.1.STATE false
     2016-04-11 15:08:25   state           false
Attributes:
   IODev      myCCU
   ccureadings 1
   statechannel 1

Update:
Ist das so gedacht mit "virtuell"? Ich vermisse den unter FHEM möglichen Team_Call für Rauchmelder, die in einem Team sind. Gibt es den irgendwie auch über die XML-Schnittstelle?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 15:31:32
Neues Problem: get myCCU update löst auch mein notify aus, da der update so tut als ob gerade von allen Geräten Events kommen. Das kann im Eventmonitor mitverfolgt werden.... War das im Sinne des Erfinders? Besser wäre, wenn "update" nur die Readings setzt und gut ist.... Oder habe ich etwas nicht bedacht?

Hinweis: Das Attribut updatemode habe ich bei meiner HMCCU nicht gesetzt. Kann das Verhalten etwa darüber beeinflusst werden?

Die Wirkung bei mir war, dass die Rolläden plötzlich runtergefahren sind.... Da ich auf eines der beim update generierten Ereignisse ein notify gesetzt habe.  ;D Ist zum Glück nix passiert, da die Katze und die Frau gerade Mittagsschlaf machen....   ::)

Dann ist mir noch aufgefallen, dass das update einen Fehler wirft und  "1 client device" nicht aktualisieren konnte. Im FHEM Log ist keine Meldung in diesem Zusammenhang zu finden. Siehe Screen-Shot. Kann es sein, dass dass mein soeben definiertes "virutelles" Device ist, das nicht aktualisiert wird. Die Meldung ist zu spärlich, um genaueres sagen zu können. Hier wäre ein Hinweis wünschenswert, welches Device nicht ging.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 April 2016, 18:06:47
Zu der Gruppe: Mit einem virtuellen Gerät funktioniert das natürlich, da diese Gruppen reine HMCCU Gruppen sind. Von denen weiß die CCU nichts. Daher kommt auch die Fehlermeldung beim "get update", da diese virtuellen Geräte keine gültige Adresse haben, zumindest keine, die die CCU kennt (to be fixed)

Mich würde mal interessieren, ob Deine Rauchmeldergruppe in der CCU unter Einstellungen->Gruppen auftaucht und wenn ja, mit welchem Namen und Adresse. Ich vermute, bei den Rauchmeldergruppen kocht EQ3 wieder mal ein Extra-Süppchen.

Es wäre schöner, Du könntest die Gruppe wie in Deinem ersten Versuch definieren. Diese Gruppen werden nämlich in der nächsten Version von HMCCU ebenfalls per RPC-Server aktualisiert. Grundsätzlich funktioniert das auch mit den virtuellen Geräten, nur kennt die die CCU eben nicht.

Das mit dem Notify habe ich noch nicht verstanden: Bezieht sich das Notify auf das HMCCU-Device? Dann könnte ein updatemode = client helfen. Das sorgt dann auch dafür, dass im IO Device keine Readings gesetzt werden.

Bei den Events musst Du unterscheiden zwischen CCU-Events und FHEM-Events. Ein FHEM-Event (und damit auch ein zugeordnetes Notify) wird immer ausgelöst, wenn ein Reading gesetzt wird. Mit event-on-change-reading und event-on-update-reading kannst Du aber einstellen, ob das FHEM-Event nur kommen soll, wenn ein Readingwert aktualisiert wird oder nur, wenn er sich geändert hat.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 April 2016, 18:49:52
Ich habe gerade die Version 3.1b eingecheckt. Wer Version 3.1 nutzt, muss nur die Dateien 88_HMCCU.pm und ccurpcd.pl aktualisieren. Vor Version 3.1 müssen alle Dateien aktualisiert werden.

Diese Version behebt Timing-Probleme beim Start des RPC-Servers auf langsamen Systemen. Diese führten dazu, dass der RPC-Server im Status "starting" stecken blieb.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 20:03:10
Zu der Rauchmeldergruppe:

In der CCU ist die als Gerät definiert, nicht als Gruppe. Die Definition hatte ich bereits in Antwort #417 als Screenshot angehängt. Dort habe ich auch den Stern vor dem Namen her.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 20:22:00
zum set ... update und notify:

Mein notify geht auf zwei Kanäle meiner HM-Fernbedienung. Die Kanäle heißen in FHEM c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter...

Hier der code des notify:

c_WZ_Rolladen_hoch:.*|c_WZ_Rolladen_runter:.* {
Log (3,"HM_Fernbedienung-Notify: $NAME, $EVTPART0, $EVTPART1");
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_SHORT:")
{
fhem("set Wohnzimmer_Rolladen_Essen up");
fhem("set Wohnzimmer_Rolladen_Sofa up");
}
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_LONG:")
{
fhem("set Wohnzimmer_Rolladen_Essen stop");
fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_SHORT:")
{
fhem("set Wohnzimmer_Rolladen_Essen down");
fhem("set Wohnzimmer_Rolladen_Sofa down");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_LONG:")
{
fhem("set Wohnzimmer_Rolladen_Essen stop");
fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
}

Hier die Definition der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter

Internals:
   CFGFN
   DEF        WZ-Rolladen-hoch:3
   IODev      myHomematicCCU
   NAME       c_WZ_Rolladen_hoch
   NR         4213
   STATE      Initialized
   TYPE       HMCCUCHN
   ccuaddr    MEQ0670565:3
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ-Rolladen-hoch:3
   ccutype    HM-RC-Dis-H-x-EU
   channels   1
   statevals  devstate
   Readings:
     2016-04-11 20:09:19   WZ-Rolladen-hoch.3.INSTALL_TEST 1
     2016-04-11 20:09:19   WZ-Rolladen-hoch.3.PRESS_CONT 1
     2016-04-11 20:09:17   WZ-Rolladen-hoch.3.PRESS_LONG 1
     2016-04-11 20:09:20   WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE 1
     2016-04-11 20:09:17   WZ-Rolladen-hoch.3.PRESS_SHORT 1
     2016-04-11 14:31:53   state           Initialized
Attributes:
   IODev      myCCU
   devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   group      Fernbedieung
   room       HMCCU


-------------------------------------------------------------------------------------------

Internals:
   CFGFN
   DEF        WZ-Rolladen-runter:4
   IODev      myHomematicCCU
   NAME       c_WZ_Rolladen_runter
   NR         4216
   STATE      Initialized
   TYPE       HMCCUCHN
   ccuaddr    MEQ0670565:4
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ-Rolladen-runter:4
   ccutype    HM-RC-Dis-H-x-EU
   channels   1
   statevals  devstate
   Readings:
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.INSTALL_TEST false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_CONT false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_LONG false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_LONG_RELEASE false
     2016-04-11 20:06:25   WZ-Rolladen-runter.4.PRESS_SHORT false
     2016-04-11 14:32:40   state           Initialized
Attributes:
   IODev      myCCU
   devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   group      Fernbedieung
   room       HMCCU

Trotz setzen von event-on-change-reading auf .* bei den beiden Kanälen reagiert das notify. event-on-update-reading habe ich bei beiden nicht gesetzt. Oder habe ich das falsch verstanden.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 11 April 2016, 21:50:00
Rauchmelder: wieder ein EQ3 Spezialfall. Statt die Gruppen zu verwenden wie bei der Heizung bilden sie hier die Gruppen als Spezialdevice mit Steenchenadresse ab. Mal sehen, wie ich das einfange. Aktuell fällt das Sternchen durch die Syntaxprüfung, daher funktioniert das nicht. Ich werde wohl meine HM Rauchmelder aus der Elektroschrottkiste holen und nochmal anlernen müssen, um das nachzustellen.

event-on-change-reading ist ja eine Standard FHEM Funktion. Für mich sieht Deine Def gut aus. Wie verhält sich das Notify, wenn Du "get update" lokal für einen Rolladen aufrufst?

Für das Setzen der Readings verwende ich FHEM Standardfunktionen. Da lässt sich nichts dran drehen.

Mm, grundsätzlich greift das Notify bei jedem Reading. Erst die IFs filtern dann auf die entsprechenden Tasten. Ich halte IF und DOIF sowieso in FHEM für Teufelszeug. Wie ist es, wenn Du für jede Taste ein eigenes Notify spendierst und in die Bedingung die Taste mit reinpackst?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 April 2016, 23:25:58
Zitat
Wie verhält sich das Notify, wenn Du "get update" lokal für einen Rolladen aufrufst?


Ääähhhh. Das ist ein Rademacher Rolladenaktor, der hat kein get update... Falls Du das get update auf dem Kanal der Fernbedienung meinst (c_WZ_Rolladen_runter), so kann ich das heute Abend nciht mehr machen, da die Frau unten auf der Coach fern sieht und ich Ärger kriege, wenn sich der Rolladen schon wieder bewegt....  :'( >:(

Wie heißt es doch so schön in der Werbung... "Meine Frau hat gesagt er soll bitte nicht so dominant sein", daraufhin der Verkäufer "Dann nehmen sie den, der ist auch nicht sooo dominant".  ;D ;D ;D
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 12 April 2016, 07:30:50
Ja, ich kenne das. Der WAF ist bei meiner Smart Home Umgebung auch ein ganz großes Thema. Du könntest 3 Dinge probieren:

1. get update auf den FB-Kanal, z.B.  get c_WZ_Rolladen_hoch update

2. Ein notify für eine FB-Aktion definieren

3. DOIF verwenden (das aber als letzte Möglichkeit, das Forum ist voll von DOIF-Fragen)

Dann wäre noch die Frage, warum Du überhaupt ein get update machst. Der RPC-Server liefert doch die Änderungen automatisch. Allerdings führt HMCCU beim Starten des RPC-Servers einmalig ein get update aus, um alle Devices in FHEM mit der CCU zu synchronisieren. Da würden dann ggf. Deine Rolläden hoch/runter fahren => auch blöd.

Eine FB habe ich glaube ich auch noch rumliegen. Muss ich mal testen.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 12 April 2016, 17:12:36
Kann es sein, dass das Setzen von event-on-change-reading auf .* ein wenig dauert, bis es wirkt oder gar ein reboot von FHEM benötigt, um zu wirken? Jedenfalls habe ich heute überhaupt keine events mehr für den Rolladen bekommen, auch nicht wenn ich die Fernbedienung gedrückt habe....

Da habe ich mal überlegt, was ich hier eigentlich konfiguriert habe....  :D


Der Wert des Readings WZ-Rolladen-hoch.3.PRESS_SHORT ändert sich aber nicht, wenn die Taste wieder losgelassen oder gar nochmal gedrückt wird, sondern verbleibt bei "1".
Es ändert sich bei einem Tastendruck nur die Farbe des Readingwertes in FHEM auf rot und die Zeitangabe.

Bei einem langen Tastendruck ist es ähnlich. Hier geht WZ-Rolladen-hoch.3.PRESS_LONG auf "1" und bleibt auf "1". Dafür ändert sich aber der Wert von WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE auf "1", wenn die Taste nach einem langen Tastendruck wieder losgelassen wird. Bei einem kurzen Tastendruck gibt es kein Signal über das Loslassen der Taste. Soweit das was ich beobachtet habe.

Nun eine mögliche Behandlung für die Fernbedienungsherausforderung:


Ist meine Überlegung nachvollziehbar und eine mögliche Option zur Implementierung?

update:

Ich habe noch beobachtet, dass bei gesetztem event-on-change-reading auf .*, der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter, folgendes Verhalten auftritt:


Das ist auch ein für mich nicht nachvollziehbares Verhalten. Welche Bedeutung hat das? Ist das so gewünscht?

Anbei noch die Definition meines Kanals:

Internals:
   CFGFN
   DEF        WZ-Rolladen-hoch:3
   IODev      myHomematicCCU
   NAME       c_WZ_Rolladen_hoch
   NR         4213
   STATE      Initialized
   TYPE       HMCCUCHN
   ccuaddr    MEQ0670565:3
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ-Rolladen-hoch:3
   ccutype    HM-RC-Dis-H-x-EU
   channels   1
   statevals  devstate
   Readings:
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.INSTALL_TEST false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_CONT false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_LONG false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_LONG_RELEASE false
     2016-04-12 17:25:31   WZ-Rolladen-hoch.3.PRESS_SHORT false
     2016-04-11 14:31:53   state           Initialized
Attributes:
   IODev      myCCU
   devStateIcon ok:10px-kreis-gruen alarm:10px-kreis-rot Initialized:10px-kreis-gelb
   event-on-change-reading .*
   group      Fernbedienung
   room       HMCCU
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 12 April 2016, 20:15:30
Wie kann das passieren?

HMCCUDEV: Arbeitszimmer_Deckenlicht Execution of CCU script or command failed

Ich habe meinen "slider" für meinen Dimmer im Arbeitszimmer mehrmahls hin- und hergeschoben. Beim 3.mal kam obige Meldung und es ging kein Befehl mehr an die CCU durch. Ich habe die Lampe dann direkt in der CCU aus- und eingeschaltet, dann konnte ich sie auch wieder über das HMCCUDEV steuern....

Komisch? :'(

Anbei die Definition des Dimmers

Internals:
   CFGFN
   DEF        AZ-Deckenlicht 1
   IODev      myHomematicCCU
   NAME       Arbeitszimmer_Deckenlicht
   NR         4710
   STATE      OK
   TYPE       HMCCUDEV
   ccuaddr    JEQ0207451
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    AZ-Deckenlicht
   ccutype    HM-LC-Dim1TPBU-FM
   channels   4
   statevals  devstate|on|off
   Readings:
     2016-04-12 19:54:02   AZ-Deckenlicht.0.CONFIG_PENDING false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.DEVICE_IN_BOOTLOADER false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.DUTYCYCLE false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.RSSI_DEVICE 128
     2016-04-12 19:54:02   AZ-Deckenlicht.0.RSSI_PEER 182
     2016-04-12 19:54:02   AZ-Deckenlicht.0.STICKY_UNREACH false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.UNREACH false
     2016-04-12 19:54:02   AZ-Deckenlicht.0.UPDATE_PENDING false
     2016-04-12 20:05:32   AZ-Deckenlicht.1.DIRECTION 0
     2016-04-12 20:05:32   AZ-Deckenlicht.1.ERROR_OVERHEAT 0
     2016-04-12 20:05:32   AZ-Deckenlicht.1.ERROR_OVERLOAD 0
     2016-04-12 20:05:32   AZ-Deckenlicht.1.ERROR_REDUCED 0
     2016-04-12 19:54:02   AZ-Deckenlicht.1.INHIBIT false
     2016-04-12 19:54:02   AZ-Deckenlicht.1.INSTALL_TEST N/A
     2016-04-12 20:05:31   AZ-Deckenlicht.1.LEVEL 1.000000
     2016-04-12 20:05:32   AZ-Deckenlicht.1.LEVEL_REAL 1.000000
     2016-04-12 19:54:02   AZ-Deckenlicht.1.OLD_LEVEL N/A
     2016-04-12 19:54:02   AZ-Deckenlicht.1.ON_TIME N/A
     2016-04-12 19:54:02   AZ-Deckenlicht.1.RAMP_STOP N/A
     2016-04-12 19:54:02   AZ-Deckenlicht.1.RAMP_TIME N/A
     2016-04-12 20:05:32   AZ-Deckenlicht.1.WORKING 0
     2016-04-12 20:05:31   control         1.000000
     2016-04-12 20:05:24   state           OK
Attributes:
   IODev      myHomematicCCU
   ccureadingfilter ^AZ-Deckenlicht!(.*)
   controldatapoint 1.LEVEL
   group      Arbeitszimmer_Licht
   icon       light_ceiling
   room       02_Oben,HMCCU
   statechannel 1
   statevals  on:1.000000,off:0.000000
   webCmd     control
   widgetOverride control:slider,0,0.050000,1,1
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 12 April 2016, 20:41:52
Kann es sein, dass das Setzen von event-on-change-reading auf .* ein wenig dauert, bis es wirkt oder gar ein reboot von FHEM benötigt, um zu wirken? Jedenfalls habe ich heute überhaupt keine events mehr für den Rolladen bekommen, auch nicht wenn ich die Fernbedienung gedrückt habe....

Nein, event-on-change-reading greift sofort. Vermutlich bekommst Du Events beim Drücken der Taste, aber der Wert der Readings ändert sich nicht. Das kannst Du prüfen, indem Du statt ...-on-change... das Attribut event-on-update-reading setzt (nicht beide!). Dann sollte sich beim Drücken einer Taste der Zeitstempel des Readings ändern.

Ich habe zwar eine Fernbedienung, aber leider keine Zeit, das momentan zu testen.

Zitat
Nun eine mögliche Behandlung für die Fernbedienungsherausforderung:
...
Ist meine Überlegung nachvollziehbar und eine mögliche Option zur Implementierung?

Wie gesagt, bevor ich das nicht selbst nachvollzogen habe, kann ich da nichts versprechen. Allerdings habe ich mit HMCCU von Anfang an einen generischen Ansatz verfolgt. Da passt eine Sonderbehandlung für einen Gerätetyp nicht so recht rein. Das wäre dann der Ansatz von CUL_HM.

Zitat
Ich habe noch beobachtet, dass bei gesetztem event-on-change-reading auf .*, der Kanäle c_WZ_Rolladen_hoch und c_WZ_Rolladen_runter, folgendes Verhalten auftritt:

  • set c_WZ_Rolladen_hoch update setzt mir alle readings auf "false"
  • wenn ich die Fernbedieungstasten drücke, gehen die entsprechenden Readings auf "1"

Das ist auch ein für mich nicht nachvollziehbares Verhalten. Welche Bedeutung hat das? Ist das so gewünscht?

Ein get update liefert bei Datenpunkten vom Typ bool entweder true oder false zurück (liegt am verwendeten Homematic Script). Der RPC-Server liefert hingegen 1 oder 0. Daher das unterschiedliche Verhalten und deshalb auch solche Definitionen in meinen Beispielen für substitute:  (true|1):an,(false|0):aus. Theoretisch ginge auch 1:true,0:false. Damit werden die RPC-Werte durch Homematic Script Werte ersetzt.

Ich habe übrigens auch mal get update beim HMCCU IO Device getestet. Bei mir verhält sich event-on-change-reading korrekt, d.h. nur geänderte Werte werden upgedated.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 12 April 2016, 20:48:03
Wie kann das passieren?

HMCCUDEV: Arbeitszimmer_Deckenlicht Execution of CCU script or command failed

Ich habe meinen "slider" für meinen Dimmer im Arbeitszimmer mehrmahls hin- und hergeschoben. Beim 3.mal kam obige Meldung und es ging kein Befehl mehr an die CCU durch. Ich habe die Lampe dann direkt in der CCU aus- und eingeschaltet, dann konnte ich sie auch wieder über das HMCCUDEV steuern....

Komisch? :'(

Bei vielen schnellen Sets kommen sich vermutlich die Sets mit den RPC-Server Updateevents ins Gehege. Du könntest im HMCCU Device das Attribut rpcinterval auf 3 setzen (Default ist 5 Sekunden). Ob das hilft weiß ich nicht.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 12 April 2016, 23:52:25
Anwendungsfall "Fernbedienungstastendruck durch notify auswerten"

Ich habe jetzt eine Lösung dank deiner Hinweise implementiert. Ausgenutzt habe ich dabei folgende Sachverhalte:
Es werden auf der Fernbedienung zwei Kanäle verwendet und damit zwei Tasten (eine für hoch und eine für runter) mit kurzem oder langem Tastendruck (der lange Tastendruck wird bei beiden Tasten als "stop" der Rolladenfahrt genutzt:
Ich habe das notify, nun auf genau diese 4 Events ausgelegt und mit der Prüfung von Parameter $EVTPART1 eq "1" festgestellt, dass eine Taste auf der Fernbedieung das Event ausgelöst hat und nicht ein update oder ein Start des rpcserver.
c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_SHORT:.*|c_WZ_Rolladen_hoch:WZ-Rolladen-hoch.3.PRESS_LONG:.*|c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_SHORT:.*|c_WZ_Rolladen_runter:WZ-Rolladen-runter.4.PRESS_LONG:.* {
Log (3,"HM_Fernbedienung-Notify: $NAME, $EVTPART0, $EVTPART1");

# #################################################
# ### nur wenn eine Taste gedrückt wird
# ### dann ist $EVTPART1 = "1" bei update "false"
# #################################################
if ($EVTPART1 eq "1"){

if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_SHORT:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen hochfahren");
# fhem("set Wohnzimmer_Rolladen_Essen up");
# fhem("set Wohnzimmer_Rolladen_Sofa up");
}
if ($EVTPART0 eq "WZ-Rolladen-hoch.3.PRESS_LONG:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen stop(hoch)");
# fhem("set Wohnzimmer_Rolladen_Essen stop");
# fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_SHORT:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen runterfahren");
# fhem("set Wohnzimmer_Rolladen_Essen down");
# fhem("set Wohnzimmer_Rolladen_Sofa down");
}
if ($EVTPART0 eq "WZ-Rolladen-runter.4.PRESS_LONG:")
{
Log (3,"HM_Fernbedienung-Notify: Rolladen stop(runter)");
# fhem("set Wohnzimmer_Rolladen_Essen stop");
# fhem("set Wohnzimmer_Rolladen_Sofa stop");
}
}
}

Zusammenhang mit gesetztem event_on-Attributen:

Setzt man beim HMCCUCHN das Attribut event-on-change-reading auf .*, so wird ein Event nur ausgelöst, wenn sich der Wert des Readings von "false" auf "1" ändert oder umgekehrt. Das passiert im Normalbetrieb (eine manuells update wird wohl im Normalbetrieb nicht erfolgen) nur, wenn der rpcserver gestartet wird und dann beim ersten Tastendruck. Alle weiteren Tastendrucke lösen kein Event mehr aus, da sich der Wert des Readings nicht ändert. Somit ist das Setzen von "event-on-change-reading auf .*" ungeeignet für diesen Anwendugnsfall.

Setzt man beim HMCCUCHN das Attribut event-on-update-reading auf .*, so wird immer ein Event ausgelöst. Bei jedem Tastendruck, beim update und beim rpcserver-Start. Das Verhalten ist allerdings auch so, wenn event-on-update-reading  und event-on-change-reading garnicht gesetzt sind.

Ergo: Für diesen Anwendungsfall "Fernbedienungstastendruck durch notify auswerten" erscheint das Setzten von event-on-update-reading und event-on-change-reading nicht sinnvoll.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 12 April 2016, 23:58:09
Zitat
Bei vielen schnellen Sets kommen sich vermutlich die Sets mit den RPC-Server Updateevents ins Gehege. Du könntest im HMCCU Device das Attribut rpcinterval auf 3 setzen (Default ist 5 Sekunden). Ob das hilft weiß ich nicht.

Mit gesetztem Attribut rpcinterval auf 3 konnte ich keine Verklemmung mehr provozieren, auch wenn ich im Sekundentakt den Dimmwert verändert habe.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 13 April 2016, 06:00:34
Hallo zusammen,

Ich versuche mich immer mehr in die FHEM Welt einzuarbeiten und dabei dieses tolle Modul für meine Bedürfnisse zu nutzen.

Ich habe viel gelesen und bekomme es auch hin, einzelne Devices anzulegen, die werte abzufragen und auch der RPC läuft mittlerweile.  Was ich mich aber frage ist, ob es eine Art Best practice Ansatz gibt. Beispiel : Aktuell lege ich jedes einzelne Homematic Device manuell an. Da gibt es doch bestimmt eine Funktion mit der ich alle Geräte aus der CCU als FHEM Devices auf einen Schlag anlege - oder z.B. das auxh selektiv für nur einzelne Gerätetyp wie z.B. jalousie Aktoren.  Geht so etwas?

Und dann noch eine allgemeine Frage: was sind readings? Und wie definiert man diese mit hmdev? Kann man das auxh automatisieren ? Bitte seht mir meine vielleicht blöden Fragen nach,  aber in diesem langen Thread habe ich die Antworten leider nicht gefunden.  Viele grüße Nic

von unterwegs gesendet

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 13 April 2016, 11:44:09
Was ich mich aber frage ist, ob es eine Art Best practice Ansatz gibt. Beispiel : Aktuell lege ich jedes einzelne Homematic Device manuell an. Da gibt es doch bestimmt eine Funktion mit der ich alle Geräte aus der CCU als FHEM Devices auf einen Schlag anlege - oder z.B. das auxh selektiv für nur einzelne Gerätetyp wie z.B. jalousie Aktoren.  Geht so etwas?

Auf ein Autocreate aller CCU Devices in FHEM habe ich bewusst verzichtet, da dies bei größeren Homematic Installationen zu einer Flut von FHEM Devices geführt hätte. Du kannst aber z.B. ein Device für einen Fenstersensor anlegen und das dann mit dem FHEM Befehl "copy" kopieren. Danach musst Du in der Oberfläche von FHEM in der Detailansicht der Kopie nochmal auf "DEF" klicken und die Adresse bzw. den Namen entsprechend dem 2. Fenstersensor anpassen. Andere Möglichkeit wäre, fhem.cfg direkt anzupassen. Davon rate ich aber ab, gerade wenn man mit FHEM noch nicht so vertraut ist.
Best Practice aus meiner Sicht: Je Typ ein Device in FHEM definieren. Die anderen vom gleichen Typ mit copy anlegen und nachträglich die Adresse anpassen.
Übrigens: HMCCUxxx hat kein Problem damit, wenn sich mehrere FHEM-Devices auf ein CCU-Device beziehen. Ich habe z.B. die Steckdosen mit eingebautem Energiezähler im Einsatz. Dafür habe ich ein Read-Only Device mit HMCCUCHN definiert, das nur die Messwerte darstellt und ein weiteres mit HMCCUDEV, über das ich die Steckdose schalte.

Zitat
Und dann noch eine allgemeine Frage: was sind readings? Und wie definiert man diese mit hmdev? Kann man das auxh automatisieren ? Bitte seht mir meine vielleicht blöden Fragen nach,  aber in diesem langen Thread habe ich die Antworten leider nicht gefunden. 

Kein Thema, jeder fängt mal an. Readings sind veränderliche Werte eines Gerätes. Das können Messwerte wie Temperatur oder Luftfeuchte sein oder auch Zusände wie offen oder geschlossen. Bei HMCCU, HMCCUDEV und HMCCUCHN entsprechen die Readings den Datenpunkten und Konfigurationsparameter der CCU Devices. Die Readings werden automatisch generiert, wenn Du einen get Befehl ausführts oder der RPC-Server Updates von der CCU empfängt. Da einige Homematic Geräte sehr viele Datenpunkte / Parameter haben und meist nur wenige davon wirklich interessant sind, macht es sinn, diese mit dem Attribut ccureadingfilter zu filtern. Außerdem sollte man das Attribut event-on-change-reading auf .* setzen. Sonst werden eine Menge FHEM Events generiert und die Performance leidet.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 13 April 2016, 11:57:17
Ich habe jetzt eine Lösung dank deiner Hinweise implementiert. Ausgenutzt habe ich dabei folgende Sachverhalte:
  • rpcserver liefert unterschiedliche Werte bei update und bei einem echten Event aus der CCU ("1" bei echtem Tastendruck; "false" bei get c_WZ_Rolladen_... update)
  • rpcserver aktualisiert die Readings sowohl bei echten Events als auch bei "get ... update" oder beim "Start des rpcserver"

Schön, dass es jetzt funktioniert. Nur um das nochmal klar zu stellen: Die Updates durch get Befehle und die Updates durch den RPC-Server sind 2 völlig verschiedene Dinge. Das läuft in der CCU in 2 getrennten Schichten ab. Ein "get update" oder auch ein "get datapoint" fragt in der CCU Logikschicht den Zustand von Datenpunkten ab und setzt die Readings in FHEM entsprechend.
Unterhalb der Logikschicht werkelt die RPC-Schicht. Diese schickt bei Änderungen an CCU Devices die geänderten Werte an alle registrierten RPC-Server (einer davon ist der von HMCCU). Die RPC-Schicht weiß nichts von der Logikschicht, kennt z.B. nicht mal die Namen der Geräte in der CCU sondern nur die Adressen.

Wenn Du jetzt z.B. mit "set datapoint" einen Wert in der Logikschicht änderst, merkt das die RPC-Schicht und schickt den geänderten Wert an die registrierten RPC-Server (u.a. HMCCU) zurück. D.h. Du setzt z.B. einen Wert mit set datapoint auf true und der RPC-Server erhält von der CCU quasi als Bestätigung 1 zurück.

Grundsätzlich sollten Nutzer von CUL_HM bei Fernbedienungen vor ähnlichen Fragestellungen stehen. Du könntest also mal in diesem Forum suchen, wie CUL_HM Nutzer diese Thematik (Notifies) gelöst haben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 13 April 2016, 15:54:09
Ich habe mal im cul_hm Forum nach der Problematik gesucht und folgendes gefunden: https://forum.fhem.de/index.php?topic=43726.0 (https://forum.fhem.de/index.php?topic=43726.0). Da versucht MiWe58 eigentlich genau das, was ich auch tun will. Homematic-Fernbedienung und nicht-Homematic-Rolladen über FHEM zu "verbinden". Also genau das, was eine Stärke von FHEM sein soll, auszunutzen. Die Lösung bestand allerdings darin, statt des notify DOIF zu verwenden. Davon hattest Du mir ja abgeraten...

Es mit cul_hm umzusetzten war auch mein erster Ansatz, der ist aber ähnlich gescheitert, wie es MiWe58 erlebt hat. Eine zufriedenstellende Lösung habe ich nicht hinbekommen. Zumal ich das damals ohne CCU versucht hatte und schon an der korrekten Konfiguration der HM-RC-Dis-H-x-EU gescheitert war. Mehr als 3-4 Tasten konnte ich beim besten Willen (und vielen Fehlversuchen) nicht konfigurieren.... Das mag ja auch an mir und meinen ungenügenden Kenntnissen über HM gelegen haben. Jetzt mit CCU2 und dem Modul HMCCU kommt FHEM seinem Anspruch als Integrator eigentlich inkompatibler Systeme zu agieren wieder einen ganzen Schritt näher...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 April 2016, 11:58:06
Erkenntnisse zur Verwendung von Fernbedienungen:

Ich habe nun mal den 2-fach Taster HM-PB-2-WM55 mit HMCCUDEV getestet.

1. Alle Datenpunkte (PRESS_SHORT, PRESS_LONG usw.) haben die Flags Write und Event, nicht jedoch Read gesetzt (s.a. get deviceinfo). Bedeutet: Ein get update liefert undefinierte bzw. unzuverlässige Ergebnisse, da ein explizites Lesen der Datenpunkte nicht erlaubt ist. Man ist also darauf angewiesen, dass die CCU Zustandsänderungen als Event an den RPC-Server schickt.

2. Die CCU schickt beim Drücken der Tasten am Taster nur dann Events, wenn die Tasten mit einem anderen Gerät verknüpft sind oder in einem CCU-Programm verwendet werden. Dieses Verhalten ist bekannt und einige User legen sich in der CCU Dummy-Programme an, die die Tastenzustände abfragen und eine Systemvariable auf irgendeinen Wert setzen um das Senden von Events zu erzwingen.

3. Die Events der CCU (z.B. zu PRESS_SHORT oder PRESS_LONG) enthalten immer eine 1 = Taste gedrückt. Einen Event "Taste nicht gedrückt" gibt es nicht. Konsequenz: event-on-change-reading darf nicht verwendet werden, stattdessen besser event-on-update-reading.

4. Die Datenpunkte PRESS_CONT und PRESS_LONG_RELEASE haben zumindest bei HM-PB-2-WM55 keine Funktion.

5. Bei jedem Tastendruck wird der Datenpunkt / Reading INSTALL_TEST mit 1 aktualisiert (könnte man auch als Tastendruckerkennung im Notify nutzen)

6. Ich würde für jede Taste bzw. jeden Kanal einer Fernbedienung ein HMCCUCHN Device definieren. Das hat den Vorteil, dass man den Zustand einer Taste über STATE darstellen kann.

In der nächsten Version wird der get update Befehl nur noch Datenpunkte / Readings aktualisieren, die das Flag "Readable" gesetzt haben. Damit dürften bei get update in Zusammenhang mit Fernbedienungen keine Probleme mehr auftreten.

Ein kleines Beispiel (Taste 1 = CCU Kanal FB-BA-1):

define HM_FB_BA_1 HMCCUCHN FB-BA-1
attribute HM_FB_BA_1 substitute 1:pressed
attribute HM_FB_BA_1 statedatapoint PRESS_SHORT
attribute HM_FB_BA_1 statevals press:true

Setzt STATE/state auf "pressed" wenn die Taste kurz gedrückt wird. Taste kann mit dem Befehl "set HM_FB_BA_1 press" kurz gedrückt werden.

Erkenntnisse zu Rauchmelder-Teams:

1. Rauchmelder-Teams sind keine CCU-Gruppen, sondern "Teams" ;-). Dementsprechend kann ein Rauchmelderteam in HMCCU bzw. HMCCUDEV nicht als Gruppen-Device (Zusatz group=...) angelegt werden. Das Anlegen einer reinen HMCCUDEV Gruppe ohne Bezug zur CCU ist zwar möglich, m.E. aber nicht sinnvoll.

2. Rauchmelder-Teams werden in der CCU wie ein eigener Gerätetyp behandelt. Die Adresse eines Teams ist die Adresse des Master-Rauchmelders mit einem Sternchen (*) davor. Momentan unterstützt HMCCU diese speziellen Adressen nicht. In der nächsten Version wird das aber der Fall sein.

3. Die Verwendung einzelner Rauchmelder wird jetzt schon von HMCCU uneingeschränkt unterstützt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 15 April 2016, 06:25:03
Hallo zap,

ich habe gerade einmal versucht meinen Raumthermostaten (noch den alten) einzubinden, scheitere aber irgendwie daran.

Bei State wird mir folgendes angezeigt:
Wohnzimmer_Heizung
T: Wohnzimmer_Heizung.1.TEMPERATURE° H: Wohnzimmer_Heizung.1.HUMIDITY% D: Wohnzimmer_Heizung.2.SETPOINT° P: n/a°

Meine config sieht so aus:
attr Wohnzimmer_Heizung IODev d_ccu
attr Wohnzimmer_Heizung ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SETPOINT|^LOWBAT$|^WINDOW_OPEN|^UNREACH)
attr Wohnzimmer_Heizung controldatapoint Wohnzimmer_Heizung.SETPOINT
attr Wohnzimmer_Heizung devStateIcon OK:10px-kreis-gruen Error:10px-kreis-rot Initialized:10px-kreis-gelb
attr Wohnzimmer_Heizung event-on-change-reading .*
attr Wohnzimmer_Heizung stateFormat T: Wohnzimmer_Heizung.1.TEMPERATURE° H: Wohnzimmer_Heizung.1.HUMIDITY% D: Wohnzimmer_Heizung.2.SETPOINT° P: DEWPOINT°
attr Wohnzimmer_Heizung statechannel 2
attr Wohnzimmer_Heizung stripnumber 1
attr Wohnzimmer_Heizung substitute LOWBAT!(0|false):no,(1|true):yes;;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
attr Wohnzimmer_Heizung userReadings DEWPOINT {HMCCU_Dewpoint($name,"Wohnzimmer_Heizung.1.TEMPERATURE", "Wohnzimmer_HeizungH.1.HUMIDITY","n/a")}

Kannst Du erkennen, was ich falsch mache?
Und wie würde ich den "statedatapoint" richtig setzen?

Ich hoffe Du kannst mir nochmal helfen.

Viele Grüße
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 April 2016, 09:11:03
Hallo zap,

ich habe gerade einmal versucht meinen Raumthermostaten (noch den alten) einzubinden, scheitere aber irgendwie daran.

Hallo Nic,

ich brauche den Typ des Thermostaten. Der wird in der Detailansicht des FHEM Devices im Feld "Internals" als "ccutype" angezeigt.

Wenn möglich noch die Ausgabe von "get Wohnzimmer_Heizung deviceinfo"
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 15 April 2016, 09:15:30
Hier die daten:

ccutype: HM-CC-TC

Ubd hier Device Info:
CHN IEQ0171822:0 Heizung Wohnzimmer:0 DPT {b} BidCos-RF.IEQ0171822:0.UNREACH = false [RE] DPT {b} BidCos-RF.IEQ0171822:0.STICKY_UNREACH = false [RWE] DPT {b} BidCos-RF.IEQ0171822:0.CONFIG_PENDING = false [RE] DPT {b} BidCos-RF.IEQ0171822:0.LOWBAT = false [RE] DPT {8} BidCos-RF.IEQ0171822:0.RSSI_DEVICE = 1 [RE] DPT {8} BidCos-RF.IEQ0171822:0.RSSI_PEER = 180 [RE] CHN IEQ0171822:1 Raumklima Wohnzimmer DPT {f} BidCos-RF.IEQ0171822:1.TEMPERATURE = 19.000000 [RE] DPT {i} BidCos-RF.IEQ0171822:1.HUMIDITY = 57 [RE] CHN IEQ0171822:2 Soll Temperatur Wohnzimmer DPT {f} BidCos-RF.IEQ0171822:2.SETPOINT = 19.000000 [RWE] DPT {i} BidCos-RF.IEQ0171822:2.ADJUSTING_COMMAND = 0 [RE] DPT {i} BidCos-RF.IEQ0171822:2.ADJUSTING_DATA = 3 [RE] DPT {b} BidCos-RF.IEQ0171822:2.STATE = [W]

OK







von unterwegs gesendet

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 April 2016, 12:08:49
Also grundsätzlich falsch ist da nichts (außer das Attribut controldatapoint). Werden denn die Readings gesetzt/angzeigt (z.B. Wohnzimmer_Heizung.1.TEMPERATURE) ?

Für die Attribute hätte ich noch folgende Tipps:

attr Wohnzimmer_Heizung ccureadingfilter (^HUMIDITY|^TEMPERATURE|^SETPOINT|^LOWBAT$|^UNREACH)
attr Wohnzimmer_Heizung statedatapoint SETPOINT
attr Wohnzimmer_Heizung controldatapoint 2.SETPOINT
attr Wohnzimmer_Heizung statevals on:100.0,off:0.0

Der Datenpunkt SETPOINT akzeptiert 2 spezielle Werte: 0=Ventil zu, 100=Ventil komplett offen. Ansonsten geht der Wertebereich von 6 bis 30 Grad. Daher die Empfehlung mit dem Attribut statevals. Dann kannst Du z.B. mit "set Wohnzimmer_Heizung off" das Ventil komplett schließen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 15 April 2016, 17:39:20
Hallo,

kann einer von Euch Spezialisten einem verzweifelnden Newbie bitte erklären, wie man an einen Dimmer einen Drehknopf drangenagelt bekommt?

Ich habe mich schon tot gegoogelt, komme aber leider nicht weiter.

Mein letzter kläglicher Versuch ging so:

attr SZDimmer webCmd state
attr SZDimmer widgetOverride state:knob,min:0,max:1,step:0.1,lineup:round
attr SZDimmer statevals state:.*

Das zeigt mir zwar den Drehknopf an, aber jetzt weiß ich nicht, was ich bei statevals angeben muss, damit der Wert auch zurück geschossen wird.
Ich check das nicht.

Danke für Hilfe!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 15 April 2016, 18:32:45
Normalerweise sollte ein Dimmer einen Datenpunkt LEVEL haben, über den die Helligkeit gesteuert wird. Das kannst Du mit dem Befehl "get SZDimmer deviceinfo" rausbekommen, der Dir alle Datenpunkte Deines Devices anzeigt.

Angenommen, Dein Dimmer hat einen Datenpunkt LEVEL in Kanal 1, sollte folgendes funktionieren:

attr SZDimmer controldatapoint 1.LEVEL
attr SZDimmer statechannel 1
attr SZDimmer statedatapoint LEVEL
attr SZDimmer statevals on:1.0,off:0.0
attr SZDimmer webCmd control
attr SZDimmer widgetOverride control:knob,min:0,max:1,step:0.1,lineup:round

Das Attribut statevals ermöglicht Dir in diesem Fall, den Dimmer mit "set SZDimmer on/off" komplett ein- oder auszuschalten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 15 April 2016, 21:55:58

Zitat
1. Alle Datenpunkte (PRESS_SHORT, PRESS_LONG usw.) haben die Flags Write und Event, nicht jedoch Read gesetzt (s.a. get deviceinfo). Bedeutet: Ein get update liefert undefinierte bzw. unzuverlässige Ergebnisse, da ein explizites Lesen der Datenpunkte nicht erlaubt ist. Man ist also darauf angewiesen, dass die CCU Zustandsänderungen als Event an den RPC-Server schickt.

Das ist auch so bei meiner Fernbedieung (HM-RC-Dis-H-x-EU). Siehe den Output von deviceinfo:

CHN MEQ0670565:0 HM-Fernbedienung:0
  DPT {b} BidCos-RF.MEQ0670565:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.MEQ0670565:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.MEQ0670565:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.MEQ0670565:0.LOWBAT = false [RE]
  DPT {8} BidCos-RF.MEQ0670565:0.RSSI_DEVICE = 1 [RE]
  DPT {8} BidCos-RF.MEQ0670565:0.RSSI_PEER = 197 [RE]
  DPT {b} BidCos-RF.MEQ0670565:0.DEVICE_IN_BOOTLOADER = false [RE]
  DPT {b} BidCos-RF.MEQ0670565:0.UPDATE_PENDING = false [RE]
  DPT {8} BidCos-RF.MEQ0670565:0.AES_KEY = 0 [R]
CHN MEQ0670565:1 Stehlampe an-dim:1
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_SHORT = false [WE]
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_LONG = false [WE]
  DPT {b} BidCos-RF.MEQ0670565:1.INSTALL_TEST = false [E]
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_CONT = false [E]
  DPT {b} BidCos-RF.MEQ0670565:1.PRESS_LONG_RELEASE = false [E]
  ...


Zitat
In der nächsten Version wird der get update Befehl nur noch Datenpunkte / Readings aktualisieren, die das Flag "Readable" gesetzt haben. Damit dürften bei get update in Zusammenhang mit Fernbedienungen keine Probleme mehr auftreten.

Prima. Das wäre genau das, was ich brauche. Dann beeinflusst, ein get update auch nicht mehr vorhandene notifies, die auf Readings lauschen....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 15 April 2016, 22:23:53
Hallo zap,

Zitat
Also grundsätzlich falsch ist da nichts (außer das Attribut controldatapoint). Werden denn die Readings gesetzt/angzeigt (z.B. Wohnzimmer_Heizung.1.TEMPERATURE) ?

ich mache mal einen Screenshot, wie es aussieht, irgendwie passt der State nicht.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 15 April 2016, 23:40:46
Normalerweise sollte ein Dimmer einen Datenpunkt LEVEL haben, über den die Helligkeit gesteuert wird. Das kannst Du mit dem Befehl "get SZDimmer deviceinfo" rausbekommen, der Dir alle Datenpunkte Deines Devices anzeigt.

Angenommen, Dein Dimmer hat einen Datenpunkt LEVEL in Kanal 1, sollte folgendes funktionieren:

attr SZDimmer controldatapoint 1.LEVEL
attr SZDimmer statechannel 1
attr SZDimmer statedatapoint LEVEL
attr SZDimmer statevals on:1.0,off:0.0
attr SZDimmer webCmd control
attr SZDimmer widgetOverride control:knob,min:0,max:1,step:0.1,lineup:round

Das Attribut statevals ermöglicht Dir in diesem Fall, den Dimmer mit "set SZDimmer on/off" komplett ein- oder auszuschalten.

Danke zap!
So funktioniert's.
Das mit dem statedatapoint hatte ich schon rausgefunden. Aber nicht das mit dem controldatapoint.
Warum muss ich bei controldatapoint 1.LEVEL angeben und bei statedatapoint nur LEVEL?

VG Alex

P.S.: Die beschriebene Methode scheint auch nur zu funktionieren, wenn man das Gerät mit HMCCUDEV definiert. Mit HMCCUCHN geht's nicht.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 16 April 2016, 09:42:07
Hallo zap,

ich mache mal einen Screenshot, wie es aussieht, irgendwie passt der State nicht.

Ah ja! Die Attribute stateformat und userreadings sind falsch. In beiden Attributen musst Du die Reading-Namen so verwenden, wie sie in FHEM angezeigt werden. stateformat ersetzt einfach die Readingnamen durch die Werte. So sollte es funktionieren:

attr Wohnzimmer_Heizung stateFormat T: Raumklima_Wohnzimmer.TEMPERATURE° H: Raumklima_Wohnzimmer.HUMIDITY% D: Soll_Temperatur_Wohnzimmer.SETPOINT° P: DEWPOINT°
attr Wohnzimmer_Heizung userReadings DEWPOINT {HMCCU_Dewpoint($name,"Raumklima_Wohnzimmer.TEMPERATURE", "Raumklima_Wohnzimmer.HUMIDITY","n/a")}
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 16 April 2016, 09:49:45
Danke zap!
So funktioniert's.
Das mit dem statedatapoint hatte ich schon rausgefunden. Aber nicht das mit dem controldatapoint.
Warum muss ich bei controldatapoint 1.LEVEL angeben und bei statedatapoint nur LEVEL?

Weil die Attribute statedatapoint und statechannel älter sind. controldatapoint habe ich erst später eingeführt und da beide Angaben in einem Attribut zusammengelegt. Werde ich vielleicht bei statedatapoint noch einbauen, ist aber nicht so einfach, da die Abwärtskompatibilität gewährleistet sein muss. Grund für 2 unterschiedliche Attribute ist, dass einige Homematic Geräte unterschiedliche Datenpunkte für das Setzen und Lesen von Werten verwenden (z.B. Thermostate).

Zitat
P.S.: Die beschriebene Methode scheint auch nur zu funktionieren, wenn man das Gerät mit HMCCUDEV definiert. Mit HMCCUCHN geht's nicht.

Grundsätzlich ist HMCCUCHN eine auf einen Kanal limitierte Variante von HMCCUDEV. Auch funktional ist das nicht so umfangreich wie HMCCUDEV. Das Attribut controldatapoint wird aber unterstützt. Da der Kanal bei HMCCUCHN bereits durch das Define festgelegt ist, wird bei controldatapoint nur der Datenpunkt ohne die Kanalnummer davor angegeben. Beispiel:

Bei HMCCUDEV: controldatapoint 1.LEVEL
Bei HMCCUCHN: controldatapoint LEVEL
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 16 April 2016, 10:49:37
Diese Inkonsistenz mit state und control ist mir auch schon aufgefallen. Um die Abwärsksompatibilität und auch Transparenz für den Benutzer zu sichern, könnte auch folgendes gemacht werden:

statedatapoint ... wie bisher
statechannel ... wie bisher

controldatapoint ... unterstützt Eingaben mit und ohne Kanalnummer
controlchannel ... neu, legt den Kanal des controldatapoint fest (und überschreibt ggf. die im controldatapoint definierte Kanalnummer)

Dann könnte man auch den Sonderfall

Zitat
Grund für 2 unterschiedliche Attribute ist, dass einige Homematic Geräte unterschiedliche Datenpunkte für das Setzen und Lesen von Werten verwenden (z.B. Thermostate).

mit diesen Attributen transparent für den Anwender beschreiben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 17 April 2016, 00:32:56
Wie kann ein Ralladenaktor: Funk- Jalousieaktor HM-LC-Bl1PBU-FM über HMCCU... gesteuert werden?

Ich habe folgende Readings beim HMCCUDEV:
Readings:
     2016-04-16 21:36:29   AZ-Rolladen.0.AES_KEY 0
     2016-04-16 21:36:29   AZ-Rolladen.0.CONFIG_PENDING false
     2016-04-16 21:36:29   AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
     2016-04-16 21:36:29   AZ-Rolladen.0.DUTYCYCLE false
     2016-04-16 21:36:29   AZ-Rolladen.0.RSSI_DEVICE 189
     2016-04-16 21:36:29   AZ-Rolladen.0.RSSI_PEER 196
     2016-04-16 21:36:29   AZ-Rolladen.0.STICKY_UNREACH false
     2016-04-16 21:36:29   AZ-Rolladen.0.UNREACH false
     2016-04-16 21:36:29   AZ-Rolladen.0.UPDATE_PENDING false
     2016-04-16 21:36:29   AZ-Rolladen.1.DIRECTION 0
     2016-04-16 21:36:29   AZ-Rolladen.1.INHIBIT false
     2016-04-16 21:36:29   AZ-Rolladen.1.INSTALL_TEST N/A
     2016-04-16 21:36:29   AZ-Rolladen.1.LEVEL 0.720000
     2016-04-16 21:36:29   AZ-Rolladen.1.STOP N/A
     2016-04-16 21:36:29   AZ-Rolladen.1.WORKING false
     2016-04-16 23:59:42   state           OK

In der Schnittstellenbeschreibung finde ich zusätzlich die Erläuterung für den Parameter DIRECTION:

Parameter DIRECTION lesend

Werteliste:
0 = NONE (Standard)
1 = UP
2 = DOWN
3 = UNDEFINED

Kann man damit irgendwie die Funktionen: UP, DOWN und STOP umsetzen? Bisher kann ich nur On und Off über das Reading LEVEL setzen....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 17 April 2016, 13:09:16
Grundsätzlich sollte LEVEL=50 den Rolladen auf halbe Höhe fahren. Voraussetzung ist, dass der Rolladen kalibiriert ist, d.h. die richtige Fahrtzeit eingestellt ist. Funktioniert das?

Außerdem kann man wohl in den Geräteeinstellungen in der CCU 2 interne Schalter aktivieren, über die dann die Steuerung erfolgt. Danach sollte get deviceinfo mehr Datenpunkte liefern.

Leider alles Theorie, da meine Rolladenschalter aufgrund von Umbauarbeiten derzeit ausgebaut sind.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 17 April 2016, 17:36:50
Da mich einige Nachfragen erreicht haben, wann denn die neue Version mit dem versprochenen internen RPC Server kommt, hier mal ein kurzes Update nach 2 Tagen zeit- und nervenintensivem Testen mit internen RPC Prozessen unter Verwendung des Moduls SubProcess.pm:

Grundsätzlich läuft es nun ohne ccurpcd.pl. Die in SubProcess.pm eingebaute Interprozess Kommunikation scheitert jedoch, wenn zu viele Homematic Geräte benutzt werden. FHEM scheint die Daten von der CCu in seiner Read-Schleife nicht schnell genug verarbeiten zu können. Dadurch gehen Events der CCU verloren. Das darf natürlich nicht sein. Ich teste beim mir mit 45 Devices, ca. 350 Kanälen und einer vermutlich mittleren 4 Stelligen Zahl an Datenpunkten. Entsprechend viele Events schickt die CCU. Mein Fazit: Für sowas ist Perl einfach nicht geeignet.

Die Version 3.2 wird also (zunächst optional) ohne ccurpcd.pl auskommen. Subprocess.pm wird dann für die Ausführung der RPC Serverprozesse verwendet, nicht jedoch für die interne Kommunikation. Die wird weiter über die Filequeues laufen. Das läuft stabil und skaliert gut.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 17 April 2016, 17:48:17
Zitat
Grundsätzlich sollte LEVEL=50 den Rolladen auf halbe Höhe fahren. Voraussetzung ist, dass der Rolladen kalibiriert ist, d.h. die richtige Fahrtzeit eingestellt ist. Funktioniert das?

Ja, das geht. Allerdings ist bei mir der obere und der untere Endpunkt vertauscht. Wenn der Rolladen komplett offen ist, dann wird er in der CCU als komplett geschlossen angezeigt... Ist das falsch verkabelt oder falsch parametriert? Siehe Bild:

Zitat
Außerdem kann man wohl in den Geräteeinstellungen in der CCU 2 interne Schalter aktivieren, über die dann die Steuerung erfolgt. Danach sollte get deviceinfo mehr Datenpunkte liefern.

Ich habe in der CCU2 einmal auf "Experten-Mode" umgestellt. Ich vermute mal, das war gemeint. Hierzu habe ich in der Benutzerverwaltung die Checkbox „Modus vereinfachte Verknüpfungskonfiguration aktivieren“ deaktiviert. Danach habe ich bei HMCCU die Deviceliste neu eingelesen und bei meinem Rolladen das HMCCUDEV mit get update neu gelesen.

=> keine neuen, erweiterten Readings sichtbar....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 17 April 2016, 18:13:56
Dass beim LEVEL Datenpunkt oben und unten vertauscht ist, ist bekannt. In CUL_HM gibt es dafür extra eine Option, um das zu vertauschen. Aber ich hatte ja schon meine Abneigung gegen Speziallösungen für einzelne Geräte erwähnt ;-) Mal sehen ...

Hier mal einige Infos zu dem Teil:

http://www.fhemwiki.de/wiki/HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor

Im Prinzip kennt CUL_HM auch nicht mehr Readings. Ich schaue mir das mal in 10_CUL_HM.pm an.

UPDATE: Womöglich kann man gar nicht angeben, ob er hoch oder runter fahren soll. Im Prinzip reicht LEVEL ja aus. Es sein denn, man möchte während der Fahrt abbrechen.

UPDATE2: Das Abbrechen der Fahrt geht vermutlich über den Datenpunkt STOP (Write Only). Der Datentyp ist ACTION, die Frage ist, welcher Wert die Fahrt stoppt.

UPDATE3: Du solltest die Fahrt eines Rolladens mit "set AZ-Rolladen 1.STOP true" abbrechen können. Starten der Fahrt wie gesagt mit LEVEL. Etwas vereinfacht:

attr AZ-Rolladen statechannel 1
attr AZ-Rolladen statedatapoint LEVEL
attr AZ-Rolladen statevals up:100,down:0

Dann dürfte folgendes möglich sein:

set AZ-Rolladen up
set AZ-Rolladen down
set AZ-Rolladen devstate 50
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 17 April 2016, 20:00:45
Ich habe den Rolladen wie folgt definiert:
Internals:
   CFGFN
   DEF        AZ-Rolladen 1
   IODev      myHomematicCCU
   NAME       Arbeitszimmer_Rolladen
   NR         3305
   STATE      1.0
   TYPE       HMCCUDEV
   ccuaddr    LEQ1032012
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    AZ-Rolladen
   ccutype    HM-LC-Bl1PBU-FM
   channels   2
   statevals  devstate|up|down
   Readings:
     2016-04-17 19:52:13   AZ-Rolladen.0.AES_KEY 0
     2016-04-17 19:52:13   AZ-Rolladen.0.CONFIG_PENDING false
     2016-04-17 19:52:13   AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
     2016-04-17 19:52:13   AZ-Rolladen.0.DUTYCYCLE false
     2016-04-17 19:52:13   AZ-Rolladen.0.RSSI_DEVICE 189
     2016-04-17 19:52:13   AZ-Rolladen.0.RSSI_PEER 196
     2016-04-17 19:52:13   AZ-Rolladen.0.STICKY_UNREACH true
     2016-04-17 19:52:13   AZ-Rolladen.0.UNREACH false
     2016-04-17 19:52:13   AZ-Rolladen.0.UPDATE_PENDING false
     2016-04-17 19:52:13   AZ-Rolladen.1.DIRECTION 0
     2016-04-17 19:52:13   AZ-Rolladen.1.INHIBIT false
     2016-04-17 19:52:13   AZ-Rolladen.1.INSTALL_TEST N/A
     2016-04-17 19:52:13   AZ-Rolladen.1.LEVEL 1.0
     2016-04-17 19:52:13   AZ-Rolladen.1.STOP N/A
     2016-04-17 19:52:13   AZ-Rolladen.1.WORKING false
     2016-04-17 19:52:13   control         1.0
     2016-04-17 19:52:13   state           1.0
Attributes:
   IODev      myHomematicCCU
   controldatapoint 1.LEVEL
   group      Arbeitszimmer
   icon       fts_shutter_1w
   room       02_Oben,HMCCU
   statechannel 1
   statedatapoint LEVEL
   statevals  up:0.0,down:1.0
   stripnumber 1
   webCmd     control
   widgetOverride control:slider,0,0.050000,1,1

"set Arbeitszimmer_Rolladen 1.STOP true" oder "set Arbeitszimmer_Rolladen AZ-Rolladen.1.STOP true" liefert leider:

HMCCUDEV: Unknown argument 1.STOP, choose one of config control datapoint devstate up down toggle
oder
HMCCUDEV: Unknown argument AZ-Rolladen.1.STOP, choose one of config control datapoint devstate up down toggle

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: cho am 17 April 2016, 21:13:54
Hallo zap,

ich versuche gerade, das Schalten des CONTROL_MODE bei einem Heizkörperthermostat HM-CC-RT-DN einzurichten. Ich scheitere daran, dass ich einerseits 1.CONTROL_MODE [RE] lesen kann, aber andererseits 1.AUTO_MODE [W], 1.MANU_MODE [W] oder 1.BOOST_MODE [W] schalten muss. Kannst Du mir bitte zeigen, wie das geht?

Danke und viele Grüße

define HM_Control_Mode HMCCUDEV HM_Gruppe group=HM-CC-RT-DN
attr HM_Control_Mode IODev HM_CCU2
attr HM_Control_Mode ccureadingfilter HM_Gruppe:1!(CONTROL_MODE),HM-CC-RT-DN:4!(CONTROL_MODE)
attr HM_Control_Mode controldatapoint 1.CONTROL_MODE
attr HM_Control_Mode event-on-change-reading .*
attr HM_Control_Mode mapdatapoints HM-CC-RT-DN:4.CONTROL_MODE=HM_Gruppe:1.CONTROL_MODE
attr HM_Control_Mode stateFormat HM_Gruppe.1.CONTROL_MODE
attr HM_Control_Mode substitute CONTROL_MODE!(0):Auto,(1):Manu,(2):Party,(3):Boost
attr HM_Control_Mode webCmd control
attr HM_Control_Mode widgetOverride control:uzsuSelectRadio,Auto,Manu,Boost
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 18 April 2016, 07:46:50
"set Arbeitszimmer_Rolladen 1.STOP true" oder "set Arbeitszimmer_Rolladen AZ-Rolladen.1.STOP true" liefert leider:

HMCCUDEV: Unknown argument 1.STOP, choose one of config control datapoint devstate up down toggle
oder
HMCCUDEV: Unknown argument AZ-Rolladen.1.STOP, choose one of config control datapoint devstate up down toggle

Du musst dem Device schon sagen, welchen Befehl es ausführen soll, wenn Du nur einen Datenpunkt angibst (in dem Fall "datapoint"):

set Arbeitszimmer_Rolladen datapoint 1.STOP true

Falls es mit "true" nicht tut, versuche "1".

Für die Attribute: Bist Du sicher, dass LEVEL im Bereich 0-1 liegt und nicht 0-100 ?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 18 April 2016, 09:15:18
LEVEL ist beim Blind 0 .. 1 und zwar als Float!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 18 April 2016, 16:54:13
Hallo zap,

ich versuche gerade, das Schalten des CONTROL_MODE bei einem Heizkörperthermostat HM-CC-RT-DN einzurichten. Ich scheitere daran, dass ich einerseits 1.CONTROL_MODE [RE] lesen kann, aber andererseits 1.AUTO_MODE [W], 1.MANU_MODE [W] oder 1.BOOST_MODE [W] schalten muss. Kannst Du mir bitte zeigen, wie das geht?

Da muss ich Dich - momentan - leider enttäuschen. Das geht so nicht. Das Problem ist, dass sich in Deinem Fall 1 Steuerelement (die Radio Buttons) auf 3 Datenpunkte beziehen. control und controldatapoint sind aber dafür gedacht, den Werte für genau einen Datenpunkt per Widget einzustellen. Wenn also z.B. die Zieltemperatur per Radio-Button einstellen wolltest, würde das so aussehen (Devicename habe ich weggelassen):

attr controldatapoint 2.SET_TEMPERATURE
attr widgetOverride control:uzsuSelectRadio,20,25,30

Aber mal sehen. Vielleicht fällt mir ja noch was ein dazu.

UPDATE: Zwar nicht unbedingt das, was Du möchtest, aber zumindest etwas komfortabler (Devicename muss nach attr noch ergänzt werden):

attr eventmap /datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/
attr controldatapoint 2.SET_TEMPERATURE
attr webCmd control:Auto:Boost
attr widgetOverride control:slider,10,1,25

Damit steht Dir in der Geräteübersicht in FHEM ein Slider für die Zieltemperatur zur Verfügung. Neben dem Slider Werden Links "Auto" und "Boost" angezeigt. Außerdem kennt FHEM dann die Befehle set Auto und set Boost.

Statt den Links kann man sich auch Icons anzeigen lassen:

attr cmdIcon Auto:sani_heating_automatic Boost:sani_heating_boost

Das sieht dann aus wie im Anhang (wobei die Icons anklickbar sind und dann den Mode einstellen)

Ach ja: aufpassen! Die richtigen Kanalnummern verwenden. Ich bin von einem Wandthermostaten ausgegangen. Da liegen die Datenpunkte in Kanal 2. Könnte bei Dir anders sein bzw. wenn ich das richtig gesehen habe, ist es bei Dir Kanal 1.

Der MANU_MODE fehlt mit Absicht. Dieser Modus wird nämlich aktiviert, indem man dem Datenpunkt MANU_MODE eine Temperatur zuweist. Um die Sache noch komplizierter zu machen, gibt es die speziellen Temperaturen 4.5 und 30.5. Erstere dreht das Ventil komplett zu während letztere das Ventil zu 100% öffnet (also im Prinzip ein on und off).

Das könnte man ausnutzen und sich noch mit eventmap einen on und off Befehl bauen sowie einen Manu Befehl, der die Temperatur auf 20 Grad einstellt:

attr eventmap /datapoint 2.AUTO_MODE 1:Auto/datapoint 2.BOOST_MODE 1:Boost/datapoint 2.MANU_MODE 4.5:off/datapoint 2.MANU_MODE 30.5:on/datapoint 2.MANU_MODE 20:Manu/
attr cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
attr webCmd control:Auto:Boost:Manu:on:off
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 18 April 2016, 20:08:55
Hallo zap,

ich habe mir eben mal die aktuellen Dateien gedownloaded.

Jetzt geht bei mir der RPC Server gar nicht mehr.

So sehen die Logs aus:
ccurpc
17.04.2016 20:57:07 Entering server loop. Use kill -SIGINT 28332 to terminate program
17.04.2016 20:57:12 ListDevices
17.04.2016 20:57:14 NewDevice: received 220 device specifications
17.04.2016 21:01:31 Received 250 events from CCU since last check
17.04.2016 21:05:14 RPC server terminated
17.04.2016 21:05:14 RPC server received 445 (447) events
17.04.2016 21:06:43 Creating file queue
17.04.2016 21:06:43 Initializing RPC server
17.04.2016 21:06:44 Callback server created listening on port 7401
17.04.2016 21:06:44 Adding callback for events
17.04.2016 21:06:44 Adding callback for new devices
17.04.2016 21:06:44 Adding callback for deleted devices
17.04.2016 21:06:44 Adding callback for modified devices
17.04.2016 21:06:44 Adding callback for replaced devices
17.04.2016 21:06:44 Adding callback for readded devices
17.04.2016 21:06:44 Entering server loop. Use kill -SIGINT 1221 to terminate program
17.04.2016 21:06:46 ListDevices
17.04.2016 21:06:50 NewDevice: received 220 device specifications
17.04.2016 21:10:43 Received 250 events from CCU since last check
18.04.2016 19:58:50 RPC server terminated
18.04.2016 19:58:50 RPC server received 616 (618) events

fhemlog:
2016.04.17 20:56:53 0: Server started with 26 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 28314)
2016.04.17 20:56:53 3: ipc fronthem:127.0.0.1:52732 (ws): ws alive with pid 28315
2016.04.17 20:57:05 0: HMCCU: RPC server started with pid 28332
2016.04.17 20:57:12 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.17 20:57:13 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.17 20:57:18 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.17 20:59:37 1: HMCCUCHN: Arbeitszimmer_Fenster Execution of CCU script or command failed
2016.04.17 21:03:06 1: HMCCUCHN: Bad_Fenster Execution of CCU script or command failed
2016.04.17 21:04:50 1: in DEFINED
2016.04.17 21:04:58 1: in SAVE
2016.04.17 21:05:14 1: in SHUTDOWN
2016.04.17 21:05:14 0: Server shutdown
2016.04.17 21:05:14 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.17 21:05:14 0: HMCCU: Stopping RPC server CB2001 with PID 28332
2016.04.17 21:05:14 0: HMCCU: Stopping RPC server with PID 28332
2016.04.17 21:05:46 1: Including fhem.cfg
2016.04.17 21:05:46 3: telnetPort: port 7072 opened
2016.04.17 21:05:48 3: WEB: port 8083 opened
2016.04.17 21:05:48 3: WEBphone: port 8084 opened
2016.04.17 21:05:48 3: WEBtablet: port 8085 opened
2016.04.17 21:06:00 2: eventTypes: loaded 117 events from ./log/eventTypes.txt
2016.04.17 21:06:02 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.17 21:06:24 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.17 21:06:24 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.17 21:06:25 1: Including ./log/fhem.save
2016.04.17 21:06:26 1: in INITIALIZED
2016.04.17 21:06:26 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.17 21:06:26 1: usb create starting
2016.04.17 21:06:27 3: Probing CUL device /dev/ttyAMA0
2016.04.17 21:06:27 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.17 21:06:27 1: usb create end
2016.04.17 21:06:27 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.17 21:06:27 0: Featurelevel: 5.7
2016.04.17 21:06:27 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 900)
2016.04.17 21:06:27 3: ipc fronthem:127.0.0.1:44803 (ws): ws alive with pid 1050
2016.04.17 21:06:39 0: HMCCU: RPC server started with pid 1221
2016.04.17 21:06:46 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.17 21:06:47 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.17 21:06:52 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.17 21:25:31 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.18 19:58:50 1: in SHUTDOWN
2016.04.18 19:58:50 0: Server shutdown
2016.04.18 19:58:50 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.18 19:58:50 0: HMCCU: Stopping RPC server CB2001 with PID 1221
2016.04.18 19:58:50 0: HMCCU: RPC server not running
2016.04.18 19:59:21 1: Including fhem.cfg
2016.04.18 19:59:21 3: telnetPort: port 7072 opened
2016.04.18 19:59:23 3: WEB: port 8083 opened
2016.04.18 19:59:23 3: WEBphone: port 8084 opened
2016.04.18 19:59:23 3: WEBtablet: port 8085 opened
2016.04.18 19:59:23 2: eventTypes: loaded 128 events from ./log/eventTypes.txt
2016.04.18 19:59:25 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 2840, <$fh> line 40.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 40.
2016.04.18 19:59:48 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.18 19:59:48 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.18 19:59:49 1: Including ./log/fhem.save
2016.04.18 19:59:49 1: in INITIALIZED
2016.04.18 19:59:49 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.18 19:59:49 1: usb create starting
2016.04.18 19:59:50 3: Probing CUL device /dev/ttyAMA0
2016.04.18 19:59:50 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.18 19:59:50 1: usb create end
2016.04.18 19:59:50 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.18 19:59:50 0: Featurelevel: 5.7
2016.04.18 19:59:50 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 912)
2016.04.18 19:59:50 3: ipc fronthem:127.0.0.1:46817 (ws): ws alive with pid 1046
2016.04.18 20:01:04 0: HMCCU: RPC server started with pid 1302
RPCQueue.pm did not return a true value at ./FHEM/ccurpcd.pl line 42.
BEGIN failed--compilation aborted at ./FHEM/ccurpcd.pl line 42.
2016.04.18 20:01:10 0: HMCCU: All RPC servers stopped
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 18 April 2016, 21:23:41
Ich nehme an, Du hast entweder ccurpcd.pl oder RPCQueue.pm nicht korrekt über den Download Link herunter geladen.  Du musst die Dateien anzeigen lassen und dann links oben "download this file" auswählen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 19 April 2016, 06:19:22
danke -das wars :-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 19 April 2016, 07:38:29
Sorry für die Unannehmlichkeiten beim Download. Es nervt mich ja auch. Das wird sich ändern. Habe bereits einen Github Account und werde HMCCU wohl erst mal bei Github unterbringen. Dann klappts auch mit dem Update (Befehl).

Leider unterstützt das FHEM Update den contrib Zweig nicht und in den FHEM-Zweig darf das Modul (noch) nicht, weil ccurpcd.pl (noch) als externe Datei dabei ist.

Daher temporär erst mal der Umweg über Github, wie das andere Modul-Entwickler auch machen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 19 April 2016, 08:42:55
Danke zap, das war's:

Zitat
Du musst dem Device schon sagen, welchen Befehl es ausführen soll, wenn Du nur einen Datenpunkt angibst (in dem Fall "datapoint"):

set Arbeitszimmer_Rolladen datapoint 1.STOP true

set Arbeitszimmer_Rolladen datapoint 1.STOP true funktioniert...


Zitat
Für die Attribute: Bist Du sicher, dass LEVEL im Bereich 0-1 liegt und nicht 0-100 ?

Ja, das Reading LEVEL liefert Werte zwischen 0.0 und 1.0. Z.B.  AZ-Rolladen.1.LEVEL 0.6. Siehe ein aktuelles list vom Arbeitszimmer_Rolladen...

Internals:
   CFGFN
   DEF        AZ-Rolladen 1
   IODev      myHomematicCCU
   NAME       Arbeitszimmer_Rolladen
   NR         3305
   STATE      OK
   TYPE       HMCCUDEV
   ccuaddr    LEQ1032012
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    AZ-Rolladen
   ccutype    HM-LC-Bl1PBU-FM
   channels   2
   statevals  devstate|up|down
   Readings:
     2016-04-19 08:36:11   AZ-Rolladen.0.AES_KEY 0
     2016-04-19 08:36:11   AZ-Rolladen.0.CONFIG_PENDING false
     2016-04-19 08:36:11   AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
     2016-04-19 08:36:11   AZ-Rolladen.0.DUTYCYCLE false
     2016-04-19 08:36:11   AZ-Rolladen.0.RSSI_DEVICE 193
     2016-04-19 08:36:11   AZ-Rolladen.0.RSSI_PEER 197
     2016-04-19 08:36:11   AZ-Rolladen.0.STICKY_UNREACH false
     2016-04-19 08:36:11   AZ-Rolladen.0.UNREACH false
     2016-04-19 08:36:11   AZ-Rolladen.0.UPDATE_PENDING false
     2016-04-19 08:36:11   AZ-Rolladen.1.DIRECTION 0
     2016-04-19 08:36:11   AZ-Rolladen.1.INHIBIT false
     2016-04-19 08:36:11   AZ-Rolladen.1.INSTALL_TEST N/A
     2016-04-19 08:36:11   AZ-Rolladen.1.LEVEL 0.6
     2016-04-19 08:36:11   AZ-Rolladen.1.STOP N/A
     2016-04-19 08:36:11   AZ-Rolladen.1.WORKING false
     2016-04-19 08:36:11   control         0.6
     2016-04-19 08:35:56   state           OK
Attributes:
   IODev      myHomematicCCU
   controldatapoint 1.LEVEL
   group      Arbeitszimmer
   icon       fts_shutter_1w
   room       02_Oben,HMCCU
   statechannel 1
   statevals  up:0.0,down:1.0
   stripnumber 1
   webCmd     control
   widgetOverride control:slider,0,0.050000,1,1
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 19 April 2016, 13:16:10
Wie ich das gestern schon für cho's Thermostatfrage beantwortet hatte kannst Du Dir mit eventmap recht einfache Abkürzungen für up, down und stop bauen:

attr Arbeitszimmer_Rolladen eventmap /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 0:down/datapoint 1.LEVEL 1:up/

Dann kannst Du folgendes machen:

set Arbeitszimmer_Rolladen up
set Arbeitszimmer_Rolladen down
set Arbeitszimmer_Rolladen stop
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 19 April 2016, 17:37:48
Anbei nun das komplette Beispiel für die Definition eines Rolladenaktors: HM-LC-Bl1PBU-FM

Internals:
   CFGFN
   DEF        AZ-Rolladen 1
   IODev      myHomematicCCU
   NAME       Arbeitszimmer_Rolladen
   NR         3305
   STATE      OK
   TYPE       HMCCUDEV
   ccuaddr    LEQ1032012
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    AZ-Rolladen
   ccutype    HM-LC-Bl1PBU-FM
   channels   2
   statevals  devstate|up|down
   Readings:
     2016-04-19 08:36:11   AZ-Rolladen.0.AES_KEY 0
     2016-04-19 08:36:11   AZ-Rolladen.0.CONFIG_PENDING false
     2016-04-19 08:36:11   AZ-Rolladen.0.DEVICE_IN_BOOTLOADER false
     2016-04-19 08:36:11   AZ-Rolladen.0.DUTYCYCLE false
     2016-04-19 08:36:11   AZ-Rolladen.0.RSSI_DEVICE 193
     2016-04-19 08:36:11   AZ-Rolladen.0.RSSI_PEER 197
     2016-04-19 08:36:11   AZ-Rolladen.0.STICKY_UNREACH false
     2016-04-19 08:36:11   AZ-Rolladen.0.UNREACH false
     2016-04-19 08:36:11   AZ-Rolladen.0.UPDATE_PENDING false
     2016-04-19 08:36:11   AZ-Rolladen.1.DIRECTION 0
     2016-04-19 08:36:11   AZ-Rolladen.1.INHIBIT false
     2016-04-19 08:36:11   AZ-Rolladen.1.INSTALL_TEST N/A
     2016-04-19 08:36:11   AZ-Rolladen.1.LEVEL 0.6
     2016-04-19 08:36:11   AZ-Rolladen.1.STOP N/A
     2016-04-19 08:36:11   AZ-Rolladen.1.WORKING false
     2016-04-19 08:36:11   control         0.6
     2016-04-19 17:33:51   state           OK
Attributes:
   IODev      myHomematicCCU
   cmdIcon    up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
   controldatapoint 1.LEVEL
   eventMap   /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 1:down/datapoint 1.LEVEL 0:up/
   group      Arbeitszimmer
   icon       fts_shutter_1w
   room       02_Oben,HMCCU
   statechannel 1
   statevals  up:0.0,down:1.0
   stripnumber 1
   webCmd     control:up:stop:down
   widgetOverride control:slider,0,0.05,1,1

Danke für alle Hinweise und Ratschläge. Das Ergebnis gefällt mir...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 19 April 2016, 18:10:22
Noch eine Kleinigkeit: wenn ich den Rolladen mit dem Slider (control) in eine neue Position fahre, dann ändert sich der Slider "unschön"

Das Verhalten/die Bedienung ist wie folgt:


Schöner wäre, wenn der Slider beim Verschieden auf 0.80 (80%) dort "verharren" würde.

In der Detailansicht des Rolladenaktor ist das Verhalten ähnlich:

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 19 April 2016, 20:20:28
Hallo Achiim,

Zitat
Anbei nun das komplette Beispiel für die Definition eines Rolladenaktors: HM-LC-Bl1PBU-FM


Könntest Du auch noch die Befehle für die Definition posten? Ich möchte gerade genau den gleichen Aktor einbinden :-)

Gruß
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 19 April 2016, 22:34:47
Spezial Service für Nic0205

define Arbeitszimmer_Rolladen HMCCUDEV AZ-Rolladen 1
attr Arbeitszimmer_Rolladen IODev myHomematicCCU
attr Arbeitszimmer_Rolladen cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
attr Arbeitszimmer_Rolladen controldatapoint 1.LEVEL
attr Arbeitszimmer_Rolladen eventMap /datapoint 1.STOP 1:stop/datapoint 1.LEVEL 1:down/datapoint 1.LEVEL 0:up/
attr Arbeitszimmer_Rolladen group Arbeitszimmer
attr Arbeitszimmer_Rolladen icon fts_shutter_1w
attr Arbeitszimmer_Rolladen room 02_Oben,HMCCU
attr Arbeitszimmer_Rolladen statechannel 1
attr Arbeitszimmer_Rolladen statevals up:0.0,down:1.0
attr Arbeitszimmer_Rolladen stripnumber 1
attr Arbeitszimmer_Rolladen webCmd control:up:stop:down
attr Arbeitszimmer_Rolladen widgetOverride control:slider,0,0.05,1,1
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 20 April 2016, 07:38:08
Noch eine Kleinigkeit: wenn ich den Rolladen mit dem Slider (control) in eine neue Position fahre, dann ändert sich der Slider "unschön"

Schöner wäre, wenn der Slider beim Verschieden auf 0.80 (80%) dort "verharren" würde.

Der Slider zeigt den Wert des Readings "LEVEL" an. Mit dem Verschieben des Sliders änderst Du nicht den Wert des Readings, sondern legst den neuen Wert fest, der an die CCU für den Datenpunkt LEVEL geschickt wird. Sobald Du den Slider los lässt, schickt HMCCU das Set-Kommando an die CCU. Zu diesem Zeitpunkt ist aber das Reading LEVEL in FHEM noch nicht aktualisiert (das Web-Interface macht das nicht automatisch). Das Reading (und damit der Slider) wird erst auf das neue LEVEL aktualisiert, wenn HMCCU das Event von der CCU bekommt (quasi als Bestätigung, dass der Befehl ausgeführt wurde). Daher "fällt" das LEVEL bzw. der Slider wieder auf den Ausgangswert zurück.

Die Häufigkeit, mit der HMCCU Events von der CCU aus der Filequeue liest, kann mit dem Attribut rpcinterval im IO Device eingestellt werden. Default ist 5 Sekunden. Unter 3 Sekunden würde ich nicht gehen, da sonst FHEM zu sehr ausgebremst wird (gerade bei vielen CCU Devices). Aber Du kannst ja mal testweise 2 Sekunden einstellen (geht nur per Kommandozeile, im Webinterface nur 3,5,10 Sekunden).

Mal überlegen ... ich müsste im Prinzip vor dem Absetzen des set Befehls das Reading mit dem neuen Wert aktualisieren ...

Danke für das Beispiel. Wenn Du nichts dagegen hast, übernehme ich das in meine Beispielsammlung.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 20 April 2016, 23:38:10
Zitat
Danke für das Beispiel. Wenn Du nichts dagegen hast, übernehme ich das in meine Beispielsammlung.

Dafür sind Beispiele da.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 April 2016, 18:13:02
Für Dein Problem mit der späten Aktualisierung des Sliders könntest Du mal das Attribut ccuverify für den Rolladen auf 1 setzen. Das bewirkt, dass direkt nach dem Setzen des Ziellevels der Wert von der CCU abgefragt und das Reading aktualisiert wird.

Die Frage ist nur, welchen Wert die CCU liefert, solange der Rolladen fährt.

Hinweis: Wenn Du das Attribut setzt, wird zwischen set und get ein usleep() aufgerufen. Das benötigt das Modul Time::HiRes

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 21 April 2016, 23:35:48
Auch mit ccuverify für den Rolladen auf 1 ist das Verhalten des Sliders wie oben beschrieben. Ich kann kein geändertes Verhalten feststellen... Hättest du erwartet, dass der Slider sich nun langsam mit dem fahrenden Rolladen mitbewegt?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 April 2016, 07:52:40
Auch mit ccuverify für den Rolladen auf 1 ist das Verhalten des Sliders wie oben beschrieben. Ich kann kein geändertes Verhalten feststellen... Hättest du erwartet, dass der Slider sich nun langsam mit dem fahrenden Rolladen mitbewegt?

Nein, ich habe gehofft, dass der Slider während der Fahrt zumindest bei 0.8 stehen bleibt und nicht erst wieder auf 0.1 zurück fällt. In dem Fall ist wohl der Datenpunkt LEVEL in der CCU beim Fahren nicht aktualisiert. Vermutlich macht die CCU das erst am Ende der Fahrt.

Einziger Workaround, den ich anbieten kann: Ich baue das so um, dass das Reading LEVEL in FHEM direkt nach dem SET Befehl auf den Zielwert gesetzt wird. Dann fällt der Slider zumindest nicht auf 0.1 zurück. Das kann dann zum Problem werden, wenn der SET Befehl (aus welchen Gründen auch immer) nicht bei der CCU bzw. dem Rolladenaktor ankommt. Dann würde der Slider einen falschen Wert anzeigen.

Eines könntest Du noch testen: Das Attribut ccuverify auf 1 setzen und das Attribut ccuget auf "State". Letzteres bewirkt, dass das Abfragen von Datenpunkten direkt an den Aktor geht. Default ist hier "Value": da werden die Datenpunkte aus der CCU gelesen. State ist etwas langsamer als Value und belastet die Batterien beim Aktor (was aber beim Rolladen eh keine Rolle spielt).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: MarkBinary am 22 April 2016, 12:43:49
Hallo zusammen.

Wie bekomme ich den die 50 virtuellen Kanäle der CCU eingebunden?
Meine Türkontakte und Systemvariablen laufen soweit.

Nur beim befehl
define test HMCCUCHN BidCoS-RF:1 readonly

bekomme ich immer
Invalid or unknown CCU channel name or address
Anbei noch meine devicelist dump
DIN-W93-CCU2
DIN-W93-CCU2:0
HM-RCV-50 BidCoS-RF:1
HM-RCV-50 BidCoS-RF:10
HM-RCV-50 BidCoS-RF:11
HM-RCV-50 BidCoS-RF:12
HM-RCV-50 BidCoS-RF:13
HM-RCV-50 BidCoS-RF:14
HM-RCV-50 BidCoS-RF:15
HM-RCV-50 BidCoS-RF:16
HM-RCV-50 BidCoS-RF:17
HM-RCV-50 BidCoS-RF:18
HM-RCV-50 BidCoS-RF:19
HM-RCV-50 BidCoS-RF:2
HM-RCV-50 BidCoS-RF:20
HM-RCV-50 BidCoS-RF:21
HM-RCV-50 BidCoS-RF:22
HM-RCV-50 BidCoS-RF:23
HM-RCV-50 BidCoS-RF:24
HM-RCV-50 BidCoS-RF:25
HM-RCV-50 BidCoS-RF:26
HM-RCV-50 BidCoS-RF:27
HM-RCV-50 BidCoS-RF:28
HM-RCV-50 BidCoS-RF:29
HM-RCV-50 BidCoS-RF:3
HM-RCV-50 BidCoS-RF:30
HM-RCV-50 BidCoS-RF:31
HM-RCV-50 BidCoS-RF:32
HM-RCV-50 BidCoS-RF:33
HM-RCV-50 BidCoS-RF:34
HM-RCV-50 BidCoS-RF:35
HM-RCV-50 BidCoS-RF:36
HM-RCV-50 BidCoS-RF:37
HM-RCV-50 BidCoS-RF:38
HM-RCV-50 BidCoS-RF:39
HM-RCV-50 BidCoS-RF:4
HM-RCV-50 BidCoS-RF:40
HM-RCV-50 BidCoS-RF:41
HM-RCV-50 BidCoS-RF:42
HM-RCV-50 BidCoS-RF:43
HM-RCV-50 BidCoS-RF:44
HM-RCV-50 BidCoS-RF:45
HM-RCV-50 BidCoS-RF:46
HM-RCV-50 BidCoS-RF:47
HM-RCV-50 BidCoS-RF:48
HM-RCV-50 BidCoS-RF:49
HM-RCV-50 BidCoS-RF:5
HM-RCV-v50
HM-RCV-50 BidCoS-RF:6
HM-RCV-50 BidCoS-RF:7
HM-RCV-50 BidCoS-RF:8
HM-RCV-50 BidCoS-RF:9
Alarmsteuerung
Alarmsteuerung:0
HM-RC-Sec4-2 MEQ0077995:1
HM-RC-Sec4-2 MEQ0077995:2
HM-RC-Sec4-2 MEQ0077995:3
HM-RC-Sec4-2 MEQ0077995:4
Sirene
Sirene:0
HM-LC-Sw1-Ba-PCB MEQ0593893:1
Terrassent�re
Terrassent�re:0
HM-Sec-SCo NEQ0063373:1
Haust�re
Haust�re:0
HM-Sec-SCo NEQ0063864:1

Vielen Dank im vorraus
Markus
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 April 2016, 12:53:55
Theoretisch müsste es wohl so heißen:

define test HMCCUCHN HM-RCV-50 BidCoS-RF:1
Denn der Name des Kanals beinhaltet "HM-RCV-50". Schlecht ist, dass FHEM hier nicht mitspielt, da Leerzeichen als Parameter nicht unterstützt bzw. als 2 Parameter behandelt werden. Du hast 2 Möglichkeiten:

1. Du benennst den Kanal in der CCU um (ohne Leerzeichen)
2. Du versuchst, beim define statt dem Kanalnamen die Adresse anzugeben

Anderes Thema: In Deiner Geräteliste tauchen Kanäle mit Umlauten auf. Das ist für die Verwendung in FHEM nicht so gut. Wie Du siehst, werden die Umlaute durch kryptische Zeichen ersetzt. Damit funktioniert HMCCU nicht richtig (für die betroffenen Kanäle). Du solltest daher diese Geräte in der CCU umbenennen, wenn Du sie in FHEM ansprechen willst.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 22 April 2016, 20:54:17
Hallo zap,

irgendwie werden der RPC Server und ich keine Freunde mehr.

Nachdem ich den FHEM neu gestartet habe, klappt alles super. ich bekomme aktuelle Status zu meinen devices - alles wie es sein soll.

Nur danach erhalte ich keine updates mehr. Ich habe z.B. gerade um 19.55 Uhr ein Fenster geöffnet, davon bekommt der RPC Server aber nichts mit.

So sieht das rpc log aus:

19.04.2016 21:56:04 ListDevices CB2001. Sending init to HMCCU
19.04.2016 21:56:06 NewDevice: received 220 device specifications
20.04.2016 05:14:50 RPC server terminated
20.04.2016 05:15:18 Creating file queue
20.04.2016 05:15:18 Initializing RPC server
20.04.2016 05:15:19 Callback server created listening on port 7401
20.04.2016 05:15:19 Adding callback for events
20.04.2016 05:15:19 Adding callback for new devices
20.04.2016 05:15:19 Adding callback for deleted devices
20.04.2016 05:15:19 Adding callback for modified devices
20.04.2016 05:15:19 Adding callback for replaced devices
20.04.2016 05:15:19 Adding callback for readded devices
20.04.2016 05:15:19 Entering server loop. Use kill -SIGINT 1231 to terminate program
20.04.2016 05:15:25 ListDevices CB2001. Sending init to HMCCU
20.04.2016 05:15:28 NewDevice: received 220 device specifications
22.04.2016 06:16:02 RPC server terminated
22.04.2016 06:16:31 Creating file queue
22.04.2016 06:16:31 Initializing RPC server
22.04.2016 06:16:31 Callback server created listening on port 7401
22.04.2016 06:16:31 Adding callback for events
22.04.2016 06:16:31 Adding callback for new devices
22.04.2016 06:16:31 Adding callback for deleted devices
22.04.2016 06:16:31 Adding callback for modified devices
22.04.2016 06:16:31 Adding callback for replaced devices
22.04.2016 06:16:31 Adding callback for readded devices
22.04.2016 06:16:31 Entering server loop. Use kill -SIGINT 2199 to terminate program
22.04.2016 06:16:38 ListDevices CB2001. Sending init to HMCCU
22.04.2016 06:16:40 NewDevice: received 220 device specifications

und so das fhem.log:
2016.04.19 06:21:14 1: in DELETED
2016.04.19 06:21:16 1: in SAVE
2016.04.19 06:22:39 1: in SHUTDOWN
2016.04.19 06:22:39 0: Server shutdown
2016.04.19 06:22:39 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 06:22:39 0: HMCCU: Stopping RPC server CB2001 with PID 3769
2016.04.19 06:22:40 0: HMCCU: RPC server not running
2016.04.19 06:22:46 1: Including fhem.cfg
2016.04.19 06:22:46 3: telnetPort: port 7072 opened
2016.04.19 06:22:46 3: WEB: port 8083 opened
2016.04.19 06:22:46 3: WEBphone: port 8084 opened
2016.04.19 06:22:46 3: WEBtablet: port 8085 opened
2016.04.19 06:22:46 2: eventTypes: loaded 136 events from ./log/eventTypes.txt
2016.04.19 06:22:47 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 06:22:56 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 06:22:56 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 06:22:56 1: Including ./log/fhem.save
2016.04.19 06:22:56 1: in INITIALIZED
2016.04.19 06:22:56 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 06:22:56 1: usb create starting
2016.04.19 06:22:57 3: Probing CUL device /dev/ttyAMA0
2016.04.19 06:22:57 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 06:22:57 1: usb create end
2016.04.19 06:22:57 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.19 06:22:57 0: Featurelevel: 5.7
2016.04.19 06:22:57 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 5476)
2016.04.19 06:22:57 3: ipc fronthem:127.0.0.1:48354 (ws): ws alive with pid 5477
2016.04.19 06:23:08 0: HMCCU: RPC server started with pid 5490
2016.04.19 06:23:13 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 06:23:18 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 06:23:19 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 06:23:24 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 06:24:08 1: in DEFINED
2016.04.19 06:24:33 1: in DELETED
2016.04.19 06:25:44 1: in SAVE
2016.04.19 18:39:30 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 18:39:30 1: PERL WARNING: Use of uninitialized value $c in string ne at ./FHEM/88_HMCCU.pm line 909.
2016.04.19 18:39:30 1: PERL WARNING: Use of uninitialized value $c in string eq at ./FHEM/88_HMCCU.pm line 912.
2016.04.19 18:39:50 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 18:46:02 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 18:46:02 1: HMCCU: ChannelNo undefined: Addr=KEQ1023911
2016.04.19 20:09:49 1: in DEFINED
2016.04.19 20:11:27 1: HMCCUDEV: Kueche_Rollo Execution of CCU script or command failed
2016.04.19 20:11:36 1: in DELETED
2016.04.19 20:11:43 1: in DEFINED
2016.04.19 20:13:17 1: in SHUTDOWN
2016.04.19 20:13:17 0: Server shutdown
2016.04.19 20:13:17 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:13:17 0: HMCCU: Stopping RPC server CB2001 with PID 5490
2016.04.19 20:13:17 0: HMCCU: RPC server not running
2016.04.19 20:13:24 1: Including fhem.cfg
2016.04.19 20:13:24 3: telnetPort: port 7072 opened
2016.04.19 20:13:24 3: WEB: port 8083 opened
2016.04.19 20:13:24 3: WEBphone: port 8084 opened
2016.04.19 20:13:24 3: WEBtablet: port 8085 opened
2016.04.19 20:13:24 2: eventTypes: loaded 179 events from ./log/eventTypes.txt
2016.04.19 20:13:25 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:13:30 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:13:30 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 20:13:30 1: Including ./log/fhem.save
2016.04.19 20:13:30 1: statefile: Please define Kueche_Rollo first
2016.04.19 20:13:30 1: in INITIALIZED
2016.04.19 20:13:30 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:13:30 1: usb create starting
2016.04.19 20:13:31 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:13:31 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:13:31 1: usb create end
2016.04.19 20:13:31 2: Error messages while initializing FHEM: statefile: Please define Kueche_Rollo first
2016.04.19 20:13:31 0: Featurelevel: 5.7
2016.04.19 20:13:31 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 28049)
2016.04.19 20:13:31 3: ipc fronthem:127.0.0.1:50248 (ws): ws alive with pid 28051
2016.04.19 20:13:42 0: HMCCU: RPC server started with pid 28063
2016.04.19 20:13:47 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:13:48 1: in DEFINED
2016.04.19 20:13:52 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:13:53 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:13:58 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 20:23:53 1: in SHUTDOWN
2016.04.19 20:23:53 0: Server shutdown
2016.04.19 20:23:53 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:23:53 0: HMCCU: Stopping RPC server CB2001 with PID 28063
2016.04.19 20:23:53 0: HMCCU: RPC server not running
2016.04.19 20:24:00 1: Including fhem.cfg
2016.04.19 20:24:00 3: telnetPort: port 7072 opened
2016.04.19 20:24:00 3: WEB: port 8083 opened
2016.04.19 20:24:00 3: WEBphone: port 8084 opened
2016.04.19 20:24:00 3: WEBtablet: port 8085 opened
2016.04.19 20:24:00 2: eventTypes: loaded 192 events from ./log/eventTypes.txt
2016.04.19 20:24:01 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:24:06 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:24:06 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 20:24:06 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:24:06 1: Including ./log/fhem.save
2016.04.19 20:24:06 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specifiedstatefile: Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
Please define Kueche_Rollo first
2016.04.19 20:24:06 1: in INITIALIZED
2016.04.19 20:24:06 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:24:06 1: usb create starting
2016.04.19 20:24:07 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:24:07 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:24:07 1: usb create end
2016.04.19 20:24:07 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specifiedstatefile: Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first Please define Kueche_Rollo first
2016.04.19 20:24:07 0: Featurelevel: 5.7
2016.04.19 20:24:07 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 28757)
2016.04.19 20:24:07 3: ipc fronthem:127.0.0.1:50293 (ws): ws alive with pid 28758
2016.04.19 20:24:18 0: HMCCU: RPC server started with pid 28769
2016.04.19 20:24:23 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:24:28 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:24:29 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:24:34 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 20:28:21 1: in SHUTDOWN
2016.04.19 20:28:21 0: Server shutdown
2016.04.19 20:28:21 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:28:54 0: HMCCU: Stopping RPC server CB2001 with PID 28769
2016.04.19 20:28:54 0: HMCCU: RPC server not running
2016.04.19 20:29:00 1: Including fhem.cfg
2016.04.19 20:29:00 3: telnetPort: port 7072 opened
2016.04.19 20:29:01 3: WEB: port 8083 opened
2016.04.19 20:29:01 3: WEBphone: port 8084 opened
2016.04.19 20:29:01 3: WEBtablet: port 8085 opened
2016.04.19 20:29:01 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 20:29:01 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:29:07 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:29:07 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 20:29:07 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:29:07 1: Including ./log/fhem.save
2016.04.19 20:29:07 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:29:07 1: in INITIALIZED
2016.04.19 20:29:07 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:29:07 1: usb create starting
2016.04.19 20:29:08 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:29:08 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:29:08 1: usb create end
2016.04.19 20:29:08 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:29:08 0: Featurelevel: 5.7
2016.04.19 20:29:08 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 29047)
2016.04.19 20:29:08 3: ipc fronthem:127.0.0.1:50328 (ws): ws alive with pid 29048
2016.04.19 20:29:20 0: HMCCU: RPC server started with pid 29060
2016.04.19 20:29:25 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:29:30 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:29:30 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:29:35 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 20:34:54 1: in SHUTDOWN
2016.04.19 20:34:54 0: Server shutdown
2016.04.19 20:34:54 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 20:34:54 0: HMCCU: Stopping RPC server CB2001 with PID 29060
2016.04.19 20:34:54 0: HMCCU: RPC server not running
2016.04.19 20:35:00 1: Including fhem.cfg
2016.04.19 20:35:00 3: telnetPort: port 7072 opened
2016.04.19 20:35:01 3: WEB: port 8083 opened
2016.04.19 20:35:01 3: WEBphone: port 8084 opened
2016.04.19 20:35:01 3: WEBtablet: port 8085 opened
2016.04.19 20:35:01 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 20:35:02 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 20:35:06 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 20:35:06 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 20:35:07 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:35:07 1: Including ./log/fhem.save
2016.04.19 20:35:07 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:35:07 1: in INITIALIZED
2016.04.19 20:35:07 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 20:35:07 1: usb create starting
2016.04.19 20:35:07 3: Probing CUL device /dev/ttyAMA0
2016.04.19 20:35:08 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 20:35:08 1: usb create end
2016.04.19 20:35:08 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 20:35:08 0: Featurelevel: 5.7
2016.04.19 20:35:08 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 29436)
2016.04.19 20:35:08 3: ipc fronthem:127.0.0.1:50369 (ws): ws alive with pid 29437
2016.04.19 20:35:19 0: HMCCU: RPC server started with pid 29449
2016.04.19 20:35:24 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 20:35:29 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 20:35:30 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 20:35:35 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 21:07:05 3: Unregistering HTTPSRV TABLETUI for URL /ftui...
2016.04.19 21:07:05 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 21:07:05 0: HMCCU: Stopping RPC server CB2001 with PID 29449
2016.04.19 21:07:05 0: HMCCU: RPC server not running
2016.04.19 21:07:06 1: Including fhem.cfg
2016.04.19 21:07:06 3: telnetPort: port 7072 opened
2016.04.19 21:07:06 3: WEB: port 8083 opened
2016.04.19 21:07:06 3: WEBphone: port 8084 opened
2016.04.19 21:07:06 3: WEBtablet: port 8085 opened
2016.04.19 21:07:06 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 21:07:06 2: fronthem: ipc listener opened at port 16385
2016.04.19 21:07:07 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:07:07 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 21:07:08 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:07:08 1: Including ./log/fhem.save
2016.04.19 21:07:08 1: in REREADCFG
2016.04.19 21:07:08 1: in SHUTDOWN
2016.04.19 21:07:08 0: Server shutdown
2016.04.19 21:07:08 0: HMCCU: RPC server not running
2016.04.19 21:07:51 1: Including fhem.cfg
2016.04.19 21:07:51 3: telnetPort: port 7072 opened
2016.04.19 21:07:52 3: WEB: port 8083 opened
2016.04.19 21:07:52 3: WEBphone: port 8084 opened
2016.04.19 21:07:52 3: WEBtablet: port 8085 opened
2016.04.19 21:08:13 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 21:08:16 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 21:08:42 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:08:42 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 21:08:42 3: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:08:43 1: Including ./log/fhem.save
2016.04.19 21:08:43 1: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:08:43 1: in INITIALIZED
2016.04.19 21:08:43 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 21:08:43 1: usb create starting
2016.04.19 21:08:44 3: Probing CUL device /dev/ttyAMA0
2016.04.19 21:08:44 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 21:08:44 1: usb create end
2016.04.19 21:08:44 2: Error messages while initializing FHEM: configfile: Wohnzimmer_rollo_vorn: unknown IODev specified
2016.04.19 21:08:44 0: Featurelevel: 5.7
2016.04.19 21:08:44 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 918)
2016.04.19 21:08:44 3: ipc fronthem:127.0.0.1:60111 (ws): ws alive with pid 1055
2016.04.19 21:08:55 0: HMCCU: RPC server started with pid 1239
2016.04.19 21:09:06 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 21:09:11 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 21:09:11 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 21:09:16 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 21:14:12 1: in SHUTDOWN
2016.04.19 21:14:12 0: Server shutdown
2016.04.19 21:14:12 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 21:14:12 0: HMCCU: Stopping RPC server CB2001 with PID 1239
2016.04.19 21:14:12 0: HMCCU: RPC server not running
2016.04.19 21:14:18 1: Including fhem.cfg
2016.04.19 21:14:19 3: telnetPort: port 7072 opened
2016.04.19 21:14:19 3: WEB: port 8083 opened
2016.04.19 21:14:19 3: WEBphone: port 8084 opened
2016.04.19 21:14:19 3: WEBtablet: port 8085 opened
2016.04.19 21:14:19 2: eventTypes: loaded 195 events from ./log/eventTypes.txt
2016.04.19 21:14:20 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 21:14:25 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:14:25 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 21:14:25 1: Including ./log/fhem.save
2016.04.19 21:14:25 1: in INITIALIZED
2016.04.19 21:14:25 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 21:14:25 1: usb create starting
2016.04.19 21:14:26 3: Probing CUL device /dev/ttyAMA0
2016.04.19 21:14:26 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 21:14:26 1: usb create end
2016.04.19 21:14:26 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.19 21:14:26 0: Featurelevel: 5.7
2016.04.19 21:14:26 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1799)
2016.04.19 21:14:26 3: ipc fronthem:127.0.0.1:60277 (ws): ws alive with pid 1800
2016.04.19 21:14:37 0: HMCCU: RPC server started with pid 1812
2016.04.19 21:14:42 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 21:14:47 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 21:14:48 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 21:14:53 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.19 21:55:29 1: in SHUTDOWN
2016.04.19 21:55:29 0: Server shutdown
2016.04.19 21:55:29 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.19 21:55:29 0: HMCCU: Stopping RPC server CB2001 with PID 1812
2016.04.19 21:55:29 0: HMCCU: RPC server not running
2016.04.19 21:55:35 1: Including fhem.cfg
2016.04.19 21:55:36 3: telnetPort: port 7072 opened
2016.04.19 21:55:36 3: WEB: port 8083 opened
2016.04.19 21:55:36 3: WEBphone: port 8084 opened
2016.04.19 21:55:36 3: WEBtablet: port 8085 opened
2016.04.19 21:55:36 2: eventTypes: loaded 196 events from ./log/eventTypes.txt
2016.04.19 21:55:37 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.19 21:55:41 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.19 21:55:41 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.19 21:55:42 1: Including ./log/fhem.save
2016.04.19 21:55:42 1: in INITIALIZED
2016.04.19 21:55:42 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.19 21:55:42 1: usb create starting
2016.04.19 21:55:42 3: Probing CUL device /dev/ttyAMA0
2016.04.19 21:55:42 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.19 21:55:43 1: usb create end
2016.04.19 21:55:43 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.19 21:55:43 0: Featurelevel: 5.7
2016.04.19 21:55:43 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 4521)
2016.04.19 21:55:43 3: ipc fronthem:127.0.0.1:60397 (ws): ws alive with pid 4522
2016.04.19 21:55:54 0: HMCCU: RPC server started with pid 4535
2016.04.19 21:55:59 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.19 21:56:04 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.19 21:56:05 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.19 21:56:10 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.20 05:14:50 1: in SHUTDOWN
2016.04.20 05:14:50 0: Server shutdown
2016.04.20 05:14:50 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.20 05:14:50 0: HMCCU: Stopping RPC server CB2001 with PID 4535
2016.04.20 05:14:50 0: HMCCU: RPC server not running
2016.04.20 05:14:57 1: Including fhem.cfg
2016.04.20 05:14:57 3: telnetPort: port 7072 opened
2016.04.20 05:14:57 3: WEB: port 8083 opened
2016.04.20 05:14:57 3: WEBphone: port 8084 opened
2016.04.20 05:14:57 3: WEBtablet: port 8085 opened
2016.04.20 05:14:57 2: eventTypes: loaded 196 events from ./log/eventTypes.txt
2016.04.20 05:14:58 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.20 05:15:02 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.20 05:15:02 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.20 05:15:03 1: Including ./log/fhem.save
2016.04.20 05:15:03 1: in INITIALIZED
2016.04.20 05:15:03 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.20 05:15:03 1: usb create starting
2016.04.20 05:15:03 3: Probing CUL device /dev/ttyAMA0
2016.04.20 05:15:04 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.20 05:15:04 1: usb create end
2016.04.20 05:15:04 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.20 05:15:04 0: Featurelevel: 5.7
2016.04.20 05:15:04 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 1206)
2016.04.20 05:15:04 3: ipc fronthem:127.0.0.1:33136 (ws): ws alive with pid 1208
2016.04.20 05:15:15 0: HMCCU: RPC server started with pid 1231
2016.04.20 05:15:20 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.20 05:15:25 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.20 05:15:26 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.20 05:15:31 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.20 09:04:12 2: HMCCU: Unknown RPC event type [EV]
2016.04.20 13:26:49 2: HMCCU: Received no events from CCU since 300 seconds
2016.04.22 06:16:02 1: in SHUTDOWN
2016.04.22 06:16:02 0: Server shutdown
2016.04.22 06:16:02 1: HMCCU: Deregistering RPC server http://192.168.178.82:7401/fh2001
2016.04.22 06:16:02 0: HMCCU: Stopping RPC server CB2001 with PID 1231
2016.04.22 06:16:02 0: HMCCU: RPC server not running
2016.04.22 06:16:08 1: Including fhem.cfg
2016.04.22 06:16:08 3: telnetPort: port 7072 opened
2016.04.22 06:16:09 3: WEB: port 8083 opened
2016.04.22 06:16:09 3: WEBphone: port 8084 opened
2016.04.22 06:16:09 3: WEBtablet: port 8085 opened
2016.04.22 06:16:09 2: eventTypes: loaded 202 events from ./log/eventTypes.txt
2016.04.22 06:16:10 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.22 06:16:15 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.22 06:16:15 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.22 06:16:15 1: Including ./log/fhem.save
2016.04.22 06:16:15 1: in INITIALIZED
2016.04.22 06:16:15 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.22 06:16:15 1: usb create starting
2016.04.22 06:16:16 3: Probing CUL device /dev/ttyAMA0
2016.04.22 06:16:16 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.22 06:16:16 1: usb create end
2016.04.22 06:16:16 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.22 06:16:16 0: Featurelevel: 5.7
2016.04.22 06:16:16 0: Server started with 27 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2180)
2016.04.22 06:16:16 3: ipc fronthem:127.0.0.1:39720 (ws): ws alive with pid 2181
2016.04.22 06:16:28 0: HMCCU: RPC server started with pid 2199
2016.04.22 06:16:33 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.22 06:16:38 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.22 06:16:38 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.22 06:16:43 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.22 06:21:34 1: in DEFINED
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:21:34 1: in ATTR
2016.04.22 06:22:05 1: in DEFINED
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:05 1: in ATTR
2016.04.22 06:22:20 1: in DEFINED
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:20 1: in ATTR
2016.04.22 06:22:30 1: in DEFINED
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:30 1: in ATTR
2016.04.22 06:22:39 1: in DEFINED
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:39 1: in ATTR
2016.04.22 06:22:47 1: in DEFINED
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:22:48 1: in ATTR
2016.04.22 06:23:00 1: in DEFINED
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:00 1: in ATTR
2016.04.22 06:23:24 1: in DELETED
2016.04.22 06:23:26 1: in SAVE
2016.04.22 07:21:25 2: HMCCU: Received no events from CCU since 300 seconds

Hast Du eine Idee woran das liegt?

Grüße
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 April 2016, 21:33:05
Das sieht von RPC-Server Seite her gut aus. Alles wie es sein soll. Vielleicht stimmt etwas bei der Device Definition des Fensters nicht. Schick mal bitte die Ausgabe von list <Fensterdev-Name>.

Ich nehme mal an, Du hast mehr als ein CCU Geräte Device definiert. Wird bei keinem davon ein Reading aktualisiert?

Gehe ins Verzeichnis /tmp und führe mehrmals hintereinander den Befehl "ls -lrt" aus. Die Datei ccuqueue_2001.dat sollte immer wieder aktualisiert werden und die Größe sollte zwischen 0 und wenigen 100 Byte wechseln.

Dass der RPC Server irgendwann aufhört Daten zu schicken ist sehr ungewöhnlich. Entweder geht gleich der Start oder die Initialisierung in die Hose oder er läuft ... bei mir wochenlang ohne Probleme (ich habe sogar 3 parallel laufen)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 22 April 2016, 21:38:17
list-ausgabe:

Internals:
   CHANGED
   DEF        MEQ0723295:1 readonly
   IODev      d_ccu
   NAME       WZ_vorn_Fenster
   NR         54
   STATE      closed
   TYPE       HMCCUCHN
   ccuaddr    MEQ0723295:1
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Fenster Wohnzimmer vorn
   ccutype    HM-Sec-SCo
   channels   1
   statevals  readonly
   Readings:
     2016-04-22 06:46:16   Fenster_Wohnzimmer_vorn.ERROR 0
     2016-04-22 06:46:16   Fenster_Wohnzimmer_vorn.LOWBAT no
     2016-04-22 06:46:16   Fenster_Wohnzimmer_vorn.STATE closed
     2016-04-22 06:46:16   state           closed
Attributes:
   IODev      d_ccu
   ccureadingfilter (ERROR|LOWBAT|STATE)
   devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
   event-on-change-reading .*
   substitute STATE!(0|false):closed,(1|true):open;LOWBAT!(0|false):no,(1|true):yes


bei ls -lrt ändert sich nichts - ccuqueue_2001.dat ist 0 Byte groß und bleibt es auch:

pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ ls -lrt
insgesamt 16
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-9y9gPWkUWLjn
drwxr-xr-x 2 pi   pi      4096 Apr 19 21:08 hsperfdata_pi
drwx------ 2 pi   pi      4096 Apr 19 21:08 ssh-00DJdDNk0bYV
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.1
srwxr-xr-x 1 pi   pi         0 Apr 19 21:08 libdhcpcd-wpa-1097.0
-rw-rw-rw- 1 fhem dialout    1 Apr 22 21:36 ccuqueue_2001.idx
-rw-rw-rw- 1 fhem dialout    0 Apr 22 21:36 ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ cat ccuqueue_2001.idx
0pi@LiNaDo_Home:/tmp $ cat ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $ cat ccuqueue_2001.dat
pi@LiNaDo_Home:/tmp $

Kann ich irgendwo so was wie ein erweitertes Logging aktivieren?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 April 2016, 22:39:42
Und der RPC-Prozess läuft?

ps -ef | grep ccurpc
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 22 April 2016, 22:52:50
ja, sieht so aus:

pi@LiNaDo_Home:/tmp $ ps -ef | grep ccurpc
fhem      2199  2180  0 06:16 ?        00:01:25 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.178.101 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
pi        3630 24103  0 22:51 pts/0    00:00:00 grep --color=auto ccurpc
p
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 23 April 2016, 11:19:51
Zitat
Eines könntest Du noch testen: Das Attribut ccuverify auf 1 setzen und das Attribut ccuget auf "State". Letzteres bewirkt, dass das Abfragen von Datenpunkten direkt an den Aktor geht. Default ist hier "Value": da werden die Datenpunkte aus der CCU gelesen. State ist etwas langsamer als Value und belastet die Batterien beim Aktor (was aber beim Rolladen eh keine Rolle spielt).

Damit kann ich auch keinen Unterschied im Verhalten feststellen. der Slider springt immer während der Fahrt auf 0.0 und wenn die Fahrt zu Ende ist, springt er ein paar Sekunden danach auf den zuvor eingestellten Wert.

Wenn das okay ist, solltest du die vorgeschlagene Lösung mit dem Setzten des Readings "auf Verdacht" einbauen, bis eine  bessere Lösung identifiziert ist. Ich stehe hierzu wieder zum Testen bereit.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: bunni am 23 April 2016, 11:29:47
Habe alles installiert, und trotzdem bekomme ich ich die Meldung Cannot load HMCCU Modul, rechte sind auch gesetzt! Was mache ich falsch?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 April 2016, 15:12:12
Habe alles installiert, und trotzdem bekomme ich ich die Meldung Cannot load HMCCU Modul, rechte sind auch gesetzt! Was mache ich falsch?

Dazu gibt es vermutlich eine Fehlermeldung im fhem Logfile. Die brauche ich, dann kann ich Dir wahrscheinlich mehr zur Ursache sagen
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: bunni am 23 April 2016, 15:58:46
Liege leider zur Zeit im Krankenhaus, sobald ich zu Hause bin werde ich das Log File posten! Danke Dir!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 April 2016, 16:48:07
Das tut mir leid. Dann wünsche ich Dir baldige Genesung!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 23 April 2016, 19:00:53
Hallo zap,

Zitat
ja, sieht so aus:

Code: [Auswählen]
pi@LiNaDo_Home:/tmp $ ps -ef | grep ccurpc
fhem      2199  2180  0 06:16 ?        00:01:25 /usr/bin/perl ./FHEM/ccurpcd.pl 192.168.178.101 2001 /tmp/ccuqueue_2001 ./log/ccurpcd_2001.log
pi        3630 24103  0 22:51 pts/0    00:00:00 grep --color=auto ccurpc
p
Beitrag editieren

der pc server scheint ja vermeintlich noch zu laufen. Ich habe heute morgen einmal hem restarted. Daraufhin leif alles super bis ca. 17.35.

Ich vermute, dass es genau ab diese Meldung im Log nicht mehr geht:

HMCCU: Received no events from CCU since 300 seconds
Kannst Du dadurch das Problem eingrenzen?

Grüße
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 24 April 2016, 11:52:49
Hallo nochmal,

etwas ist mir noch aufgefallen:

Ich habe hier einen alten Thermostaten konfiguriert (mit Absicht mal ganz rudimentär):

IODev
d_ccu
NAME
Bad_Heizung
NR
155
STATE
Initialized
TYPE
HMCCUDEV
ccuaddr
HEQ0508540
ccudevstate
Active
ccuif
BidCos-RF
ccuname
Heizung Bad
ccutype
HM-CC-TC
channels
4
statevals
devstate
Readings
Raumklima_Bad.HUMIDITY
53
2016-04-24 11:48:27
Raumklima_Bad.TEMPERATURE
18.600000
2016-04-24 11:48:27
Soll_Temperatur_Bad.ADJUSTING_COMMAND
0
2016-04-24 11:48:48
Soll_Temperatur_Bad.ADJUSTING_DATA
0
2016-04-24 11:48:48
state
Initialized
2016-04-24 11:42:34

Ich bekomme diesen aber nie vom state "initialized" weg.

Durch die Attribute:

statechannel 1

statedatapoint Raumklima_Bad.TEMPERATURE

sollte doch eigentlich der State gleich TEMPERATURE sein. Ich habe das Gefühl (kann mich aber auch täuschen), dass das den RPC Server auch in den "Wahnsinn" treibt und deswegen nicht immer alle Statusänderungen verarbeitet werden.

Bei einem get Bad_Heizung update werden auch alle Readings aktualisiert, aber eben state ändert sich nichts.


die Readings sehen so aus:

Heizung_Bad.0.CONFIG_PENDING
false
2016-04-24 11:48:03
Heizung_Bad.0.LOWBAT
false
2016-04-24 11:48:03
Heizung_Bad.0.RSSI_DEVICE
1
2016-04-24 11:48:03
Heizung_Bad.0.RSSI_PEER
188
2016-04-24 11:48:03
Heizung_Bad.0.STICKY_UNREACH
false
2016-04-24 11:48:03
Heizung_Bad.0.UNREACH
false
2016-04-24 11:48:03
Raumklima_Bad.HUMIDITY
53
2016-04-24 11:54:20
Raumklima_Bad.TEMPERATURE
18.600000
2016-04-24 11:54:20
Soll_Temperatur_Bad.ADJUSTING_COMMAND
0
2016-04-24 11:54:40
Soll_Temperatur_Bad.ADJUSTING_DATA
0
2016-04-24 11:54:40
Soll_Temperatur_Bad.SETPOINT
1.000000
2016-04-24 11:48:03
Soll_Temperatur_Bad.STATE
N/A
2016-04-24 11:48:03
state
Initialized
2016-04-24 11:42:34
Hat jemand noch einen Tip für mich? Kann es sein, dass es das Attribut "State" im Thermostaten einfach nicht gibt, HMCCU aber verzweifelt versucht dieses Attribut auf "State" in FHEM zu mappen?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 April 2016, 14:47:42
Hallo Nic,

Du darfst bei statedatapoint nur den Datenpunkt angeben, also z.B. TEMPERATURE. Der entsprechende Kanal (Nummer) wird über statechannel festgelegt. HMCCU mappt diesen Datenpunkt auf STATE. Das beeinträchtigt den RPC Server nicht.
Das ist leider noch etwas unschön, zumal bei controldatapoint die Kanalnummer und der Datenpunkt zusammen angegeben werden. Ist leider nicht so einfach zu ändern, ohne die Kompatibilität zu verlieren.

Zu Deinem RPC Server Problem: Du hast also FHEM morgens gestartet und damit auch den RPC Server. Dann wurden bis nach 17:00 Uhr auch die Readings immer wieder automatisch aktualisiert, nicht nur einmalig beim Starten?? Und dann hat die Aktualisierung plötzlich aufgehört?

Die Meldung im Log "received no events since 300 seconds besagt nur, dass seit 5 Minuten keine Aktualisierung von der CCU mehr über den RPC Server in FHEM ankam. Das ist also das Symptom, nicht die Ursache.

Falls möglich schau Dir mal /var/log/messages in der CCU an. Gibt es da Fehlermeldungen?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 24 April 2016, 15:13:43
Hallo zap,

Zitat
Du darfst bei statedatapoint nur den Datenpunkt angeben, also z.B. TEMPERATURE. Der entsprechende Kanal (Nummer) wird über statechannel festgelegt. HMCCU mappt diesen Datenpunkt auf STATE. Das beeinträchtigt den RPC Server nicht.
Das ist leider noch etwas unschön, zumal bei controldatapoint die Kanalnummer und der Datenpunkt zusammen angegeben werden. Ist leider nicht so einfach zu ändern, ohne die Kompatibilität zu verlieren.

Das war es - jetzt funktioniert auch das Mapping - danke!

Hast Du noch einen Tip für mich, wie ich jetzt z.B. TEMPERATURE in FHEM-Tablet-UI anspreche (was nehme ich denn als data-device)?

Zitat
Zu Deinem RPC Server Problem: Du hast also FHEM morgens gestartet und damit auch den RPC Server. Dann wurden bis nach 17:00 Uhr auch die Readings immer wieder automatisch aktualisiert, nicht nur einmalig beim Starten?? Und dann hat die Aktualisierung plötzlich aufgehört?

Die Meldung im Log "received no events since 300 seconds besagt nur, dass seit 5 Minuten keine Aktualisierung von der CCU mehr über den RPC Server in FHEM ankam. Das ist also das Symptom, nicht die Ursache.

Falls möglich schau Dir mal /var/log/messages in der CCU an. Gibt es da Fehlermeldungen?

Ja genau so war es. Leider ist var/log/messages bei mir nur 1 Tag - und heute habe ich schon zig mal restarted. Ich beobachte das mal.



Gruß
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 24 April 2016, 17:42:07
Hast Du noch einen Tip für mich, wie ich jetzt z.B. TEMPERATURE in FHEM-Tablet-UI anspreche (was nehme ich denn als data-device)?

Du gibst als data-device den Namen des FHEM-Devices an, dessen Reading Du darstellen möchtest. In Deinem vorherigen Beispiel wäre das "Bad_Heizung".


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 24 April 2016, 17:44:39
Zitat
Du gibst als data-device den Namen des FHEM-Devices an, dessen Reading Du darstellen möchtest. In Deinem vorherigen Beispiel wäre das "Bad_Heizung".

Das funktioniert für TEMPERATURE prima, wenn ich jetzt aber z.B. "HUMIDITY" anzeigen will, klappt das nicht.

<div data-type="label" class="narrow darker" data-device="Bad_Heizung.HUMIDITY"></div> zeigt einfach nichts.
<div data-type="label" class="narrow darker" data-device="Bad_Heizung"></div> zeigt mir TEMPERATURE
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 24 April 2016, 21:11:46
... ich habe raus gefunden.

so funktioniert es:

<div data-type="label" class="narrow darker" data-device="Bad_Heizung" data-get="Raumklima_Bad.HUMIDITY"></div>

Wobei Raumklima_Bad der Name des Channels 1 in der CCU ist.

Was ich trotzdem nicht verstehe ist, warum statt data-get="Raumklima_Bad.HUMIDITY" nicht auch data-get="1.HUMIDITY"

funktioniert...
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 April 2016, 07:52:23
Wobei Raumklima_Bad der Name des Channels 1 in der CCU ist.

Was ich trotzdem nicht verstehe ist, warum statt data-get="Raumklima_Bad.HUMIDITY" nicht auch data-get="1.HUMIDITY"

funktioniert...

Weil "Raumklima_Bad" in Deinem Beispiel zwar zufällig mit dem Namen des Kanals in der CCU identisch ist, bei data-get aber prinzipiell der Reading-Name angegeben werden muss. Und "1.HUMIDITY" ist eben kein Reading-Name.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: bunni am 26 April 2016, 10:05:49
Hallo,
bin wieder zu Hause, das scheißt mir das Logfile raus, wenn ich versuche das HMCCU-Modul zu definieren:
2016.04.26 10:04:06 1: reload: Error:Modul 88_HMCCU deactivated:
 Can't locate File/Queue.pm in @INC (you may need to install the File::Queue module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 49.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 49.

2016.04.26 10:04:06 0: Can't locate File/Queue.pm in @INC (you may need to install the File::Queue module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/88_HMCCU.pm line 49.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 49.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 April 2016, 11:59:09
Es wird das Modul File::Queue benötigt. Allerdings scheinst Du eine etwas ältere Version von HMCCU zu verwenden. File::Queue wird schon geraume Zeit nicht mehr verwendet, d.h. Du musst das nicht über CPAN installieren. Lade bitte mal die aktuellen Versionen runter (Link siehe 1. Post):

88_HMCCU.pm, 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, RPCQueue.pm, ccurpcd.pl

Die Datei RPCQueue.pm ersetzt im Prinzip File::Queue.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 27 April 2016, 06:10:42
Zitat
Zu Deinem RPC Server Problem: Du hast also FHEM morgens gestartet und damit auch den RPC Server. Dann wurden bis nach 17:00 Uhr auch die Readings immer wieder automatisch aktualisiert, nicht nur einmalig beim Starten?? Und dann hat die Aktualisierung plötzlich aufgehört?

Die Meldung im Log "received no events since 300 seconds besagt nur, dass seit 5 Minuten keine Aktualisierung von der CCU mehr über den RPC Server in FHEM ankam. Das ist also das Symptom, nicht die Ursache.

Falls möglich schau Dir mal /var/log/messages in der CCU an. Gibt es da Fehlermeldungen?

Hallo zap,

heute habe ich tatsächlich das Log der CCU noch erwischt.

So sieht fhem-Log aus:

2016.04.26 20:46:41 1: Including fhem.cfg
2016.04.26 20:46:41 3: telnetPort: port 7072 opened
2016.04.26 20:46:41 3: WEB: port 8083 opened
2016.04.26 20:46:41 3: WEBphone: port 8084 opened
2016.04.26 20:46:41 3: WEBtablet: port 8085 opened
2016.04.26 20:46:42 2: eventTypes: loaded 438 events from ./log/eventTypes.txt
2016.04.26 20:46:43 2: fronthem: ipc listener opened at port 16384
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1191, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2840, <$fh> line 43.
2016.04.26 20:46:48 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2016.04.26 20:46:48 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2016.04.26 20:46:48 1: Including ./log/fhem.save
2016.04.26 20:46:48 1: in INITIALIZED
2016.04.26 20:46:48 0: HMCCU: Autostart of RPC server after FHEM initialization in 12 seconds
2016.04.26 20:46:48 1: usb create starting
2016.04.26 20:46:49 3: Probing CUL device /dev/ttyAMA0
2016.04.26 20:46:49 3: Can't open /dev/ttyAMA0: Keine Berechtigung
2016.04.26 20:46:49 1: usb create end
2016.04.26 20:46:49 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.26 20:46:49 0: Featurelevel: 5.7
2016.04.26 20:46:49 0: Server started with 34 defined entities (version $Id: fhem.pl 9893 2015-11-15 08:43:05Z rudolfkoenig $, os linux, user fhem, pid 2883)
2016.04.26 20:46:49 3: ipc fronthem:127.0.0.1:53142 (ws): ws alive with pid 2884
2016.04.26 20:47:01 0: HMCCU: RPC server started with pid 2898
2016.04.26 20:47:06 0: HMCCU: Received SL event. RPC server CB2001 starting server loop.
2016.04.26 20:47:11 1: HMCCU: Registering callback http://192.168.178.82:7401/fh2001 with ID CB2001 at http://192.168.178.101:2001/
2016.04.26 20:47:11 1: HMCCU: RPC callback with URL http://192.168.178.82:7401/fh2001 initialized
2016.04.26 20:47:16 0: HMCCU: Received IN event. RPC server CB2001 initialized.
2016.04.26 21:45:36 2: HMCCU: Unknown RPC event type [EV]
2016.04.26 21:56:39 2: HMCCU: Unknown RPC event type [EV]
2016.04.26 23:41:08 2: HMCCU: Unknown RPC event type [EV]
2016.04.27 00:39:29 2: HMCCU: Unknown RPC event type [EV]
2016.04.27 01:08:24 2: HMCCU: Unknown RPC event type [EV]
2016.04.27 03:12:30 2: HMCCU: Received no events from CCU since 300 seconds

und so /var/log/messages auf der CCU:

Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",par
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","IEQ0171822:2","ADJUSTING_COMMAND",0}],[methodName:"event",params
Apr 27 03:12:07 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","IEQ0173109:1","VALVE_STATE",0}],[methodName:"event",params:{"
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","IEQ0173109:1","VALVE_STATE",0}],[methodName:"event",params:{"CB2
Apr 27 03:12:27 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0508540:2","ADJUSTING_COMMAND",0}],[methodName:"event",par
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0508540:2","ADJUSTING_COMMAND",0}],[methodName:"event",params
Apr 27 03:12:34 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:36 homematic-ccu2 user.debug setclock: Wed Apr 27 03:12:36 CEST 2016                                                                                                   
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0510129:1","TEMPERATURE",19.000000}]}) on binary://192.168
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:1","TEMPERATURE",19.000000}]}) on http://192.168.178.
Apr 27 03:12:48 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0510129:1","HUMIDITY",63}],[methodName:"event",params:{"Bi
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:1","HUMIDITY",63}],[methodName:"event",params:{"CB200
Apr 27 03:13:01 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","LEQ0081955:2","ACTUAL_TEMPERATURE",14.600000}],[methodName:"e
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0081955:2","ACTUAL_TEMPERATURE",14.600000}],[methodName:"even
Apr 27 03:13:21 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","HEQ0510129:2","ADJUSTING_COMMAND",0}],[methodName:"event",par
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","HEQ0510129:2","ADJUSTING_COMMAND",0}],[methodName:"event",params
Apr 27 03:13:27 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","KEQ0729410:4","CONTROL_MODE",1}],[methodName:"event",params:{
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0729410:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB
Apr 27 03:13:33 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:36 homematic-ccu2 user.debug setclock: Try to get time from ntp.homematic.com                                                                                           
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","KEQ0519697:4","CONTROL_MODE",1}],[methodName:"event",params:{"CB
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"BidCos-RF","KEQ0519697:4","CONTROL_MODE",1}],[methodName:"event",params:{
Apr 27 03:13:39 homematic-ccu2 user.err rfd: XmlRpc transport error                                                                                                                 
Apr 27 03:13:45 homematic-ccu2 user.err rfd: XmlRpcClient error calling event({[methodName:"event",params:{"CB2001","LEQ0002140:2","ACTUAL_TEMPERATURE",18.700000}],[methodName:"even

Kannst Du damit etwas anfangen?

Viele Grüße Nie
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 April 2016, 09:12:03
Hallo Nic,

das sieht in der Tat so aus, als würde ab einem bestimmten Zeitpunkt der RPC-Server seine Arbeit einstellen. Die Fehlermeldungen in der CCU bedeuten, dass die CCU die Events an FHEM bzw. den RPC-Server schicken möchte, dieser aber keine Verbindung akzeptiert.

Das kann verschiedene Ursachen haben (ich gehe jetzt mal davon aus, dass der ccurpcd.pl Prozess noch läuft):


Bei meinen Tests ist das auch schon aufgetreten. Allerdings erst dann, wenn ich 3 CCU RPC-Schnittstellen (Wireless, Wired und Homematic IP) auf einen RPC-Server Prozess in FHEM losgelassen habe. Dann sind einige Events verloren gegangen und ich hatte die gleichen Meldungen im CCU Log. Ganz am Anfang habe ich auch mit dem FHEM-Webserver als RPC-Server experimentiert. Auch da gab es hin und wieder diese Meldungen im CCU-Log und es sind Events verloren gegangen. In beiden Fällen kam es aber nie vor, dass der RPC-Server komplett aufgegeben hat.

Wenn das Problem auftritt, könntest Du auf dem FHEM-Server mal den Befehl "netstat -an" ausführen. Die Ausgabe würde mich interessieren, insbesondere die Verbindungen mit Status "LISTEN" oder auch "TIME_WAIT", "SYN_WAIT".

Bzgl. Version RPC::Server muss ich erst mal bei mir nachschauen, welche ich benutze.

Nachtrag: Was ich auch interessant finde, sind die "Unknown event type" Meldungen für "EV". Das ist kein unknown Event-Type sondern der Standardtyp ... mysteriös.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 27 April 2016, 13:41:00
Hallo zap,

So sieht das netstat dann aus:

pi@LiNaDo_Home:~ $ netstat -an
Aktive Internetverbindungen (Server und stehende Verbindungen)
Proto Recv-Q Send-Q Local Address           Foreign Address         State     
tcp        0      0 0.0.0.0:3777            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:9000            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:5544            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:9001            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:2121            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8081            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8082            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:8085            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:16384         0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:52582         127.0.0.1:16384         VERBUNDEN 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51084   TIME_WAIT 
tcp     5844      0 192.168.178.82:7401     192.168.178.101:53861   CLOSE_WAIT
tcp        0      0 127.0.0.1:42692         127.0.0.1:9000          VERBUNDEN 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51126   TIME_WAIT 
tcp        0      0 192.168.178.82:8083     192.168.178.201:34351   TIME_WAIT 
tcp     4415      0 192.168.178.82:7401     192.168.178.101:53854   CLOSE_WAIT
tcp        0      0 192.168.178.82:5544     192.168.178.101:51094   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51074   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51110   TIME_WAIT 
tcp        0   3808 192.168.178.82:22       192.168.178.201:39749   VERBUNDEN 
tcp        0      0 192.168.178.82:7401     192.168.178.101:53745   VERBUNDEN 
tcp        0      0 127.0.0.1:42678         127.0.0.1:9000          VERBUNDEN 
tcp        0      0 192.168.178.82:41394    192.168.178.101:2001    VERBUNDEN 
tcp        0      0 127.0.0.1:9000          127.0.0.1:42692         VERBUNDEN 
tcp        0      0 192.168.178.82:8083     192.168.178.201:34350   TIME_WAIT 
tcp     5844      0 192.168.178.82:7401     192.168.178.101:53872   CLOSE_WAIT
tcp        0      0 192.168.178.82:5544     192.168.178.101:51112   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51117   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51092   TIME_WAIT 
tcp     4415      0 192.168.178.82:7401     192.168.178.101:53844   CLOSE_WAIT
tcp        0      0 192.168.178.82:5544     192.168.178.101:51115   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51103   TIME_WAIT 
tcp        0      0 127.0.0.1:9001          127.0.0.1:48437         VERBUNDEN 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51101   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51128   FIN_WAIT2 
tcp        0      0 127.0.0.1:48437         127.0.0.1:9001          VERBUNDEN 
tcp     6675      0 192.168.178.82:7401     192.168.178.101:53828   CLOSE_WAIT
tcp     6675      0 192.168.178.82:7401     192.168.178.101:53813   CLOSE_WAIT
tcp        0      0 192.168.178.82:8083     192.168.178.201:34352   VERBUNDEN 
tcp        0      0 127.0.0.1:48422         127.0.0.1:9001          VERBUNDEN 
tcp        0      0 127.0.0.1:9000          127.0.0.1:42678         VERBUNDEN 
tcp        0      0 127.0.0.1:16384         127.0.0.1:52582         VERBUNDEN 
tcp        0      0 127.0.0.1:9001          127.0.0.1:48422         VERBUNDEN 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51089   TIME_WAIT 
tcp        0      0 192.168.178.82:5544     192.168.178.101:51107   TIME_WAIT 
tcp6       0      0 :::9123                 :::*                    LISTEN     
tcp6       0      0 :::8101                 :::*                    LISTEN     
tcp6       0      0 127.0.0.1:32936         :::*                    LISTEN     
tcp6       0      0 :::139                  :::*                    LISTEN     
tcp6       0      0 :::8080                 :::*                    LISTEN     
tcp6       0      0 :::80                   :::*                    LISTEN     
tcp6       0      0 :::22                   :::*                    LISTEN     
tcp6       0      0 :::8443                 :::*                    LISTEN     
tcp6       0      0 :::445                  :::*                    LISTEN     
tcp6       1      0 192.168.178.82:50447    192.168.178.68:81       CLOSE_WAIT
tcp6       1      0 192.168.178.82:40626    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:50150    192.168.178.79:54963    CLOSE_WAIT
tcp6       1      0 192.168.178.82:40585    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40616    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40640    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40563    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40570    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:48009   TIME_WAIT 
tcp6       1      0 192.168.178.82:34405    192.168.178.1:49000     CLOSE_WAIT
tcp6       1      0 192.168.178.82:40630    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40559    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40621    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40573    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40612    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47996   TIME_WAIT 
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47970   TIME_WAIT 
tcp6       1      0 192.168.178.82:40601    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40613    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:39674    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40564    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40594    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:40656    72.30.202.51:80         VERBUNDEN 
tcp6       1      0 192.168.178.82:40627    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40628    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40654    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:48001   TIME_WAIT 
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47990   TIME_WAIT 
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47984   TIME_WAIT 
tcp6       1      0 192.168.178.82:40577    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40610    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40606    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40575    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40611    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:48015   FIN_WAIT2 
tcp6       1      0 192.168.178.82:40595    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40648    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40651    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40636    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40581    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40634    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40587    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40629    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40589    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40635    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40565    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40614    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40566    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:49216    192.168.178.87:8091     CLOSE_WAIT
tcp6       1      0 192.168.178.82:40645    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40608    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47973   TIME_WAIT 
tcp6       1      0 192.168.178.82:40619    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40599    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47993   TIME_WAIT 
tcp6       0      0 192.168.178.82:9123     192.168.178.101:48006   TIME_WAIT 
tcp6       1      0 192.168.178.82:40576    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40644    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40579    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40617    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40562    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:34408    192.168.178.1:49000     CLOSE_WAIT
tcp6       1      0 192.168.178.82:40641    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40593    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:40659    72.30.202.51:80         VERBUNDEN 
tcp6       1      0 192.168.178.82:40604    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40609    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40586    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:34404    192.168.178.1:49000     CLOSE_WAIT
tcp6       1      0 192.168.178.82:40623    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40618    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40647    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40600    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47987   TIME_WAIT 
tcp6       1      0 192.168.178.82:40633    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:40657    72.30.202.51:80         VERBUNDEN 
tcp6       1      0 192.168.178.82:40572    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40631    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40638    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40605    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40583    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40622    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40591    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40574    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40607    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40637    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40588    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40571    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40590    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:40658    72.30.202.51:80         VERBUNDEN 
tcp6       1      0 192.168.178.82:40567    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40561    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40620    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40582    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40642    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40639    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40592    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40632    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40558    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:48004   TIME_WAIT 
tcp6       1      0 192.168.178.82:40603    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47979   TIME_WAIT 
tcp6       1      0 192.168.178.82:40649    72.30.202.51:80         CLOSE_WAIT
tcp6       0      0 192.168.178.82:9123     192.168.178.101:47963   TIME_WAIT 
tcp6       1      0 192.168.178.82:40655    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40598    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40560    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40643    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40615    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40580    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40584    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40650    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40578    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40646    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:40602    72.30.202.51:80         CLOSE_WAIT
tcp6       1      0 192.168.178.82:47238    192.168.178.69:46511    CLOSE_WAIT
udp        0      0 0.0.0.0:32814           0.0.0.0:*                         
udp        0      0 0.0.0.0:68              0.0.0.0:*                         
udp        0      0 0.0.0.0:68              0.0.0.0:*                         
udp        0      0 192.168.178.82:123      0.0.0.0:*                         
udp        0      0 127.0.0.1:123           0.0.0.0:*                         
udp        0      0 0.0.0.0:123             0.0.0.0:*                         
udp        0      0 192.168.178.255:137     0.0.0.0:*                         
udp        0      0 192.168.178.82:137      0.0.0.0:*                         
udp        0      0 0.0.0.0:137             0.0.0.0:*                         
udp        0      0 192.168.178.255:138     0.0.0.0:*                         
udp        0      0 192.168.178.82:138      0.0.0.0:*                         
udp        0      0 0.0.0.0:138             0.0.0.0:*                         
udp        0      0 0.0.0.0:5353            0.0.0.0:*                         
udp        0      0 0.0.0.0:1900            0.0.0.0:*                         
udp        0      0 0.0.0.0:9116            0.0.0.0:*                         
udp6       0      0 :::52796                :::*                               
udp6       0      0 :::56908                :::*                               
udp6       0      0 :::45162                :::*                               
udp6       0      0 fe80::b179:1b02:e95:123 :::*                               
udp6       0      0 ::1:123                 :::*                               
udp6       0      0 :::123                  :::*                               
udp6       0      0 :::5353                 :::*                               
udp6       0      0 :::42804                :::*                               
udp6       0      0 192.168.178.82:34114    :::*                               
udp6       0      0 :::38744                :::*                               
udp6       0      0 :::1900                 :::*                               
udp6       0      0 :::56257                :::*                               
raw6       0      0 :::58                   :::*                    7         
Aktive Sockets in der UNIX-Domäne (Server und stehende Verbindungen)
Proto RefCnt Flags       Type       State         I-Node   Pfad
unix  4      [ ]         DGRAM                    22539    /run/wpa_supplicant/wlan0
unix  2      [ ACC ]     STREAM     HÖRT          9684     @/tmp/.X11-unix/X0
unix  2      [ ACC ]     STREAM     HÖRT          8502     /var/run/avahi-daemon/socket
unix  2      [ ACC ]     STREAM     HÖRT          8504     /var/run/dbus/system_bus_socket
unix  2      [ ]         DGRAM                    8526     /var/run/thd.socket
unix  2      [ ACC ]     STREAM     HÖRT          11530    /tmp/ssh-RQzjsqm2RGzQ/agent.1024
unix  2      [ ]         DGRAM                    22577    /tmp/libdhcpcd-wpa-1020.4
unix  2      [ ]         DGRAM                    22578    /tmp/libdhcpcd-wpa-1020.5
unix  2      [ ACC ]     STREAM     HÖRT          7051     /var/run/dhcpcd.sock
unix  2      [ ACC ]     STREAM     HÖRT          7053     /var/run/dhcpcd.unpriv.sock
unix  2      [ ACC ]     STREAM     HÖRT          10881    /tmp/.pcmanfm-socket--0-pi
unix  2      [ ACC ]     STREAM     HÖRT          9750     @/tmp/dbus-9cHuB7oc2I
unix  2      [ ]         DGRAM                    4787     /run/systemd/journal/syslog
unix  2      [ ACC ]     STREAM     HÖRT          9685     /tmp/.X11-unix/X0
unix  2      [ ACC ]     STREAM     HÖRT          9745     /tmp/ssh-5Qb0Ylc5rYzK/agent.876
unix  2      [ ACC ]     STREAM     HÖRT          9120     /tmp/.menu-cached-:0-pi
unix  2      [ ]         DGRAM                    1245     /run/systemd/notify
unix  2      [ ACC ]     STREAM     HÖRT          8926     /var/run/samba/nmbd/unexpected
unix  2      [ ACC ]     STREAM     HÖRT          1247     /run/systemd/private
unix  2      [ ]         DGRAM                    1263     /run/systemd/shutdownd
unix  14     [ ]         DGRAM                    1265     /run/systemd/journal/dev-log
unix  2      [ ACC ]     SEQPAKET   HÖRT          1269     /run/udev/control
unix  2      [ ]         DGRAM                    9721     /run/user/1000/systemd/notify
unix  2      [ ACC ]     STREAM     HÖRT          1273     /run/systemd/journal/stdout
unix  2      [ ACC ]     STREAM     HÖRT          9723     /run/user/1000/systemd/private
unix  6      [ ]         DGRAM                    1275     /run/systemd/journal/socket
unix  2      [ ACC ]     STREAM     HÖRT          9126     @/dbus-vfs-daemon/socket-l7grkNtl
unix  3      [ ]         STREAM     VERBUNDEN     11030   
unix  3      [ ]         STREAM     VERBUNDEN     9097     /run/systemd/journal/stdout
unix  2      [ ]         DGRAM                    10880   
unix  3      [ ]         STREAM     VERBUNDEN     8520     
unix  2      [ ]         DGRAM                    10270   
unix  3      [ ]         STREAM     VERBUNDEN     11026   
unix  3      [ ]         STREAM     VERBUNDEN     9846     
unix  3      [ ]         STREAM     VERBUNDEN     9814     /var/run/dbus/system_bus_socket
unix  3      [ ]         STREAM     VERBUNDEN     11654   
unix  3      [ ]         STREAM     VERBUNDEN     5921     
unix  3      [ ]         STREAM     VERBUNDEN     9110     
unix  2      [ ]         DGRAM                    21515   
unix  3      [ ]         STREAM     VERBUNDEN     9095     @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     VERBUNDEN     10726    @/tmp/.X11-unix/X0
unix  3      [ ]         STREAM     VERBUNDEN     7142     
unix  3      [ ]         STREAM     VERBUNDEN     10885    /run/systemd/journal/stdout
unix  3      [ ]         STREAM     VERBUNDEN     11590   
unix  3      [ ]         STREAM     VERBUNDEN     9114   &nbsp
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 April 2016, 17:18:11
hmm, was mir auffällt sind die vielen CLOSE_WAITs auf dem RPC-Server Port 7401. Bei mir sieht das so aus (gefiltert auf die 7401):

netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.1.12:7401       192.168.1.11:41120      ESTABLISHED

D.h. Eine aufgebaute Verbindung der CCU und der Server, der auf eingehende Verbindungen wartet. Keine CLOSE_WAITs.
Ist Dein FHEM per WLAN im Netz?

Dann fällt mir noch auf, dass Deine CCU (müsste die IP mit der 101 hinten sein) Verbindungen zum Port 5544 aufbaut. Außerdem scheint ein Prozess auf dem FHEM-System auf Port 5544 zu lauschen. Läuft da parallel noch eine andere Kommunikation mit der CCU? Das kannst Du wie folgt rausbekommen:

netstat -tulpn | grep 5544

In der letzten Spalte steht der Name des Prozesses, der den Port nutzt.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 27 April 2016, 21:29:12
Hallo zap,

Zitat
hmm, was mir auffällt sind die vielen CLOSE_WAITs auf dem RPC-Server Port 7401. Bei mir sieht das so aus (gefiltert auf die 7401):

Code: [Auswählen]
netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.1.12:7401       192.168.1.11:41120      ESTABLISHED

D.h. Eine aufgebaute Verbindung der CCU und der Server, der auf eingehende Verbindungen wartet. Keine CLOSE_WAITs.
Ist Dein FHEM per WLAN im Netz?

Ja, ist die Testmaschine, die ist per WLAN im Netz. ist das schlimm?

Zitat
Dann fällt mir noch auf, dass Deine CCU (müsste die IP mit der 101 hinten sein) Verbindungen zum Port 5544 aufbaut. Außerdem scheint ein Prozess auf dem FHEM-System auf Port 5544 zu lauschen. Läuft da parallel noch eine andere Kommunikation mit der CCU? Das kannst Du wie folgt rausbekommen:

Code: [Auswählen]
netstat -tulpn | grep 5544

In der letzten Spalte steht der Name des Prozesses, der den Port nutzt.

Stimmt, das war noch eine alte IP Symcon Testversion. habe ich jetzt mal Deaktiviert und den fhem server neu gestartet.

Jetzt nach dem Neustart sieht es wie folgt aus.
netstat:

pi@LiNaDo_Home:~ $ netstat -an | grep 7401
tcp        0      0 0.0.0.0:7401            0.0.0.0:*               LISTEN     
tcp        0      0 192.168.178.82:7401     192.168.178.101:37755   VERBUNDEN 

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 28 April 2016, 09:35:59
Wenn das WLAN stabil läuft, ist das kein Problem. Blöd ist nur, wenn ab und zu die Verbindung abbricht. Das könnte sich negativ auf den RPC-Server auswirken.

Aber ich habe eher IP-Symcon im verdacht. Das registriert sich ja auch bei der CCU, und zwar für den gleichen Port (2001) und mit der gleichen Ziel-IP (Deinem FHEM). Das könnte zu Konflikten führen.

Bin gespannt, ob es nun ohne Abbruch läuft.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: klaso am 19 Mai 2016, 22:34:15
Hallo zusammen,

habe heute bei der CCU2 ein Firmwareupdate auf V2.19.9. Das Modul funktioniert in fhem weiterhin ;-)
VG
klaso
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Mai 2016, 19:13:09
Ich habe gerade eine neue Version (Link siehe 1. Beitrag) eingecheckt. Die neue Version besteht nun aus folgenden Dateien:

88_HMCCU.pm 88_HMCCUDEV.pm, 88_HMCCUCHN.pm, HMCCUConf.pm, RPCQueue.pm, ccurpcd.pl

Neu ist die Datei HMCCUConf.pm. Sie enthält Default-Attribute für eine Reihe von Homematic Devices (s.u. Befehl 'set defaults'). Außerdem benötigt HMCCU ab sofort das FHEM Standardmodul SubProcess.pm (Teil von FHEM).

Neue Funktionen und Änderungen in der Version 3.2:


Hinweis: Ich habe in dieser Version ziemlich viel geändert (und dementsprechend lange getestet). Bugs sind trotzdem nicht ausgeschlossen. Daher macht Euch bitte eine Kopie der alten Module, bevor Ihr die neuen installiert, damit der Rückweg einfach ist. Bitte HMCCUConf.pm bei der Installation nicht vergessen.

Bitte insbesondere den eingebauten RPC Server (ccuflags = intrpc) intensiv testen. In der nächsten Version soll nur noch dieser verwendet werden. Dann entfallen ccurpcd.pl und RPCQueue.pm.
Die Verwendung des internen RPC Servers ist daran zu erkennen, dass statt ccurpcd.pl einer oder mehrere FHEM Prozesse laufen. Ansonsten ist das Verhalten identisch (Logfiles, Prozess-IDs im IO Device usw.).

Wenn jemand gerne weitere Default-Attribute in HMCCUConf.pm hätte, bitte Meldung an mich mit exaktem Homematic Gerätetyp und den Attribut-Werten. Dann nehme ich das auf. Erleichtert die Definition neuer Geräte ungemein.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 24 Mai 2016, 23:19:04
  • Das Attribut ccuverify bei HMCCUDEV Devices kennt nun den Wert 2. Dieser bewirkt, dass beim Setzen eines Datenpunktes in der CCU das zugehörige Reading in FHEM sofort (d.h. noch vor der Rückmeldung durch den RPC Server) aktualisiert wird. Dadurch könnte das "Springen" des Sliders bei der Bedienung eines Jalousienaktors über das Webinterface vermieden werden (bitte testen!)

Jalousienaktor: auf den ersten Blick ja. :-)
Dimmaktor: auf den ersten Blick nein. :-)

VG Alex
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 Mai 2016, 07:45:18
Jalousienaktor: auf den ersten Blick ja. :-)
Dimmaktor: auf den ersten Blick nein. :-)

VG Alex

Habe leider keinen Dimmaktor um das zu testen. Bei meinen Heizungsthermostaten funktioniert es (sogar mit ccuverify = 0). Muss mal ein paar Log-Statements einbauen, um mehr Infos zu erhalten, was da beim Dimmer anders läuft. Werde eine spezielle Debug-Version in den nächsten Tagen bereit stellen.

Welchen Wert hat bei Dir das Attribut rpcinterval im IO Device?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 26 Mai 2016, 16:37:48
rpcinterval ist bei mir 3.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 27 Mai 2016, 16:41:40
Hallo,

ich musste gerade meine CCU2 neustarten.
Danach hatte fhem keine richtige Verbindung mehr.
Erst nach einem "set ccu2 rpcserver off" und "set ccu2 rpcserver on" ging es wieder.

VG Alex
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Mai 2016, 20:39:23
Ich hoffe, der CCU Neustart wurde nicht wg. HMCCU notwendig.

Das von Dir beschriebene Verhalten bei Neustart der CCU ist normal. Grund: wenn der RPC Server gestartet wird, registriert er sich bei der CCU als Empfänger von Nachrichten. Leider vergisst die CCU beim Neustart ihre registrierten Empfänger. Daher sollte man vor einem CCU Neustart den RPC Server stoppen und später wieder starten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Loredo am 27 Mai 2016, 21:04:51
Merkt der RPC Server nicht irgendwie, dass die CCU Registrierung weg ist? Bei einem Stromausfall etc wäre es gut, wenn man nicht händisch eingreifen müsste.


Gruß
Julian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Mai 2016, 21:21:32
Nein, der RPC Server ist rein passiv. Er meldet sich aber per Notification, wenn für eine bestimmte Zeit keine Events von der CCU kamen: "No events from CCU since xxx seconds". Das xxx legt man mit dem Attribut rpcevtimeout fest. Dann kann man per notify mit einem "set rpcserver restart" darauf reagieren.

Andere Möglichkeit: per ping device die Erreichbarkeit der CCU checken und bei Fehler mit mindestens 1 Minute Verzögerung den RPC Server neu starten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Loredo am 27 Mai 2016, 22:16:16
Hm, gehört so eine Logik nicht besser ins Modul, anstatt dass die sich jeder für sich (und doch wieder irgendwie gleich) zusammenstellt?


Gruß
Julian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Mai 2016, 22:52:45
Mm ... ja. Könnte ich machen. So in der Art: wenn Attribut rpcevtimeout gesetzt ist, wird bei Ausbleiben der Events der RPC Server neu bei der CCU registriert. Das wäre auch effektiver als die Prozesse komplett neu zu starten.

Ist für die nächste Version vorgemerkt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 27 Mai 2016, 23:50:09
Super, danke!
Dafür hätte ich auch plädiert.  :D
Vielleicht sogar mit einem sinnvollen Default-Wert für rpcevtimeout vorbelegt?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Loredo am 29 Mai 2016, 23:44:18
Ist für die nächste Version vorgemerkt.


Klingt gut :-)


Hätte hier noch etwas zu fixen:


Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE UNREACH|^HUMIDITY|^TEMPERATURE|^LOWBAT20 20/ at ./FHEM/88_HMCCU.pm line 976.


Hatte zuvor per set-Default ein paar Standard-Configs eingespielt (dürfte hier von einem TH sein).




Gruß
Julian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 30 Mai 2016, 16:51:57
Dürfte ein TH vom Typ HM-WDS40-TH-I sein. Kannst Du das FHEM Device rausfinden? Mich interessiert der Wert des Attributs ccureadingfilter. Sieht irgendwie seltsam aus in der Fehlermeldung mit dem "^LOWBAT20 20" am Ende. Der Default Wert für dieses Attribut endet eigentlich auf "^LOWBAT$".

Möglicherweise ist da beim Download der Datei HMCCUconf.pm etwas schief gegangen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Loredo am 01 Juni 2016, 21:33:47
Gibt es denn die Möglichkeit die Readings umzubenennen? Ich würde z.B. gerne "FL_Motion-1.LEVEL" gerne nur als "pct" haben, damit es dem Fhem Standard entspricht und man es mit :FILTER Ausdrücken einfacher/übersichtlicher hat. Ist denn angedacht die Readings irgendwie zu mappen? Meine vorher schön übersichtlichen DOIFs verkomplizieren sich extrem, vor allem auch wegen der Abhängigkeit den Devicenamen mit im Reading zu haben, wenn es sich um ein HMCCUDEV Device handelt.


Es ist ja prima, dass man schon so viel einstellen kann über die Attribute. Aber es ist schon sehr aufwändig das für jedes Gerät einzustellen. Könnte man beim zentralen HMCCU Device nicht einen get-Befehl (zwecks User-Absicherung kein set-Befehl) machen, der aus einer Liste alle in der CCU verfügbaren Geräte anbietet und man diese einfach auswählen und anlegen kann? Dabei könnte man auch hinterlegen ob es jetzt sinnvoller ist ein HMCCUDEV oder HMCCUCHN Device anzulegen. So richtig optimal scheint mir beides nicht immer zu sein, manchmal möchte man bei so simplen Geräten wie einem Fenstersensor eigentlich Kanale 0+1 als Kombination haben, es aber trotzdem als HMCCUCHN anlegen, um die ganzen Präfixes bei den Readings zumindest los zu werden.
Ich weiß, der setter "defaults" soll hier eigentlich helfen. Neben dem, dass er besser als getter aufgehoben wäre, damit normale User die Konfig nicht mutwillig verpfuschen können, gilt es hier wohl die Datenbank etwas zu füttern. Dazu würde ich gerne etwas beisteuern. Nur scheitere ich schon daran mit eine zufriedenstellende Konfig zusammen zu schrauben bzw. bin mir bisher bei keinem Device sicher, ob das tatsächlich nicht besser geht. Die bisherigen Defaults und Beispiele hier im Forum fand ich alle eher weniger praxistauglich :-/


Könnte man auch die Doppelbelegung von STATE als Reading auflösen (ist zB bei Fenstersensoren drin)? Ich weiß, es kommt wohl so aus der CCU heraus. Ist aber in Fhem so nicht gut aufgehoben.


Die grundsätzliche Anbindung der CCU finde ich schon gut gelöst. Wie ist denn der Plan das rund zu machen, um es produktiv nutzbar zu machen?




Gruß
Julian
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 02 Juni 2016, 07:46:39
Die grundsätzliche Anbindung der CCU finde ich schon gut gelöst. Wie ist denn der Plan das rund zu machen, um es produktiv nutzbar zu machen?

Dein Beitrag hilft mir schon sehr, das "rund" zu machen. Auf solchen Input von Nutzern bin ich angewiesen, da ich bisher v.a. meine eigenen Anforderungen umgesetzt habe (ich nutze es bei mir in Verbindung mit Tablet-UI produktiv).

HMCCU verfolgt ein anderes Konzept als CUL_HM. HMCCU ist ein generischer Ansatz, in dem alle Feinheiten über Attribute definiert werden. Das hat den Vorteil, dass auch neue Homematic Geräte sofort genutzt werden können. Bei CUL_HM hingegen ist jeder Gerätetyp speziell implementiert. Das macht die Konfiguration für den Nutzer einfacher. Allerdings muss man bei neuen Geräten warten, bis die Unterstützung eingebaut ist und der Code wird extrem aufwändig (ok, das ist ein Problem des Entwicklers bzw. die Verlagerung der Komplexität in den Code).

Für einige Deiner Punkte kann ich mir zumindest Workarounds vorstellen. Mehr dazu demnächst. Die Geschichte mit den Devicenamen im Readingname bei HMCCUDEVs ist entstanden, da bei einigen Homematic Devices Datenpunkte mehrfach vorkommen. Zur Abgrenzung müsste ich zumindest die Kanalnummer in den Readingname aufnehmen. Bei HMCCUCHN ist das nicht notwendig, da sich das ja immer auf genau einen Kanal bezieht.

Aber danke für die Anregungen. Während die Finger das schreiben, arbeitet das Hirn schon daran ;-)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Loredo am 02 Juni 2016, 16:40:32
Aber danke für die Anregungen. Während die Finger das schreiben, arbeitet das Hirn schon daran ;-)


Klasse  8)
Auch wenn mein Feedback nicht so strukturiert war und mir noch 1000 andere Dinge durch den Kopf gegangen sind. Ich schaue mal weiter, brauche aber irgendwie recht fix eine Lösung meine Grundfunktionen daheim wieder ans laufen zu kriegen. Die Reading Namen sind dabei nur ein Randschauplatz.


Ich habe wohl eine Menge Geräte, die noch keine Defaults haben. Ich würde dafür auch gerne Defaults liefern, tue mich aber sehr schwer herauszufinden wie ich die überhaupt definiere. Beispielsweise habe ich einen Dimmaktor und möchte dabei neben dem eigentlichen Dimmwert auch die Hochdimmzeit sowie eine Ausschaltzeit definieren. Über CUL_HM geht das ganz einfach und soweit ich weiß werden diese Werte auch alle an den HM Aktor übertragen und nichts davon bleibt in Fhem. Da stellt sich nun die Frage wie ich das mit HMCCU löse? Ich kann zwar den LEVEL-Wert übergeben, aber wie übergebe ich gleichzeitig noch andere Werte? Natürlich wäre es schön, wenn die ganzen Setter irgendwie kompatibel wären und auch so heißen. Den generischen control-Setter kann es ja trotzdem geben und ich finde den Ansatz, dass alle Geräte direkt funktionieren können sollen sehr gut. Für die Praxis braucht es aber irgendwie mehr Kompatibilität/Interoperabilität.


Kannst du mir irgendwie helfen, um da besser rein zu kommen, damit ich dann auch mithelfen kann die Defaults-Datenbank zu vergrößern?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 02 Juni 2016, 17:20:25
Ich erlaube mir mal, auf https://forum.fhem.de/index.php/topic,41060.msg429362.html#msg429362 zu verweisen und die Folgebeiträge. Inwieweit sich das hier mit HMCCU adaptieren lässt, weiß ich nicht.

Über einen XML-RPC-Aufruf geht das mit einem putParamset. Allerdings ist bei dem Dimmer wichtig, dass das putParamset in zwei Etappen durchgeführt wird, darum habe ich für das eigentlich einfache putParamset einen neuen Befehl implementiert, der das entsprechend aufteilt und durchführt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 03 Juni 2016, 11:58:58
Ich habe wohl eine Menge Geräte, die noch keine Defaults haben. Ich würde dafür auch gerne Defaults liefern, tue mich aber sehr schwer herauszufinden wie ich die überhaupt definiere.

Grundsätzlich solltest Du für jedes Gerät folgende Attribute festlegen:

ccureadingfilter: Einige Gerätetypen liefern eine Unmenge an Datenpunkten. Ohne den Filter würde das zu sehr vielen Readings führen. Eine Liste der verfügbaren Datenpunkte liefert "get deviceinfo". In den Filter müssen nur Datenpunkte aufgenommen werden, die die Flags R=Read oder E=Event gesetzt haben. Die anderen sind Write Only.

statechannel bzw. statedatapoint: Legt fest, über welchen Kanal bzw. welchen Datenpunkt die Befehle "get devstate" und "set devstate" auf ein Gerät zugreifen. Wenn das nicht festgelegt ist, kann devstate nicht verwendet werden (Zugriff per get/set datapoint geht natürlich immer).

stripnumber: Legt fest. ob Fließkommawerte abgeschnitten oder mit allen Nachkommastellen in Readings gespeichert werden. Empfehlung wäre 1, d.h. 1 Nachkommastelle, wobei 2 nicht für 2 Nachkommastellen sondern für 0 Nachkommastellen steht.

substitute: Ersetzt bestimmte Werte aus der CCU durch sprechende Texte (z.B. true/1 => on, false/0 => off)

statevals: Umkehr von substitute, d.h. ersetzt FHEM Werte vor dem Senden an die CCU (z.B. on => true, off => false)

Das sind wie gesagt die Attribute, die ich immer für ein Device setze.  Wenn ich etwas mehr Komfort in der FHEM Oberfläche haben möchte, kommen noch Attribute wie controldatapoint, widgetOverride, cmdIcon usw. dazu.

Zitat
Beispielsweise habe ich einen Dimmaktor und möchte dabei neben dem eigentlichen Dimmwert auch die Hochdimmzeit sowie eine Ausschaltzeit definieren. Über CUL_HM geht das ganz einfach und soweit ich weiß werden diese Werte auch alle an den HM Aktor übertragen und nichts davon bleibt in Fhem. Da stellt sich nun die Frage wie ich das mit HMCCU löse? Ich kann zwar den LEVEL-Wert übergeben, aber wie übergebe ich gleichzeitig noch andere Werte?

Habe leider keinen Dimmer, daher hier einige theoretische Tipps, die Du ggf. mal testen könntest: Wenn ein Homematic Gerät einen Datenpunkt ON_TIME anbietet (s.a. get deviceinfo), stellt HMCCUDEV automatisch einen Set-Befehl on-for-timer bereit, mit dem das Gerät für eine bestimmte Zeit eingeschaltet werden kann. Sollte bei einem Dimmer funktionieren, tut es aber leider nicht, weil ich da noch einen Bug drin habe (gerade gefunden).
Wenn zusätzlich noch die Ramp-Time mitgegeben werden soll, müsstest Du 2 bzw. 3 Befehle absetzen. Beispiel (LEVEL muss zuletzt gesetzt werden):

set mydev datapoint 1.RAMP_TIME 3.0
set mydev datapoint 1.ON_TIME 600
set mydev datapoint 1.LEVEL 0.7

oder

attr mydev statechannel 1
attr mydev statedatapoint LEVEL
attr mydev statevals on:1.0,off:0.0,half:0.5
set mydev datapoint 1.RAMP_TIME 3.0
set mydev datapoint 1.ON_TIME 600
set mydev half

Umbenennen von Readings: Wenn Du sofort eine Lösung brauchst, kann ich Dir momentan nur die Definition eines Userreadings empfehlen (umständlich, ich weiß). Aber ich arbeite daran, zumal es mich selbst stört, dass ich aufgrund des Devicenames im Reading einige sinnvolle Defaults nicht definieren kann.


Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 11 Juni 2016, 16:03:04
Sorry, dass ich eine Zeit lang nicht mehr online war... Aber nun meine erste Rückmeldung zu den neuen Funktionen und Änderungen:


Neue Funktionen und Änderungen in der Version 3.2:

  • Homematic Gruppen werden nun uneingeschränkt unterstützt und vom RPC-Server aktualisiert. Hierzu muss das Attribut rpcport im IO Device (HMCCU) um den Port 9292 ergänzt werden. Das Attribut mapdatapoint in HMCCUDEV Devices wird damit obsolet.
  • Unterstützung für Rauchmeldergruppen (CCU Adressen beginnen mit einem '*')
  • Das Modul 88_HMCCU enthält nun einen RPC-Server. Um diesen zu aktivieren muss beim IO Device das Attribut ccuflags auf 'intrpc' gesetzt werden. Dann wird ccurpcd.pl nicht mehr verwendet.
  • Das Attribut ccuverify bei HMCCUDEV Devices kennt nun den Wert 2. Dieser bewirkt, dass beim Setzen eines Datenpunktes in der CCU das zugehörige Reading in FHEM sofort (d.h. noch vor der Rückmeldung durch den RPC Server) aktualisiert wird. Dadurch könnte das "Springen" des Sliders bei der Bedienung eines Jalousienaktors über das Webinterface vermieden werden (bitte testen!)
  • Mit dem Attribut 'substitute' können nun auch Fließkommawerte ersetzt werden, sofern sich eine Regel auf einen bestimmten Datenpunkt (Präfix 'Name!') bezieht.
  • Das Attribut 'statedatapoint' akzeptiert nun die gleiche Notation wie 'controldatapoint', d.h. <channelnumber>.<datapoint>

Port 9292:

Habe ich zusätzlich zu 2001 gesetzt und keine "Auswirkung" wahrgenommen.
 
Rauchmeldergruppen
Kann jetzt definiert und der Status ausgelesen werden. Diese Gruppe kann als HMCCUDEV definiert werden. Dann hat sie 2 Channels. Den Channel 0 und 1. Channel 1 kann ausgelesen werden. Channel 0 geht imemr auf Error. In der CCU hat die Rauchmeldergruppe nur einen Channel.  Siehe auch screenshot im Anhang. Komisch, ist da noch in Bug?

ccuverify Wert 2
Der Rolladenaktor springt immer noch. Auch bei einem Dimmer ist das so.

ccuflags auf 'intrpc' gesetzt

Ich erhalte bisher nicht bekannte Einträge im logfile, die ich gerne verstehen würde.
2016.06.12 11:35:53 2 : HMCCU: Create child process with timeouts 0.01 and 0.25
2016.06.12 11:35:53 0 : HMCCU: Child process for server CB2001 started with PID 22639
2016.06.12 11:35:53 2 : HMCCU: Create child process with timeouts 0.01 and 0.25
2016.06.12 11:35:53 0 : HMCCU: Child process for server CB9292 started with PID 22640
2016.06.12 11:35:53 0 : RPC server(s) starting
2016.06.12 11:35:56 0 : HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.06.12 11:36:03 1 : HMCCU: Registering callback http://192.168.178.15:7401/fh2001 with ID CB2001 at http://192.168.178.16:2001/
2016.06.12 11:36:05 1 : HMCCU: RPC callback with URL http://192.168.178.15:7401/fh2001 initialized
2016.06.12 11:36:08 0 : HMCCU: Received IN event. RPC server CB2001 initialized.
2016.06.12 11:36:08 0 : HMCCU: Received SL event. RPC server CB9292 enters server loop
2016.06.12 11:36:15 1 : HMCCU: Registering callback http://192.168.178.15:14692/fh9292 with ID CB9292 at http://192.168.178.16:9292/groups
2016.06.12 11:36:25 1 : HMCCU: RPC callback with URL http://192.168.178.15:14692/fh9292 initialized
2016.06.12 11:36:31 0 : HMCCU: Received IN event. RPC server CB9292 initialized.
2016.06.12 11:36:31 2 : HMCCU: Update of device VIR0000001 failed
2016.06.12 11:36:31 2 : HMCCU: Device *MEQ0257246:0 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:2 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:1 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Updated devices. Success=13 Failed=4
2016.06.12 11:36:31 1 : HMCCU: All RPC servers running

Was bedeutet z.B.: "HMCCU: Update of device VIR0000001 failed"???


Den Rest habe ich noch nicht getestet. Weiters Feedback folgt.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 14 Juni 2016, 17:07:23
Habe ich zusätzlich zu 2001 gesetzt und keine "Auswirkung" wahrgenommen.

Ich gehe jetzt mal davon aus, dass Du in der CCU2 eine Gruppe definiert hast (z.B. einen Thermostaten und einen Fenstersensor). Wenn Du nun in FHEM ein HMCCUDEV Device für diese Gruppe anlegst, sollten die Readings entsprechend aktualisiert werden. Diese Aktualisierung läuft bei Gruppen über den Port 9292.

Beispiel: listing einer meiner Gruppen mit einem Heizungsthermostat und einem Wandthermostat. Die Mitglieder müssen bei der Definition mit "group=" angegeben werden.

Internals:
   DEF        G-AZ-HZ group=KL-AZ-HZ,KL-AZ-TH
   IODev      d_ccu
   NAME       HM_G_AZ_HZ
   NR         123
   STATE      T: 23.5° H: 60% D: 4.5° P: 15.3° V: 0% MANU
   TYPE       HMCCUDEV
   ccuaddr    INT0000001
   ccudevstate Active
   ccugroup   LEQ0851979,LEQ1462664
   ccuif      VirtualDevices
   ccuname    G-AZ-HZ
   ccutype    HM-CC-VG-1
   channels   3
   statevals  devstate
   Readings:
     2016-06-14 16:53:14   DEWPOINT        15.3
     2016-05-26 21:31:24   G-AZ-HZ.0.LOWBAT no
     2016-06-14 16:53:14   G-AZ-HZ.1.CONTROL_MODE MANU
     2016-06-14 16:53:14   G-AZ-HZ.1.SET_TEMPERATURE 4.5
     2016-05-26 21:31:25   KL-AZ-HZ.0.LOWBAT no
     2016-06-14 16:53:13   KL-AZ-HZ.4.CONTROL_MODE MANU
     2016-06-14 16:53:14   KL-AZ-HZ.4.SET_TEMPERATURE 4.5
     2016-06-14 16:53:14   KL-AZ-HZ.4.VALVE_STATE 0
     2016-05-26 21:31:24   KL-AZ-TH.0.LOWBAT no
     2016-06-14 16:52:43   KL-AZ-TH.1.HUMIDITY 60
     2016-06-14 16:52:43   KL-AZ-TH.1.TEMPERATURE 23.5
     2016-06-14 16:41:58   KL-AZ-TH.2.CONTROL_MODE MANU
     2016-06-14 16:52:23   KL-AZ-TH.2.SET_TEMPERATURE 4.5
     2016-06-14 16:41:58   KL-AZ-TH.2.WINDOW_OPEN_REPORTING closed
     2016-04-21 18:27:52   LOWBAT_COUNT    0
     2016-04-21 18:27:52   LOWBAT_STATE    no
     2016-06-14 16:53:14   control         4.5
     2016-06-14 16:53:14   state           4.5
Attributes:
   IODev      d_ccu
   ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT$|^VALVE|^CONTROL|^WINDOW_OPEN)
   cmdIcon    Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
   controldatapoint 1.SET_TEMPERATURE
   event-on-change-reading .*
   eventMap   /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
   group      Heizung Arbeitszimmer
   icon       rc_HOME
   room       Homematic
   stateFormat T: KL-AZ-TH.1.TEMPERATURE° H: KL-AZ-TH.1.HUMIDITY% D: KL-AZ-TH.2.SET_TEMPERATURE° P: DEWPOINT° V: KL-AZ-HZ.4.VALVE_STATE% G-AZ-HZ.1.CONTROL_MODE
   statechannel 1
   statedatapoint SET_TEMPERATURE
   stripnumber 1
   substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
   userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-AZ-TH.1.TEMPERATURE", "KL-AZ-TH.1.HUMIDITY","n/a")}, LOWBAT_STATE:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(KL-AZ-TH.0.LOWBAT|KL-AZ-HZ.0.LOWBAT) {HMCCU_AggReadings($name, "KL.*LOWBAT","cnt","yes","")}
   webCmd     control:Auto:Manu:Boost:on:off
   widgetOverride control:slider,10,1,25

Zitat
Rauchmeldergruppen
Kann jetzt definiert und der Status ausgelesen werden. Diese Gruppe kann als HMCCUDEV definiert werden. Dann hat sie 2 Channels. Den Channel 0 und 1. Channel 1 kann ausgelesen werden. Channel 0 geht imemr auf Error. In der CCU hat die Rauchmeldergruppe nur einen Channel.  Siehe auch screenshot im Anhang. Komisch, ist da noch in Bug?

Den Kanal 0 fügt die CCU bei jedem Gerät hinzu. Darin werden Datenpunkte wie UNREACH oder RSSI verwaltet. Der Kanal 0 kann normalerweise nur gelesen werden. Bitte definiere das Rauchmelderteam mal mit HMCCUDEV statt mit HMCCUCHN. Könnte sein, dass das besser funktioniert.

[quote]
ccuverify Wert 2
Der Rolladenaktor springt immer noch. Auch bei einem Dimmer ist das so.
[/quote]

Schade. Bei einem Slider für einen Thermostaten funktioniert es. Aber ich gebe noch nicht auf ;-)

Zitat
2016.06.12 11:36:31 2 : HMCCU: Update of device VIR0000001 failed
2016.06.12 11:36:31 2 : HMCCU: Device *MEQ0257246:0 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:2 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Device LTK0044162:1 has no readable datapoints
2016.06.12 11:36:31 2 : HMCCU: Updated devices. Success=13 Failed=4
2016.06.12 11:36:31 1 : HMCCU: All RPC servers running

Was bedeutet z.B.: "HMCCU: Update of device VIR0000001 failed"???

Die Startmeldungen sehen gut aus. Das Device LTK... ist vermutlich ein Schalter oder Taster. Daher die Meldung "no readable datapoints".
Das Device *M... ist der Kanal 0 der Rauchmeldergruppe. Hier gibt es anscheinen wirklich ein Problem. Eigentlich müssten gerade der Kanal lesbare Datenpunkte enthalten. Wie gesagt, muss ich testen.
Das Device VIR... ist die Adresse einer HMCCUDEV Gruppe, die keine Entsprechung in der CCU hat. Das Gruppieren in FHEM mit HMCCUDEV funktioniert grundsätzlich, jedoch habe ich noch keinen sinnvollen Anwendungsfall gefunden. Diese reinen FHEM Gruppen haben die Adresse VIR... während CCU Gruppen die Adress INT... haben. Beim Starten werden alle Devices einmal aktualisiert, d.h. die aktuellen Werte aus der CCU geholt. Das funktioniert für  reine FHEM Gruppen nicht, da es ja kein Pendant in der CCU gibt.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: FrankOL am 18 Juni 2016, 00:00:21
Moin zusammen,

vorweg, ich bin Anfänger bzw. ich habe bei den ganzen Möglichkeiten/Parametern nicht den Durchblick.
Im FHEM habe ich u.a. eine Jalousie die ich steuern kann:

# Jalousiensteuerung
define Jalousien_Kueche_klein GenShellSwitch /home/pi/fernotron-control/FernotronRemote.sh 1 u d
attr Jalousien_Kueche_klein cmdIcon on:black_up off:black_down
attr Jalousien_Kueche_klein group Jalousien
attr Jalousien_Kueche_klein room Küche

Die meisten Jalousien laufen bei mir allerdings über die CCU2.
Ich hätte jetzt gerne, dass ich mit der CCU2 eine Verbindung zum FHEM herstelle und diese eine Jalousie über die CCU2 runterfahren kann.
Ist das HMCCU dafür "zu mächtig"? Gibt es vielleicht eine einfachere Lösung?
Ich möchte die Profis hier nicht stören, aber vielleicht kann mir jemand einen Tipp/Link/HowTo geben wie ich das realisieren kann?

Gruß
Frank
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 18 Juni 2016, 09:42:35
Keine Sorge, Du störst nicht.

Dafür ist HMCCU nicht geeignet. Mit dem Modul kannst Du von FHEM aus die CCU bzw. daran angeschlossene Geräte steuern. Also das genaue Gegenteil von Deiner Anforderung.

Wenn ich das jetzt richtig verstehe, ist die Jalousie kein Homematic Gerät.

Du kannst von der CCU aus FHEM Befehle absetzen. Dazu benötigst Du das Tool "socat" oder "nc" auf der CCU. Die Tools gibt es hier:

http://homematic-forum.de/forum/viewtopic.php?f=26&t=13299

Die Tools kopierst Du auf der CCU z.B. in das Verzeichnis /etc/config/addons/scripts.
Dann legst Du Dir ein Shellscript an, z.B.

#!/bin/sh

FHEM_SERVER="192.168.1.11"
FHEM_PORT=7072

if [ $# -ne 1 ]; then
echo "Usage: fhem.sh Command"
exit 1
fi

echo -e "$1\nquit\n" | /etc/config/addons/scripts/nc $FHEM_SERVER $FHEM_PORT

Wenn Dein Script fhem.sh heißt, kannst Du nun mit folgendem Befehl Deine Jalousie von der CCU aus in FHEM ansprechen:

fhem.sh "set Jalousien_Kueche_klein on"


Die Einbindung von Shellscripts in die CCU Oberfläche (z.B. per CUxD und Virtuellem oder auch echtem Taster) wird an vielen Stellen beschrieben. Das würde jetzt hier zu weit führen. Einfach mal googeln.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: FrankOL am 19 Juni 2016, 01:46:46
Chaka! Es funktioniert tatsächlich!  8)
Vielen Dank für den Tipp!

Wenn das mal jemand nachbauen möchte der genau so wenig Ahnung hat wie ich, dann sollte er darauf achten, den set-Befehl in Hochkomma zu setzen, damit kann man sich ein paar Stunden rumtüffteln ersparen.  ;)

dom.GetObject("CUxD.CUX2801001:3.CMD_EXEC").State("/usr/local/addons/scripts/fhem.sh 'set Jalousien_Kueche_klein on'");

Alles in allem genau das was mir noch fehlte, vielen Dank noch mal!

Gruß
Frank
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 19 Juni 2016, 12:07:33
Hallo Zap,

ich bin gerade mal wieder bei meinen Eltern und habe es gewagt dein Modul zu updaten. Und es läuft wunderbar - sogar noch schneller als vorher.
Wirklich grandiose Arbeit von dir.  :)

Da alles so gut läuft, wollte ich nun auch versuchen, ein HM Programm einzubinden. Geht das schon und hast du da evtl. ein Beispiel?
Das Programm wurde von meinem Bruder in der CCU aufgebaut. Ich sehe nur so viel wie auf dem Bild.

Zum Hintergrund: Das Programm schaltet eine Wasserpumpe und Bewässerungsanlagen an.

Viele Grüße

Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 19 Juni 2016, 18:47:04
Die Programme findest Du in der CCU unter "Programme und Verknüpfungen" / "Programme und Zentraleverknüpfungen"

Wenn dann Dein Programm z.B. "SicherheitsCheck" heißt und dein CCU Device in FHEM "d_ccu" kannst Du das Programm wie folgt ausführen:

set d_ccu execute SicherheitsCheck

In Deinem Fall scheint es so zu sein, dass das Programm mit einer virtuellen CCU Taste verknüpft wurde. Grundsätzlich müsste es auch möglich sein, von FHEM aus diese virtuellen Tasten anzusprechen. Das habe ich aber noch nicht getestet. Werde ich bei Gelegenheit mal versuchen. Aber die erste Variante oben sollte funktionieren.

Das "HM-RCV-50 BidCoS-RF:34" ist ein Kanal für einen virtuellen Taster der CCU. Davon gibt es m.W. 50 Stück. Du kannst versuchen, diesen Kanal mal mit HMCCUCHN in FHEM nutzbar zu machen. Dazu musst Du aber den Kanal umbenennen (wegen Leerzeichen im Namen) oder die Kanaladresse verwenden. Ich befürchte aber, dass das nicht funktioniert, da diese virtuellen Taster ein anderes Adressierungsschema haben (BidCoS-RF:Kanalnummer). Dieses Schema wird derzeit von HMCCU nicht unterstützt.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 20 Juni 2016, 09:21:48
Hi zap, vielen Dank!

Und wie ist es, wenn der Programm-Name Leerzeichen enthält?

Viele Grüße

Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 20 Juni 2016, 09:36:10
Und wie ist es, wenn der Programm-Name Leerzeichen enthält?

Das wird nicht funktionieren. Hintergrund: FHEM hat ein grundsätzliches Problem mit Leerzeichen in Parametern. Bei einem Befehl wie

set d_ccu execute Mein Programm

bekommt ein Modul von FHEM 2 Parameter "Mein" und "Programm" übergeben.

Leider unterstützt FHEM auch keine Parameter in Hochkomma wie z.B.

set d_ccu execute "Mein Programm"

Bei CCU Programmen bleibt also nur der Verzicht auf Leerzeichen im Namen.

BTW: Nutzt Du eigentlich den internen RPC-Server (ccuflags = intrpc) oder nach wie vor ccurpcd.pl ? (ich frage, weil ich ccurpcd.pl früher oder später beerdigen möchte, damit HMCCU endlich in das FHEM Update rein kann)

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 20 Juni 2016, 19:55:32
Hi zap,

vielen Dank. Ich habe noch ccurpcd.pl verwendet, aber jetzt gerade umgestellt. Und läuft weiterhin top. :)

Kann ich eig. auf die Systemvariablen irgendwie reagieren? Also sobald sie sich ändern? Dazu müsste ich diese ja irgendwie in den Readings hinein bekommen.

Mir ist auch noch was bei einem Sensor aufgefallen. Der ist als HMCCUCHN angelegt und aktualisiert sich nicht von alleine.


Viele Grüße

Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 Juni 2016, 12:31:14
Variablen werden über das IO Device abgefragt. Beispiel

get d_ccu vars XY.*

Liest alle Variablen, die mit XY beginnen.

Dann noch das Attribut ccureadings auf 1 setzen, damit auch im IO Device Readings angelegt werden und den get vars Befehl per FHEM AT Device  regelmäßig ausführen lassen (leider unterstützt die CCU nicht die Aktualisierung von Variablen per RPC-Server).
Dann kanst Du per Notify auf Änderung der Readings reagieren.

Für den Sensor, dessen Werte nicht aktualisiert werden: Schick mal bitte die Ausgabe von "list <devname>"
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 21 Juni 2016, 15:28:01
Hi zap,

ich nutze auch Dein Modul und bin ganz happy, dass es gut funktioniert. 3 Fragen habe ich, zu denen ich Rat suche:


VG Yil
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 Juni 2016, 16:31:02
Mir fällt auf, dass der RPCServer (ich nutze den internen) regelmässig stoppt, wobei das entsprechende Reading "rpcserver" nicht aktualisiert wird, wohl aber der Eintrag in den Internals "RPCServer".

Den Effekt hatte bisher noch niemand. Entweder der RPC-Server bleibt gleich nach dem Start stehen oder er läuft stabil. Hast Du irgendwelche Fehlermeldungen ("HMCCU:") im FHEM Logfile ?

Zitat
Die Readings der eingelesenen Geräte sind sehr lang. Bei einem Device-Name "Garten.Bewegung" (und einem Channel-1-Namen "Garten-Bewegung.1" bekomme ich z.B. das Reading "Garten.Bewegung.1.BRIGHTNESS" - handlicher wäre, wenn man nur "BRIGHTNESS" bekommen würde. Ist sowas machbar?

Für Devices vom Type HMCCUCHN (einzelne Kanäle) geht das schon mit dem Attribute ccureadingformat=name. Für die HMCCUDEV Devices wird es ab der nächsten Version gehen.

Zitat
Der Status wird bei einigen Geräten nicht gesetzt, sondern lautet dann meist "Initialized". Bei 2 Temperatursensoren würde ich gerne im Status via einer dewpoint-Definition T: H: D: mit zugehörigen Angaben haben. Bei Bewegungsmeldern würde ich gerne motion/noMotion im Status ablesen, so wie das beim HM-CFG-LAN Adapter funktioniert hat. Gibt es dazu Möglichkeiten?

Wenn STATE gesetzt werden soll, musst Du mit den Attributen statechannel und statedatapoint den Kanal und den Datenpunkt festlegen, der in STATE übernommen werden soll. Wenn z.B. der Datenpunkt TEMPERATURE im Kanal 2 liegt und nach STATE soll, sieht das so aus:

attr devname statechannel 2
attr devname statedatapoint TEMPERATURE

Oder kürzer:

attr devname statedatapoint 2.TEMPERATURE

Wenn Du mehrere Werte in STATE haben möchtest, nimmst Du das FHEM Standardattribut stateFormat. Z.B.

attr devname stateFormat T: KL-BO-TH.1.TEMPERATURE° H: KL-BO-TH.1.HUMIDITY% D: KL-BO-TH.2.SET_TEMPERATURE° P: DEWPOINT°

Das Reading DEWPOINT ist ein userreading:

attr devname userReadings DEWPOINT {HMCCU_Dewpoint($name,"KL-BO-TH.1.TEMPERATURE", "KL-BO-TH.1.HUMIDITY","n/a")}

In den Beispielen musst Du eigentlich nur die Namen der Kanäle und Datenpunkte durch Deine ersetzen. Dann sollte es funktionieren.

Wenn Deine Bewegungsmelder nicht "motion/nomotion" in einem Datenpunkt liefern sonder true/false oder 1/0 kannst Du diese Werte mit dem Attribut substitute konvertieren lassen bevor sie in STATE geschrieben werden:

attr devname substitute (true|1):motion,(false|0):nomotion

Oder bechränkt auf einen bestimmten Datenpunkt MOTION

attr devname substitute MOTION!(true|1):motion,(false|0):nomotion
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 21 Juni 2016, 23:37:17
Sehr cool - danke für die Hilfe. Funktioniert alles sauber bei mir bis auf das userreading DEWPOINT. Den Kanalnamen habe ich durch meinen ersetzt, aber er zeigt es leider nicht an.

Ist nur ne Kleinigkeit, aber wie kann ich im reading stateFormat aus "19.300000°" 19,3° machen? Ich hab mit sprintf herumprobiert, bin aber nicht drauf gekommen.

Zum RPC-Server habe ich (immer mal wieder) folgendes im Log (verbose 5):

2016.06.21 15:02:49 1: HMCCU: Deregistering RPC server http://192.168.1.100:7401/fh2001 at http://192.168.1.15:2001/
2016.06.21 15:02:49 0: HMCCU: Stopping RPC server CB2001 with PID 13963
2016.06.21 15:02:49 0: CCURPC: CB2001 Server loop terminated
2016.06.21 15:02:49 2: CCURPC: Eventcount DD = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount EV = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount EX = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount IN = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount ND = 152
2016.06.21 15:02:49 2: CCURPC: Eventcount RA = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount RD = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount SL = 1
2016.06.21 15:02:49 2: CCURPC: Eventcount UD = 0
2016.06.21 15:02:49 2: CCURPC: Eventcount total = 156
2016.06.21 15:02:49 2: CCURPC: Eventcount writeerror = 0
2016.06.21 15:02:51 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2016.06.21 15:02:51 0: HMCCU: RPC server(s) with PID(s) 13963 shut down. f=1
2016.06.21 15:02:51 2: HMCCU: Eventcount DD = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount EV = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount EX = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount IN = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount ND = 152
2016.06.21 15:02:51 2: HMCCU: Eventcount RA = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount RD = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount SL = 1
2016.06.21 15:02:51 2: HMCCU: Eventcount ST = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount UD = 0
2016.06.21 15:02:51 2: HMCCU: Eventcount total = 156
2016.06.21 15:02:51 0: HMCCU: Periodical check found no RPC Servers
2016.06.21 15:02:51 0: HMCCU: All RPC servers stopped

Was auffällt ist, dass der RPCServer jedesmal aussteigt, wenn ich die fhem.cfg editiere.

Auf die nächste Version freue ich mich schon  ;D
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Juni 2016, 07:53:19
Ist nur ne Kleinigkeit, aber wie kann ich im reading stateFormat aus "19.300000°" 19,3° machen? Ich hab mit sprintf herumprobiert, bin aber nicht drauf gekommen.

Das Attribut stripnumber ist Dein Freund. Hier kannst Du folgende Werte angeben:

0 = Alle Nachkommastellen
1 = Eine Nachkommastelle
2 = Keine Nachkommastelle

Beim userreading für den DEWPOINT musst Du die Readings angeben, nicht die Kanalnamen. Sorry, hatte ich falsch beschrieben.

Zitat
Was auffällt ist, dass der RPCServer jedesmal aussteigt, wenn ich die fhem.cfg editiere.

Die Logfile Einträge weisen nicht auf einen Fehler hin. Sieht aus als würde der RPC-Server normal gestoppt werden. Wenn Du das cfg File editierst, wirst Du vermutlich FHEM neu starten oder? Beim Shutdown von FHEM wird der RPC-Server natürlich auch gestoppt. Wenn dann beim Starten nicht das Attribut rpcserver = on ist, wird er auch nicht automatisch gestartet.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: ToM_ToM am 22 Juni 2016, 10:57:58
Hi zap,

ich hatte gehofft, ich könnte das mit dem at umgehen. ;)
Zu meinem Problem mit dem Sensor: Ich bin leider wieder abgereist und kann diese Info jetzt nicht mehr nachliefern.
Am gleichen Abend hatte ich aber auch noch festgestellt dass FHEM auch nicht mehr die Info über "Fenster auf/zu" automatisch bekommt.
Daraufhin hatte ich dann alles nochmal neu gestartet und dann ging es. Evtl. ist das Problem mit dem Sensor damit auch behoben. Dies hatte ich aber nicht mehr geprüft.


Viele Grüße
Thomas
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 22 Juni 2016, 11:18:05
Zitat
Die Logfile Einträge weisen nicht auf einen Fehler hin. Sieht aus als würde der RPC-Server normal gestoppt werden. Wenn Du das cfg File editierst, wirst Du vermutlich FHEM neu starten oder? Beim Shutdown von FHEM wird der RPC-Server natürlich auch gestoppt. Wenn dann beim Starten nicht das Attribut rpcserver = on ist, wird er auch nicht automatisch gestartet.

Folgendes konnte ich nachstellen:


Wenn ich hingegen den RPCServer manuell stoppe, dann lauten die internen Werte anders:

Interner Wert RPCPID: 0; interner Wert RPCPRC: none; interner Wert RPCState = stopped; internern Wert STATE = busy; reading rpcstate = running; reading state = busy

Ich hab mal 2 Screenshots angehängt. Dieses Verhalten ist beliebig oft reproduzierbar. Hilft das weiter bei der Fehlersuche?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Juni 2016, 11:42:00
Hört sich fast so an als würde das  Modul neu geladen werden wenn die cfg gespeichert wird. Muss ich bei mir mal ausprobieren. Vielleicht weiss ja jemand, ob das ein Feature von FHEM ist.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 22 Juni 2016, 14:52:56
Hi,

ich habe da mal ein Problem, wo ich nicht weiß, ob ich mich einfach nur zu dämlich anstelle:

Ich benutze einen Homematic Dimmer und zwei Aufputz-Rolladenaktoren.
Die Readings, die da kommen (z.B. 1.LEVEL) sind immer Real-Zahlen: also von 0.000000 bis 1.000000.

Nun ist es so, dass Steuerelemente, wie knob gerne mit den Prozenten arbeiten würden: also 0 - 100.
Das kann man wiederum ganz gut parametrieren, indem man min, max und step-Werte angibt.
Allerdings führt das immer wieder zu Klimmzügen.

Bei der Siri-Anbindung über Homebridge bin ich nun leider vollends gescheitert, weil die intern CurrentPosition und TargetPosition als Integers fahren. Also nur 0-100 möglich ist. Oder auch 0 und 1. Also Markise auf oder zu. Was auch nicht im Sinne des Erfinders ist.  :D

Ich habe nirgends gesehen, dass das Problem sonst einer hätte.
Mach ich ggf. irgendwas falsch, dass bei mir 0.00 bis 1.00 verwendet wird, statt 0-100 Prozent?

Schlau wäre tatsächlich, wenn man Dimmer und Rolladenaktoren mit Prozentwerten ansteuern könnte und die Readings (1.LEVEL) auch Prozentwerte (also 0-100) zurück liefern würden.

Hoffe auf Hilfe.

VG Alex
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Juni 2016, 18:51:38
Ich verstehe Dein Problem, habe allerdings derzeit keine Lösung dafür. HMCCU reicht momentan numerische Werte der Datenpunkte 1:1 an die Readings weiter (ok, bei Bedarf kann man die Nachkommastellen abschneiden lassen).

Da müsste ich was implementieren, so eine Art "scale" Attribut, das in beide Richtungen (Get/Set) arbeitet. Ich schreibe es auf die Liste.

Wenn es nur um die Darstellung in den Readings ginge, könntest Du einfach ein Userreading definieren, das den Wert eines Datenpunktes mit 100 multipliziert. Das hilft aber nicht beim Setzen der Werte.

Ich könnte mir in der nächsten Version folgendes vorstellen:

attr <dev> scale 1.LEVEL:100,1.TEMPERATURE:10

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 22 Juni 2016, 18:56:13
Das geht über eventMap. Sowohl hin als auch zurück.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 22 Juni 2016, 18:57:44
Das geht über eventMap. Sowohl hin als auch zurück.

Und wie?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 22 Juni 2016, 21:00:01
https://forum.fhem.de/index.php/topic,43023.msg350289.html#msg350289
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Juni 2016, 22:03:13
Hi Ralli,

ich hatte auch daran gedacht, wollte es aber nicht vorschlagen, weil es schon irgendwie hässlich ist ;-)

Aber ok, als Workaround funktioniert es bis ich eine etwas elegantere Lösung in HMCCU eingebaut habe.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 22 Juni 2016, 22:14:03
Das ist jetzt bestimmt eine dumme Frage, aber hat jemand mal ein komplettes define-Statement für einen Dimmer mit dem Modul HMCCU? Meiner will nicht ... :o

VG Yil
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 22 Juni 2016, 22:38:43
Ich glaube ein Dimmer wurde irgendwo in diesem Thread schon mal behandelt. Langsam wird der Beitrag hier auch etwas unübersichtlich.

Jedenfalls hier erst mal die Erklärung für das Stoppen des RPC Servers beim Editieren der fhem.cfg

https://forum.fhem.de/index.php/topic,54890.0.html

Was will denn nicht beim Dimmer? Poste doch mal ein list Devname , wenn zumindest der Define klappt. Auch ein " get devname deviceinfo " ist manchmal aufschlussreich
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 23 Juni 2016, 07:26:38
Hi zap,

danke für's Recherchieren - jetzt ist's mir klar, warum das so dermaßen deutlich zu reproduzieren war. Ich weiß, dass es viele unverständige Blicke gibt, wenn man preisgibt, dass man die fhem.cfg von Hand editiert. Schlechte Angewohnheit, die jedoch viel Flexibilität beinhaltet. Ich versuche "umzulernen" ;)

Dimmer mache ich in einem separaten Post. Ggf. könnte man aber Geräte, die als HMCCUDEV definiert werden, auch hier behandeln: https://forum.fhem.de/index.php/topic,51339.0.html - was meinst Du?

Meiner Meinung nach ist das HMCCU-Modul eines der ganz wichtigen Module der Zukunft in Sachen Homematic, wenn der klassische und weit verbreitete HMLAN ausstirbt (was zwangsläufig der Fall sein wird, nachdem die Produktion eingestellt und das Gerät "end-of-life" ist (alles sehr aktuell lt. Hersteller EQ3). Hier lohnt es sich früh, Knowhow aufzubauen und breit zu streuen. An der Stelle ein Danke, dass Du Dich darum kümmerst!

VG Yil
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 23 Juni 2016, 08:09:02
Was daran verwerflich sein soll, die fhem.cfg von Hand zu editieren (wenn man weiß, was man tut und auch ein Backup hat), weiß ich nicht.
Ich mache das auch oft. Vor allem, wenn ich ein neues Gerät in Betrieb nehme und dafür ein vorhandenes einfach klonen kann.  ;)

Dimmer: Ich poste mal mein Beispiel in den von Yil angegebenen anderen Thread. :)

Skalierung der Prozentwerte: Da gibt es jetzt eine Lösung für die homebridge, das die 0..1 Werte auf 0..100 aufbläst und umgekehrt wieder die Luft rauslässt. (Ich poste das in dem Dimmerbeispiel gleich mit.)
Wäre dennoch schön, wenn man das auch in HMCCUDEV/HMCCUCHN machen könnte.  :)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 23 Juni 2016, 08:24:34
Hi aski71, danke für Deine moralische Unterstützung. Ich habe von einigen sehr erfahrenen fhem-Anwendern fast schon böse und abfällige Kommentare geerntet, als ich mich als fhem-Editor geoutet habe. Ich bin so "aufgewachsen", einen ordentlich lesbaren und strukturierten Code zu haben und es seit vielen Jahren gewohnt, direkt im Code zu arbeiten.

Vorteil, wenn man das NICHT tut, ist wohl, dass die Änderungen sofort greifen, denn beim Speichern der fhem.cfg wird ein rereadcfg ausgelöst, dass temporäre Verbindungen kappt (hat zap für mich recherchiert). Im Ergebnis verliere ich z.B. immer die Verbindung zur HMCCU und muss diese neu starten (RPCServer). Ein anderer Vorteil ist, dass auch Änderung in aus der fhem.cfg ausgelagerten Dateien, die dann über include eingebunden werden, sofort greifen. Ändert man diese include-Datein manuell, muss fhem komplett neu gestartet werden.

Dimmer-Beispiel: sehr cool, vielen Dank.

Ich könnte außerdem noch Hilfe bei der Definition der 3 Rauchmelder und des TeamLeaders gebrauchen, denn diese Geräte hängen bei mir noch am (mittlerweile außer Betrieb genommenen, da defekten) HMLAN-Adapter und müssen ebenfalls auf die neue HMCCU umgebaut werden. Aber dazu melde ich mich im anderen Post separat.

VG Yil
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 23 Juni 2016, 08:36:00
Ja, das ist mir auch schon aufgefallen mit dem PRCServer. Aber wenn man das weiß ist es ja kein Beinbruch. Muss man halt einen "set ccu2 rpcserver on" nach dem Speichern und neu laden hinterher schicken und alles ist gut.

Prima, wenn das Dimmer-Beispiel hilft. Bei Rauchmeldern und TeamLeader (was ist letzteres überhaupt  :D ) kann ich leider nicht weiter helfen. Hab noch keine Rauchmelder...  :o In Bayern erst Nachrüstepflicht bis Anfang 2018.  ;D

VG Alex
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 23 Juni 2016, 08:58:20
Tja, in Sachen Rauchmeldern hat BW da die Nase vorn  ;)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Juni 2016, 11:53:39
Bei Rauchmeldern kocht eQ3 leider wieder ein separates Süppchen. Eine Rauchmeldergruppe hat nichts mit einer normalen CCU Devicegruppe zu tun. Ein Rauchmelder ist der Master. So eine Gruppe hat ein Sternchen am Ende der Adresse.

ich würde für die Gruppe einfach mal ein Device anlegen und schauen, was man damit anfangen kann. Auch hier einfach mal get deviceinfo benutzen.

Kann das leider nicht testen, da ich meine HM Rauchmelder nach diversen Fehlalarmen entsorgt und durch Gira Melder mit HomeMatic Schliesserkontakt ersetzt habe. Ok, war scheiss teuer, aber die Nachtruhe war es mir wert
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 23 Juni 2016, 12:09:13
Ist zwar jetzt ein wenig off topic, aber: Welche Hm-Rauchmelder hattest Du?
Die aktuellen 10-Jahres-Dinger im 3er Pack?
Oder ältere?
Hab das mit den Fehlalarmen schin öfter gehört....
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Juni 2016, 12:21:49
ich hatte die älteren. Für die neuen liegen mir bzgl. Fehlalarme noch keine Infos vor.

Bei den älteren gabe es 1-2 lange Threads im Homematic Forum.

An sich ist die Gruppen-Funktion ja eine schöne Sache. Allerdings nicht, wenn man ständig Fehlalarme hat und dann im ganzen Haus die Dinger angehen. Einen habe ich dann mal nachts in den Garten gefeuert und die anderen am nächsten Tag abgebaut.

Ich kenne allerdings auch Leute, die mit den alten nie Fehlalarme hatten. Mir scheint, da war die Serienstreuung enorm. Und ja, ich habe alle EQ3 Anweisungen befolgt (regelmäßig Kalibrieren usw.).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: aski71 am 23 Juni 2016, 12:24:46
Danke für die Info.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Juni 2016, 12:27:21
Da ich immer wieder Nachfragen dazu erhalte, hier mal die HMCCU Roadmap für die nächsten 1-2 Versionen:

- Integration in den FHEM SVN Hauptzweig (standard update Funktion)
- Verkürzte Reading-Names auch bei HMCCUDEV Devices
- Skalierung von Reading-Werten
- Unterstützung von RAMP_TIME bei set Befehlen (sofern das Device das unterstützt)
- Unterstützung von virtuellen Tasten der CCU (50 Kanäle)
- CCU Heartbeat Mechanismus

Das sind die Dinge, an denen ich gerade aktiv arbeite.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 23 Juni 2016, 14:07:27
Danke für die Roadmap - da ist einiges drin, auf was ich mich freue.

Aber eine andere Frage in dem Zusammenhang: wozu sind denn die HMCCUCHN gut - sprich in welchem Fall würde ich denn einen Device auf einen einzelnen Kanal definieren?

Stichwort Homematic Rauchmelder: ich habe bisher viel von Fehlalarmen gehört und jetzt von Dir auch, aber ich selbst hatte im letzten halben Jahr keinen einzigen (solange sind die Dinger im Einsatz). Gekauft habe ich noch die ältere Version: http://www.elv.de/homematic-vds-funk-rauchmelder-bidcos.html

Beim Pairing in der Homematic Zentrale habe ich jeden Rauchmelder einzeln angemeldet. Dabei hat jeder Rauchmelder auch automatisch seine eigene Gruppe angelegt, die sich nicht mehr löschen lässt - weiß jemand, warum?

Müsste ich nicht so weiter machen, dass ich in der Homematic Zentrale eine Gruppe anlege, in die ich alle Rauchmelder übernehme (so habe ich das bei dem HMLAN-Adapter machen müssen). Oder muss ich die Rauchmelder direkt miteinander peeren?

Bitte da mal um Info, damit ich nicht schon vor der Übernahme in FHEM Rauchmelder-Chaos anrichte  :o

Und klar- ich teste gerne alles aus, was zu dem Thema hier empfohlen wird!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 23 Juni 2016, 14:26:32
Nach etwas Suchen habe ich folgende Anleitung gefunden, die helfen mag: http://files.elv.de/Assets/Produkte/7/766/76676/Downloads/76676_vernetzung_um.pdf - mit dem abschließenden Test hat man die Gewissheit, sie ordentlich angelernt und vernetzt zu haben.

Anbei die Info aus

get HMCCU2 deviceinfo RauchmelderTeam
in der Anlage. Gibt ja nicht wirklich viel her ...

Und nun die Einbindung in HMCCU ...  ::)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Juni 2016, 16:34:00
Wenn Deine Rauchmelder keine Fehlalarme verursachen ist ja alles in Ordnung. Meine sind auch schon 2 Jahre alt und hatten am Ende beinahe täglich einen Fehlalarm.

Bei den Datenpunkten der Rauchmeldergruppe ist wohl nur STATE sinnvoll. Ich vermute, das geht auf true, wenn einer der Melder in der Gruppe auslöst. Insofern empfehle ich Dir, noch je ein Device in FHEM für jeden einzelnen Melder zu definieren. Dann kannst Du auch erkennen, welcher Melder ausgelöst hat.

Laut EQ-3 Doku hat ein RM vom Typ HM-Sec-SD-2 im Kanal 1 folgende Datenpunkte:

ERROR_ALARM_TEST
ERROR_SMOKE_CHAMBER
STATE
LOWBAT
INSTALL_TEST

Da alle in einem Kanal liegen, bietet es sich an, dafür HMCCUCHN zu verwenden. Das hat einige Vorteile, da HMCCUCHN jetzt schon Readings unterstützt, die nur aus dem Datenpunktnamen bestehen. Außerdem unterstützt HMCCUCHN read only Devices, d.h. ohne Set Befehl (was in diesem Fall oder auch bei Fenstersensoren Sinn macht, da diese Geräte keine Schreibzugriffe zulassen).

z.B.

define myRM HMCCUCHN ccu-channel-name-or-address readonly
attr myRM ccureadingfilter (LOWBAT|STATE)
attr myRM substitute STATE!(true|0):alarm,(false|0):kein_alarm;LOWBAT!(true|1):yes,(false|0):no
attr myRM ccureadingformat datapoint

Aber Achtung! Für das Gruppendevice immer HMCCUDEV verwenden, da bis jetzt nur dieses die *Adresse unterstützt.

Grundsätzlich fügt die CCU2 bei jedem Device einen künstlichen Kanal 0 hinzu, in dem solche Datenpunkte wie UNREACH oder RSSI bereitgestellt werden. Wenn Dich die interessieren, musst Du natürlich immer HMCCUDEV verwenden.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 24 Juni 2016, 09:07:24
Danke, das werde ich heute ausprobieren. Bleibt für mich noich eine Frage offen: wie kann ich den TeamMelder aktiv anstoßen - also Befehle wie TeamCall, alarmOn (brauche ich für die Alarmanlage) und alarmOff (muss ja auch wieder aussschalten).

Hast Du da eine Idee? Definiert hab ich den TeamMelder so:

define RauchmelderTeam HMCCUDEV *MEQ0258600 1
attr RauchmelderTeam IODev HMCCU2
attr RauchmelderTeam ccureadingfilter (STATE)
attr RauchmelderTeam devStateIcon off:general_aus smoke-Alarm.*:secur_alarm@red
attr RauchmelderTeam devStateStyle style="text-align:right;;"
attr RauchmelderTeam event-on-change-reading .*
attr RauchmelderTeam eventMap /teamCall:Teamruf/ /alarmOn:Alarm an/ /alarmOff:Alarm aus/
attr RauchmelderTeam group Rauchmelder
attr RauchmelderTeam icon secur_smoke_detector
attr RauchmelderTeam room Device,Zentral
attr RauchmelderTeam statechannel 1
attr RauchmelderTeam statevals alarmOn:true,alarmOff:false
attr RauchmelderTeam substitute STATE!true:alarmOn,false:alarmOff,1:alarmOn,0:alarmOff

Leider funktionieren die Befehle so nicht, die Rauchmelder reagieren nicht darauf (wobei die Einrichtung lt. Abschlußtest ok ist).
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 24 Juni 2016, 16:48:50
Danke, das werde ich heute ausprobieren. Bleibt für mich noich eine Frage offen: wie kann ich den TeamMelder aktiv anstoßen - also Befehle wie TeamCall, alarmOn (brauche ich für die Alarmanlage) und alarmOff (muss ja auch wieder aussschalten).

Gar nicht. Das sehen sowohl die XML-RPC-Schnittstellen als auch die Logikschicht der CCU nicht vor.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 25 Juni 2016, 23:48:37
Echt? Ich kann den Alarm der RM nicht selbst aktiv auslösen? Dann kann ich die RM ja gar nicht in die Signalisierung meiner Alarmanlage einbinden. Beim HMLAN-Adapter ging das.

@zap: könntest Du das Thema auch mit auf die Roadmap nehmen? Sonst müsste ich mir noch eine Alarmsirene besorgen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 26 Juni 2016, 07:19:49
Das kann zap nicht auf die Roadmap nehmen.

Vollständig lesen:

Zitat
Das sehen sowohl die XML-RPC-Schnittstellen als auch die Logikschicht der CCU nicht vor.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 26 Juni 2016, 11:19:08
@Ralli: Hast Du auch eine Erklärung, warum es mit dem HMLAN-Adapter (HM-CFG-LAN) ging?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 26 Juni 2016, 12:56:38
Weil da fhem mit dem Modul CUL_HM als Zentrale fungiert und unmittelbar auf unterster Ebene mit den Sensoren und Aktoren kommunizieren kann - also BidCoS spricht.

Das Modul HMCCU kann und macht das nicht, es ist dazu da, eine bestehende CCU mit den von ihr zur Verfügung gestellten Methoden "fernzubedienen".

Da solltest Du aber eigentlich selbst drauf kommen, wenn Du Dich mit den Modulen richtig auseinander gesetzt hast.

Workaround 1:
Nimm dies: http://www.elv.de/homematic-komplettbausatz-innensirene-als-mini-alarmanlage.html
Hat den Vorteil, dass es im Alarmfall weniger Funkverkehr gibt, da nicht alle RM wild durch die Gegend funken.

Workaround 2:
http://www.elv.de/homematic-schaltaktor-fuer-batteriebetrieb-komplettbausatz.html
Das Relais kannst Du an die Drahtanbindung eines RM anschließen. 2.5 Sekunden für Alarm ein- und 6.5 für Alarm ausschalten.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 27 Juni 2016, 08:45:54
Als Ergänzung: hier eine kleine Bastelanleitung für das manuelle Auslösen eines Rauchmelders:

http://homematic-forum.de/forum/viewtopic.php?f=31&t=9263

Grundsätzlich sollte man mit solchen Basteleien an Rauchmeldern vorsichtig sein. Bei Fehlern besteht die Gefahr, dass der Melder im Ernstfall nicht mehr auslöst.

Meine Empfehlung wäre daher eine Sirene für die Alarmanlage zu verwenden.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Yil am 27 Juni 2016, 16:11:41
Danke für Eure Rückmeldungen - die Idee mit der Sirene war mein Plan B  ;)
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Achiim am 20 Juli 2016, 21:05:32
Dimmer und Tablet UI:

Ich habe einen LED-Dimmer definiert und möchte diesen über Tablet UI mit einem Dimmer Widget steuern. Das scheitert aber momentan.

So ist der Dimmer in FHEM definiert:

define Keller_LED_Bar HMCCUDEV Keller-LED-Bar 1
attr Keller_LED_Bar IODev myHomematicCCU
attr Keller_LED_Bar controldatapoint 1.LEVEL
attr Keller_LED_Bar event-on-change-reading .*
attr Keller_LED_Bar group BeachBar
attr Keller_LED_Bar icon light_led_stripe
attr Keller_LED_Bar room 04_Keller
attr Keller_LED_Bar statechannel 1
attr Keller_LED_Bar statedatapoint 1.LEVEL
attr Keller_LED_Bar statevals on:1.0,off:0.0
attr Keller_LED_Bar stripnumber 1
attr Keller_LED_Bar substitute 1.0:on,0.0:off,1:on,0:off
attr Keller_LED_Bar webCmd control
attr Keller_LED_Bar widgetOverride control:slider,0,0.1,1,1

Und so das Widget in Tablet UI:
<div data-type="dimmer" data-device="Keller_LED_Bar"
data-set="control" data-min="0" data-max="1" data-off="0" data-on="1" class="cell"></div>

Da die Werte vom LED-Dimmer zwischen 0 und 1 liegen, kann ich mit dem Widget nicht "dimmen", da es keine Zwischenwerte gibt. data-step="0.1" wird vom widget nicht unterstützt. data-step kann nur ganzzahlige Werte. Die Werte von "control" sollten dann zwischen 0 und 100 liegen. Wie krieg ich das zusammen?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 21 Juli 2016, 07:23:46
In der nächsten Version von HMCCU wird es ein Attribut zum Skalieren von Werten geben.

Einige TabletUI Widgets unterstützen steps < 1, aber eben nicht alle. Bei Widgets, die von knob abgeleitet sind geht es.

Momentan kannst Du das nur über ein anderes Widget lösen.

Die neue Version von HMCCU sollte Ende nächster Woche fertig sein. Wollte zwar noch  ein paar Dinge einbauen und insbesondere die Integration in den FHEM Update Zweig machen, aber das kann ich auch verschieben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 22 Juli 2016, 20:28:44
Hallo zap,

ich habe gerade meine FHEM Installation aufgeräumt und dann alles neu installiert. Leider funktioniert HMCCU jetzt nicht mehr so wie es soll.

Im Log erscheint immer folgendes:

2016.07.22 20:08:00 1: HMCCU: 500 Can't connect to 192.168.178.101:8181

Das merkwürdige ist, wenn ich die ganzen HMCCU Definitionen manuell eingebe, läuft alles bis zum Neustart.

So sieht meine Definition aus:

define d_ccu HMCCU 192.168.178.101
attr d_ccu ccureadingformat name
attr d_ccu ccureadings 0
attr d_ccu devStateIcon (OK|Initialized):10px-kreis-gruen Error:10px-kreis-rot
attr d_ccu event-on-change-reading .*
attr d_ccu icon rc_HOME
attr d_ccu rpcinterval 5
attr d_ccu rpcport 2001
attr d_ccu rpcserver on

Wie gesagt, nach einem Neustart des Raspi startet fhem gar nicht mehr und es erscheint die obige Log-Meldung.

Hast Du eine Idee, was da schief läuft? Die IP der CCU ist definitiv richtig.

Grüße
Dominic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: chris1284 am 22 Juli 2016, 20:38:47
ich muss mal ebend nachfragen:
-wenn ich mir eine ccu2 zulege, habe ich einbußen in der bezug auf fhem und hm?
- aktuell fahre ich ein fhem+ hmlan+ hm-cfg-usb+ maxcune im homematic-mode als i.O und alle ist an die vccu gebunden, devices unterinandere verunden um auch ohne fhem schalten zu können

werden meine erwatungen erfüllt werden können:
- alle devices an ccu2 binden und untereinander für direktes schalten
(bei der ccu 1 wäre noch der vorteil des batteriebetriebes den es bei der 2er nicht mehr gibt)
- die io's würde ich an die ccu2 binden (hmlan und hmusb)
- alle devices in fhem auslesbar, schaltbar und zeitnahe statusänderungen
- betrieb ohne fhem möglich (bis auf evtl. in fhem erzeugte operationen natürlich)
- vorteile da man andere nicht fhem entwicklungen parallel nutzen kann (ccu scripte, erweiterungen usw)
- untertsützung von devices die in fhem nicht gehen wie der rgbw controller

danke !
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 23 Juli 2016, 07:09:41
Hallo zap,

ich habe es die halbe nach langt probiert - ich bekomme es einfach nicht mehr hin :-(

Die Meldung

HMCCU: 500 Can't connect to 192.168.178.101:8181


kommt nach jedem Neustart und zwar immer beim define d_ccu HMCCU 192.168.178.101.

Wenn ich das Define Auskommentiere und danach in fhem per Hand in die Kommandozeile eintrage,
dann funktioniert es einwandfrei ...

Hast Du einen Tip für mich?
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 23 Juli 2016, 18:47:47
@Nico,Chris: kann eure Fragen leider erst Montag beantworten, da momentan unterwegs mit sporadischer Internet Verbindung 
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Ralli am 24 Juli 2016, 07:08:41
Vielleicht ist zum Start von fhem das Netzwerk noch nicht fertig.

In /etc/init.d/fhem

die Zeile

# Required-Start:       $local_fs $remote_fs

zu

# Required-Start:       $local_fs $remote_fs $network

verändern.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 24 Juli 2016, 15:22:04
Hallo Ralli,

danke - das wars :-)

Vielen vielen Dank.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 Juli 2016, 17:14:08
ich muss mal ebend nachfragen:
-wenn ich mir eine ccu2 zulege, habe ich einbußen in der bezug auf fhem und hm?
- aktuell fahre ich ein fhem+ hmlan+ hm-cfg-usb+ maxcune im homematic-mode als i.O und alle ist an die vccu gebunden, devices unterinandere verunden um auch ohne fhem schalten zu können

Wenn Du beides haben möchtest, also CUL_HM und HMCCU: das wurde hier schon mal diskutiert. Ich glaube, Du musst dann sowohl in der CCU2 als auch in FHEM die gleiche HMID verwenden. Das ist aber Theorie. Ich selbst habe das nicht getestet, da ich kein CUL habe.

Zitat
werden meine erwatungen erfüllt werden können:
- alle devices an ccu2 binden und untereinander für direktes schalten

Ja, Geräte, die an der CCU2 angelernt sind, können (sofern sie das unterstützen) direkt miteinander gepairt werden. Dann können Sie auch ohne CCU interagieren.

Zitat
(bei der ccu 1 wäre noch der vorteil des batteriebetriebes den es bei der 2er nicht mehr gibt)

Ich würde die 2er nehmen. Dann hast Du auch gleich Unterstützung für Homematic IP.

Zitat
- die io's würde ich an die ccu2 binden (hmlan und hmusb)

Wie Du das machen willst, ist mir nicht klar. Es funktioniert so: HMCCU ist das IO Device, das die Kommunikation mit der CCU2 erledigt. hmlan und hmusb brauchst Du nicht mehr. Das Anlernen an die CCU2 sowie das Pairen der Geräte untereinander wird alles in der CCU2 erledigt.

Zitat
- alle devices in fhem auslesbar, schaltbar und zeitnahe statusänderungen
- betrieb ohne fhem möglich (bis auf evtl. in fhem erzeugte operationen natürlich)
- vorteile da man andere nicht fhem entwicklungen parallel nutzen kann (ccu scripte, erweiterungen usw)
- untertsützung von devices die in fhem nicht gehen wie der rgbw controller

Mit HMCCU uneingeschränkt ja.

Aber HMCCU ist NICHT kompatibel mit VCCU!!

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: chris1284 am 25 Juli 2016, 18:31:45
bezüglich hmlan und hmusb: an die ccu1 konnte man diese als weitere io-devices anbinden um die ccu-reichweite zu erhöhen, ich denke das geht zu mindest mit dem hmlan auch bei der 2er. zur fhemseite hat man dann natürlich nur die ccu2 als io. vccu brauch ich dann net mehr und den cube als 2. hmlan auch nicht da diecu2 einen teil abdecken würde und der hmlan einen anderen. den hm-cfg-usb würd ich in fhem / zum spielen nutzen.

Danke dir!
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 25 Juli 2016, 20:32:14
Hallo zap,

jetzt muss ich doch noch einmal stören :-(

Ich habe im Log folgenden Eintrag wenn ich bei einem Fensterkontakt  "get Arbeitszimmer_Fenster update" ausführen:

2016.07.25 20:27:03 1: HMCCUCHN: Arbeitszimmer_Fenster No readable datapoints found
Der Status ist dann "error".

Das merkwürdige ist, dass ein genauso definierter Fensterkontakt mir den korrekten Status liefert.

Ein get Arbeitszimmer_Fenster devstate bringt mir dann den aktuellen Status, aber keine Datenpunkte für LOWBAT und ERROR.

So ist der der TFK definiert:

define Arbeitszimmer_Fenster HMCCUCHN LEQ0501605:1 readonly
attr Arbeitszimmer_Fenster IODev d_ccu
attr Arbeitszimmer_Fenster ccureadingfilter (ERROR|LOWBAT|STATE)
attr Arbeitszimmer_Fenster devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr Arbeitszimmer_Fenster event-on-change-reading .*


Hast Du noch einen Tip für mich?

Gruß
Nic
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 25 Juli 2016, 22:32:15
Dass get devstate funktioniert, aber get update nicht ... möglich. Bei get devstate wird einfach dumpf der Datenpunkt STATE abgefragt. Bei get update prüft HMCCU, ob es lesbare Datenpunkte gibt (es gibt tatsächlich Datenpunkte, in die man nur schreiben kann oder die sogar nur Events produzieren).

Jedenfalls müsste get update die 3 Datenpunkte finden. Prüfen kannst Du das, indem Du folgenden Befehl ausführst

get d_ccu deviceinfo LEQ0501605

Das gibt Dir alle Kanäle und Datenpunkte aus inklusive der Flags (bei STATE, ERROR und LOWBAT sollten das [RE] für Read und Event sein.

So und jetzt wird es kompliziert. Schau Dir mal von Deinem Device das Internal ccutype an. Hier findest Du den Gerätetyp (z.B. HM-Sec-SCo). Nun führst Du den Befehl "list d_ccu" aus.

In der folgenden rechte langen Ausgabe suchst Du den oben gefundenen Gerätetyp, also z.B. HM-Sec-SCo. In meinem Fall sieht das wie unten aus. Wichtig ist, dass unter Ch: 1: bei Error, Lowbat und State hinter oper jeweils eine 5 steht.

Hm-sec-sco:
         Ch:
           0:
             Aes_key:
               oper       1
               type       8
             Config_pending:
               oper       5
               type       2
             Device_in_bootloader:
               oper       5
               type       2
             Lowbat:
               oper       5
               type       2
             Rssi_device:
               oper       5
               type       8
             Rssi_peer:
               oper       5
               type       8
             Sticky_unreach:
               oper       7
               type       2
             Unreach:
               oper       5
               type       2
             Update_pending:
               oper       5
               type       2
           1:
             Error:
               oper       5
               type       16
             Install_test:
               oper       4
               type       2
             Lowbat:
               oper       5
               type       2
             State:
               oper       5
               type       2

Falls Du das nicht findest, führe einmal den Befehl "get d_ccu devicelist" aus, um die Geräte neu aus der CCU abzufragen.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 06:04:49
Hi,

get device info liefert alle drei Datenpunkte.

list d_ccu liefert:

Hm-sec-sc-2:
         Ch:
           0:
             Aes_key:
               oper       1
               type       8
             Config_pending:
               oper       5
               type       2
             Lowbat:
               oper       5
               type       2
             Rssi_device:
               oper       5
               type       8
             Rssi_peer:
               oper       5
               type       8
             Sticky_unreach:
               oper       7
               type       2
             Unreach:
               oper       5
               type       2
           1:
             Error:
               oper       5
               type       16
             Install_test:
               oper       4
               type       2
             Lowbat:
               oper       5
               type       2
             State:
               oper       5
               type       2

get Arbeitszimmer_Fenster update liefert leider immer noch "no readable datapoints found"
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Juli 2016, 09:08:29
Hast Du mehrere Fensterkontakte und tritt das Problem bei allen auf ?

Hast Du mal ein "get d_ccu devicelist" ausgeführt und danach nochmal das "get xxxx update" versucht ?

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 10:11:19
Hi, ja habe 10 FensterKontakte 6 gehen, 4 nicht :-( 

Get d_ccu devicelist hat zwar rund 280 Kanäle geladen,  aber am Verhalten ändert sich leider nichts :-(

Gesendet von meinem GT-I9505 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Juli 2016, 11:53:09
Ok, poste mal bitte ein "list <devname>" von einem Device das geht und von einem das nicht geht. Ausserdem die Definition und die Attribute von einem das geht.

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 13:07:11
So sieht es bei einem aus, der nicht funktioniert :


Internals:
   CHANGED
   DEF        LEQ1060645:1 readonly
   IODev      d_ccu
   NAME       Schlafzimmer_Fenster
   NR         68
   STATE      Error
   TYPE       HMCCUCHN
   ccuaddr    LEQ1060645:1
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Fenster Schlafzimmer
   ccutype    HM-Sec-SC-2
   channels   1
   statevals  readonly
   Readings:
     2016-07-25 21:01:53   Fenster_Schlafzimmer.STATE 0
     2016-07-26 10:09:07   state           Error
Attributes:
   IODev      d_ccu
   ccureadingfilter (ERROR|LOWBAT|STATE)
   devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
   event-on-change-reading .*
   substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):1

Gesendet von meinem GT-I9505 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 13:10:21
Und so sieht es bei einem aus der funktioniert :

nternals:
   DEF        LEQ0175072:1 readonly
   IODev      d_ccu
   NAME       Kueche_Fenster
   NR         29
   STATE      0
   TYPE       HMCCUCHN
   ccuaddr    LEQ0175072:1
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Fenster_Kueche
   ccutype    HM-Sec-SC-2
   channels   1
   statevals  readonly
   Readings:
     2016-07-25 20:35:39   Fenster_Kueche.ERROR 0
     2016-07-25 20:35:39   Fenster_Kueche.LOWBAT 0
     2016-07-25 20:35:39   Fenster_Kueche.STATE 0
     2016-07-25 20:35:39   state           0
Attributes:
   IODev      d_ccu
   ccureadingfilter (ERROR|LOWBAT|STATE)
   devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
   event-on-change-reading .*
   substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):1

Gesendet von meinem GT-I9505 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 13:12:42
Und hier noch die Definition des tfk, der funktioniert :

#Fenster
#Kueche
define Kueche_Fenster HMCCUCHN LEQ0175072:1 readonly
attr Kueche_Fenster IODev d_ccu
attr Kueche_Fenster ccureadingfilter (ERROR|LOWBAT|STATE)
attr Kueche_Fenster devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
attr Kueche_Fenster event-on-change-reading .*
attr Kueche_Fenster substitute STATE!(0|false):0,(1|true):1;;LOWBAT!(0|false):0,(1|true):1


Gesendet von meinem GT-I9505 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Juli 2016, 14:16:09
Kann es sein, dass alle TF-Kontakte, bei denen get update nicht funktioniert, ein Leerzeichen im CCU-Namen (Internal ccuname) enthalten ist?

Zumindest ist das der einzige relevante Unterschied, den ich in den 2 Beispielen erkennen kann.

Wenn dem so ist bitte erst mal nichts unternehmen (umbenennen oder so). Vielleicht kann ich das in HMCCU beheben.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 15:13:32
Hi, leider nein.

Hier von einem der nicht funktioniert (trotz ohne Leerzeichen ):


Save config
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Internals:
   DEF        MEQ0723287:1 readonly
   IODev      d_ccu
   NAME       Gaeste_WC_Fenster
   NR         48
   STATE      Error
   TYPE       HMCCUCHN
   ccuaddr    MEQ0723287:1
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Fenster_Gaeste_WC
   ccutype    HM-Sec-SCo
   channels   1
   statevals  readonly
   Readings:
     2016-07-25 20:47:54   Fenster_Gaeste_WC.ERROR 0
     2016-07-25 20:47:54   Fenster_Gaeste_WC.LOWBAT 0
     2016-07-25 20:47:54   Fenster_Gaeste_WC.STATE 0
     2016-07-26 15:10:46   state           Error
Attributes:
   IODev      d_ccu
   ccureadingfilter (ERROR|LOWBAT|STATE)
   devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
   event-on-change-reading .*
   substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):




Gesendet von meinem GT-I9505 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 15:15:32
Und hier mit Leerzeichen , wo das update funktioniert :


Internals:
   CHANGED
   DEF        MEQ0723295:1 readonly
   IODev      d_ccu
   NAME       WZ_vorn_Fenster
   NR         36
   STATE      0
   TYPE       HMCCUCHN
   ccuaddr    MEQ0723295:1
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    Fenster Wohnzimmer vorn
   ccutype    HM-Sec-SCo
   channels   1
   statevals  readonly
   Readings:
     2016-07-26 15:14:24   Fenster_Wohnzimmer_vorn.ERROR 0
     2016-07-26 15:14:24   Fenster_Wohnzimmer_vorn.LOWBAT 0
     2016-07-26 15:14:24   Fenster_Wohnzimmer_vorn.STATE 0
     2016-07-26 15:14:24   state           0
Attributes:
   IODev      d_ccu
   ccureadingfilter (ERROR|LOWBAT|STATE)
   devStateIcon closed:10px-kreis-gruen open:10px-kreis-rot
   event-on-change-reading .*
   substitute STATE!(0|false):0,(1|true):1;LOWBAT!(0|false):0,(1|true):1

Gesendet von meinem GT-I9505 mit Tapatalk

Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: zap am 26 Juli 2016, 16:28:37
Versuch mal bitte folgendes:

attr d_ccu ccutrace LEQ0501605

Dann nochmal den Befehl

get Arbeitszimmer_Fenster update

ausführen (Verbose Level muss min. 2 sein).
Dann im FHEM Logfile nachschauen. Es sollte nun 3 Zeilen geben, die so anfangen:

HMCCU: Addr=
HMCCU: Script response =
HMCCU: Script =

Diese Ausgabe hätte ich gerne.
Titel: Antw:Neues Modul HMCCU für Homematic CCU
Beitrag von: Nic0205 am 26 Juli 2016, 16:38:53
So sieht das dann aus:


2016.07.26 16:35:02 1: in ATTR
2016.07.26 16:35:41 2: HMCCU: Addr=LEQ0501605:1 Name=Fenster Arbeitszimmer
2016.07.26 16:35:41 2: HMCCU: Script response =
0

2016.07.26 16:35:41 2: HMCCU: Script =

string sDPId;
string sChnName = "Fenster Arbeitszimmer";
integer c = 0;
object oChannel = dom.GetObject (sChnName);
if (oChannel) {
  foreach(sDPId, oChannel.DPs()) {
    object oDP = dom.GetObject(sDPId);
    if (oDP) {
       if (OPERATION_READ & oDP.Operations()) {
         WriteLine (sChnName # "=" # oDP.Name() # "=" # oDP.Value());
         c = c+1;
      }
    }
  }
  WriteLine (c);
}
      
2016.07.26 16:35:41 1: HMCCUCHN: Arbeitszimmer_Fenster No readable datapoints found


Gesendet von meinem GT-I9505 mit Tapatalk
T