Neues (altes) Modul: Homematic CCU mit XML-RPC an FHEM, HMRPC reborn

[Ralli]

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.

[henryk]

Moin,

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.

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

[trilu]

prima, klappt gut!

[Raymund]

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

[henryk]

Moin,

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

[Raymund]

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

[Raymund]

Hallo Henryk,

anbei eine abwärts kompatible Version, hoffentlich fehlerfrei soweit

Gruß
Raymund

[EdgarM]

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

[zap]

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.

[henryk]

Moin,

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.

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

[zap]

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.

[Ralli]

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.

[Ralli]

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.

[Ralli]

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.

[zap]

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.