Homematic VirtualDevices ansprechen

Muss man jetzt wohl doppelt erstellen … :cool:

Laut ELV (wenn keine Schutzbehauptung) ist alles in der Doku zur XMLRPC-Schnittstelle enthalten.

Gruß
Bruno

Hallo…

in der Beschreibung der HomeMatic XML-RPC-Schnittstelle von eq-3 habe ich folgende Stelle gefunden:

… "Die HomeMatic Zentrale verfügt derzeit über drei :confused: Schnittstellen, über die Geräte angeschlossen sein können:
 [ul]
[li]BidCos-RF für Funk-Komponenten Port-Nummer: 2001
[/li][li]BidCos-Wired für drahtgebundene Geräte (ist nur in Verbindung mit einem HomeMatic Wired LAN Gateway verfügbar) Port-Nummer: 2000
[/li][/ul]
Hier scheint die Doku unvollständig zu sein. Im Homematic Forum fand ich folgendes:

"…

[ul]
[li]BidCos-RF für Funk-Komponenten Port-Nummer: 2001
[/li][li]BidCos-Wired für drahtgebundene Geräte Port-Nummer: 2000
[/li][li]System für interne Geräte Port-Nummer: 2002 …"
[/li][/ul]

Leider komme ich hier nicht weiter. Im Homematic Socked kann man ja nur die Ports für „Wired“ und „RF“ hinterlegen.
Ich experimentiere gerade mit der „hmxml.ipc.php“ aus meinem Heizungsprojekt. Dort erhalte ich jedoch immer die nachfolegnde Fehlermeldung. „Es konnte keine Verbindung hergestellt werden, da der Zielkomputer die Verbindung verweigerte. (10061)“. … :confused:

2002 ist nur die CCU1.
Port 1999 ist die CCU2.
Leider gibt es auch da (zumindest bei der CCU2) kein Befehl mit getDeviceList. :frowning:
Michael

Letztendlich isses das Problem, dass ich nicht weiss, wer was machen kann/muss. Port 2002 hatte ich gelesen, geht aber nicht. Ist es der überhaupt?

Bräuchte also irgendeinen Hinweis … ja, wir … oder, … nein, wir nicht … :wink: :cool:

Lade dir bei HM inside das XMLRPCbin Tool, und probiere es selber aus. Es geht einfach nicht.
Diese virtuellen Geräte hängen intern an einem neuen Interface. Für jedes Interface gibt es einen XMLRPC-Server, nur hierfür wohl (noch?) nicht.
Per HM-Script kann man die Geräte abfragen und Werte setzen, aber leider auch nicht konfigurieren (Zeitpläne). :frowning:
Sonst hätte ich mal versucht mein HM-Modul zu erweitern.
Allerdings wirft das HM-Script das dritte Interface ‚Virtuell‘ aus.
Habe mich am letzten WE mehrere Stunden mit dem XMLRPCs rumgeschlagen.
Michael

Ich glaube es Dir ja, brauche aber eine Aussage des „Herstellers“ (Symcon GmbH)

Dann lass den Jungs doch mal die Behauptung von ELV zukommen.
Weil in beiden Dokumenten von EQ3 über die XMLRPCs steht nix über die virtuellen Geräte oder einem Interface hierfür.
Und da auf meine Frage bei ELV auch keine Antwort kommt…
Sehe ich IPS da nicht in der Pflicht.
Michael
PS: Aber vielleicht bekommst du ja noch eine offizielle Aussage :slight_smile:

2002 ist der „pfmd“-Service und der quatscht wohl nur mit der CCU-eigenen HW (die Grafik ist noch aus CCU1-Zeiten):

Ich finde auch weder in der JSON-API (http://<CCU-IP>/api/homematic.cgi) noch in den Methoden (unter /www/api/methods) irgendeinen Hinweis wie man da aktuell von außen vernünftig rankommen könnte. Mysteriös! :rolleyes:

EDIT: Habe gerade die Source zur Grafik wiedergefunden: WikiMatic

Cheers
/Jens

Also bei der XMLRPC Spec der CCU1 ( Dateiname mit 1.502 und von vor 3 Jahren glaub ich) ist Port 2002 noch dokumentiert.
Bei der Spec der CCU2 (steht CCU2 im Dateinamen und ist von diesem Jahr) wird Port 1999 einfach unterschlagen, aber ist da und erreichbar. Allerdings habe ich ihm nix sinnvolles entlocken können, außer einer Auflistung der verfügbaren Befehle.
Ich vermute mal wider einen Schnellschuß bei der Entwicklung.
Die Gruppen vereinfachen ja ungemein das einrichten der Direktverknüpfungen und das einstellen des Wochen Profils, so dass es wichtig war.
Aber das ganze extern auch bereit zu stellen… oder gar daran zu denken.
Da die virtuellen Geräte ja auch nur in der CCU existieren, können die vermutlich gar nicht über die Daemons der HW-Ebenen erreicht werden. Und konnten dort auch nicht eingehängt werden ohne das die Jungs von EQ3 noch was kaputt machen :slight_smile:
Man könnte jetzt natürlich versuchen ähnlich wie CuxD eine Erweiterung zu schreiben welche auf der CCU läuft und die logischen Virtuellen Geräte extern bereit stellt. Aber dazu bin ich zu wenig Linux-Crack.
Mal sehen ob sich vom Hersteller was regt.
Michael
PS: Wenn ich mir so das Schema ansehe… vielleicht ist ja nur der Port nicht offen auf der CCU zum XMLRPC des Virtuell Interface…der ReGa Hss muss ja auch irgendwie an die Daten kommen.

Mal aus einem ganz anderen Winkel betrachtet … aktuell nutze ich die Gruppen nicht (mehr) und hatte das Thema eigentlich schon unter „naja, es war gut gemeint“ abgelegt. Hintergrund: wenn man sich die von den Gruppen erstellten Direktverknüpfungen anschaut wird schnell klar, dass hier viel zu viel angelegt wird (Fensterkontakte …). Da werden lustig die FKs mit dem WTs und den HKs verschnurpselt … und wofür? Na, wenn man nicht genug Servicemeldungen hat, generiert man sich so halt welche! :rolleyes: Einmal bekommt der WT den FK-Zustand nicht mit, das nächste mal die CCU, dann sind die HKs beleidigt …
Nach manueller Erstellung der Verknüpfungen (nur WT mit FKs und WT mit HKs) war dann hier auch wieder Ruhe.

Cheers
/Jens

Das ließ mir nun keine Ruhe…
Und ich habe ihn den XMLRPC … erst da !
UND Bruno, jetzt darfst du einen Request bei IP-Symcon aufmachen… denn er geht nicht ab ‚Werk‘.

Grund ist das hier:
<IP-CCU>:9292/groups

Der Port ist ja noch im HM-Socket einstellbar (einfach einen zweiten anlegen, als nur Funk angeben und bei Funk die 9292 eintragen. Außerdem einen weiteren freien Port vom IPS-PC für Eventserver).
Der Port ist auch offen, aber leider kommt nie was von der CCU zurück, weil die URL nicht stimmt.

Ein kurzer Test mit dem hmxml.inc und xmlrpc.php gibt mir bei listDevices alle meine Gruppen !

Gefunden habe ich ihnen in den InterfaceList.xml auf der CCU.

Michael

EDIT: Eben noch weiter getestet. Also (noch) gibt es keine Werte welche direkt in IPS sinn machen. Ich habe keine SET_TEMPERATUR o.ä. in der Gruppe gefunden. Einfach null Values bei getParamsetDescription. :frowning: Oder ich war blind :rolleyes:
Dafür geht das lesen der Wochenprofile mit getParamset :smiley:

Den Request gibt es schon, siehe erster Post, wusste, Du schaffst das :stuck_out_tongue: :smiley:

Komisch, das funktioniert bei mir fast problemlos, einzig die Gruppen ohne Wandthermostat, die habe ich alle aufgelöst und selber direkt verknüpft (das hatten wir aber schon).

Gruß
Bruno

@Nall chan

Ich bin begeistert … :slight_smile: … muss das gleich heute Abend mal ausprobieren.

Gruß

Swifty

Habe deine Scripte für die Wochenprofile im Webfront nur kurz getestet.
Wollte mich da jetzt nicht rein hängen um zu versuchen die Gruppen zu integrieren.
Musst auf jeden Fall in der hmxml dem Init erweitern damit auch ein Pfad möglich ist.
Blöd halt das es nun ein anderes Interface ist, so kann man nicht gleichzeitig Funk und Virtual ansprechen.
Musst eventuell das mit in die Config aufnehmen…
Michael

Ihr schafft es echt noch, dass ich wieder einen Verusch mit den Gruppen wage :smiley:

Hallo…

die ersten Versuche sehen nicht schlecht aus. Zumindest der Wochenplan sollte unkompliziert in meine Steuerung zu integrieren sein. Alles weitere (Modus, set_Temp etc.) sieht schwierig aus, solange die VirtualDevices von IPS nicht originär unterstützt werden.

Aktuell habe ich noch ein „Hardware-Rolladenprojekt“ am werkeln :D. Sobald ich damit fertig bin gehts mit der Heizung weiter.:loveips:

PS: So wie Nall chan schrieb liegt das Problem aktuell darin, dass man im Homematic Socked den Pfad „groups“ nicht hinterlegen kann. Könnte man da nicht etwas tricksen und eine Anfrage mittels eines Programms „umbiegen“. Sorry wenn ich mich so untechnisch ausdrücke :o … ich bin kein Netzwerkspezialist.
Ich stelle mir vor, in IPS einen Homematic Socket einzurichichten und dort die IP und einem Port vom lokalem PC einzutragen. Ein Programm müsste sodann Anfragen an diese (lokale)Adresse auf die IP_CCU2:9292/groups "umleiten … ginge dies ?

Gruß

Swifty

Irgendwie scheint die Symcon GmbH komplett Urlaub zu haben :cool:

Ich werde heute Abend mal meinen Apachen verbiegen und das mal ausprobieren.
Michael

Ist doch ein frustrierendes Unterfangen.
Also über IPS habe ich es nicht hinbekommen. Auch wenn ich versuche einen Proxy zu nutzen welche auf /groups umleitet bekomme ich keinen Antwort von der CCU.
Ich vermute mal das mein Proxy nicht mit dem Bin-Format umgehen kann. (statt XML wie die Events oder die HMXML.inc.php es nutzen.)

Aber ich habe dafür es geschafft die VALUES der Geräte zu lesen :smiley:
(War wohl wirklich zu spät / zu blind.)

Allerdings meckert hier der XML-Parser der rpcxml bei ‚°C‘ :mad:
Dafür sind hier wirklich alle Werte enthalten, sogar die Luftfeuchte (WT in der Gruppe vorausgesetzt).

<member>
<name>PARTY_STOP_MONTH</name>
<name>CONTROL_MODE</name>
<name>PARTY_STOP_DAY</name>
<name>BOOST_MODE</name>
<name>ACTUAL_HUMIDITY</name>
<name>PARTY_START_DAY</name>
<name>PARTY_TEMPERATURE</name>
<name>AUTO_MODE</name>
<name>SET_TEMPERATURE</name>
<name>PARTY_START_MONTH</name>
<name>MANU_MODE</name>
<name>ACTUAL_TEMPERATURE</name>
<name>PARTY_STOP_YEAR</name>
<name>COMFORT_MODE</name>
<name>PARTY_MODE_SUBMIT</name>
<name>PARTY_START_YEAR</name>
<name>PARTY_STOP_TIME</name>
<name>PARTY_START_TIME</name>
<name>LOWERING_MODE</name>

Für das Programmieren der Wochenprofile sind die Werte unerheblich, es muss aber die HMXML.inc.php so geändert werden dass sie nicht mehr von HM-Instanzen in IPS abhängig ist; das sie zwei Interfaces Unterstützt (sonst muss sich der User entscheiden immer oder nie Gruppen zu nutzen) und der Codierungsfehler durch °C behoben werden.
(Freiwillige vor. welche Swifty unterstüzen können :p)

Dann müßte für Swifty’s Umsetzung noch die logische Zuordnung eingeplegt werden, welche HM-Instanzen in welcher Gruppen sind.
Letzter Punkt kann entfallen wenn Paresy uns erhört hat und uns einen geänderten HM-Socket spendiert. :smiley:
(Auch wenn heute extreme Kopfschmerzen habe… nun will ich es wissen ob CuxD auch mit IPS geht.)

Michael

Hi …

ich hab da mal was „vorbereitet“ … :smiley:

Die beiliegende test_hmxml.inc.php habe ich umgestrickt. Das Script sollte - so wie es ist - in meinem Heizungsscript laufen (Es muss dazu nur umbenannt werden) Achtung beta !!! Ich hab’s noch nicht ausführlich getestet.

Das Script erkennt ein VirtualDevice und spricht sodann auch das richtige Interface an. Es funktioniert sowohl mit IPS-IDs, wie auch HM-Adressen.

Damits bei Euch läuft müsst Ihr noch in den Zeilen 40ff die $GLOBALS anpassen. Die wandern später in die HM_Heizung_Konfig.

Die nachfolgenden Beispiele sollten die entsprechenden Wochenprofile ausgeben:


include "test_hmxml.inc.php";
$id='INT0000001';
HMXML_getTempProfile($id , $day = false, $echo = true, $WT_Profil=-1);

oder


include "test_hmxml.inc.php";
$id=42818;
HMXML_getTempProfile($id , $day = false, $echo = true, $WT_Profil=-1);

Sobald die neue Version vorzeigbar ist berichte ich im Heizungs-Thead weiter … :smiley:

test_hmxml.inc.php.zip (6.41 KB)