FHEM Forum

Moin,

für die Koppelung einer Homematic CCU an FHEM per XML-RPC (die mitgelieferte API) habe ich basierend auf den existierenden Codestücken in contrib/HMRPC ein funktionierendes Modul gebaut. Der existierende Code in contrib funktionierte aus mehreren Gründen nicht (unter anderem weil einkommende XML-RPC-Requests FHEM für mindestens 20 Sekunden blockieren, eher länger, wenn es mehrere Updates von der CCU gibt), und ich habe diese Aspekte erst einmal repariert. Es fühlt sich zwar immernoch wie ein Fremdkörper an, tut aber zumindest erstmal ein bisschen.

Vorteile:

• Keine Zusatzinstallation auf der CCU erforderlich
• Callbacks von der CCU bei jeder Änderung: Instantane Updates in FHEM

Code hier: https://github.com/henryk/fhem-HMRPC

Dokumentation habe ich noch keine, es gilt der größte Teil von contrib/HMRPC/HMRPC.txt weiterhin.

Technisch habe ich das so verbessert dass die Callbacks der CCU nicht mehr über einen eigenen Socket reinkommen (was durch die Inflexibilität von RPC::XML::Server dann notwendigerweise dazu führt, dass ein timeout abgewartet wird) sondern von FHEMWEB angenommen werden. Dazu waren zwei Patches an FHEMWEB nötig, die Rudolf bereits eingespielt hat, also dann irgendwann auftauchen wenn man ein Entwicklungszweig-FHEM hat. Andernfalls kann man sie aus http://forum.fhem.de/index.php/topic,41030.msg332339.html#msg332339 und http://forum.fhem.de/index.php/topic,41034.msg332383.html#msg332383 direkt beziehen.

Installation:
update force https://raw.githubusercontent.com/henryk/fhem-HMRPC/master/controls_HMRPC.txt
shutdown restart

CCU definieren:
define hmrf HMRPC I.P.der.CCU 2001

Zur Zeit ist der Port unter der FHEMWEB zu erreichen ist auf 8083 hartkodiert, kann aber über ein Attribut geändert werden:
attr hmrf callback_base http://I.P.von.FHEMWEB:port/fhem (Es muss der gesamte Basis-URL der FHEMWEB-Instanz inklusive Port und "/fhem" angegeben werden.)

Danach meldet die CCU jede Attributänderung selbsttätig an FHEM. Wenn autocreate aktiv ist, werden entsprechende HMDEV-Devices angelegt. Obacht: Ich weiss nicht warum, aber das funktioniert nur, wenn bereits ein HMDEV-Device existiert. Daher muss man nach der Installation einmalig define foo HMDEV foo
delete foo machen.


Grade akute Fragen an erfahrenere FHEM-Entwickler:

• Das beschriebene autocreate-Problem, wie löst man das? Symptom: hmrf: Unknown code HMDEV KEQ...:0 LOWBAT 1, help me! im FHEM-Log. Sobald das erste HMDEV-Device definiert wurde wird stattdessen ein neues Device HMDEV_KEQ... angelegt.
• Ich möchte gerne ein Attribut bereits direkt zum Beginn der Funktionalität verwenden. Aber wenn FHEM startet und Definitionen aus fhem.cfg liest, dann kommt ja erst das define und dann das attr (oder auch nicht, wenn das Attribut nicht gesetzt ist). Zur Zeit warte ich einfach 10 Sekunden, aber das kann's ja nicht sein. Ich weiss, dass ich prinzipiell auf global:INITIALIZED lauschen kann und dann die Arbeit aufnehmen, aber was ist dann, wenn der Benutzer das Device interaktiv definiert, also nicht aus dem fhem.cfg. Muss ich da eine Fallunterscheidung einbauen?
• Ich habe Port 8083 und Basis "/fhem" hartgecoded (kann man halt mit dem Attribut überschreiben). Kann ich irgendwie dynamisch die Kontaktdaten einer aktiven FHEMWEB-Instanz rausfinden und benutzen?

Danke für Deine Weiterentwicklung.

Vor Installation ist ein


cpan -i RPC::XML::Server


notwendig.

Ich habe einige Fragen / Anmerkungen zur neuen Version:

- Die alte Version von HMRPC hat keine Bestätigungen für die Callbacks an die CCU geschickt. Das hat zu massiven Fehlermeldungen im Systemlog der CCU geführt. Geht das jetzt?
- Das mit den Timeouts verstehe ich nicht. Ich habe zum Testen einen simplen RPC Server mit Prozess-Forks für das Connection-Handling in C++ geschrieben. Das funktioniert bestens. Nur eben in FHEM nicht.

Habe mein Modul HMCCU "aus der Not heraus" geschrieben, weil ich HMRPC nicht stabil zum Laufen bekommen habe. Grundsätzlich ist RPC die bessere Variante, weil die Info von der CCU kommt. Wenn das ganze stabil ist und ohne FHEM Patch auskommt, werde ich es nochmal testen.

Wobei für meinen persönlichen Usecase eigentlich die Richtung FHEM -> CCU ausreicht.

Ich hätte noch gaaaanz kleine Kleinigkeiten:

Für die definierte CCU(2) könnten folgende Readings noch von Interesse sein, die irgendwo bei einem list ... auch mitkommen:

FIRMWARE   2.15.2
INTERFACE  LEQ ......
RF_ADDRESS 11343442

wobei INTERFACE ja Seriennummer ist und RF_ADDRESS hexadezimal als HMID der Zentrale dargestellt werden sollte.

Ansonsten werde ich das Modul mal in meiner Produktivumgebung aufnehmen und erst mal zwei-drei Devices "umziehen".

Zitat von: henryk am 14 September 2015, 00:36:49

Ich habe Port 8083 und Basis "/fhem" hartgecoded (kann man halt mit dem Attribut überschreiben). Kann ich irgendwie dynamisch die Kontaktdaten einer aktiven FHEMWEB-Instanz rausfinden und benutzen?[/li][/list]

Man kann doch mit AttrVal() auf Attribut-Werte zugreifen ...

Moin,

Zitat von: zap am 21 September 2015, 14:33:03
- Die alte Version von HMRPC hat keine Bestätigungen für die Callbacks an die CCU geschickt. Das hat zu massiven Fehlermeldungen im Systemlog der CCU geführt. Geht das jetzt?

Das hast du anderswo schonmal geschrieben, ich kann das nicht nachvollziehen. Ich habe mittlerweile die komplette Spezifikation zur HomeMatic-XML-RPC-Schnittstelle durchgelesen und kann nichts derartiges finden. Events werden über ein Callback an eine Methode event() geliefert, deren Rückgabetyp void ist. Es gibt keine Bestätigung (also, ausser dass halt die Funktion zurückkehren muss). Ich habe mit dem neuen Modul auch keine Fehlermeldungen im CCU-Log.

Zitat von: zap am 21 September 2015, 14:33:03
- Das mit den Timeouts verstehe ich nicht. Ich habe zum Testen einen simplen RPC Server mit Prozess-Forks für das Connection-Handling in C++ geschrieben. Das funktioniert bestens. Nur eben in FHEM nicht.

Ja, eben. FHEM ist im wesentlichen eine große Event-Loop in einem Thread in einem Prozess. Wenn du forkst, kannst du nicht mehr auf die Attribute im originalen Prozess zugreifen, um die Ereignisse, von denen du per Callback gelernt hast, weiterzugeben. Das Modul Blocking.pm verwendet einen kruden Trick: Es forkt, und meldet dann das Ergebnis der Ausführung über die (dafür aktiviert sein müssende) Telnet-Schnittstelle zurück. Einen ähnlichen Trick könnte man auch verwenden, um Ereignisse aus einem XML-RPC-Server in einem eigenen Prozess in FHEM zu kriegen, aber ... Holy complexity, batman.
FHEM ist auch überhaupt nicht multi-thread-sicher, d.h. der Ansatz, einen blockierenden XML-RPC-Server in einem eigenen Thread zu haben, scheidet auch weitgehend aus.

Und wie gesagt, XML::RPC::Server ist nicht event-loop-kompatibel, das blockiert einfach mal so x Sekunden während es auf neue Requests wartet.

Zitat von: Ralli am 21 September 2015, 15:08:48
Für die definierte CCU(2) könnten folgende Readings noch von Interesse sein, die irgendwo bei einem list ... auch mitkommen:

FIRMWARE   2.15.2
INTERFACE  LEQ ......
RF_ADDRESS 11343442

Ja, ich muss mal gucken. Zur Zeit wird einfach nur als Reading verzeichnet, was in einem Event kam und daher relativ garantierten Aktualitätswert hat. Diese Dinge die du zitierst muss man initiativ bei der CCU abfragen, ich schau' mal, ob ich das zufriedenstellend einpflegen kann. (Dieses Designschema, was bei HM in FHEM generell vorhanden zu sein scheint, dass Dinge angezeigt werden, die keine Relation zur Wirklichkeit haben, sondern ein set getConfig o.ä. erfordern, kann ich nicht ausstehen.)

Zitat von: Ralli am 21 September 2015, 15:08:48
Ansonsten werde ich das Modul mal in meiner Produktivumgebung aufnehmen und erst mal zwei-drei Devices "umziehen".

Ich hab' bei mir zu Hause seit 'ner knappen Woche einen Fenstersensor und ein HM-CC-TC per HMRPC in FHEM, soweit ohne klagen. Seit letzter Nacht geht auch das passende set SETPOINT_2. Ein HM-TC-IT-WM-W-EU hab' ich auch noch, aber das ist eine Komplexitätsstufe für sich: In der CCU ist das Heizungsteam als virtuelles Gerät INT0...01 repräsentiert, das wird aber über Port 2001 nicht exportiert. Ich hab' gelernt, dass es auf Port 9292 unter /groups noch einen XML-RPC-Endpunkt gibt, der dann diese internen Gruppen darstellt, daran fummele ich derzeit noch.

Zitat von: zap am 21 September 2015, 15:29:37
Man kann doch mit AttrVal() auf Attribut-Werte zugreifen ...

Ja, wenn man den Namen der Instanz kennt. Ich wollte nicht "WEB" hartcoden, weil das genauso schlimm wäre. Ich bin es halt aus anderen Projekten eher gewöhnt, dass es eine ordentliche API für solche Fragen gibt. Mittlerweile habe ich aber gelernt, dass es wohl Usus zu sein scheint, einfach selber in $defs herumzusuchen bis man ein FHEMWEB findet, grusel. Aber ok, mach' ich demnächst.

--
Henryk Plötz
Grüße aus Berlin

Hallo Henryk,

in meiner Produktivumgebung scheitert's zunächst daran, dass ich mein Standard-Webfrontend auf 8083 (ohne SSL) mit Nutzer/Passwort "abgesichert" habe. So kann das Modul bzw. die CCU2 offensichtlich kein RPC-Callback etablieren.

Edit:

Und das führt dazu, dass die CCU2 in ihrem Webfrontend nicht mehr wirklich funktioniert - zumindest dann, wenn man zB die Geräteübersicht aufruft.

Edit2:

Es wäre sinnvoll, die definierte CCU disablen zu können mit attr CCU2 disable 1.

Das mit dem Beantworten der Events steht so nicht in der Spezifikation. Allerdings habe ich es an verschiedenen Stellen und in diversen Beispielprogrammen schon gesehen. Die CCU erwartet (so das Gerücht) ein Leermeldung zurück:

<?xml version="1.0"?>
<methodResponse>
   <params>
      <param><value></value></param>
   </params>
</methodResponse>

Hier steht schon mal was darüber (im 1. Post):

http://homematic-forum.de/forum/viewtopic.php?t=4827

Oder hier ein Zitat: "I have read about this issue/function on the CCU2. After 10 messages from the CCU2 without a right answer from the client, the CCU stop sending messages to the client and delete the client from the list.
A workaround to fix this problem is re-init after 10 messages."

Ich such nochmal weiter ... aber andererseits: wenn es mit dem neuen Modul keine Fehler mehr in /var/log/messages gibt ist ja alles gut.

Moin,

Zitat von: zap am 21 September 2015, 18:13:01
Das mit dem Beantworten der Events steht so nicht in der Spezifikation. Allerdings habe ich es an verschiedenen Stellen und in diversen Beispielprogrammen schon gesehen. Die CCU erwartet (so das Gerücht) ein Leermeldung zurück

Achso, ja, natürlich. Das ist einfach Teil des XML-RPC-Aufrufs, es muss (mit void) zurückkehren. Das kann man aber auch gar nicht falsch machen, wenn man sich die XML-RPC-Implementierung nicht selber bastelt (und dabei schludert), und das hat der Perl-Code auch von Anfang an richtig gemacht. Genauer gesagt, richtig machen gewollt. Es kehrt grade immer mit dem aktuellen Timestamp zurück, weil Perl implizit den letzten Ausdruck als Return-Wert verwendet (grr). Das ignoriert die CCU zum Glück, sie erwartet ja sogar nur void.

Zitat von: Ralli am 21 September 2015, 17:52:35
in meiner Produktivumgebung scheitert's zunächst daran, dass ich mein Standard-Webfrontend auf 8083 (ohne SSL) mit Nutzer/Passwort "abgesichert" habe. So kann das Modul bzw. die CCU2 offensichtlich kein RPC-Callback etablieren.

Hast du mal ausprobiert, ob attr hmrf callback_base http://username:password@I.P.von.FHEMWEB:port/fhem funktioniert?

Zitat von: Ralli am 21 September 2015, 17:52:35
Und das führt dazu, dass die CCU2 in ihrem Webfrontend nicht mehr wirklich funktioniert - zumindest dann, wenn man zB die Geräteübersicht aufruft.

Huch, wait, what? Das sollte in keinem Fall passieren. Mal gucken, ob ich das replizieren kann.

Perspektivisch bin ich aber jetzt so weit, wahrscheinlich doch einen eigenen Port aufzumachen. Ich hatte gehofft, durch Verwendung von FHEMWEB auf unkomplizierte Weise einen soliden existierenden HTTP-Server zu kriegen. *hust* Das kann ich glaub' ich besser, wenn ich's von Hand mache.

--
Henryk Plötz
Grüße aus Berlin

Zitat von: henryk am 21 September 2015, 22:13:34
Hast du mal ausprobiert, ob

Code Auswählen Erweitern

attr hmrf callback_base http://username:password@I.P.von.FHEMWEB:port/fhem funktioniert?

::) 8) ;D hätte ich ja auch selbst mal drauf kommen sollen. Das klappt. Ist nur etwas unschön, da dadurch User/Pass im Klartext in der Config (und im Log) stehen.

Zitat
Huch, wait, what? Das sollte in keinem Fall passieren. Mal gucken, ob ich das replizieren kann.

Ist bei mir zuverlässig jedes mal so gewesen.

Nach Umzug in meine Produktivumgebung lediglich folgende Informationen entgegen allem möglichen in der Testumgebung:


Internals:
   CFGFN
   DEF        10.0.0.64 2001
   NAME       CCU2
   NR         1260
   STATE      Registered
   TYPE       HMRPC
   callbackpath /HMRPC_CCU2
   callbackurl http://x:y@10.0.0.30:8083/fhem/HMRPC_CCU2/request
   serveraddr 10.0.0.64
   serverport 2001
   Helper:
Attributes:
   callback_base http://x:y@10.0.0.30:8083/fhem
   group      Schnittstellen
   icon       hm_ccu
   room       System


... und keine Events kommen an, damit auch kein Autocreate usw.

Btw noch eine Frage: Macht Dein Modul beim Restart von fhem eigentlich eine Status-Abfrage aller HMDEV bei der definierten CCU2?

Und ebenfalls btw: Respekt für http://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ !

Zitat von: henryk am 21 September 2015, 17:29:09
Ja, eben. FHEM ist im wesentlichen eine große Event-Loop in einem Thread in einem Prozess. Wenn du forkst, kannst du nicht mehr auf die Attribute im originalen Prozess zugreifen, um die Ereignisse, von denen du per Callback gelernt hast, weiterzugeben. Das Modul Blocking.pm verwendet einen kruden Trick: Es forkt, und meldet dann das Ergebnis der Ausführung über die (dafür aktiviert sein müssende) Telnet-Schnittstelle zurück. Einen ähnlichen Trick könnte man auch verwenden, um Ereignisse aus einem XML-RPC-Server in einem eigenen Prozess in FHEM zu kriegen, aber ... Holy complexity, batman.
FHEM ist auch überhaupt nicht multi-thread-sicher, d.h. der Ansatz, einen blockierenden XML-RPC-Server in einem eigenen Thread zu haben, scheidet auch weitgehend aus.

Ich habe in den vergangenen Tagen mal ein bisschen rumprobiert in Richtung generischer TCP Server in FHEM implementieren. Inzwischen habe ich aufgegeben. Wenn ich einen separaten Prozess für jede Verbindung forke, hab ich das von Dir beschriebene Problem mit dem Zugriff auf die FHEM Daten. Wenn ich einen iterativen Ansatz verwende, steht FHEM logischerweise während eine Anfrage bearbeitet wird.
Eine Lösung wäre m.E. nur möglich, wenn sich die Architektur von FHEM in Richtung Multi-Processing ändern würde. Daran glaube ich nicht (enormer Aufwand).
Alternative: Solche Schnittstellen wie z.B. RPC-Server werden in einem externen Programm implementiert und kommunizieren mit FHEM. Das halte ich schon eher für realisierbar. Habe speziell für die RPC Geschichte auch schon mal überlegt, einfach einen Apache mit XML-RPC zu installieren.

Hi Henryk,
klasse Sache mit dem RPC Modul. Ich hatte das alte Modul vor einem halben Jahr mal getestet und bin kläglich gescheitert.
Diesmal läuft es definitiv besser. Testraum mit MAX Wandthermostat, Heizungsregler und 2 Fenstersensoren über Homegear an FHEM läuft soweit ganz gut.
Beim HMDEV vermisse ich ein paar Sachen wie z.B. stateFormat, dass lässt sich aber über das Modul Readingsgroup lösen.
Allerdings ist mir ein Fehler im Zusammenhang mit dem Wochenprogramm des Wandthermostaten aufgefallen. Wenn ich das Wochenprogramm über Homegear oder den hm-manager ändere, wird nach einer Error Routine bei FHEM über Port 8083 gesucht...

09/27/15 10:29:33.093 Module MAX: Info: Parameter ENDTIME_FRIDAY_1 of peer 12 and channel 0 was set to 0x56.
09/27/15 10:29:33.108 Info: Calling RPC method "system.multicall" on server 127.0.0.1.
09/27/15 10:29:33.110 Info: Connecting to host 127.0.0.1 on port 2015...
09/27/15 10:29:33.119 Info: Connected to host 127.0.0.1 on port 2015. Client number is: 29409
09/27/15 10:29:33.131 Info: Calling RPC method "system.multicall" on server 127.0.0.1.
09/27/15 10:29:33.143 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.160 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29410
09/27/15 10:29:33.255 Module MAX: CUL "My-MAX-CUL": Info: Sending (My-MAX-CUL, WOR: yes): 1916001006A62303178D00064456546B44CC5514452045204520
09/27/15 10:29:33.295 Info: Calling RPC method "updateDevice" on server 127.0.0.1.
09/27/15 10:29:33.296 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.299 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29411
09/27/15 10:29:33.347 RPC Server (Port 2001): Info: Connection from 127.0.0.1:44174 accepted. Client number: 29412
09/27/15 10:29:33.360 RPC Server (Port 2001): Info: Client number 29412 is calling RPC method: getServiceMessages Parameters:
09/27/15 10:29:33.366 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: updateDevice' on server
09/27/15 10:29:33.372 Info: Calling RPC method "error" on server 127.0.0.1.
09/27/15 10:29:33.375 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.386 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29413
09/27/15 10:29:33.419 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: error' on server
09/27/15 10:29:33.420 Info: Calling RPC method "error" on server 127.0.0.1.
09/27/15 10:29:33.421 Info: Connecting to host 127.0.0.1 on port 8083...
09/27/15 10:29:33.423 Info: Connected to host 127.0.0.1 on port 8083. Client number is: 29414
09/27/15 10:29:33.485 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: error' on server


Sagt Dir das was?

Viele Grüße
Horst

Moin,

Zitat von: trilu am 27 September 2015, 17:00:49
Beim HMDEV vermisse ich ein paar Sachen wie z.B. stateFormat, dass lässt sich aber über das Modul Readingsgroup lösen.

Ich nehme auch pull-requests auf github an :)

Zitat von: trilu am 27 September 2015, 17:00:49

Code Auswählen Erweitern


09/27/15 10:29:33.295 Info: Calling RPC method "updateDevice" on server 127.0.0.1.
09/27/15 10:29:33.296 Info: Connecting to host 127.0.0.1 on port 8083...
...snip...
09/27/15 10:29:33.366 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: updateDevice' on server
09/27/15 10:29:33.372 Info: Calling RPC method "error" on server 127.0.0.1.
09/27/15 10:29:33.375 Info: Connecting to host 127.0.0.1 on port 8083...
...snip...
09/27/15 10:29:33.419 Error in RPC response from 127.0.0.1. faultCode: 200 faultString: Method lookup error: No method 'Unknown method: error' on server


Das ist ein Bug in Homegear. Die "Spezifikation" für das XML-RPC-Interface von eQ-3 spezifiziert das zwar leider nicht, aber sowohl die defacto-Implementierung der Original-CCU als auch Homegear's eigene Dokumentation (https://www.homegear.eu/index.php/XML_RPC_Method_Reference#XML_RPC_Client_Functions (https://www.homegear.eu/index.php/XML_RPC_Method_Reference#XML_RPC_Client_Functions)) stimmen überein: Ein XML-RPC-Client muss nicht alle Callbacks implementieren, stattdessen wird bei Registrierung über system.listMethods() abgefragt, welche existieren, und dann nur diese verwendet. Das HMRPC-Modul hat zur Zeit nur newDevices() (Callback das Informationen über neue Geräte bekommt) und event() (Callback über das alle Events eingekippt werden), sowie einen Dummy für listDevices() der immer behauptet, wir würden gar keine Geräte kennen.

In deinen Logs versucht Homegear updateDevice() (eine Gerätekonfiguration wurde geändert) aufzurufen. Da das nicht klappt, kommt es zu einem Fehler, und einem doppelten: Homegear versucht jetzt den Fehler über error() (ein Fehler in Homegear ist aufgetreten, das ist übrigens gar nicht Teil der eQ-3-XML-RPC-Spezifikation) zu melden.

Kannst du den Bug bei Homegear melden? https://github.com/Homegear/Homegear/issues

--
Henryk Plötz
Grüße aus Berlin

Zitat von: Ralli am 22 September 2015, 05:37:39
Nach Umzug in meine Produktivumgebung lediglich folgende Informationen entgegen allem möglichen in der Testumgebung:

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        10.0.0.64 2001
   NAME       CCU2
   NR         1260
   STATE      Registered
   TYPE       HMRPC
   callbackpath /HMRPC_CCU2
   callbackurl http://x:y@10.0.0.30:8083/fhem/HMRPC_CCU2/request
   serveraddr 10.0.0.64
   serverport 2001
   Helper:
Attributes:
   callback_base http://x:y@10.0.0.30:8083/fhem
   group      Schnittstellen
   icon       hm_ccu
   room       System


... und keine Events kommen an, damit auch kein Autocreate usw.

Btw noch eine Frage: Macht Dein Modul beim Restart von fhem eigentlich eine Status-Abfrage aller HMDEV bei der definierten CCU2?

Und ebenfalls btw: Respekt für http://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ !

Hallo Henryk,

hast Du hier eine Idee? Ich komme nicht weiter.

Vielen Dank!
Bug ist gemeldet...

Ich habe die 61_HMDEV.pm mal um die FN Attribute erweitert. Lässt sich auch alles schön auswählen, aber bei den Events werden die FN Attribute nicht immer berücksichtigt.

sub
HMDEV_Initialize($)
{
  my ($hash) = @_;

  $hash->{Match}     = "^HMDEV .* .* .*";
  $hash->{DefFn}     = "HMDEV_Define";
  $hash->{ParseFn}   = "HMDEV_Parse";
  $hash->{SetFn}     = "HMDEV_Set";
  $hash->{GetFn}     = "HMDEV_Get";
  $hash->{AttrList}  = "IODev do_not_notify:0,1".
                        $readingFnAttributes;
}


Zitat von: Ralli am 03 Oktober 2015, 08:45:34
ast Du hier eine Idee? Ich komme nicht weiter.

Ich habe es jetzt zunächst so gelöst, dass ich eine weitere WEB-Instanz ohne Authentifizierung eröffne und auf die IP von der CCU2 beschränke. Damit klappt die Integration einwandfrei.

Moin,

Zitat von: trilu am 03 Oktober 2015, 10:56:05
Ich habe die 61_HMDEV.pm mal um die FN Attribute erweitert. Lässt sich auch alles schön auswählen, aber bei den Events werden die FN Attribute nicht immer berücksichtigt.

Ja, den Code der die Readings setzte hatte ich nicht angefasst und der war noch aus der Zeit vor readingsSingleUpdate()/readingsBulkUpdate(). Der hat einige special cases selbst behandelt, aber kannte natürlich $readingFnAttributes noch nicht. Ich hab das mal ersetzt jetzt, müsste nun alles gehen.

Zitat von: Ralli am 04 Oktober 2015, 11:10:57
Ich habe es jetzt zunächst so gelöst, dass ich eine weitere WEB-Instanz ohne Authentifizierung eröffne und auf die IP von der CCU2 beschränke. Damit klappt die Integration einwandfrei.

Ok, schade, aber danke für das Feedback. Ich bin mittlerweile auch zu dem Schluss gekommen, dass die Benutzung von FHEMWEB nur ein schlechter Hack ist, und ich das nochmal richtig[tm] machen muss, falls ich dazu komme. Was man halt bauen will ist eine wiederbenutzbare HTTP-Server-Komponente (die dann auch gleich die Basis von FHEMWEB sein kann).

--
Henryk Plötz
Grüße aus Berlin

prima, klappt gut!

Hallo,

klappt schon, aber der STATE (Internals) wird nach meiner Erfahrung nicht mehr gesetzt, weil es kein Attribute (Reading) "state" gibt. Habe die "alte Mimik" noch dazu gebaut und dann funktioniert es wieder wie vorher.

Gruß
Raymund

Moin,

Zitat von: Raymund am 07 Oktober 2015, 15:48:46
klappt schon, aber der STATE (Internals) wird nach meiner Erfahrung nicht mehr gesetzt, weil es kein Attribute (Reading) "state" gibt.

Das war größtenteils beabsichtigt, weil Benutzer jetzt mit sowas wie attr stateFormat ACTUAL_TEMPERATURE_2 °C ein beliebiges, für das jeweils Gerät passende spezifische Format für STATE setzen können. Korrigier' mich wenn ich falsch liege, aber deine Änderung überschreibt das jetzt wieder mit dem generischen "aller kram hier rein" (also für ein HM-TC-IT-WM-W-EU krieg' ich da insbesondere so sinnlose Readings wie PARTY_START_DAY_2, PARTY_START_MONTH_2, etc. importiert).

--
Henryk Plötz
Grüße aus Berlin

Da wirst Du Recht haben, wenn das so beabsichtigt ist. Ich habe ca. 20 HM-Devices in Betrieb und kann mit diesen Statuswerten ganz gut leben, weil ich entsprechende Regexe benutze. Aber ich versuche mal eine Abfrage, ob attr stateFormat gesetzt ist. Dann wäre die Sache abwärtskompatibel.

Gruß
Raymund

Hallo Henryk,

anbei eine abwärts kompatible Version, hoffentlich fehlerfrei soweit ;-)

Gruß
Raymund

Hallo ihr beiden,

könntet ihr einem noob mal einen Auszug aus der fhem.cfg zeigen, ich glaube, dass ich das noch nicht sauber habe und deswegen auch nicht damit zurecht komme.

Wäre echt super.
HM-TC-IT-WM-W-EU und HM-CC-RT-DN wären für mich super ;)

grüße

Ich habe jetzt mal etwas mit dem Modul gespielt. Parallel dazu ein standalone Perl Programm mit den XML-RPC Funktionen aus dem Modul erstellt. Nun habe ich einen seltsamen Effekt: Die NewDevice Callbacks von der CCU kommen korrekt an, die Events jedoch nicht. Stattdessen gibt es in /var/log/messages auf der CCU haufenweise Fehlermeldungen in der Art:

XmlRpcClient error calling event({[methodName:"event",params:{"CB1","LEQ0598158:2","ACTUAL_TEMPERATURE",20.200000}],[methodName:"event",params:{"CB1","LEQ0598158:2","ACTUAL_HUMIDITY",52.000000}],[methodName:"event",params:{"CB1","

Die Meldung ist auch im messages File hinten abgeschnitten wie im Beispiel oben. Also entweder auf Server-Seite wird die Event Callback nicht aufgerufen, weil XML-RPC meint, die registrierten Methoden (Callbacks) passen nicht oder es liegt daran, dass die CCU bei ihrem Event-Call offensichtlich mehrere Events in einem Array übergibt (Feature system.multicall). Unterstützt RPC::XML system.multicall bzw. muss man es in irgendeiner Option erst aktivieren?


Wie gesagt: ich bekomme nur die Devices per NewDevice. Prinzipiell funktioniert also die Kommunikation. Nur die Events gehen nicht.

Moin,

Zitat von: zap am 18 Oktober 2015, 17:38:57
Ich habe jetzt mal etwas mit dem Modul gespielt. Parallel dazu ein standalone Perl Programm mit den XML-RPC Funktionen aus dem Modul erstellt. Nun habe ich einen seltsamen Effekt: Die NewDevice Callbacks von der CCU kommen korrekt an, die Events jedoch nicht.

Zitat von: zap am 18 Oktober 2015, 17:38:57
Also entweder auf Server-Seite wird die Event Callback nicht aufgerufen, weil XML-RPC meint, die registrierten Methoden (Callbacks) passen nicht oder

Das hat nicht mit dem Modul zu tun. Auch kenne ich deinen Code nicht. Nimm halt wireshark und schau den Netzwerkverkehr an, um nachzugucken, was (oder was nicht) passiert.

--
Henryk Plötz
Grüße aus Berlin

Danke für den Tipp. Ein tcpdump des Netzwerkverkehrs zwischen CCU und meinem Raspberry brachte die Erleuchtung. Ich hatte in der Callback Funktion für Events als letztes Statement einen print Befehl drin. Die Perl-Funktion hat den Wert des Print-Ausdrucks zurückgegeben und das hat durchgeschlagen bis zur CCU. Und die CCU hat das als Fehler gewertet.
Blöde Eigenart von Perl. Ich hasse diesen Interpreter-Mist fast noch mehr als Java. Jedenfalls läuft jetzt alles wie es soll.

BTW: Ich vermute, dass das Signature Attribut bei add_method() überhaupt keine Bedeutung hat. Der Methodname und die Referenz zum Callback Handler sind wichtig.

Was mich immer noch wundert: Vom Init der Schnittstelle bis zur Übertragung der NewDevice Meldungen von der CCU vergehen manchmal bis zu 3 Minuten. Hängt vermutlich mit irgendwelchen Rerfresh-Zyklen der CCU zusammen.

Hallo Henryk,

ich habe jetzt das von Dir überarbeitete Modul eine Zeit lang getestet. Ich habe eine CCU2 mit einigen Sensoren und Aktoren, beim Init erzählt sie was von 350 Spezifikationen.

Leider wird auch mit diesem Modul der in fhem integrierte Webserver überlastet, wenn bspw. durch die Thermostate ein gewisses Grundrauschen auf der RPC-Schnittstelle vorhanden ist. Nachvollziehbar bricht dann nach ca. 10-12 Minuten Dauerfeuer auf der Schnittstelle der Connect ab - ich kann mit netstat sehen, dass keine Callback-Verbindung mehr von der CCU2 zu fhem besteht. Nach dem Reconnect geht's dann so weiter. Während die Events noch ankommen, gönnt sich fhem auch sehr deutliche Wartezeiten beim Zugriff auf das Frontend - obwohl ich für die CCU2 eine exklusive Web-Instanz definiert habe.

Ich bin nun mal auf das Original-Modul, welches mal von Dirk gepatched wurde, zurückgegangen und habe dort für meinen Anwendungszweck minimale Änderungen in HMDEV.pm durchgeführt. Das Modul läuft bei mir ohne Verbindungsabbruch, dafür aber mit dem auch von Dir bereits festgestellten Ausbremsen des Gesamtsystems.

Nochmal hallo Henryk,

ich habe in Dein 60_HMRPC.pm / 60_HMDEV.pm mal noch die Möglichkeit des statusRequest eingebaut.

Bei Aufruf von

set MeinFhemDef statusRequest

wird der in der CCU(2) bekannte Status von den bei mir genutzten Dimmern, Schaltern und Fenster-Sensoren und RTs geholt, und die entsprechenden Readings werden gesetzt. Ist vielleicht nicht schön programmiert, funktioniert aber.

Jedes HMDEV-Device hat bei mir ein userReading state, welches dann automatisch den state bzw. STATE entsprechend setzt.

Neuer Sachstand:

Henryk's HMRPC-Modul mit der von mir eingebauten Ergänzung läuft nun einwandfrei.

Die von mir erwähnte Überlastung hatte seine Ursache darin, dass ab einer bestimmten Menge der RPC-Callbacks ohne ergänzende Einstellungen in den Devices einfach zu viele Events generiert wurden und so fhem in der Abarbeitung einerseits der RPC-Einwürfe und andererseits der Events nicht mehr hinterher kam - daraufhin hat dann die CCU regelmäßig die Bedienung des Clients (fhem) bis zum periodischen Re-Init eingestellt.

Es ist also ab einer nicht weiter einzugrenzenden Menge an Devices, die regelmäßige RPC-Callbacks von der CCU nach sich ziehen, unabdingbar, dass sinnvoll mit den Attributen event-on-change-reading sowie event-on-update-reading gearbeitet wird, um die Event-Generierung einzuschränken.

Die RPC Request Geschichte hat mich jetzt echt Nerven gekostet. Habe in HMCCU die Abfrage aller Datenpunkte eines Kanals auf RPC getParamset umgestellt. Funktioniert auch, allerdings nur in einigen Fällen. Wenn jemand selbst damit experimentieren möchte, sollte er folgendes beachten:

• die RPC Schnittstelle der CCU unterstützt nur originäre Homematic Interfaces (z.B. keine CUxD Devices)
• die Methode getParamset liefert bei einigen Kanälen (z.B. Kanal 2 des Wandthermostaten) reproduzierbar falsche Werte
• die Methode getParamset funktioniert bei manchen Kanälen gar nicht (z.B. Kanal 0 des Wandthermostaten). Rückmeldung ist "Failure -1".

Bin jetzt jedenfalls wieder zurück zu XML-API gewechselt. Mittelfristig werde ich auf die eingebaute JSON API umstellen, die zumindest CUxD unterstützt.

Hallo zap,

danke.

getParamset funktioniert ja nur mit der Angabe, welches Paramset Du haben möchtest - und manche der Kanäle bieten nicht alle Paramsets. Der Thermostat bspw. hat das Paramset VALUES grds. nur auf Kanal 4.

Zitat von: Ralli am 13 November 2015, 07:53:29
getParamset funktioniert ja nur mit der Angabe, welches Paramset Du haben möchtest - und manche der Kanäle bieten nicht alle Paramsets. Der Thermostat bspw. hat das Paramset VALUES grds. nur auf Kanal 4.

Der Wandthermostat HM-TC-IT-WM-W-EU hat in den Kanälen 0,1 und 2 jeweils das Paramset VALUES. Trotzdem arbeitet die Abfrage nur beim Kanal 1 korrekt. Bei 0 kommen falsche Werte, bei 2 kommt eine Fehlermeldung.

Ein Blick in /var/log/messages brachte jetzt aber etwas Licht ins Dunkel: "HSSParameter::GetValue() id=PARTY_MODE_SUBMIT failed getting physical value." Laut Doku kann RPC nur mit logischen Geräten. Ich vermute, hier liegt das Problem.

Fazit: RPC ist nur sehr eingeschränkt tauglich.

Zitat von: Ralli am 01 November 2015, 15:08:03
Nochmal hallo Henryk,

ich habe in Dein 60_HMRPC.pm mal noch die Möglichkeit des statusRequest eingebaut.

Bei Aufruf von

set MeinFhemDef statusRequest

wird der in der CCU(2) bekannte Status von den bei mir genutzten Dimmern, Schaltern und Fenster-Sensoren und RTs geholt, und die entsprechenden Readings werden gesetzt. Ist vielleicht nicht schön programmiert, funktioniert aber.

Jedes HMDEV-Device hat bei mir ein userReading state, welches dann automatisch den state bzw. STATE entsprechend setzt.

Hi Ralli,
wollte gerade mal testen, aber irgendwie macht es keinen Unterschied.
Bekomme auf eine Anfrage zum Status nur sowas zurück: invalid set call HMDEV_JEQ0276495 statusRequest

Viele Grüße
Horst

Hallo Horst,

worauf setzt Du den statusRequest denn ab? Der muss auf ein definiertes Device vom Type HMDEV abgesetzt werden.

Was steht im Log?

Bei mir funktioniert das einwandfrei und wird täglich mehrfach genutzt.

Ok, habs gefunden :-)
else {
Log 2,"HMRPC $a[0] statusRequest $a[1]: failed, don't know type $typ";
return undef;


2015.11.23 12:08:21 2: HMRPC hmrf statusRequest JEQ0276495: failed, don't know type BC-TC-C-WM-2
2015.11.23 12:22:32 2: HMRPC hmrf statusRequest JEQ0276495: failed, don't know type BC-TC-C-WM-2


Na, dann passt ja alles.

Der Status kann nur von den (mir) bekannten Devices ausgelesen, interpretiert und in die Readings umgewandelt werden.

Mach mal ein list von dem Device.

fhem> list HMDEV_JEQ0276495

Internals:
   CHANGED
   DEF        JEQ0276495
   IODev      hmrf
   LASTInputDev hmrf
   MSGCNT     460
   NAME       HMDEV_JEQ0276495
   NR         370
   STATE      T: 19.2 °C, D: 19.0 °C
   TYPE       HMDEV
   hmaddr     JEQ0276495
   hmdevtype  BC-TC-C-WM-2
   hmrf_MSGCNT 460
   hmrf_TIME  2015-11-23 18:15:25
   Readings:
     2015-11-23 18:15:25   ACTUAL_TEMPERATURE_1 19.2
     2015-11-23 17:06:15   CONTROL_MODE_1  0
     2015-11-23 18:15:25   RSSI_DEVICE     -68
     2015-11-23 18:15:25   SET_TEMPERATURE_1 19
   Hmdevinfo:
     ADDRESS    JEQ0276495
     FAMILY     4
     FIRMWARE   1.3
     FLAGS      1
     ID         12
     INTERFACE  VMC3446724
     PARENT
     PHYSICAL_ADDRESS 202637
     RF_ADDRESS 202637
     ROAMING    0
     RX_MODE    2
     TYPE       BC-TC-C-WM-2
     TYPE_ID    768
     VERSION    1
     CHANNELS:
       0
       1
       4
     CHILDREN:
       JEQ0276495:0
       JEQ0276495:1
       JEQ0276495:4
     PARAMSETS:
       MASTER
Attributes:
   IODev      hmrf
   alias      Thermostat
   devStateStyle style="text-align:left"
   event-on-change-reading ACTUAL_TEMPERATURE_1,SET_TEMPERATURE_1,CONTROL_MODE_1
   group      Heizung
   room       31_Mansarde
   sortby     0
   stateFormat { sprintf("T: %0.1f °C, D: %0.1f °C", ReadingsVal( $name, 'ACTUAL_TEMPERATURE_1', 0 ), ReadingsVal( $name, 'SET_TEMPERATURE_1', 0 ) ) }




Hast du eine Ahnung wie ich an die weiteren Readings vom Device komme? Hinter JEQ0276495:1 verbirgt sich auch noch Einiges mehr
ACTUAL_TEMPERATURE      
AUTO_MODE   
BOOST_MODE
BOOST_TIME_PERIOD      
COMFORT_TEMPERATURE      
CONTROL_MODE         
ECO_TEMPERATURE      
MANU_MODE      
MAX_TEMPERATURE      
PARTY_STOP_DAY      
PARTY_STOP_MONTH      
PARTY_STOP_TIME      
PARTY_STOP_YEAR      
PARTY_TEMPERATURE      
SET_TEMPERATURE      
SHOW_SET_TEMPERATURE      
WINDOW_OPEN_TEMPERATURE

Vom Grundsatz her empfehle ich, das Device direkt mit JEQ0276495:1 zu definieren und darauf den statusRequest abzusetzen. Dann schaust Du, welchen Typ er dafür ermittelt/angibt.

Sodann nimmst Du Dir den Quelltext von 60_HMRPC.pm und modifizierst / ergänzt folgenden Block:


case "CLIMATECONTROL_RT_TRANSCEIVER" {
@readingslist=("SET_TEMPERATURE","ACTUAL_TEMPERATURE","VALVE_STATE","BATTERY_STATE");
}


um


case ["CLIMATECONTROL_RT_TRANSCEIVER","DEIN_ERMITTELTER_TYP"] {
@readingslist=("SET_TEMPERATURE","ACTUAL_TEMPERATURE","VALVE_STATE","BATTERY_STATE");
}


und in der @readingslist um die zusätzlichen Datenpunkte bzw. Readings, die bei einem statusRequest neu gesetzt werden sollen.

Wenn es wegen dem fehlenden VALVE_STATE bei diesem Device Probleme gibt, duplizierst statt modifizierst Du den Block, änderst CLIMATECONTROL_RT_TRANSCEIVER auf den von Dir ermittelten Typ und führst in der @readingslist (nur) die passenden Datenpunkte/Readings auf.

Vielen Dank - brauche aber nochmal Hilfe :-)
Ich habe das Device jetzt mal mit Kanal angelegt, jetzt hat aber der Kanal noch zwei Listen (Paramsets) - Master and Value, wie komme ich da dran?
Internals:
   CFGFN
   DEF        JEQ0276495:0
   IODev      hmrf
   LASTInputDev hmrf
   MSGCNT     49
   NAME       HMDEV_JEQ0276495_0
   NR         9276
   STATE      ???
   TYPE       HMDEV
   hmaddr     JEQ0276495:0
   hmdevtype  MAINTENANCE
   hmrf_MSGCNT 49
   hmrf_TIME  2015-11-24 12:00:22
   Readings:
     2015-11-24 12:00:22   RSSI_DEVICE     -65
   Hmdevinfo:
     ADDRESS    JEQ0276495:0
     AES_ACTIVE 0
     CHANNEL    0
     DIRECTION  0
     FAMILY     4
     FLAGS      3
     ID         12
     INDEX      0
     LINK_SOURCE_ROLES
     LINK_TARGET_ROLES
     PARENT     JEQ0276495
     PARENT_TYPE BC-TC-C-WM-2
     TYPE       MAINTENANCE
     VERSION    1
     PARAMSETS:
       MASTER
       VALUES
Attributes:
   IODev      hmrf
   group      Thermostat
   room       31_Mansarde

:0 ist falsch. Bitte mit :1 definieren! Und das Paramset Value wird ja letztendlich beim statusRequest abgefragt und ausgewertet.

ich verzweifle langsam :-)
Das mit 0 und 1 ist schon klar, in 0 steht nur auch das Wochenprogramm...

Irgendwie geht der statusRequest nicht mehr durch

Das schicke ich über Telnet oder Web
set HMDEV_JEQ0276495_1 statusRequest

und das bekomme ich zurück
invalid set call HMDEV_JEQ0276495_1 statusRequest

2015.11.24 17:34:58 4: FHEMWEB:192.168.6.2:14939 POST /fhem&room=Unsorted&cmd=set+HMDEV_JEQ0276495_1+statusRequest; BUFLEN:0
2015.11.24 17:34:58 4: name: /fhem&room=Unsorted&cmd=set+HMDEV_JEQ0276495_1+statusRequest / RL:1130 / text/html; charset=UTF-8 / Content-Encoding: gzip


kann es sein das der Syntax nicht stimmt?

Hallo Horst,

Asche auf mein Haupt. Es bedarf auch einer Änderung in 60_HMDEV.pm, die ich nicht mehr im Kopf hatte.

Bitte die Zeile 113


return "invalid set call @a" if(@a != 3 && @a != 4);


wie folgt modifizieren:


        return "invalid set call @a" if(@a != 3 && @a != 4 && $a[1] ne "statusRequest");


Hallo,

das Folgende betrifft z.B. das Anhalten von Rollläden mit dem STOP-Befehl:

ich glaube festgestellt zu haben, dass es HM-seitig Unterschiede bei der Auswertung von booleschen Werten gibt, weshalb z.B. set <NAME> STATE_1 true geht, set <NAME> STOP_1 true aber nicht. Somit ließen sich Rollläden nicht anhalten.

Ich habe bei mir in der 60_HMRPC.pm eine entsprechende Anpassung gemacht nach der es nun klappt. Wenn das jemanden interessiert, dann sollten wir das abgestimmt einbauen und testen. Ich blicke gerade nicht mehr durch, welche Version aktuell ist  ;)

Gruß
Raymund

Bei STATE Werten wird teilweise 0/1 und teilweise true/false verwendet. RPC Events verwenden z.B. immer 0/1. Wie es bei RPC Set Befehlen ist, weiß ich nicht. Deshalb im Zweifel HM-Script oder JSON-API statt RPC.

Zitat von: zap am 27 November 2015, 11:54:27
Bei STATE Werten wird teilweise 0/1 und teilweise true/false verwendet. RPC Events verwenden z.B. immer 0/1. Wie es bei RPC Set Befehlen ist, weiß ich nicht. Deshalb im Zweifel HM-Script oder JSON-API statt RPC.

Klappt hier mit gut 20 Devices ohne Zweifel seit einem Jahr. Jetzt eben auch mit STOP. :)

@Ralli - vielen Dank, jetzt klappt es.

Ich habe das Modul zusammen mit Homegear in Betrieb und für einfache Schaltaufgaben komme ich jetzt damit klar.
Interessant wird es bei komplexeren Sachen, wie Wochenprogramm für Thermostate

ENDTIME_FRIDAY_1
ENDTIME_FRIDAY_10
ENDTIME_FRIDAY_11
ENDTIME_FRIDAY_12
ENDTIME_FRIDAY_13
...
TEMPERATURE_FRIDAY_1
TEMPERATURE_FRIDAY_10
TEMPERATURE_FRIDAY_11
TEMPERATURE_FRIDAY_12
TEMPERATURE_FRIDAY_13
...


Im Normalfall werden diese Variablen gesetzt und mit einem putParamSet ans Device übertragen.
So wie ich das RPC Modul verstehe, wird hier jeder einzelne Wert mit setValue übertragen. Was ein sofortiges Update ans Device veranlasst.

Hast Du eine Idee wie man das lösen könnte?

Viele Grüße
Horst

Hallo Horst,

fein, dass es jetzt klappt.

... bisher nicht, da ich diese im Regelfall eher selten zu ändernden Dinge aus der CCU2 heraus mache. Ich fürchte, dafür wäre eine größere Modifikation notwendig.

@trilu

putParamSet ist wohl schon implementiert: https://groups.google.com/forum/#!topic/fhem-users/xKMH_4ZoMNA

Siehe auch in der 60_HMRPC, sub HMRPC_Set. Habe es aber noch nicht getestet.

Gruß
Raymund

Hatte ich auch entdeckt, bin gerade am testen

Also in henryks HMRPC Set gibt es zwar einen putparamset Call, allerdings setzt der nur einen Wert gleichzeitig.
Das müsste man noch ausbauen ...
Aber wie stellt Ihr Euch eigentlich den Aufruf eines solchen Set Befehls in FHEM vor?

Sowas in der Form:

set xy paramset Datapoint Value Datapoint Value ...

Nur so als Anregung für mich ;-)

Zitat von: Raymund am 30 November 2015, 18:57:36
putParamSet ist wohl schon implementiert: https://groups.google.com/forum/#!topic/fhem-users/xKMH_4ZoMNA
Siehe auch in der 60_HMRPC, sub HMRPC_Set. Habe es aber noch nicht getestet.

Im Code ist nur (rudimentär) die Möglichkeit eingebaut, putParamset zu nutzen:


my $paramset={$a[3]=>$a[4]};

$ret=$hash->{client}->simple_request("putParamset",$a[1],$a[2],$paramset);


Eine komfortable Möglichkeit, wie sie wahrscheinlich Horst (trilu) vorschwebt, ist damit m.E. noch nicht realisierbar. Daher: um bspw. die gleiche Funktionalität wie im Modul CUL_HM einzubauen, dürften deutliche Modifikationen/Ergänzungen notwendig sein.

Zitat von: trilu am 30 November 2015, 12:49:09

Code Auswählen Erweitern


ENDTIME_FRIDAY_1
ENDTIME_FRIDAY_10
ENDTIME_FRIDAY_11
ENDTIME_FRIDAY_12
ENDTIME_FRIDAY_13


Die Verwaltung der einzelnen Zeiten/Werte müsste hier im FHEM Modul erfolgen, da die Thermostate keine Datenpunkte dafür anbieten (und nur die können ja per setvalue/putparamset gesetzt werden.
Sehr aufwändig.

Klar bietet der Thermostat diese Datenpunkte, die sind nur nicht sichtbar, weil im Master Set. Das MDDEV liest derzeit aber nur VALUE nach Channel aus.
Ich bin mir noch nicht ganz sicher, wie ich es eigentlich gerne möchte - Man kann ja derzeit ein Gerät, oder eine Reihe von Geräten nach Channel definieren.

Also entweder etwas wie HMDEV_JEQ0276495
oder eine Geräteliste wie HMDEV_JEQ0276495:0, HMDEV_JEQ0276495:1 usw.

Von der Übersichtlichkeit auf erster Ebene würde sich die generelle Definition anbieten (HMDEV_JEQ0276495), es gibt nur ein Gerät mit allen Parametern im Bauch.
Allerdings wäre die Readingsliste bei einem Thermostat ziemlich lang und man müsste allen Readings ein Flag bzgl Kanal und MASTER/VALUES mitgeben.

Die Alternative, Geräte werden mit :0, :1, etc angelegt - damit wäre es auf erster Ebene unübersichtlicher, aber die Readingsliste würde sich in Grenzen halten und bräuchte nur das Flag bzgl MASTER/VALUE.

Was meint ihr?

Hat beides sein Für und Wieder.

Ich habe mich entscheiden, auf den jeweiligen Channel zu gehen - der Übersichtlichkeit halber und weil die verschiedenen Channel teilweise auch verschiedenen Räumen zugeordnet werden.

Der für mich einzige Nachteil besteht darin, dass ein UNREACH auf :0 empfangen wird und so ins Leere läuft. Da überlege ich aber zur Zeit, ob ich diesen Spezialfall nicht im HMDEV-Code abfange und auf jeden Channel, welches zu dem entsprechenden Device gehört, gebe.

Die Thermostate sind ebenfalls recht spezielle Devices, bei denen die jeweiligen Kanäle (oder zumindest Teile daraus) m.E. durchaus in einem einzigen fhem-Device abgebildet sein sollten. Es kommt halt immer darauf an, was man für einen Ansatz wählt. Mein Ansatz besteht nicht darin, die Wochenprogramme zwingend über fhem ändern zu lassen.

Shit, jetzt bin ich so schlau wie vorher :-)

Derzeit stelle ich das Wochenprogramm auch nicht über FHEM, aber es hätte was, das über ein Modul der Tablet UI zu machen.
Da ist es dann aber egal, ob alles in ein Device oder mehrere geht. Momentan tendiere ich auch zu mehreren Devices.

Wozu brauchst Du den UNREACH in allen Kanälen?

Stelle Dir einen Doppel-Schalter-Aktor vor. Der eine Kanal ist für das Licht in einem Raum, der andere Kanal für das Licht in einem anderen Raum. Also sind für mich grds. :1 und :2 interessant. Aber in :0 stehen für mich (in fhem) grds. keine interessanten Dinge drin - ausser, das Device ist nicht erreichbar. Aber nur dafür will ich nicht noch extra ein :0 in fhem definieren. Da gebe ich lieber dann, wenn das Problem auftritt, ein UNREACH in fhem an die Kanäle des betroffenen Devices weiter.

Bei einem Rolladen-Aktor ist es gleich. :1 ist interessant für mich, :0 normalerweise nicht - nur bei einem UNREACH.

ich schau mal was sich machen lässt. hat es eigentlich einen grund warum du die readings spezifizierst?
case ["SHUTTER_CONTACT","ROTARY_HANDLE_SENSOR"] {
@readingslist=("STATE","LOWBAT");
}


man könnte doch alle abfragen?

2015.12.01 11:27:05 0: HMRPC hmrf statusRequest JEQ0276495:0: TYPE is MAINTENANCE
2015.12.01 11:27:06 0: HMRPC hmrf $ret = {
         'CONFIG_PENDING' => 0,
         'RSSI_PEER' => '0',
         'BOOT' => 0,
         'RSSI_DEVICE' => '-69',
         'STICKY_UNREACH' => 0,
         'LOWBAT' => 0,
         'UNREACH' => 0
       };

2015.12.01 11:27:06 0: HMRPC hmrf got 7 keys, @keylist = (
             'CONFIG_PENDING',
             'RSSI_PEER',
             'BOOT',
             'RSSI_DEVICE',
             'STICKY_UNREACH',
             'LOWBAT',
             'UNREACH'
           );

2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading CONFIG_PENDING to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading RSSI_PEER to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading BOOT to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading RSSI_DEVICE to -69
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading STICKY_UNREACH to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading LOWBAT to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: updating Reading UNREACH to 0
2015.12.01 11:27:06 0: HMRPC hmrf statusRequest JEQ0276495:0: succesful


Mir ging es wirklich nur um einen statusRequest - und nicht um ein getConfig. Darum habe ich nur die für den Betrieb wesentlichen Datenpunkte/Readings hier abgefragt - wie gesagt, im Hinterkopf behalten, dass ich normalerweise kein :0 habe.

Bei einem getConfig würde ich hingegen tatsächlich immer das :0 mit allen Datenpunkten und alle verfügbaren Datenpunkte aller Channels abfragen und entsprechend in den Readings aktualisieren. Das habe ich aber bisher eben nicht implementiert, da ich keinen Anwendungszweck dafür habe ;).

Du hast recht, ich baue gerade ein getConfig :-)

Ich habe meine 60_HMDEV.pm bezüglich des thematisierten UNREACH auf alle Channels erweitert. Quick and dirty nach Zeile 83:


      if($msg =~ /HMDEV ([A-Z]{3}[0-9]{7}):[0-9]{1,2} UNREACH ([01])/) {
      fhem("setreading DEF=$1:..? unreachable $2");
      }


Edit: Funktioniert aber bewusst nur, wenn der Channel (also normalerweise :0), welcher UNREACH produziert, nicht definiert ist.

Ich habe jetzt einen getConfig eingebaut, der VALUES als auch MASTER ausließt. Der statusRequest sollte weiterhin funktionieren :-)
Ein Device sollte als Channel angelegt sein, also in der Form mit :0, :1

Danach in der Kommandozeile ein set HMDEV_<was auch immer> getConfig
danach sollte in den readings das komplette Channelset enthalten sein.

Ich werde mich die Tage mal an das putParamset machen.

Sehr schön - die Logging-Funktion müsste noch kosmetisch modifziert werden, damit klar ist, dass die Einträge während des getConfigs erfolgen.

Ich glaube, es ist an der Zeit, tatsächlich eine gemeinsame Weiterentwicklung über git oder besser noch hier in SF zu machen.

m.E. ist RPC (alleine) der falsche Weg. RPC macht Sinn wenn es darum geht, in FHEM automatisch Updates / Events von der CCU zu erhalten. Beim direkten Setzen/Auslesen von Werten hat es aber zu viele Einschränkungen:

- Es werden nur BidCos Devices unterstützt (kein CUxD etc).
- Bei einigen Kanälen/Datenpunkten liefert RPC getvalue / getparamset reproduzierbar falsche Werte
- Es können keine CCU Variablen ausgelesen / verändert werden
- Es können keine CCU Programme / Scripts ausgeführt werden

Als Alternative empfiehlt sich das in der CCU eingebaute JSON-API oder direkt HM-Script. Da auch JSON einige (wenige) Nachteile hat, ist HM-Script meine präferierte Schnittstelle.
Ich würde ggf. neben HM-Script JSON verwenden, um das Anlegen von Variablen in der CCU umzusetzen und ParamSets zu lesen / zu schreiben. Das wäre aber der einzige Anwendungsfall.
JSON bietet interessanterweise auch eine Möglichkeit an, Events mit Updates für Datenpunkte zu erhalten. Diese unterstützen angeblich auch nicht BidCos Devices (im Gegensatz zu RPC). Leider habe ich das bisher nicht zum Laufen bekommen.

Hallo zap,

wie Du weißt, finde ich, dass die Kombination - möglichst sogar in einem einzigen Modul vereint - den perfekten Kompromiss darstellt.

Wichtig ist mir, dass nur die offiziellen vom Hersteller bereitgestellten Schnittstellen genutzt werden - sodass ich letztendlich im Falle eines Falles einfach nur die CCU gegen eine andere austauschen muss, Backup zurückspielen und fertig. Bei der "Kommunikationsschnittstelle" mit rudimentärsten Automatismen, wofür ich die CCU nunmal ausschließlich einsetze, möchte ich nicht auf den Support von Dritten angewiesen sein. (also CCU2 macht bei mir die Kommunikation und steuert die OU-LEDs; Komfort nur im Sinne von Rollo anziehen, wenn Fenster auf Kipp und wieder runter, wenn zu; alles andere an Komfortfunktionen macht fhem.)

Nun habe ich allerdings meine komplette fhem-Installation zur Zeit bis auf wenige Ausnahmen auf HMRPC umgestellt und habe dabei darauf geachtet, dass die von mir maßgeblich verwendeten fhem-Befehle sowohl bei HMRPC den CUL_HM entsprechen.

Ich müsste nun nahezu alles umstellen, wenn ich auf HMCCU schwenke, da hier ein "anderer Dialekt" verwendet wird.

Und ich nutze keine CCU sondern Homegear, habe darin MAX Heizungsregler, Thermostate, etc gemischt mit HM Komponenten für Licht und Rollo.
Soweit ich gesehen habe, gibt es ja ein weiteres Modul wo der Ansatz der Json API für die CCU verfolgt wird. So wirklich rund läuft das aber wohl auch noch nicht.
Gemeinsame Weiterentwicklung fände ich auch gut. Ist allerdings auch die Frage was Henryk mit seinem Modul vor hat :-)

Um vielleicht mal ein wenig Werbung für Homegear zu machen - es ist klasse was das Ding schon kann. MAX, HM, PHILIPS, INSTEON, SONOS. Neue Funktionalitäten werden über eine XML Datei mit Script/PHP bereitgestellt. Interface zur Außenwelt über HMRPC oder mqqt. Was fehlt ist eine nette und resourcenschonende Oberfläche. Ich hatte Openhab und IO broker getestet, aber so wirklich hat mich keins überzeugt.

FHEM ist halt doch klasse, aber Homegear als Middleware ist auch nicht zu verachten.

Anscheinend nichts. Ich hatte ihn vor einiger Zeit mal angeschrieben und keine Reaktion bekommen. Und hier ist ja auch kein Lebenszeichen mehr von ihm.

wenn wir es weiterentwickeln wollen, müssen wir auch aufräumen :-)
und uns überlegen ob wir zwei module oder eins wollen und welche funktionen wo hinkommen

momentan ist es ein wenig spagetti....

Also meines Wissens gibt es mittlerweile 4 Module / Entwicklungen in Sachen CCU Anbindung:

1. Das alte Modul HMRPC von Oliver Wagner. Status: wird nicht mehr weiter entwickelt.
2. Das neue Modul HMRPC von hendryk. Baut auf dem alten auf. Status: ?
3. Eure Modifikationen von HMRPC (2). Status: z.T. sehr individuelle Anpassungen für Einzelfälle
4. Mein Modul HMCCU. Status: wird weiter entwickelt, da ich es selbst benutze

Welche dieser Entwicklungen sollen nach Eurer Meinung zusammen gelegt werden?
@trilu: mir ist kein Modul bekannt, das JSON verwendet.

Nun zu den mehr oder weniger offiziellen Schnittstellen der CCU. Da gibt es:

1. RPC (offiziell, dokumentiert). Problem: Eingeschränkte Funktionalität. Im Prinzip auf Datenpunkte von BidCos-Devices beschränkt
2. JSON (offiziell, dokumentiert). Problem: Event-Subscription funktioniert nicht (zumindest habe ich bisher kein funktionierendes Beispiel gefunden)
3. HM-Script (dokumentiert, aber HTTP-Aufrufe der CCU sind "halb-offiziell"). Bietet mit kleinen Einschränkungen die größte Flexibilität.

Dann gibt es noch Middlewares:

1. MQTT (Entwicklung CCU seitig durch Oliver Wagner (s.o.), Modul für FHEM vorhanden). Das ist sehr viel versprechend. Wollte ich mir bei Gelegentheit mal anschauen, da man vermutlich nur konfigurieren, nicht programmieren müsste.
2. HMCompanion (ebenfalls Oliver Wagner). Status: Wurde durch MQTT abgelöst.
3. Homegear: eigentlich keine echte Middleware sondern CCU Alternative. Da müsste man dann auch andere Lösungen wie IPSymcon betrachten

Hallo,

ich habe das Modul mal weiter gepimpt.

Änderungen:

1) Es ist die Übermittlung von Paramsets mit mehreren Wertepaaren möglich
2) getConfig auf ein Device ist möglich
3) req listBidcosDevices wird ausgewertet

Zu 1)
Bislang war es nur möglich, z.B. ein


set Schalter STATE true


oder ein


set Schalter MASTER LOGGING 0


durchzuführen. Dabei wurde im ersten Fall intern ein setValue durchgeführt und im zweiten Fall ein putParamset, allerdings war das begrenzt auf ein Wertepaar (hier im Beispiel MASTER).

Nun ist es möglich, auch mehrere Wertepaare direkt zu übermitteln. Beispiel:


set Schalter VALUES ON_TIME 30.0 STATE true


Zu 2)
Dazu werden nun aus dem Paramset MASTER des Devices einige Informationen von der CCU abgeholt und in die Readings geschrieben. Hat man von einem Doppel-Schaltaktor bspw. einen Kanal unmittelbar als HMDEV-Device definiert, so wird bei dem "Vater" von diesem Device das Paramset MASTER ausgelesen.

Besonderheit für Dimmer:

Es ist nicht möglich, für einen Dimmer alle erforderlichen Werte auf einmal in einem putParamset zu übermitteln, so dass diese auch für die nächste Schaltaktion genutzt werden. Daher ist hier eine Besonderheit eingebaut:

Ein


set Dimmer dim-with-timer ON_TIME x RAMP_TIME y LEVEL z


wird intern auf die Übermittlung eines Paramsets für die ersten beiden Werte und auf ein setValue für den Dim-Level aufgesplittet. Die Reihenfolge der übergebenen Parameter ist bei diesem Befehl unbedingt einzuhalten! Als Werte für x un y sind Float zu nutzen (Einheit ist Sekunden also 300.0 für 300 Sekunden), als Wert für z ein Float, also 0.01 bis 1.0 (unbedingt mit Punkt und ggf. gefolgt von 0, Einheit ist Prozent - also 0.01 ist 1 Prozent, 1.0 ist 100 Prozent, 0.5 ist 50 Prozent).

Zu 3)
Sofern HM-CFG-LAN oder/und HM-LAN-Gateways als HMDEV-Device definiert sind, können bspw. durch periodische Abfrage auf die definierte CCU(2) mit set CCU2 req listBidcosInterfaces alle 10 Minuten die Readings für Duty Cycle aktualisiert werden; damit kann dann ein SVG erzeugt werden.

Wie immer gilt: Verwendung der modifizierten Module auf eigene Gefahr. Bei mir laufen sie einwandfrei.

Hi Ralli,
hab mich auch die letzten Wochen ein bisschen mit dem Modul gespielt und wie es immer so ist, ein wenig den Fokus verloren.
Hatte irgendwann das Problem, das zu viele Devices in meiner Config waren und da XMLRPC nicht unbedingt schnell ist, ging die Systemlast hoch und FHEM kam nicht mehr hinterher mit der Verarbeitung. Deshalb habe ich angefangen das Modul auf RPCBIN umzuschreiben - schaus Dir mal an, bin aber noch nicht fertig...
Bisher ist das Devicehandling nur rudimentär implementiert. Hänge noch an der Schnittstelle zu Homegear.
Viele Grüße
Horst

Interessant (RPCBIN). Ich bräuchte noch sowas, um HMCCU and CUxD anzukoppeln, das leider nur RPCBIN spricht.

In Deinem Fall sieht die Kette so aus? CCU2 - Homegear - FHEM ??

Ich befürchte nur, schneller wird das auch nicht sein. Der lahme Webserver von FHEM ist hier der limitierende Faktor. Ich habe mittlerweile 45 Homematic Devices in FHEM. Ich denke, mit dem eingebauten Webserver geht da gar nichts mehr.

@trilu

Hallo Horst,

das Problem ist nach meiner Meinung nicht die RPC-Schnittstelle - die ist auch bei meinen vielen Devices schnell genug. Das Problem ist, dass bei dem verwendeten Modul grundsätzlich jede Änderung eines Readings ja einen Event produziert, weil kein Default für ein event-on-change-reading oder ein event-on-update-reading existiert. Setzt man diese zwei Attribute konsequent und natürlich sinnvoll bei den eingebundenen Devices ein, gibt es absolut kein Problem mehr mit der Performanz.

Ich habe ca. 100 Devices eingebunden. Keine Probleme (mehr).

Ich habe am Wochenende noch was für rssiInfo und getServiceMessages eingebaut. Das teste ich aber noch intern.

naja, ich hole mir von homegear auch noch die beschreibung der events :-)
bzw. die inhalte für die readings die auf listen basieren...

mir ist aufgefallen, dass ein listdevice für 30 geräte über xmlrpc mit dekodierung etwa 3 sekunden dauert, mach ich es über rpcbin bin ich im 0 komma bereich

ZitatIn Deinem Fall sieht die Kette so aus? CCU2 - Homegear - FHEM ??

Ne, nicht ganz - Homegear an FHEM
und/oder Homegear an CCU2
Damit bekomme ich Sonos und MAX Geräte dargestellt als wären es Homematic Geräte

ZitatIch befürchte nur, schneller wird das auch nicht sein. Der lahme Webserver von FHEM ist hier der limitierende Faktor. Ich habe mittlerweile 45 Homematic Devices in FHEM. Ich denke, mit dem eingebauten Webserver geht da gar nichts mehr.

Ich nutze nicht den Webserver von FHEM, weil binary - ich nutze die Mechanik von Telnet, bzw halt die socket communication von Perl.

Das Ding ist um Welten schneller!

Der aktuelle Stand des HMRPC-Moduls anbei.

Änderungen zum vorherigen Post:

1) "req listBidcosInterfaces" wurde ersetzt durch den Befehl "updateBidcosInterfaces"
2) "rssiInfo" und "getServiceMessages" rudimentär eingebaut (noch ohne sinnvolle Funktion, wichtig war mir nur, den übermittelten HASH bzw. ARRAY korrekt abarbeiten zu können
3) Insgesamt wurde die Funktion HMRPC_Set überarbeitet

Zu 1):
Sofern ein (oder mehrere) HM-LAN-CFG, HM-LAN-GW oder die RF-Schnittstelle der CCU mit ihren Seriennummern als HMDEV-Devices in fhem definiert sind, werden die von der CCU abgeholten Informationen in den Readings dieser Devices aktualisiert. ACHTUNG: unbedingt bei den Interfaces event-on-update-reading und event-on-change-reading verwenden, da sonst immer für jedes aktualisierte RSSI-Reading ein Event in fhem generiert wird. Ich habe das extra nicht im Modul selbst deaktiviert, da es durchaus aus Benutzer-Sicht auch mal sinnvoll sein kann, auf entsprechende Events reagieren zu können.

NEU: darüber hinaus werden auch die RSSI-Informationen  der CCU ausgelesen und entsprechend auf die Interfaces als Readings verteilt.

Zu 1) und 2):
Die Kommandos werden unmittelbar auf die definierte CCU abgesetzt, ohne ein vorangestelltes "req".

Hallo zusammen,

anbei nun eine Version 0.6, die auch mit der RPC-XML API für HmIP zurecht kommt. Folgende Änderungen und Ergänzungen wurden vorgenommen:

• Anpassungen für die Kommunikation mit RPC-XML API für HmIP auf Port 2010
• Spezieller Befehl dim-with-timer für Dimmer; Beispiel:
  set DIMMER_CHANNEL dim-with-timer ON_TIME 30.0 RAMP_TIME 5.0 LEVEL 50
  ... setzt einen Dimmer auf 50% für 30 Sekunden und nimmt als Rampenzeit 5 Sekunden; diese Reihenfolge ist einzuhalten!
• Es können nun Paramsets mit mehr als einem Wertepaar abgesetzt werden, sowohl für MASTER als auch für VALUES; Beispiel:
  set MEIN_DEVICE VALUES ON_TIME 10.0 STATE true
  ... schaltet bspw. eine Steckdose für 10 Sekunden ein
• Die in fhem definierten Geräte bekommen nun mehr Informationen in den Internals, sobald das erste mal ein Event für ein solches Gerät eingegangen ist
• Auf der definierten CCU könnnen unmittelbar die Befehle updateBidcosInterfaces,getServiceMessages und rssiInfo abgesetzt werden.
  1) set CCU updateBidcosInterfaces
      ... versorgt alle der CCU zugeordneten, aber in fhem definierten HM-CFG-LAN und LAN-Gateways mit zusätzlichen Informationen insbesondere mit den RSSI-Werten der Devices, mit denen die Schnittstellen Kontakt hatten
  2) set CCU rssiInfo
      ... gibt im Log eine Liste mit aktuellen RSSI-Werten aus
  3) set CCU getServiceMessages
      ... protokolliert im Log die aktuellen Servicemeldungen der CCU
• Da die CCU keine Möglichkeit bietet, über die RPC-XML API Systemvariablen zu lesen oder zu ändern oder Programme zu starten, wurde die Möglichkeit über einen Zugriff auf die HomeMatic-Script API eingebaut. Es können unmittelbar auf die CCU daher die Befehle run,setvar und getvar abgesetzt werden (kleine Anleihe aus dem Modul HMCCU ;-)).
  1) set CCU run MEINPROGRAMM
      ... lässt das Programm MEINPROGRAMM auf der CCU ausführen
  2) set CCU setVar VARIABLE WERT
      ... setzt die Variable VARIABLE auf der CCU mit dem Wert WERT
  3) set CCU getVar VARIABLE
      ... liefert den Wert der Variable VARIABLE zurück
• Auf einem Device können die Spezialbefehle getConfig, statusRequest und rssiInfo abgesetzt werden.
  1) set MEINDEVICE statusRequest
      ... liest das Paramset VALUES des definierten Devices (Channels) komplett aus und setzt es in Readings um
      Außerdem wird aus dem Paramset MASTER vom Master-Channel (:0) der Datenpunkt UNREACH ausgelesen und in den Readings gesetzt
  2) set MEINDEVICE getConfig
      ... liest das Paramset VALUES des Master-Channels (:0) und setzt es in Readings um
      ... liest das Paramset MASTER des definierten Devices (Channels) und setzt es in Readings um
      ... liest das Paramset LINK des definierten Devices (Channels) und setzt es in Readings um
      ... führt ein getLinks auf dem definierten Device (Channel) aus und setzt es in Readings um
  3) set MEINDEVICE rssiInfo
      ... fragt die RSSI-Informationen der CCU ab und trägt die für das Device in Frage kommenden in den dortigen Readings ein

Für eine CCU mit "normalen" Homematic-Komponenten ist wie gehabt die CCU mit

define CCU2 IP_MEINER_CCU 2001

zu definieren.

Für HmIP-Komponenten ist zusätzlich noch

define HMIP IP_MEINER_CCU 2010

zu definieren.

Bei der Definition von Devices ist dann darauf zu achten, dass das Attribut IODev auf die passende Schnittstelle verweist - also normale Homematic-Devices hier im Beispiel auf CCU2, HmIP-Devices auf HMIP.

Die weitere Definition einer weiteren Schnittstelle für HMW auf Port 2000 ist davon unberührt.

Hallo Ralli,

die Version 0.6 ist ein echter Fortschritt und ersetzt erfolgreich meine "Eigenentwicklung".

SetVar müllt allerdings ziemlich das Logfile zu. Ich kann das Modul gerne gelegentlich auf Log3 umstellen oder möchtest Du das selbst machen in einer eventuellen Weiterentwicklung?

Danke jedenfalls und Grüße
Raymund

Hallo Raymund,

freut mich.

Was genau meinst Du mit "SetVar müllt ziemlich das Logfile zu" ? Standard ist ja Loglevel 3 und wenn Du viel dieses Methode nutzt, dann ist jedes mal ein Eintrag im Log. Da wäre in Zeile 365 lediglich


Log 3,"HMRPC getVar URL=$url";


durch


Log 4,"HMRPC getVar URL=$url";


zu ersetzen. Oder was meinst Du?

Hallo Ralli,

ja genau, das meine ich. Habe es auch schon auf 4 gesetzt, wie Du schreibst. Aber ich denke, es wäre sinnvoll, solche häufigen Info-Ausgaben generell auf 4 zu setzen um dann per verbose im HMRPC-Objekt einstellen zu können, ob man sie sehen will oder nicht. So ist nach meinem Verständnis Log3 ja gedacht!? Natürlich nur, wenn Du das Modul noch weiter entwickeln willst. Sonst wäre es ja mit der einmaligen Änderung (3->4) auch erledigt.

Ich habe eine ganze Reihe von HM-Teilen und das klappt so wunderbar und zuverlässig mit FHEM. Ich hatte quick and dirty kleine Korrekturen in das alte Modul eingebaut, speziell für die Rollladensteuerung. Aber jetzt mit der 0.6 geht das auch und es gibt sogar mehr Internals. Was will man(n) mehr ;-)

Grüße
Raymund

Hallo zusammen,

anbei nun eine Version 0.7, die speziell im Modul HMDEV weiter entwickelt wurde. Bspw. wurde ein grundsätzliches State-Handling eingebaut. Das Modul HMRPC wurde modifiziert, so dass der Status der RPC-XML-Schnittstelle nun als Reading zur Verfügung steht; damit sind Event-gesteuerte Maßnahmen möglich. Folgende Änderungen und Ergänzungen wurden vorgenommen:

• Befehl on-for-timer für Typ SWITCH eingebaut; alternativ "set MEIN_SWITCH on 30" schaltet für 30 Sekunden ein.
• Befehl "set MEIN_DIMMER 50 30 [10]" schaltet einen Dimmer für 30 Sekunden auf 50% mit einer Rampe für 10 Sekunden
• In der Web-Oberfläche werden nun die Standard-Befehle per Dropdown angeboten.
• In der Web-Oberfläche werden nun für Dimmer, Rolladenaktoren und Thermostate über das automatisch gesetzte Attribut widgetOverride Slider angeboten, wenn das Attribut noch nicht definiert wurde.
• Bei der Definition eines HMDEV-Devices kann nun optional noch der Type (hmdevtype) mit angegeben werden.
• Für manche Devices werden nun anhand des Internals hmdevtype (auf Grund von der o.a. Definition oder nachdem die Info von der CCU eingeht) die Attribute event-on-change-reading, event-on-update-reading und webCmd automatisch gesetzt, wenn diese Attribute noch nicht definiert wurden.
• Es wurde das Attribut stateReading eingeführt. Wird dieses mit dem Namen eines Datenpunktes (Reading) gesetzt, wird dessen Wert in das Reading (!) state übernommen und dafür ein Trigger ausgelöst. Mit dem Standard-Attribut stateFormat kann nach wie vor das Internal (!) STATE modifiziert werden.
• Es wurde ein grundsätzliches State-Handling für Devices vom Typ Thermostat, Dimmer, Switch, Rolladenaktor, Wetter, LED-Status-Display (KEY), Fenstersensoren und Bewegungsmelder eingeführt. Hier wird nun automatisch das Readings state - und damit auch das Internal STATE - gesetzt, wenn stateFormat nicht definiert ist und kein userReading für state existiert.
• Im Rahmen des o.a. State-Handlings werden manche Datenpunkte/Readings nur noch ohne Trigger geupdatet - es sei denn, man setzt das neue Attribut event-filter-for-state-off auf 1.
• Dieses neue Attribut wird automatisch für Devices vom Typ Wetter, Thermostat und Mess-Steckdose gesetzt, da die hier generierten Events meistens zum Logging für Diagramme genutzt werden.
• Die Datenpunkte/Readings LOWBAT, BATTERY_STATE und BatteryVoltage werden nun ausgewertet und im Reading battery "übersetzt".
• Der/das Datenpunkt/Reading FAULT_REPORTING wird in das Reading deviceErr "übersetzt".
• Manche Log-Aufrufe wurden auf Log-Level 4 gesetzt.

Kleine Änderung im Modul HMRPC:

- Beim statusRequest werden keine unmittelbaren Updates der Readings mehr durchgeführt, sondern stattdessen werden die abgefragten Werte durch das Modul HMDEV geparsed (state-handling).

Hallo zusammen,

ich hab das HMRPC Modul aus dem Git Repo installiert und läuft prima.
Jetzt wollte ich die neuste Version installieren, und hab die beiden .pm Dateien ins FHEM reinkopiert,
jedoch sagt fhem dann:
2016.05.08 11:49:02 1: configfile: Cannot load module HMRPC
HMDEV_MEQ0058214: unknown IODev specified
...

Meine Config:
define hmrf HMRPC 192.168.2.11 2001

Mach ich da was falsch?

Das Modul HMDEV wird offensichtlich korrekt geladen, aber nicht das Modul HMRPC - und darum finden die HMDEVICES das IODev nicht. Warum das Modul HMRPC nicht geladen wird, ist aber aus Deinem Post nicht erkennbar, hier fehlen die wichtigen Infos aus dem Log.

Ah im git repo heisst die 60_hmdev.pm  61_hmdev.pm und bleibt im FHEM verzeichnis.
Muss ich die vielleicht löschen?

Ich bekomme folgende Fehlermeldung.

2016.05.10 21:52:43 1: reload: Error:Modul 60_HMRPC deactivated:
Type of arg 1 to keys must be hash or array (not private variable) at ./FHEM/60_HMRPC.pm line 396, near "$ret)

Was mache ich falsch?

Kann ich nicht nachvollziehen, die Zeilennummer passt auch nicht mit der aktuellen Version zusammen.

Bitte immer beide Module austauschen. Und kein reload sondern ein shutdown restart machen!

hm da fehlt ihm die switch.pm



2016.05.20 21:59:06 1: reload: Error:Modul 60_HMDEV deactivated:
Can't locate Switch.pm in @INC (you may need to install the Switch 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 . ./FHEM) at ./FHEM/60_HMDEV.pm line 19, <$fh> line 466.
BEGIN failed--compilation aborted at ./FHEM/60_HMDEV.pm line 19, <$fh> line 466.

2016.05.20 21:59:06 0: Can't locate Switch.pm in @INC (you may need to install the Switch 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 . ./FHEM) at ./FHEM/60_HMDEV.pm line 19, <$fh> line 466.
BEGIN failed--compilation aborted at ./FHEM/60_HMDEV.pm line 19, <$fh> line 466.

2016.05.20 21:59:07 1: Including ./log/fhem.save
2016.05.20 21:59:08 1: configfile: Cannot load module HMRPC


Was fehlt, muss man rein machen :-).

apt-get install libswitch-perl

oder

cpan -i Switch

Danke.
Dachte switch.pm wäre zur steuerung der HM Switches für das Modul.
Jetzt gibts nur noch ein warning beim start:

2016.05.21 14:31:13 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/60_HMDEV.pm line 227.

Jetzt werd ich erstmal testen. Danke.