auch der zweite „Happen“ wirft weitere Fragen auf
Daher bitte konstruktiv bleiben 😉
Ich finde, dass Thomas schon recht hat - was sprach dagegen, im ersten Rutsch die Anleitung zu posten?
Zur Auflösung des "Ratespiels" hier der "verdeckte" Teil:
Beiträge von tvbshelly
-
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
der hat einen Potentialfreien Relaiskontakt und darf Mischbetrieb haben
Dieser "Mischbetrieb" heißt, das Gerät ist SELV konform
-
die Klemmen 4 und 5 zum Anschluss eines Wandschalters
Dann passt das:
Klemme O des Shelly plus 1 mit Klemme 4 der Torsteuerung verbinden; Klemme I des Shelly mit Klemme 5. Einen Auto-Off-Timer mit Laufzeit 0,5 bis 1 Sekunde einstellen.
-
Die IT Welt dreht immer schneller - wohl wahr.
-
Aber ursprünglich ist so etwas kein MQTT Feature.
Das ist auch weiterhin kein MQTT Feature.
Aber es gibt wohl sogenannte Pattern, mit denen man Request/Response via MQTT nachbilden kann.
https://www.hivemq.com/blog/mqtt5-ess…sponse-pattern/
ZitatThe inclusion of the request-response pattern in the MQTT 5 specification was largely driven by the need for these “business ACKs.” MQTT users sought the capability to provide end-to-end acknowledgments between an application message’s sender and receiver
Die Zuordnung erfolgt hier mit etwas, was Correlation Data genannt wird.
Ich kenne das von IBM MQ unter dem Begriff correlation id, und vermutlich heißt es bei JSON RCP via MQTT eben id.
-
Zumindest klingt es danach - das müsste man testen.
Ich habe leider keine Gen4 Geräte, da ich Zigbee nicht nutze
-
Verrätst du uns noch, was falsch war? Vielleicht hat jemand anderes später mal das gleiche Problem
-
Ich denke nicht, dass es hier um Weisheiten geht. Unser "Disput" dreht sich um was anderes:
Es gibt hier 2 unterschiedliche Dinge in meinen Augen:
1. die direkten Befehle an den Shelly via HTTP oder Shelly.call - hier gibt es weder id im Sinne von Request id (!) noch params.
2. Befehle an einen generischen Endpunkt:
So wie ich das verstehe verwendet Shelly für MQTT Befehle und für den generischen HTTP Endpunkt /rpc die JSON RPC Spezifikation.
Diese legt fest, dass jeder Request eine id als Parameter schickt und der Verarbeiter dieser Nachricht/Request in der Antwort zur Zuordnung diese id wieder angeben muss.
Letztendlich ist es da egal, ob man das für sinnvoll, notwendig oder zwingend hält - es ist eben so definiert für JSON RPC.
Da müssen wir uns nicht einmal einigen. Wenn du es nur mit "kann" akzeptierst und für dich die Aufrufe funktionieren - was mich zwar wundert, weil zumindest laut Spec diese id Pflicht ist, aber vielleicht ist es der Shelly Implementierung auch egal - ist es doch ok.
-
Ich denke schon, dass die relevant sind.
Laut Shelly Doku
https://shelly-api-docs.shelly.cloud/gen2/General/R…rame-as-payload
ZitatClients POST to /rpc on the Shelly, supplying the entire JSON RPC call frame as payload
verwendet Shelly hier den JSON RPC Standard. Dieser wird für 1.0 hier
https://www.jsonrpc.org/specification_v1
und für den aktuellen 2.0 - keine Ahnung, was Shelly nutzt - hier dokumentiert:
https://www.jsonrpc.org/specification
So wie ich das verstehe, ist in beiden Versionen in der Payload der parameter id ein Pflichtwert, um die Antwort der Anfrage zuzuordnen.
Bei einem synchronem HTTP Post erscheint das ein wenig seltsam (schadet aber auch nicht), aber in asynchronen Protokollen wie MQTT ist das sinnvoll.
Diese JSON RPC Aufrufe (Endpunkt /rpc) sind etwas völlig anderes als die direkten Aufrufe via der Methode Shelly.call("Input.ResetCounters")
-
Die Links verweisen in einen anderen Kontext.
Meinst du die Links bezüglich JSON RPC ?
Wir bleiben hoffentlich dran. Es kann nur erhellend sein.
Sorry, ich brauche immer Zeit zum nachdenken und formulieren. Deshalb bezieht sich dieser Beitrag nicht auf deinen letzten.
Lass dir Zeit - Sorgfalt ist hier wichtiger als der schnelle Klick - ich hoffe, ich bin nicht zu schnell mit meinen Antworten
-
Fazit: In params kann die Id weggelassen werden, was ich auch tue.
Code http://<IP Adresse>/rpc/Input.ResetCounters?id=2¶ms={"type":["counts"]}Im Skript:
Code Shelly.call("Input.ResetCounters", {id:2,params:{type:["counts"]}});Das ist insofern verständlich, als es im Plus Uni nur eine Zählerinstanz gibt.
Ob hier params ignoriert wird oder nicht, kann man meiner Meinung nach nicht feststellen, weil es eh nur einen Zähler gibt und dieser bereits durch die Angabe der ?id=2 bzw. bei Shelly.call {id:2} zurückgesetzt wird. Ob mit oder ohne Angabe von type ändert nichts.
-
Nein, eine solche Id ist keine Pflicht. S.o. Beitrag #7.
towiat Entweder du bist falsch informiert oder du verwendest einen anderen Kontext als ich. Wenn du deine Quelle genauer spezifizierst, habe ich Gelegenheit, diese zu prüfen. Ist dein Kontext die System MQTT?
Laut Shelly Doku: supplying the entire JSON RPC call frame
https://shelly-api-docs.shelly.cloud/gen2/General/R…rame-as-payload
Zitathttps://www.jsonrpc.org/specification_v1
->
1.1 Request (method invocation) ¶
A remote method is invoked by sending a request to a remote service. The request is a single object serialized using JSON.
It has three properties:
- method - A String containing the name of the method to be invoked.
- params - An Array of objects to pass as arguments to the method.
- id - The request id. This can be of any type. It is used to match the response with the request that it is replying to.
-
Btw, ich habe oben einiges dargelegt.
Sorry, aber das dargelegte ist widersprüchlich in meinen Augen.
Aber wir können es auch einfach so im Raum stehen lassen
-
Dazu ist die type Komponente im params Objekt zuständig.
Aber nur beim generisch RPC Endpunkt - wenn du das direkt addressierst mit Input.ResetCounters musst man den Parameter type direkt angeben.
-
Wenn das "muss" durch ein "kann" ersetzt wird, passt es.
Inhaltlich auf jeden Fall - aber erlaubt Shelly das? Oder ist bei Shelly id Pflicht bei diesem generischen RPC Endpunkt? Leider schweigt sich die Doku dazu aus
Edit: towiat war schneller
-
In diesem Protokoll muss jedem Request eine (frei vergebbare) ID mitgegeben werden, mit der man - wenn nötig - den Request an den Shelly mit dessen Response abgleichen kann. Diese ID hat aber nichts mit der ID des abgefragten Objekts zu tun.
Genau das hatte ich geschrieben bzw. zumindest gemeint
- ich hoffe, nicht allzu unverständlichZitatDieser Endpunkt hat auch einen Parameter id damit man in der Antwort diese der Anfrage zuordnen kann
-
Das impliziert die P2P Kommunikation, welche (s.o.) nicht MQTT basiert ist.
Ich denke, Request/Response kann man auf diese Weise mit MQTT simulieren. Ansonsten wäre die ID doch völlig unnütz.
-
geht glaub ich auch in Software am Shelly)
Ja, das geht und ist vermutlich einfacher als die Kabel erneut umzuklemmen
-
Die nun freien Klemmen des Funkempfängers Klemme 1 (L1 "down") und 3 (L2 "up" ) verbinden mit den Eingängen des Shelly's S1 und S2
=> Dies ist nur notwendig wenn du den Funkempfänger weiter wie gehabt nutzen willst.Sofern benötigt: Ausprobieren - möglicherweise wird das nicht funktionieren, weil der Funkempfänger kein echter Schalter ist.
-
Nur bei der MQTT Nutzung per System, weil dieses für eine Peer to Peer Kommunikation over MQTT eingerichtet ist. Notwendig ist diese Nutzung aber nicht.
So ganz verstehe ich nicht, was du schreibst. Der Shelly "antwortet" in einem Topic auf eine Nachricht an "/rpc", in dem auch andere Nachrichten, z.B. automatische Statusupdate gesendet werden - dann benötige ich doch die ID für die Zuordnung von der Anwort zur Anfrage, oder?
