-
-
Notifications
You must be signed in to change notification settings - Fork 192
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XML-RPC ist inkonsitent #2024
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. |
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 |
Danke. Und dann bitte noch einzeln/genauer thematisieren welche konkreten probleme / Inkonsistenzen du siehst bzw problematisch ansiehst. |
Im XML sind 2 Links.
Desweiteren sind die Parameter auch im folgenden getParamset nicht so formatiert wie im getLinks.
|
Die Anfragen werden ja direkt vom HMIPServer beantwortet. Fixen kann das nur eQ-3. |
Kann man die Anfrage nicht abfangen und vorher bearbeiten? Aber ich werde mich Mal an den Support wenden. Danke. |
Laut XmLRPC Spec ist liegt hier kein Fehler vor:
Wenn kein Typ spezifiziert wurde ist der Typ Warum eq-3 hier mit einem String |
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. |
Die meisten werden wohl nicht das XML parsen, sondern eine XmlRPC-Client Bibliothek verwenden. |
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. |
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) |
Ich glaube aber auch das viele der Middelwares nicht die Konfiguration des Systems also Scope haben. Dann interessieren einen die Paramsets normalerweise recht wenig. |
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. |
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. |
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. |
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. |
Falls dieses Ticket wirklich nicht durch RaspberryMatic zu reparieren ist schließt es gerne. Und danke für die Geduld! |
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. |
Ich werde das mal in eine Diskussion konvertieren damit das ganze nicht ganz untergeht. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
The text was updated successfully, but these errors were encountered: