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.
Ob es eine, zwei oder 10 Fernbedienungen der gleichen Art sind, ist total egal.
Entscheidend hierbei ist, ob du - oder wer auch immer - eine Taste zum umschalten oder eine Taste für Ein und eine Taste für Aus hast.
Bedenke, dass du etwas realisieren willst, was nicht vorgesehen ist!
An deinen Fotos kann ich nichts funktionswichtiges erkennen.
Martins Schaltskizze ist eindeutig.
Entscheidend für dein Ziel ist aber die Art der Fernbedienung - ein Taster je Verbraucher oder zwei Taster je Verbraucher.
Zeige doch mal deine Fernbedienung!
Krauskopp Anleitung muss passen.
Der McPower verhält sich offensichtlich wie ein Schalter - nur ferngesteuert.
Stelle dir mal stattdessen einen Schalter am SW Eingang (= Input (0)) des Shelly vor!
Du schaltest die Lampe ausschließlich per Shelly ein oder aus. Davon bekommt der McPower aber nichts mit, ein entsprechender Schalter auch nicht.
Wenn du nun mit der Fernbedienung schalten willst, dann schaltet der McPower um, so als ob du einfach mal auf einen Schalter drückst - unabhängig davon, in welcher Schaltstellung dieser steht.
Du willst ja sicher nur dann mit der Fernbedienung schalten um den Schaltzustand des Verbrauchers (Lampe) zu ändern.
Somit muss mit jeder Änderung am Ausgang des McPower der Shelly den Ausgang umschalten.
Genau das ist die Funktion des Modus "Edge switch" im Shelly.
Hm, was bietet denn die Fernbedienung? Einen Taster zum umschalten oder einen Taster für ein und einen Taster für aus?
Bei Letzterem wird es so, wie du willst, nicht gelingen können.
Grund: Du musst dann immer wissen, in welchem Schaltzustand der McPower steht - und das Gegenteil auf der Fernbedienung wählen.
Oder du drückst die andere Taste, wenn es mit der ersten nicht geklappt hat. 
Ich hoffe, uns nicht zu verwirren. 
Ok, danke für deinen Hinweis Martin.
Ich habe die Einspeisung übersehen. Da zeigt sich wieder, dass ich keine PV besitze. 
Dann passe ich meinen obigen Post an.
wen z.B. 800W erzeugt werden, ist das noch lange nicht der erzeugte Überschuss, es sei denn, es gibt keine weiteren Verbraucher. Dazu muss der Verbrauch ja auch gemessen werden und damit auch der nicht verbrauchte Anteil vom Ertrag.
Vielleicht ist ihm das nicht wichtig.
Ich nutze die Cloud ausschließlich als zusätzliche Option. Imho sollte eine von dir angestrebte Lösung keiner Cloud überlassen werden - was ist, wenn die Cloud nicht erreichbar ist?
Eine lokale, autarke Lösung ist, wie Krauskopp bereits erwähnte, mit einem Shelly der zweiten Generation wie Plus 1PM und einem darauf laufenden Skript erreichbar. Aber ...
Afaik kann ausschließlich eine von den Kraftwerken entnommene Leistung gemessen werden und keine solche, die (potentiell) verfügbar ist. Somit müsste in gewissen Abständen ein Verbrauchen eingeschaltet und gemessen werden, um die Gesamtleistung zu ermitteln.
Ich bitte um eine Korrektur dieser Annahme, wenn es eine andere Möglichkeit zur Messung geben sollte.
Fragen:
Hierzu kann ich keinen getesteten Beitrag liefern, weil ich weder ein Kraftwerk noch einen Shelly 1PM besitze, aber mehrere 2.5, Plus 2PM und Plus 1 (ohne PM).
Um mich der Lösung zu nähern, täte ich einen der beiden Shelly (1. Gen.) gegen einen der zweiten Generation, oder beide durch einen skriptfähigen EM austauschen. Im zweiten Fall wäre afaik noch ein Schaltaktor erforderlich.
Das Skript kann beide Leistungsmesswerte erfassen. Ich gehe auf eine Lösung ein, die einen Plus 1PM nutzt. Mit einem übergeordneten System (ich nutze dafür Node-RED Flows) gelingt so etwas auch, was aber etwas weniger autark ist.
Das Skript kann folgende Dinge tun.
Sollte der Empfang des verbleibenden Shelly 1PM nicht gelingen, was ich nicht vermute, kann notfalls auch dieser durch einen der zweiten Generation ersetzt werden.
Falls du dir das Erstellen eines Skriptes zutraust, kann ich dir eine solche Lösung empfehlen.
Andernfalls kann ich nur ein Skript anbieten, welches den funktionalen Rahmen bietet. Darin müssten die Anweisungen ergänzt werden, welche die Messwerte des anderen Shelly holen und im Skript zwischenspeichern.
Noch einmal der Hinweis:
Eine solche Lösung per Cloud ist nicht ausfallsicher und schon deshalb nicht empfehlenswert. Für möglichst ausfallsichere Lösungen sind diese weitgehend autark zu implementieren.
Schade, du kannst oder willst offensichtlich nicht sorgfältig lesen.
Wenn du das nämlich tätest, würdest du spätestens nach meinen Reaktionen erkennen müssen, dass ich kein Skript angeboten habe.
Ich habe vermutlich mehr Zeit deinem Thema geopfert als du selbst.
Darüber mal nachzudenken, wäre angemessen.
Und deinen Sarkasmus kannst du dir schenken. Er ist nicht angebracht und destruktiv.
Ein derart impertinentes und ignorantes Verhalten ist mir hier noch nicht begegnet.
Edit:
Falls du bereit bist, trotz unserer Differenzen, konstruktiv an deinem Thema und mit möglichen, auch alternativen Implementationen zu experimentieren, können wir hoffentlich diese Differenzen hinter uns lassen. Eine fertige Lösung auf die Schnelle wirst du vermutlich mit der derzeitig aktuellen Firmware und Cloud nicht erhalten. Falls doch, darfst du gerne mein Statement ignorieren.
Von meinen 5 im Einsatz befindlichen TRV fallen immer mal wieder welche aus, d.h. ich erreiche sie im Netz nicht mehr und sie sind auch nach Akku aufladen und Resets nicht erreichbar.
Ich muss immer wieder mal experimentieren, was mich inzwischen sehr stört.
Deshalb steige ich auf Shelly Plus 1 mit AddOn + Ventilantrieb und insbesondere selbst erstelltem Skript um.
Diese Kombination arbeitet erheblich zuverlässiger und ähnlich autark wie die TRV.
Das System Shelly läuft eigentlich ganz gut. Bis auf die Fühler.
Für die Fühler kann "das System Shelly" nichts - bis auf die Empfehlung, DS18B20 einzusetzen. Für die Fühler ist letztlich der Anwender zuständig.
Dein Einsatz erscheint auch leicht grenzwertig bei solch hohen Temperaturen - mit allen Einschränkungen der von DIYROLLY angemerkten fakes.
Du verwendest offensichtlich die Cloud (Stichwort Szenen), ich weiß allerdings nicht, zu welchem Zweck.
Wenn du damit etwas regeln lässt, kann ich nur davon abraten, die Cloud zu verwenden, wenn diese Regelung wichtig ist.
Wie ich bereits an anderen Stellen anmerkte, ist die Cloud nicht hinreichend funktionssicher.
Für wichtige Regelungen sollte etwas Lokales eingesetzt werden, damit solche Regelungen auch bei Ausfall der Cloud oder des Internetzugangs noch funktionieren.
Das ist irgendwie logisch.
Es bleibt die Frage, warum diese Sensoren in solch kurzen Abständen ausfallen.
Auszug aus dem Datenblatt: Measures Temperatures from -55°C to +125°C
Liegen deine zu messenden Temperaturen oberhalb 125°C?
Nach deiner Eröffnunng eher nicht.
Hm ...
Ich nutze zwar keine Szenen (aus guten Gründen), eine Notwendigkeit der Umkonfiguration bei einem Sensortausch kann ich aber nicht erkennen.
Die Komponente ist jeweils unabhängig vom Sensorexemplar "temperature:100" bzw. "temperature:<Sensor Id>", die Id Werte der am AddOn angeschlossenen Sensoren beginnen mit 100, dann101, ...
In der grafischen Oberfläche heißen diese Temperature (100) ...
Eine Sensor interne Id, mit welcher die Firmware den jeweiligen Sensor erkennt, sollte in den Anwendungen keine Rolle spielen, da die Firmware die o.a. Id (100, ...) bereitstellt.
Edit:
Ich musste bisher keinen solchen Sensor tauschen. Ich weiß somit nicht, ob mit einem Tausch die Firmware eine neue Id vergibt. Evtl. kann hier ein solches Problem vorliegen, wenn mehrere Sensoren an einem AddOn angeschlossen sind.
Ich habe diesen Thread als Anlass genommen, eine Einführung in Shelly Scripting zu erstellen.
Diese Einführung ist hier zu finden: Skripteinführung - Teil 1
Warum habe ich dies in Angriff genommen?
Ich sehe immer wieder, dass hier die Cloud zusammen mit Szenen und sogar für Temperaturregelungen bevorzugt eingesetzt wird.
Ich kann davor nur warnen.
Wenn, durch welche Ereignisse auch immer, die Cloud oder gar der Internetzugang ausfällt, funktionieren solche Szenen und Regelungen nicht mehr.
Deshalb halte ich es für zweckmäßig, die Cloud als zusätzliche Option zu verwenden, wann man dies mag - aber keinesfalls als obligatorischen Bestandteil.
Alles, was ein Shelly eigenständig abarbeiten kann, ist deutlich funktionssicherer als eine Cloud-Lösung und sogar funktionssicherer als eine Implementation in einem übergeordneten lokalen System.
Dies halte ich für triftige Grunde, im Zweifelsfall und bei hinreichendem Engagement auf Skript-Implementationen zu setzen.
Auch bei Einsatz eines übergeordneten Systems ist eine zumindest teilweise Autarkie eines Shelly für dieses System entlastend. Skripte können auch adaptierend eingesetzt werden, um Nachrichten an das übergeordnete System "mundgerecht" bereitzustellen.
Der bekannte Nachteil besteht in der Zweckdienlichkeit, zumindest grundlegende Kenntnisse im Shelly Scripting zu besitzen.
Falls sich jemand meine bisher erstellte Einführung "antun" sollte und dabei Verständnisfragen auftreten, bin ich gerne bereit, mich auf solche Fragen einzulassen.
Es kann aber auch sein, dass ich dann auf andere Dokumentationen verweisen muss.
Aah, das fällt unter meinen möglichen Fehlerpunkt 6. 
Ich habe mit allen vieren keine Erfahrung.
Und dafür gibt es auch für
Deppen wiemich, fertige Beispiele. Logisch.
Ich nehme allenfalls solche Beispiele als Anregung. Bisher sah ich nichts, was bereits für meine Ziele "fertig" war.
Er wollte ja gerade bei Handbetrieb die Sperre ("wenn ich z. Bsp. den Taster betätige")
Das ist unerheblich. Entscheidend ist die Tatsache, dass es per Skript möglich ist, unterschiedliche Quellen zu unterscheiden und daraufhin selektiv arbeiten zu lassen.
Das derartige Ziel des Klienten kann so implementiert werden.
Für mehr Übersicht in einem per Skript gespeicherten Protokoll habe ich folgende Idee.
Das Protokollskript sollte separat arbeiten, also unabhängig vom Applikationsskript.
Zum Protokollskript:
Es erhält den gleichen Eventhandler wie das Applikationsskript, welcher aber etwas anderes tut.
Er speichert gewisse, in Verdacht gerate Dinge in einer Datenstruktur - oder in mehreren. Ich nenne diese mal Verdacht.
Das Protokollskript erhält eine weitere Funktion, ich nenne sie mal speichern().
speichern() sorgt irgendwie dafür, dass die Daten in Verdacht gespeichert werden, lokal oder per Nachricht remote.
Das Applikationsskript nutzt Ausnahmebehandlung (try, catch).
Im catch Block wird per ein Ereignis ausgelöst, welches vom Protokollskript zum speichern verarbeitet wird.
oder
Im catch Block wird per Methode "Script.Eval" die Funktion speichern() aufgerufen.
Auf diese Weise wird eine Protokolldatei nicht voll gemüllt sondern enthält evtl. interessante Informationen.
Welche Dinge zu speichern sind, hängt vom Verdachtsfall ab.
Edit:
Um einen Shelly.call() Aufruf zum speichern zu vermeiden, ist es vielleicht doch besser, die Teile vom Protokollskript in das Applikationsskipt zu integrieren.
Automatik-, Zeit- und bspw. Helligkeits-gesteuerter Betrieb lassen sich leicht in einem Skript unterscheiden und entsprechend kann der Handbetrieb ungesperrt arbeiten.
Und nun eine Lösung für "NichtSkriptFans"
Die sollen hinausgehen und das Eis abkratzen.
Im Ernst:
Ohne Skript lassen sich imho ausschließlich vorgesehene Dinge implementieren.
Alles, was darüber hinausgeht, ist etwas für Skripte - und bei Bedarf Schedule Jobs.
Dann schreibst Du ein dickes Skript, mit dem Du dann die Rollladenfunktionen in allen Plus2PM abschaltest.
Sooo dick muss das nicht sein. Ein Datenfeld mit Einträgen für alle betreffenden Shelly und eine passende Schleife ...
Da gibt es das Wetter umsonst.
Es gibt etwas umsonst? Wo wo wo ... 
Das Wetter ist immer umsonst, nur manche Folgen nicht. Und das (erste) ist gut so.
Sorry, das waren halt Steilvorlagen - tue ich sonst eher nicht.
Kann ich dem Shelly vlt. explizit auftragen, nach einem Addon zu suchen?
Habe ich noch nicht versucht. Die Dokumentation beinhaltet Sys.SetConfig ... https://shelly-api-docs.shelly.cloud/gen2/0.14/Comp…s#configuration sorry, erst ab der zweiten Generation
Zwecks Fehlersuche erscheint es zielführend, vom Groben zum Feinen vorzugehen.
Falls eines von beiden den Fehler beseitigt, zwecks Kontrolle vorheriges Teil desselben Typs wieder einbauen und testen.
Tritt der Fehler wieder auf, dieses Teil reparieren (lassen) oder entsorgen.
Mögliche Fehlerursachen:
Viel Erfolg!
