So wie ich das kenne, ist das die übliche Darstellung für diese Art Diagramme (nicht nur bei Shelly):
Beiträge von tvbshelly
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.
-
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
WAS wollt ihr denn lösen, außer Ein- und Ausschalten?
->
Heizkörper ein Shelly Thermostat angebaut und wollten dies auch über die Website steuern
Ich nehme an, dass es sich hier um ein BLU TRV handelt, was gesteuert werden soll - das kann immerhin mehr als nur an/aus.
-
Warum fragst du dann?
Das erfährst du direkt im Satz, der deinem "gekürzten" Zitat folgt.
-
Ich täte daran nichts über 1kW anschließen
Mit rund 4A bist du dann aber deutlich im sicheren Bereich.
-
-
-
dass auf Phase C Minuswerte angezeigt werden,
Das ist bei Einspeisung korrekt.
das habe ich mit der Messrichtung- Umkehr auf Phase C geregelt.
Jetzt wird bei Balkonkraftwerkeinsatz anstelle der Leistung von knapp 800 W gerade die Hälfte auf Phase 3 angezeigt, dafür aber eine hohe, nichtstimmige Scheinleistung.
Hast du den Wandler gedreht oder in der WebUI umgestellt? Letztendlich wird aber die Umkehrung des Vorzeichens hier keinen Messfehler auslösen.
Woher weißt du, dass 800 W auf Phase 3 gemessen werden müssen? Weil das BKW das gerade produziert? Dann liegt hier ein Verständnisproblem vor.
Wo genau sind die Wandler vom Pro 3EM angeschlossen? Direkt hinter dem Zähler?
-
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 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")
