XML-RPC ist inkonsitent #2042
Replies: 19 comments
-
Bitte nur konkrete Beispielauszüge mit dargelegten unterschieden samt curl payload hier zeigen und nicht ein kompletten xml tree. Denn es ist schwer das zu reproduzieren bzw deiner Argumentation zu folgen wenn nicht klar ersichtlich ist wie genau dieser tree erzeugt wurde. |
Beta Was this translation helpful? Give feedback.
-
Tut mir leid ich dachte es wäre eindeutig genug. Hier nochmal der curl request. Ich könnte auch eine Postman Collection zur Verfügungstellen falls das hilft.
Danke |
Beta Was this translation helpful? Give feedback.
-
Danke. Und dann bitte noch einzeln/genauer thematisieren welche konkreten probleme / Inkonsistenzen du siehst bzw problematisch ansiehst. |
Beta Was this translation helpful? Give feedback.
-
Im XML sind 2 Links.
Desweiteren sind die Parameter auch im folgenden getParamset nicht so formatiert wie im getLinks.
|
Beta Was this translation helpful? Give feedback.
-
Die Anfragen werden ja direkt vom HMIPServer beantwortet. Fixen kann das nur eQ-3. |
Beta Was this translation helpful? Give feedback.
-
Kann man die Anfrage nicht abfangen und vorher bearbeiten? Aber ich werde mich Mal an den Support wenden. Danke. |
Beta Was this translation helpful? Give feedback.
-
Laut XmLRPC Spec ist liegt hier kein Fehler vor:
Wenn kein Typ spezifiziert wurde ist der Typ Warum eq-3 hier mit einem String |
Beta Was this translation helpful? Give feedback.
-
Mich stört gar nicht Mal das sie die Typen nicht richtig ausweisen. Es stört vorallem das ich mich nicht darauf verlassen kann, dass es zumindest innerhalb einer Methode gleich ist. Ich kann nicht glauben, dass ich der erste bin dem das aufällt. |
Beta Was this translation helpful? Give feedback.
-
Die meisten werden wohl nicht das XML parsen, sondern eine XmlRPC-Client Bibliothek verwenden. |
Beta Was this translation helpful? Give feedback.
-
Das mach ich auch. Aber auch die weiß nicht das number 0 manchmal boolean false heißt. Zu mindestens generische nicht. Und für Dart hat noch keiner einen Client für Homematic gebaut. - Das wollte ich machen. |
Beta Was this translation helpful? Give feedback.
-
Vielleicht sollte ich dieses Issue Ticket besser in einen Diskussionsbeitrag konvertieren, denn ich sehe nicht wie im Zuge der RaspberryMatic Entwicklung man hier etwas verbessern könnte solange diese Teile closed-source sind. Die Art der XMLRPC Antworten sind so wie sie sind und damit muss man irgendwie leben. Auch kommt man erfahrungsgemäß um eine Mischung aus XMLRPC, JSON-RPC und direktes ReGa-Skripting nicht drumherum und das nutzen im Grunde alle anderen Middlewares wie ioBroker, HomeAssistant & Co und das auch aus gewissen guten Gründen (z.b. um den DutyCycle gering zu halten bei Abfragen) |
Beta Was this translation helpful? Give feedback.
-
Ich glaube aber auch das viele der Middelwares nicht die Konfiguration des Systems also Scope haben. Dann interessieren einen die Paramsets normalerweise recht wenig. |
Beta Was this translation helpful? Give feedback.
-
Das stimmt teilweise (Homematic Manager bietet das prinzipiell auch). IMHO sollte man den Aufwand (wie du ja merkst) nicht unterschätzen und am besten die Idee von einer kompletten Konfigurationsoberfläche abseits der CCU WebUI verwerfen und besser vllt an der Restrukturierung bzw neuausrichtung der WebUI (siehe #1511) mitarbeiten. |
Beta Was this translation helpful? Give feedback.
-
Ich will tatsächlich auch nicht umbedingt eine gesamte Konfigurations Oberfläche nachbauen. Ich finde aber das gewisse Konfigurationen Mobil besser funktionieren. Ich arbeite gerade an einer mobilen App. Die App ermöglicht Konfigurationen an Geräten, wie beispielsweise Zeitpläne oder Direktverbindungen direkt am Gerät vorzunehemen. Das zu konfigurierende Geräte wird per Knopfdruck ausgewählt. Dadurch spart man sich das nervige einrichten einer Direktverbindung für jeden Empfänger. Eine Flurschaltung mit 4 Schaltern und 2 Lampen benötigt, da jeweils 2 Verbindungen pro Sender pro Empfänger benötigt werden, 16 Direktverbindungen. Das ist eine Menge die man nicht im aktuellen WebUI machen möchte. Es gab aber noch ein Problem, dass mein Vorgehen unmöglich gemacht hat. Das wurde jetzt aber in #1567 gelöst. |
Beta Was this translation helpful? Give feedback.
-
Yet Another App?!? Wäre es nicht sinnvoller sich an bereits existierenden Apps (tinyMatic, PocketControl, etc.) zu beteiligen als das Rad neu erfinden zu wollen, weil prinzipiell wirst du auf die selben Dinge stoßen wie die Apps? Und wenn man die CCU WebUI irgendwann sogar responsive hinbekommen würde wäre es ja sogar möglich einfach via smartphone auf die WebUI zuzugreifen und gut ist.
All das könnte man der existierenden WebUI auch beibringen und müsste hier nicht eine neue App&co bauen die dann wieder andere Limitationen haben wird. |
Beta Was this translation helpful? Give feedback.
-
Der Zweck meiner App is sehr begrenzt es geht um das konfigurieren von Geräten. Die meisten Apps, soweit ich weiß, sind dadrauf ausgelegt die Geräte zu steuern aber nicht Sie zu konfigurieren.
Die ganze WebUI responsive zu machen ist vermutlich sehr viel Aufwand. Die App bietet mir erstmal einen Weg die Technik/UX relativ einfach zu testen. (Sowohl das Problem mit der inkonsitenten API als auch mit der versteckten Direktverbindung wäre in der WebUI auch aufgekommen)
Ich hab tatsächlich schon dadrüber nachgedacht. Und das wäre der leichteste Weg die Funktionalität möglichst vielen zur Verfügung zustellen. Native Apps haben immer den Nachteil, dass Sie erst über die Stores zur Verfügung gestellt werden müssen. Das WebUI wird mit direkt zur Verfügung gestellt. Ich werde erstmal wie geplant einen Prototypen erstellen wenn der gut funktioniert würde ich mich freuen wenn wir nochmal dadrüber reden könnten ob/wie mein Prototyp in der WebUI funktionieren kann. |
Beta Was this translation helpful? Give feedback.
-
Falls dieses Ticket wirklich nicht durch RaspberryMatic zu reparieren ist schließt es gerne. Und danke für die Geduld! |
Beta Was this translation helpful? Give feedback.
-
Wenn das wirklich eine mögliche Option von dir ist solltest du dir in der Tat mal #1511 näher anschauen, denn arg weit weg von der originalen WebUI dürfen wir uns auch nicht wegbewegen wegen Kompatibilität und zukünftiger Updates und da stellt #1511 einen guten Kompromiss dar eine aktuelle js API einzuführen aber das Look&Feel zu versuchen beizubehalten. |
Beta Was this translation helpful? Give feedback.
-
Ich werde das mal in eine Diskussion konvertieren damit das ganze nicht ganz untergeht. |
Beta Was this translation helpful? Give feedback.
-
Describe the issue you are experiencing
Die XML-RPC Api ist inkonsistent.
Wenn ich die Methode getLinks order getParamset aufrufe, werden die Daten underschiedlich formatiert.
Das ParameterSet ist in getLinks und getParamset unterschiedlich formatiert.
Es ist nicht nur zwischen zwei Endpunkten unterschiedlich sondern auch innerhalb der Datensätze eines Endpunktes. Ein Beispiel sind die LONG_MULTIEXECUTE Werte
Das macht Integration schwierig.
Describe the behavior you expected
Die Formatierung sollte einheitlich sein.
Steps to reproduce the issue
What is the version this bug report is based on?
3.65.11.20221005
Which base platform are you running?
rpi3 (RaspberryPi3)
Which HomeMatic/homematicIP radio module are you using?
n/a
Anything in the logs that might be useful for us?
Additional information
No response
Beta Was this translation helpful? Give feedback.
All reactions