I would monitor the MQTT messages, for example, with MQTT Explorer. A better approach would be to use Node-RED. In a simple flow, an MQTT subscriber node (mqtt in) can receive and count the messages. Perhaps the messages are being sent too frequently.
The devices are really great but the firmware is crap.
I think the firmware, especially the underlying operating system, is very good. There are always bugs because the firmware is constantly being updated. Older firmware is not an alternative.
Ich habe in #8 mein Skript in Zeile 24 korrigiert. Vermutlich ist damit die Anzeige wie gewünscht.
Im Beitrag #8 habe ich den Hinweis ergänzt.
Ich habe den Hinweis auf die Zeiteinstellung ja nicht so ernst gemeint, weshalb ich ein Augenzwinkern dazu setzte.
Weiß den einer von euch, warum der Text Netzspannung sich nicht mehr von Eingeschaltet in Ausgeschaltet ändert?
Ich werde das Skript an der betreffenden Stelle mal genauer analysieren.
Schon klar. Aber im Kommentar der Vorlage des TE steht 10s.
Deine Einschätzung meines Skriptes ist nicht ganz richtig. Mein Skript ist genau so aufgebaut wie deines zu Anfang. Es arbeitet asynchron, d.h. das Eintreffen der Infos vom anderen Shelly wird nicht abgewartet. Ich kann dies aber leicht per Timer einbauen. Das Skript von towiat hingegen arbeitet synchron, weil die Verarbeitung der Infos in der inneren Callback Funktion stattfindet.
towiat's Skript: RPC -> callback -> RPC -> callback (hierin werden beide Infos verarbeitet)
Wenn du towiat's Skript verständlich finden solltest, ist seines im Zweifelsfall die technisch etwas bessere Lösung.
Und an euch beide: 10 s sind 10000 ms und nicht etwa 6000 ms. 
Es gibt auch Sonderregelungen und Ausnahmen von der Impressumspflicht. So sind beispielsweise rein private Webseiten, die keinerlei geschäftsmäßige Absichten verfolgen, in der Regel von der Impressumspflicht ausgenommen.
Gefunden unter Impressumspflicht für Webseiten: Regelungen und Beispiele - RECHTECHECK.DE
Um solche Webseiten handelt es sich bei mir. Auch las ich an verschiedenen Stellen, dass die Impressumspflicht zum Verbraucherschutz beitragen solle. Es gibt bei mir nicht einen einzigen Verbraucher, da ich hier ausschließlich Informationen zur Verfügung stelle, die für Interessierte gedacht sind und ich keinerlei Einnahmen damit erziele - im Gegenteil, diese Webseiten kosten mich monatlich ca. 13€. Ich trage damit also Verluste. Bekannterweise gibt es in diesem Forum auch einschlägige Geschäftsinteressen, was in vielen Fällen, so auch bei mir, in keiner Weise gegeben ist. Mehr Unkommerzionalität kann ich mir nicht vorstellen. Wenn ich gleich eine Art Impressum beifüge, dann keinesfalls mit meiner Adresse oder gar Email-Adresse und Telefonnummer.
Ich beschäftige mich bereits seit ca. 1994 mit dem WWW und veröffentlichte Webseiten, alle ohne geschäftliche Zwecke. Damals schrieb ich meine Email-Adresse noch hinein, woraufhin ich Jahre später massenhafte Spam-Mails erhielt und mich gezwungen sah, meine Email-Adresse zu ändern. Man muss mir also nicht von WWW bezogen relativ unerfahrener Seite kommen und etwas vom Pferd erzählen. 
Eine Real Time Clock mit Batteriepufferung wäre ja bereits eine zielführende Erweiterung. Damit sollte ein solcher Shelly auch ohne permanenten Zeitserverzugang auskommen - für den Zeitstempel.
Überzeugende Kombination, im Shelly vermutlich weniger wahrscheinlich - oder?
Ich bewerbe hier erstens nichts, es steht nur als Hinweis im Zusammenhang mit mitunter bedenklichem Einsatz einer Cloud.
Und zweitens, wie bereits tvbshelly bemerkte, leiste ich an gegebener Stelle auf eigene Kosten und ohne jeglichen direkten oder indirekten Gewinn Hilfestellung für technisch Interessierte.
Prinzipiell bin ich bereit, ein Impressum einzubauen, was ich auch auf einer anderen der von mir auf eigene Kosten etc. (s.o.) bereitgestellten Subdomains bereits tat. Ich finde es aber sehr merkwürdig, dass sich hieran jemand stößt (Krümelkackerei). Mich interessiert, ob du ( Jo_Be) auch Konstruktives beizusteuern hast.
Das Skript brauchst du ggf. erst dann hier zu posten, wenn es deinerseits einen weiteren Bedarf geben sollte.
Die boolesche Algebra greift bei den beiden Alternativen zur Inversion des Schaltens. Ich habe beide angeboten, damit Titty-Twister die für ihn verständlichere wählen kann.
Ansonsten hat das Skript von towiat den Vorteil der Synchronität, d.h. es werden die aktuell vom zweiten Shelly gelieferten Zustandsinformationen verarbeitet. Das von mir gekürzte Skript orientiert sich halt mehr am Ausgangsskript und dürfte für den TE deshalb zunächst vertrauter wirken. Durch die verfügbaren, kürzeren Funktionen ist es auch etwas leichter an Änderungen anpassbar.
Ich bin nie auf dem "modernsten" Stand von Verfügbarkeiten, empfehle (leicht naiv) aber generell beim Kauf die neueste Generation. Falls ältere Geräte, bspw. der zweiten Generation, vorhanden sind , können solche hierfür eingesetzt werden.
Der Hinweis von thgoebel sollte für deine Zwecke genügen. Bei finigraleren Wünschen ließe sich eine Kombination aus Schedule Jobs und Skript einsetzen.
Du musst schon selbst wissen, wie du es haben willst.
Klar, man kann alles, was gewünscht ist, recht einfach in Code umsetzen.
Ob dies in der Funktion setRelayState() oder in deren Aufruf erfolgen soll, ist perspektivisch zu betrachten - beides ist möglich, nur nicht zugleich. Letzteres täte sich gegenseitig aufheben.
Ich nehme hierfür bspw. mal den Aufruf.
setRelayState(!(switch_status[0] && switch_status[1]));Alternativ gelingt dies auch per Boolescher Algebra mit einer ODER Verknüpfung:
setRelayState(!switch_status[0] || !switch_status[1]);Die Boolesche Algebra gehört zu den tiefsten Grundlagen der IT.
Manchmal gewinne ich den Eindruck, dass Grundlagenkenntnisse nicht mehr angemessen geschätzt werden. Vielleicht sehe ich dies als "IT Dinosaurier" so. Die "moderne " KI gibt mir nicht zuletzt unter meiner Perspektive erheblich zu denken, als alter Knabe. Ich werde die Folgen aber nicht mehr ertragen müssen. Meine Kinder und Enkel werden unter den Fehlleistungen aktueller Politik leiden. Die Sprücheklopfer aus jedweder Richtung sind dafür verantwortlich, ohne sich als Schneeflocke für eine Lawine selbst zu erkennen. Nimm mir bitte meine Gedanken nicht übel! 
Ich interpretiere "EM" als energy measuremt und weniger als energy management.
Ja klar, das tue ich gerne.
Es wird aber ca. 2,5 Wochen dauern, bis ich wieder zu Hause bin.
Diese Site fand ich bereits, aber keine Doku zu dem Teil.
pdf?
Ich finde dazu keine Doku. Habt ihr die Teile etwa bereits, bevor sie auf den Markt kommen?
Aus gegebenem Anlass kann ich die Firmware 1.5.1-beta2 nicht empfehlen.
Meine Shelly Plus 2PM Hauptuhr zur Steuerung von Nebenuhren per Skript fiel nach Stromausfall aus, nicht rücksetzbar.
Ich setzte einen anderen Shelly Plus 2PM ein, aktualisierte dessen Firmware auf o.a. Version, richtete den Shelly ein (Skript, KVS, Schedule Jobs) und startete das Skript.
Resultat mit der beta2: Es gibt einen RPC Fehler, den dieses Skript zuvor noch nie verursachte. Nach Rückbau auf Firmware 1.4.4 läuft alles fehlerfrei. Vermutlich täte es dies auch bei 1.5.1, was ich aber nicht testete, da die Firmware Upgrades unterschiedlich zur Verfügung stehen, offenbar abhängig von der aktuellen Firmware auf dem Gerät oder anderen Daten. Diese Unstimmigkeit lässt ebenfalls noch Wünsche übrig ...
Noch ein Hinweis:
Mit MQTT ginge es ebenfalls recht verlässlich und komfortabel. Hierfür brauchst du einen MQTT Broker, welchen du vermutlich nicht vorhältst.
Mit retained MQTT Nachrichten kann der Shelly mit den Eingangszuständen ausschließlich bei einer Änderung als MQTT Publisher eine entsprechende Nachricht retained senden. Solche Nachrichten speichert der Broker.
Der empfangende Shelly als MQTT Subscriber erhält automatisch die vom Publisher zuletzt gesendete Nachricht. Dies erfolgt auch dann, wenn dieser Shelly hochfährt, weil er sich dann automatisch als Subscriber beim Broker meldet und dieser die letzte vom Publisher gesendete Nachricht an den Subscriber sendet.
Vorteile:
Nachteile:
Zur Verarbeitung der aktuellen Zustände beider Eingänge des anderen Shelly fallen mir ad hoc vier echte Alternativen ein.
Hinweis: Wenn du keine hohe Aktualität der Eingangszustände brauchst, empfehle ich der Einfachheit wegen Variante 1.2. Sie ist relativ robust.