ich versuche gerade mich etwas mehr mit CUxD zu beschäftigen.
Außer das es wohl noch einen Bug gibt, welches den CUxD abstürzen läßt bei Zugriff mit IPS, habe ich noch ein dazugehörigen Funktionswunsch seitens IPS.
IPS spricht mit den RPCs abgehend im binrpc Format; Der Eventserver versteht aber nur XML; warum ?
Würde der Eventserver auch binrpc verstehen, könnte man auch den CUxD ansprechen.
z.Z. meldet sich IPS mit init (‚http://ip:port‘,‚IPS‘) an den RPC der CCU an.
Und bekommt dann Events im XML-Format.
Würde sich IPS mit init('xmlrpc_bin://ip:port) anmelden und der Eventserver binrpc verstehen, hätten wir alle CUxD Geräte in IPS
Michael
PS: Habe gerade eine binrpc Beispiel-Quellcode vielleicht baue ich selber mal was …
Ich hab mit dem BIN-RPC Live Converter auch schon ein wenig geliebäugelt … habs aber noch nicht weiter verfolgt. Ich versteh halt zu wenig von der Materie :o.
Prinzipiell dürfte das ja kein Problem sein. Wir Verarbeiten intern ja schon das binrpc. Ich hatte mir das noch nicht genauer angesehen. Läuft das weiterhin mit einem Webserver oder ist es dann ein normaler Socket?
Ein normaler Socket. Habe die Daten mal eben mit einem IPS-ServerSocket empfangen und in RPCXML zum IPS-HM-Socket gesendet. Geht (naja Bastel-Lösung siehe unten).
Die Anmeldung muss dann, wie schon geschrieben mit xmlrpc_bin://<ip>:<port> erfolgen.
Und im Gegensatz zu dem VirtualDevices-RPC klappt die Kommunikation von IPS -> CUxD sofort; aber nur 3 Minuten lang.
Problem ist wohl das IPS als KeepAlive immer ein die Methode ‚loglevel‘ sendet.
Nach drei Paketen mit loglevel (= 3 Minuten) stürzt CUxD ab
Könnte man nicht als KeepAlive einfach ‚system.listMethods‘ nutzen ?
Ich habe das PHP-Script mal in IPS eingebunden… es geht irgendwie… mit viel gefrickel.
Zwei ServerSocket, ein ClientSocket, drei RegVars und einen HM-Socket, sowie drei Scripte.
Je ein Client-/Server Socket welche zwischen den RPC und dem HM-Socket hängen und die Daten weiterschieben.
Dabei wird das ‚loglevel‘ von IPS nur emuliert und nicht zum RPC gesendet (wegen dem Absturz/Bug im CUxD; der kennt diese Methode nicht). Außerdem wird die init-Meldung von http:// auf xmlrpc_bin:// geändert.
Somit kann ich aus IPS Geräte schalten.
Der zweite Serversocket nimmt die Events vom RPC im rpcbin-Format an und übergibt sie an das Converter-Script aus dem HM-Forum.
Das Script sendet direkt aus PHP das Event dann als XMLRPC an den HM-Event-Socket in IPS.
Viel gefrickel und gebastel, bestimmt nicht produktiv verwendbar aber eine Menge gelernt
Könnte man dieses Prinzip nicht auch verwenden, um die VirtualDevices direkt einzubinden.
Die Kommunikation müsste im Prinzip dann wie folgt verlaufen:
IPS an CCU:
HM_Konfigurator -> HM_Socket -> IPS Server Socket -> Daten per Skript direkt an CCU Port 9292/groups weiterleiten
CCU an IPS:
Antwortet wie bisher an den HM Socket (Ereignis Port)
Ja könnte gehen.
Eigentlich wollte auch die Tage meine XBees Serie2 einbinden. Aber der Spieltrieb lässt nicht nach
Zumindest als Machbarkeitsstudie kann ich das ja mal angehen.
Michael
Es geht leider nicht… nur wieder mit diversen Sockets, und Konverter/Transcoder XMLRPC <–> RPCBIN.
Da es hier etwas OT ist; Hintergründe dazu hier in dem Fred, dann hat Paresy auch gleich ein paar Infos
Michael
Auch ich möchte den Wunsch noch mal bekräftigen. Ich beschäftige mich seit Version 4 (und der Möglichkeit ohne Windows-Kiste auszukommen) mit IPS und hätte schon beinnahe zugeschlagen - als ich dann mitbekommen habe, dass CUxD nicht direkt unterstützt wird. Echt schade …
Da EQ3 vom BinRPC Format eher weggeht (die HM IP Sachen werden wohl nur noch im XML Format sein), werden wir eher komplett zu XML-RPC wechseln. Ich würde also vorschlagen, dass du eher beim CUxD Werbung für das „aktuellere“ XML-RPC machst
ich wuppe gerade alles von openhab auf IPS. Die Ansteuerung der cuxd Komponenten wäre für mich auch eine praktische Geschichte. Ich habe zwar nur Aktoren, aber alles über eine virtuelle Fernbedienung zu basteln ist wieder wie bei openhab (gebastel…)
Daher +1 für eine direkte Umsetzung in IPS.
Das Argument, jetzt am abzulösenden System nicht mehr zu erweitern, kann ich nachvollziehen. Wenn sich hier neue Möglichkeiten auftun würde ich mich über eine Umsetzung freuen.
Ich weiß ja nicht, ob man hier als absoluter Neuling schon Wünsche äußern darf, ich muss aber gestehen, dass ich eigentlich erwartet hatte, dass ich meine FS20 Geräte über CUXd an der Homematic mit Symcon transparent weiterverwenden kann.
Auch liegt meine ganze Steuerlogik noch auf der Homematic und daher hätte ich auch gerne Durchgriff auf die Variablen auf der Homematic. Das können selbst die recht einfachen Frontends die ich bisher mit der Homematic verwendet habe (CCU.IO und ioBroker). Bin etwas enttäuscht und sauer auf mich selbst, dass mir das beim testen nicht aufgefallen ist.
Besteht hier gar keine Hoffnung oder hat wenigstens jemand die Lösung für die Variablen?
So wie ich das sehe wir CUL/FS20 auch nicht direkt am Symcon PC unterstützt, oder?
Was wird denn über CuxD gesteuert? Wenn das busware ist die kann man direkt an IP-Symcon betreiben. Und Systemexec über CuxD von IP-Symcon anzustoßen wäre wie von hinten durch die Brust ins Auge. Das geht auch direkt von IP-Symcon.
