JsonRPC vs XmlRPC bei Verwendung in HA

[SukramJ]

Moin,

ich beschäftige mich ja seit einiger Zeit mit der Integration der CCU in HA, und in dem Zusammenhang mit den zur Verfügung stehenden APIs.

Aufgrund mangelnder TCL Kenntnisse hab ich Fragen zur JsonRPC Implementierung einiger für mich relevanter API Funktionen:

• getValue
• setValue
• getParamset
• putParamset
• getParamsetDescription

Für mich sieht die Implementierung im wesentlichen nach folgenden Merkmalen aus:

• Zur Schnittstellenauswahl wird ein zusätzlicher Parameter interface übergeben.
• Die Rückgabewerte werden in JSON umgewandelt.

Ansonsten sehe ich hier keine Optimierungen, die insbesondere in Bezug auf getParamset und getValue, den Durchgriff auf die physischen Geräte puffern.

Mein Fazit: Ob ich die Methode über JsonRPC oder XmlRPC Aufrufe ist eigentlich egal, zumindest was in Bezug auf den Gerätedurchgriff und Auswirkungen auf den DutyCycle relevant ist.

Was habe ich übersehen?
Warum wäre eine Nutzung von JsonRPC zu bevorzugen?

[jens-maus]

Mein Fazit: Ob ich die Methode über JsonRPC oder XmlRPC Aufrufe ist eigentlich egal, zumindest was in Bezug auf den Gerätedurchgriff und Auswirkungen auf den DutyCycle relevant ist.

Da hast du natürlich prinzipiell vollkommen recht. Entgegen meiner damaligen Annahme von SukramJ/hahomematic#328 (comment) sehe ich es inzwischen auch so, das bzgl. der DutyCycle-Problematik es im Grunde irrelevant ist, ob man nun auf die JSONRPC oder XMLRPC API setzt um an die jeweiligen Gerätedaten mit den von dir genannten Methoden heranzukommen. Beide sollten sich komplett gleich verhalten (auch bzgl. Datencaching), eben weil die JSONRPC im Grunde "nur" ein Wrapper für xmlrpc basierte Aufrufe via tclsh (siehe tclrpc.so) darstellt und hier doch kein zusätzliches Caching passiert.

Es scheint also lediglich relevant zu sein, dass man es unterlässt die getValue und getParamset Methoden exzessiv zu nutzen um die Metadaten der Geräte abzufragen (vor allem bei Abfragen an rfd/BidCos-RF) und man stattdessen diese Abfrage via ReGa-Skripting machen sollte wie du das ja inzwischen in hahomematic umgesetzt hast, weil es ansonsten zu einer unnötigen Überhöhung des DutyCycle kommt.

Was habe ich übersehen? Warum wäre eine Nutzung von JsonRPC zu bevorzugen?

Bzgl. der von dir genannten Methoden sehe ich inzwischen (nachdem ich mir den Quellcode erneut angeschaut habe) in der Tat keine Unterschiede und es käme auf einen Versuch an für diese doch wieder auf XMLRPC zu setzen. Auf der anderen Seite aber nutzt die neue HA Integration ja ohnehin weiterhin zwingend die JSONRPC API für gewisse andere Dinge. Es sollte also im Grunde "egal" sein. Einzig alleine der Umstand das man auf die JSONRPC via http/https zugreift und somit teilweise von gewissen Firewallproblematiken nicht betroffen ist, kann - je nach Anwendungsfall/Applikation - ein wesentlicher Vorteil darstellen.

[SukramJ]

Danke für die schnelle Antwort.

Die initiale Datenabfrage über RegaScripting hat ja insgesamt eine enorme Verbesserung gebracht, und das nicht nur in Bezug auf den DutyCycle, sondern insgesamt auf das Startverhalten der Integration.
Mir geht es ja um die eigene Einordung zur API Verwendung. Die XmlRPC-Methoden sind in der Nutzung etwas handlicher, und da wir ja auch weiterhin eine Homegear-Kompatibilität erhalten wollen, kann man sich dann auch die zusätzliche JsonRPC-Implementierung teilweise sparen.
Die parallel API Nutzung soll und muss ja auch weiterhin bestehen bleiben, so das die Firewall-Problematik davon unberührt ist.

Vielen Dank.