XMLRPC mit Java

[gzi]

Hallo,
Wenn es nur um sowas geht:

“die Info, daß in Kabine 4 der Taster XY gedrückt wurde....
In einem anderen System
weiterverarbeiten“,

dann würde ich das viel primitiver lösen, sofern am anderen System ein Webserver läuft.

In der CCU ein simples WebUI Programm:

Wenn SensorXY bei Änderung auslösen
Dann Skript sofort ausführen

Im Skript den Sensorwert holen und dann einen http-Request absenden. In der Form:

Code: Alles auswählen

http://server/ccudatenverarbeiten.php?taster=name&clicked=true

Das Skript ccudatenverarbeiten.php macht den Rest.Das muss natürlich kein PHP sein, sondern kann ein cgi , ein Java Programm oder sonstwas sein, was der Webserver versteht.

Hat nebenbei den Vorteil, dass die Systeme schön entkoppelt sind und man das auch ganz einfach testen kann.

Aber wie gesagt, nur wenns um einzelne Messwerte oder Ereignisse geht.

gzi

[Familienvater]

Hi,

und jetzt unabhängig von Deinen Software-Problemen:

Z.B. die Info, daß in Kabine 4 der Taster XY gedrückt wurde. Diese Information soll dann automatisiert in unserer RehaVerwaltung weiterverarbeitet werden. Z.B. indem auf sämtlichen Monitoren an der Rezeption ein Notfall angezeigt wird mit der Position des Notfalls, der Uhrzeit der Alarmauslösung und der Möglichkeit den Notruf zurückzusetzen.
Nur so als eines von vielen Beispielen.

Man kann viel mit HOMEmatic machen, vielleicht würde ich auch der Oma eine HM-Fernbedienung geben, die am Bett liegt, damit die zu HAUSE nach Hilfe klingeln kann, für etwas "im kommerziellen Sinne lebenswichtiges" würde ich HOMEmatic nicht nutzen (die Großschreibung von mir verdeutlicht das HOME). Es ist weder ein REHAmatic, noch eine NOTRUFKLINGELmatic.
Irgendeiner muss nämlich irgendwann im Fall der Fälle den Kopf hinhalten, warum da eine HOMEmatic genutzt wurde, die für soetwas keine Zulassung hat, und wer jetzt den (Personen-)Schaden zahlt, weil ein Notruf-Klingeln im Funk oder auf dem Bus versumpft ist.
Auch wenn wir alle (kein) Verständnis haben, das im Gesundheitswesen an allen Ecken gespart wird, es kauft ja hoffentlich auch kein Klinikchef im Baumarkt Schubkarren, nur weil die sich auch zum liegend-Transport von Patienten eignen, und außerdem viel billiger als Rollstühle etc. sind.

Just my 2 Cents,
der Familienvater

[Fonzo]

Man kann viel mit HOMEmatic machen, vielleicht würde ich auch der Oma eine HM-Fernbedienung geben, die am Bett liegt, damit die zu HAUSE nach Hilfe klingeln kann, für etwas "im kommerziellen Sinne lebenswichtiges" würde ich HOMEmatic nicht nutzen (die Großschreibung von mir verdeutlicht das HOME).

Funk würde ich persönlich da auch ausschließen und wenn man etwas momentan findet in so Einrichtungen dann eher KNX oder LCN. Aber grundsätzlich bietet ja EQ3 mit Homematic IP Wired auch ein Bus an. Die Namensgebung ist zugegebener Maßen eindeutig auf den Zweck des Privatgebrauchs zugeschnitten, aber das schließt ja nicht gänzlich aus, dass es Firmen gibt die das anderweitig einsetzten. Die kontroverse Diskussion Homematic in Hotels einzusetzen wurde hier im Forum ja auch schon geführt, weil es einfach Firmen gibt, die so was dem Kunden anbieten.
Wenn man die Wahl hat, gibt es da aber sicher haufenweise Systeme, die speziell auf den Zweck zugeschnitten und etabliert sind, da muss man nicht unbedingt mit Homematic eine neue Baustelle aufmachen, von der es zur Zeit gar keine Beurteilung der langfristigen Zuverlässigkeit in so einem Umfeld gibt.

[Familienvater]

Hi,

zumindest dem klassischen Wired traue ich ggf. auch nicht mehr weiter, als ich das 12/7er werfen kann. Eigentlich ist der Bus zuverlässig, und es geht nix verloren, aber gerade mit dem 12/7er gibt es z.B. bei DVs innerhalb des gleichen Moduls mit mehreren gleichzeitig zu schaltenden Ausgängen Probleme, das da stillschweigend Meldungen versumpfen. Und Wired IP klingt zwar alles ganz nett, aber hat für mich nach dem was ich so lese und reininterpretiere auch immer noch eher Beta-Geschmack.

Der Familienvater

[JSteinhilber]

Hallo die Herren,
keine Angst, ich möchte mit HomeMatic keine Notrufanlage ersetzen. Vielmehr sollen vorhandene Notrufanlage(n) erstmalig in unsere Verwaltungsarbeit integriert werden, genauer gesagt in die QM-Notfalldokumentation. "Versumpfen" Informationen im HomeMatic-Nirvana hat dies keinen direkten Einfluß auf den eigentlichen Notfall bzw. Notruf.
Wie dem auch sei, bislang geht ohnehin noch nichts.

Mit meinem XMLRPC-Problem bin ich nämlich noch keinen Schritt weitergekommen, und das obwohl ich zu dem Thema gefühlt das Internet leergelesen habe.
Hier nochmal eine kurze Zusammenfassung von meinem bisherigen Verständnis wie die Sache funktionieren sollte:
- Damit ich über die Änderung von Werten automatisch informiert werde, brauche ich eine XMLRPC-Server und einen XMLRPC-Client.
- Der XMLRPC-Client meldet den XMLRPC-Server mit Adresse und Port an der CCU an.
- Die CCU sendet daraufhin eine Anfrage an den Server und möchte über die vorhandenen Methoden informiert werden (system.listMethods).
- Der Server gibt die Mehoden-Namen in einem Response zurück.
- Jetzt sendet die CCU eine Anfrage und möchte über die vorhandenen Devices informiert werden (listDevices).
- Da meine Notebook über keine Devices verfügt gebe ich im Response die Anfrage ohne Werte zurück.

So und ab der Stelle hätte ich erwartet daß die CCU mir zyklisch events liefert, das tut sie aber nicht.
Schweigen im Walde.
Wenn ich über den Client einen ping auslöse. Ruft die CCU die multicall-Methode auf und liefert das Ergebnis (PONG) in beigelegten "event".

Wie bringe ich die CCU dazu mir automatisiert Werteänderungen sei es über die multicall-Methode oder direkt über die event-Methode zu liefern?

Grüße an Alle
Jürgen

[Fonzo]

Wie bringe ich die CCU dazu mir automatisiert Werteänderungen sei es über die multicall-Methode oder direkt über die event-Methode zu liefern?

Hat es denn irgendeinen speziellen Grund warum das ganz neu in Java geschrieben werden soll oder eine spezielle Anforderung? Ansonsten muss man das Rad wie gesagt nicht neu erfinden openHAB nutzt Java. Wenn man ein PHP Server sucht, der die Werte ausliest und darstellt kann man auch IP-Symcon nutzten.

[JSteinhilber]

Hat es denn irgendeinen speziellen Grund warum das ganz neu in Java geschrieben werden soll oder eine spezielle Anforderung?

Ja es hat einen Grund. Ich hätte einfach gerne eine kleine schlanke Blackbox, die ich lediglich mit der Adresse und dem Port der XMLRPC-Server-Instanz füttere und bekomme laufend die geänderten Werte geliefert, und zwar nur dann, wenn sich ein Wert geändert hat.
Grüße
Jürgen

[Familienvater]

Hi,

Ich hätte einfach gerne eine kleine schlanke Blackbox, die ich lediglich mit der Adresse und dem Port der XMLRPC-Server-Instanz füttere und bekomme laufend die geänderten Werte geliefert, und zwar nur dann, wenn sich ein Wert geändert hat.

theopraktisch ja. So ein bisschen Fehlerhandling wie PING-PONG sollte die Box. ggf. auch machen, damit die mitbekommt, wenn die andere Seite nicht mehr da ist, oder das "Abonnement" z.B. wegen einem Neustart vergessen hat.
In bin kein Java-Mensch, ich hab eine XMLRPC-Client mit c# mit Code hier aus dem Forum gedengelt, der läuft seit langer Zeit stabil, aber teilweise gab es nach Firmware-Updates auf der Zentrale plötzlich Probleme, weil z.B. der HmIP ein kleines bisschen kritischer geworden war, und ohne 110% saubere Anworten nach 24h abgeschmiert ist. Auch kommen immer mal wieder neue "Security"-Verbesserungen hinzu, und auf einmal ändern sich die Ports, oder man kann/muss sich Authentifizieren, oder kann mit SSL/TLS arbeiten, aber böse gesagt "immer nur halbgar".
Ich fürchte, die kleine Box wird auch regelmäßig bemuttert werden wollen, weil sich eben was auf CCU-Seite ändert, oder man auf das nächste Java-Release wechseln will/muss usw.

So ganz grundsätzlich:
Nimm Dir ein fertiges openHAB/ioBroker Image, konfiguriere da den XMLRPC-Adapter, und häng Dich mit Wireshark/TCP-Dump drauf, und schaue einfach, was die "richtig" machen, und vergleiche das mit dem, was Du sendest/empfängst. Und dann würde ich ggf. zuerst nur Versuchen, mit den rfd zu Connecten, der war zumindest damals der, der am "stabilsten" lief, und auch Clients wieder abgemeldet hat, wenn die nicht sauber antworten, außerdem loggt der bei Debug ggf. halbwegs gescheit ins Syslog. Der HmIP-Server war zumindest damals sehr "zickig", und ist regelmäßig komplett ausgestiegen, wenn Events nicht sauber quittiert wurden.

Zum Thema nur geänderte Werte:
Du bekommst jedes Event, nicht nur geänderte Werte, das kann bei einem TFK mit zyklischen Meldungen jede Stunde und ohne Öffnung durchaus 24x geschlossen am Tag sein.

Der Familienvater

[hobbyquaker]

So und ab der Stelle hätte ich erwartet daß die CCU mir zyklisch events liefert, das tut sie aber nicht.
Schweigen im Walde.
Wenn ich über den Client einen ping auslöse. Ruft die CCU die multicall-Methode auf und liefert das Ergebnis (PONG) in beigelegten "event".

Wenn der Ping Call einen Pong Event verursacht funktioniert Deine Event Subscription. Wenn keine anderen Events kommen gibt es wahrscheinlich keine Von was für Geräten erwartest Du denn konkret Events? Oder bist Du eventuell einfach auf dem falschen Schnittstellenprozess unterwegs? (rfd/BidCos-RF nutzt Port 2001, hmserver/HmIP Port 2010). Falls es um Events von HmIP-Tastern geht zusätzlich nochmal der Hinweis: Forensuche bemühen, Stichwort "reportValueUsage".

[erbian]

Hallo an alle Java Fans,

hier ein kleines Java 11 Programm zur Demonstration der HomeMatic XML-RPC-Schnittstelle mit Apache-XMLRPC 3.1.3
(https://archive.apache.org/dist/ws/xmlr ... nt-src.zip)

Das Programm erwartet die URL auf die HM-Zentrale (Port 2001) als Parameter im Aufruf.

Leider muss Apache-XMLRPC an einer Stelle modifiziert werden:
Ersetze im Package org.apache.xmlrpc.server in der Klasse AbstractReflectiveHandlerMapping
die Zeile 152
String name = pKey + "." + method.getName();
durch
String name = (pKey.equals("") ? "" : pKey + ".") + method.getName();
Dies ist erforderlich, da Apache-XMLRPC von zweiteiligen Methodennamen mit einem Punkt in der Mitte ausgeht,
Homematic aber einteilige Methodennamen verwendet. Da stört der Punkt.

LG erbian