VPN/Proxy erkannt
Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.
Ich habe den Shally Plug an einem Balkonkraftwerk mit 2,0 KW peak angeschlossen um die Leistung zu monitoren.
Für eine Dauerleistung von gerade mal 2,0 KW
Welche Einspeise-Leistung hat dein BKW jetzt konkret? - es geht nicht um die Panel
Mach doch mal bitte ein Foto vom Typenschild.
Dann läuft die Abfrage nicht über das Device API / RPC sondern das Cloud API - das macht es eher komplizierter als nötig.
Doku für das Cloud API:
https://shelly-api-docs.shelly.cloud/cloud-control-api/communication-v2
Vermutlich ist es einfacher, das Device API zum Auslesen zu nutzen. Dafür ist dann nur wichtig, dass der Shelly vom Router per DHCP immer die gleiche IP bekommt oder du eine feste IP eingestellt hast.
Hier die Doku dafür für deinen Shelly 1 Gen4:
https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen4/Shelly1G4
weshalb Balkonkraftwerke auf max. 800W
Balkonkraftwerk mit 2,0 KW peak
Thomas, ich denke hiermit ist die Leistung der angeschlossenen Panel gemeint (wird in kW peak angegeben).
Nachdem die letzten Tage sehr sonnig waren ist es dem Shelly trotz 16A Zulassung zu heiß geworden.
Die Kontaktkelche der Steckdose hätte ich gerne gesehen. Hier liegt wohl die Wurzel des Übels: Zu geringer Kontaktdruck wegen Verschleiß?
Ich frage mich hier auch, ob diese Steckdose überhaupt grundsätzlich für 16A ausgelegt war.
Was steht als URL in der Variable cloud_url ?
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:
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/
The 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
Clients 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
https://www.jsonrpc.org/specification_v1
->
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:
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ändlich
Dieser Endpunkt hat auch einen Parameter id damit man in der Antwort diese der Anfrage zuordnen kann
