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.
Wenn der Ausgang ausgeschaltet ist, kann der Shelly Plus 1 PM nicht messen. Also geht deine Frage an der Machbarkeit vorbei.
Was kannst du stattdessen tun?
Du misst bspw. mit einem Shelly PM Gen 3 die eingespeiste Leistung. Dieser Mess-Shelly kann, abhängig von der gemessenen Leistung eine Nachricht per HTTP oder auch MQTT senden, welche ein anderer Shelly dazu veranlasst, zu schalten.
Nach /rpc/ muss es input.getstatus?id=0 heißen. Das steht alles recht genau in der Dokumentation.
Mit der Methode Input.SetConfig kann man nur den Eingang konfigurieren und nicht etwa abfragen.
Btw, die Methodennamen sind case insensitiv.
Genau genommen geht es um den Wechselrichter, dessen Daten erforderlich sind.
Und außerdem sind die 16A ein eher theoretischer Wert. Ich täte daran nichts über 1kW anschließen - nur mal zur Orientierung.
Die Schaltung ist sehr einfach und wird funktionieren.
Ich mag manchmal meinen Ruhestand - als 76 Jähriger. 
Und in Kürze ist der Tag der Arbeit (1. Mai). Vernachlässigt das bitte nicht! Ich bleibe zu Hause ... 
"Da staunt der Laie und der Fachmann wundert sich."
Alias: "Geht das?"
Meine Frage: "Wo gibt es noch mehr trial and error?"
Wer sich nun (als Laie) verunsichert fühlt, Glückwunsch!
Unsicherheiten sind gut und angemessen. Herumstocherei ist (mitunter) gefährlich.
Wer etwas Brauchbares/Gutes will, muss auch investieren - in Zeit oder in Geld oder in beides. Entschuldigt bitte meinen Kommentar! Manchmal wird es mir in der Konsumwelt zuviel. 
Verwirrend? Dann habe ich mein Ziel erreicht, zumindest etwa - eigentlich eher "Verunsicherung", aber das ist nicht vorgesehen. 
Bevor wir uns im Streben um Weisheiten verlieren. 
Ich kann vieles von euch akzeptieren, nur eines nicht.
Ein MUSS in diesem Kontext ist nicht förderlich, ein KANN ist ok.
aber in asynchronen Protokollen wie MQTT ist das sinnvoll.
Das zweifle ich an. Unter dem Aspekt einer beabsichtigten P2P Kommunikation erscheint es erforderlich. Wenn man dies als MQTT Fortschritt wertet, ist das ein Disput Argument. Aber ursprünglich ist so etwas kein MQTT Feature.
Nur mal so im Kontext dieses Thread.
Ich bin ja grundlegend sehr angetan von der Shelly Firmware Entwicklung. Klar, ich sehe manchmal auch einen Stolperstein. Aber ich finde, dass die Richtung - für meine Anliegen zumindest - stimmt. Auch die Dokumentation finde ich unter dem Strich sehr gelungen. All dies lässt mich an den Shelly "kleben", trotz Erfahrungen mit Tasmota und Berry (für manche Zwecke die bessere Alternative, insbesondere auf einem ESP32 Entwicklungsboard).
Ich bin kein naiver Konsument und mag Eigenkreativität. Hoffentlich wird Shelly solches weiterhin unterstützen und nicht in einen geschäftstüchtigen finanziellen Erfolg absteigen. Die Gefahr erscheint mir am Horizont erkennbar. 
Meinst du die Links bezüglich JSON RPC ?
Ja.
tvbshelly Die Links verweisen in einen anderen Kontext. Dieser erscheint mir an dieser Stelle wenig relevant. Zusätzlich zeigt die dort dargelegte Info ein Paradigma auf, nach welchem möglichst alle Informationen eingebettet sind, die ggf. nutzbar sind. Nutzbar! Aber nicht zwingend. Das ist der Knackpunkt. Deshalb schrieb ich von "kann" anstatt "muss". Ich kann somit keinen Widerspruch zwischen erforderlich und optional erkennen.
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.
Würdest du bitte zumindest einen der festgestellten Widersprüche beschreiben? Ich gehe gerne darauf ein.
Btw, ich habe oben einiges dargelegt. Ich halte es für nachlässig, meinen Darlegungen ungeprüft zu widersprechen. Es kostet meine Zeit und Mühe.
Trotz alledem freue ich mich an diesen euren Beteiligungen. Also, trotz Rauschen, macht weiter so!
Oder ist bei Shelly id Pflicht bei diesem generischen RPC Endpunkt?
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?
muss jedem Request eine (frei vergebbare) ID mitgegeben werden
Wenn das "muss" durch ein "kann" ersetzt wird, passt es.
dann benötige ich doch die ID für die Zuordnung von der Anwort zur Anfrage, oder?
Das impliziert die P2P Kommunikation, welche (s.o.) nicht MQTT basiert ist.
Das ist sehr einfach, auch wenn ich hier noch interpretiere.
Wenn du eine spezifische Komponente eines Zählers rücksetzen willst, dann musst du das zu rücksetzende Ding angeben. Dazu ist die type Komponente im params Objekt zuständig. Ob diese type Komponente verfügbar ist, ist zielorientiert zu prüfen. Dabei dürften die Antworten des Shelly Systems helfen.
Wenn ein spezifisches Rücksetzen nicht angestrebt ist, braucht type nicht angegeben zu werden. Dann ist der Parameter params typischerweise obsolet.
Eine Id Komponente in params ist nicht zwingend, weshalb ohne type auch params entfallen kann.
Habe ich mich (objektorientiert) verständlich ausgedrückt?
Btw, ich kenne mich mit Objektorientierung relativ gut aus. Unter einer Perspektive bedeutet dies Eigenverantwortlichkeit der Objekte. Diese stellen Kommunikationsschnittstellen zur Verfügung. Was sie mit einer Nachricht tun, bleibt den Objekten überlassen. Dieses Paradigma ist auch MQTT zu eigen. Eine Peer to Peer Kommunikation ist in MQTT nicht vorgesehen, entschuldige bitte meine Erklärungen. Wenn eine solche P2P Kommunikation erwünscht ist, müssen zusätzliche Infos in den Payloads eingepflanzt werden. Dafür ist aber MQTT nicht verantwortlich, sondern ausschließlich dessen Clients. Soll heißen:
"Ich (MQTT Broker) stelle mein schwarzes Brett zur Verfügung. Was Ihr (Clients) damit tut, bleibt euch überlassen. Wenn jemand von euch nicht erreichbar ist, kann ich das den anderen mitteilen (LWT), wenn ihr das so wollt."
es gibt laut Doku nur id und type
Ja, type muss aber im Objekt params enthalten sein, ein type ohne params funktioniert nicht.
- das ist leider etwas verwirrend in der Doku.
Das finde ich auch.
aber z.B. bei MQTT ... benötigt wird.
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.
Kleines Zurückrudern. Ich habe experimentiert.
Fazit: In params kann die Id weggelassen werden, was ich auch tue.
http://<IP Adresse>/rpc/Input.ResetCounters?id=2¶ms={"type":["counts"]}Im Skript:
Shelly.call("Input.ResetCounters", {id:2,params:{type:["counts"]}});Das ist insofern verständlich, als es im Plus Uni nur eine Zählerinstanz gibt.
Und es kommt noch besser.
Da in der Doku der zweite Parameter als optional angegeben ist, habe ich weiter reduziert. Ergebnis:
http://<IP Adresse>/rpc/Input.ResetCounters?id=2Im Skript:
Shelly.call("Input.ResetCounters", {id:2});Btw, mein Skript reagiert praktisch unmittelbar auf einen Impuls am Zählereingang, während das Web-UI stark verzögert aktualisiert.
Auszug aus meinem Experimentierskript:
let counter = 0;
function count(ev) {
if(ev.component!=="input:2") return;
Shelly.call("input.getstatus", {id:2},
function(res){
let c = res.counts.total;
if(c!==counter) {
counter = c;
print(counter);
}
}
);
}
Shelly.addEventHandler(count);
// Zähler rücksetzen
Shelly.call("Input.ResetCounters", {id:2});Vermutlich ignoriert die RPC Methode bei id 2 den zweiten Parameter. Oder man kann vielleicht im type spezifisch rücksetzen. Bei Muße will ich das mal testen.
Für Mitleser! 
Im Skript tut es bspw. folgender RPC:
Shelly.call("Input.ResetCounters", {id:2,params:{id:0,type:["counts"]}});Man kann an verschiedenen Stellen auch Anführungszeichen verwenden, wie bspw. "[counts]" statt ["counts"]. Insbesondere die Keys können in Anführungszeichen gesetzt werden. Ich mag eher die obige Notation, welche an JavaScript Objekten orientiert ist. Die [] müssen sein, weil (nach Doku) der type Wert ein Datenfeld sein muss.
Fazit: Die params Komponente im Objekt ist erforderlich.