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

[trilu]

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.

[Ralli]

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.

[zap]

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.

[Ralli]

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.

[trilu]

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.

[Ralli]

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

[trilu]

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

[zap]

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

[Ralli]

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

Code Auswählen Erweitern


set Schalter STATE true


oder ein

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

Code Auswählen Erweitern


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.

[trilu]

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

[zap]

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.

[Ralli]

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

[trilu]

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

[trilu]

In 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

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.

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!

[Ralli]

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