Den Begriff "Abdeckung" hab ich erst hier im Forum das erste Mal gelesen und musste mich erst mal daran gewöhnen.
PitchControl Ah, jetzt verstehe ich. Sorry, ich habe mich an manche komische Begriffe schon so gewöhnt, dass es mir nicht aufgefallen ist, was du meinst.
Ich habe bei mir alles auf English eingestellt, was auch nicht immer perfekt ist, aber recht gut. Vermutlich wäre Bulgarisch die fehlerfreieste Fassung, aber das spreche ich nicht 
Die Werte sind aber nicht korrekt, und werden es auch nicht, nur weil man es behauptet 
Bei der jbmedia Wetterstation, die Westerwald2000 genannt hat, ist WLAN an der Bildschirm-Station. Der Bildschirm und die Außenstation sind per 433 MHz verbunden, was deutlich mehr Reichweite als WLAN ermöglicht.
Was möchtest du uns damit sagen? PitchControl
Hier mal in Englisch:
Flutschi Ja, die 3 Wandler sitzen korrekt. Die Leistung habe ich ausreichend oft mit dem eHZ abgeglichen. Auch bei der Energie habe ich oft genug sowohl die tägliche Energie-Differenz zw. Bezug und Einspeisung mit dem eHZ vergleichen als auch die monatlichen Werte. Das passt alles bis auf ein paar 100 Watt.
Trotz fehlerhaften Saldieren kann man bei meiner Anordnung mit dem gemeinsamen Raum ja jederzeit über einen beliebigen Zeitraum den Hausverbrauch Energie errechnen. Dadurch kann ich das auch recht gut überprüfen.
Nur nachträglich Saldieren ist eben nicht möglich.
Weil sonst wäre alles korrekt.
Wie müssten denn deiner Annahme nach die Wandler "sitzen", damit es in dem Dashboard mit Unknown stimmt?
OT: Beherrschet er die hohe Kunst des OT Schreibens oder tue er nur so?
ich hoffe du hast nichts dagegen.
Das ist absolut ok 
Das Datenblatt des BL0942 war mir durchaus bekannt. Es ist die Frage, ob man das Schalten im Nulldurchgang folgerichtig in der Shelly-Firmware implementiert hat.
Habe eben bei einem Shelly 1PM Gen3 nachgesehen: CF1 (Pin6) des BL0942 ist mit Pin 10 des ESP-Shelly-038F verbunden. Dieser Pin trägt die Bezeichnung MTDI bzw. GPIO5. Damit würde der Nulldurchgang der Spannung an den Prozessor gemeldet.
1.7.0-beta1:
Und daraus ergibt sich auch eine falsche Historie
Die falsche Historie entsteht dadurch, dass der Pro 3EM nicht saldiert.
Das Dashboard zeigt Leistung (d.h. Momentanverbrauch/Einspeisung an). Diese messen die Shellys zwar korrekt, aber das Dashboard macht daraus teilweise unsinnige Ausgaben.
Die Historie zeigt Energie. Energie wäre nur bei funktionierendem Saldieren korrekt. Deshalb ist die Historie bei PV Nutzung leider unbrauchbar - zumindest wenn man wissen möchte, wieviel man bezogen oder eingespeist hat.
Wir können ja mal ein anderes Beispiel nehmen, um zu zeigen, was auf dem Dashboard falsch läuft:
Diese Anzeige entspricht meiner Beschreibung, dass ich die beiden Pro 3EM (Grid & PV) in einen eigenen Raum gelegt habe. Die Tachonadel zeigt den korrekten Hausverbrauch von aktuell 230 Watt.
Der blaue Wert bei PV sind aktuell 3.82 kW Erzeugung, die erstmal ins Hausnetz gehen. Der grüne Wert beim Grid zeigt Einspeisung 3.6 kW an. Der Hausverbrauch (könnte man auch Eigenverbrauch nennen, vermeide ich aber) beträgt somit 220 W, was mit kleiner Rundungsungenauigkeit auch dem Tachowert von 230 Watt entspricht.
In "Verbrauch nach Gerätetyp" sieht man bei Netzquelle bereits den 1. Fehler (*): Hier wird ein Wert von 3.6 kW angezeigt - als Zahl korrekt, die Frage ist aber die Bedeutung der Richtung also das Vorzeichen. Aus Verbrauchersicht ist Bezug immer positiv, Einspeisung negativ: Daher müsste dieser Wert negativ sein (oder alternativ in grün angezeigt).
Unbekannt ist hier einfach die Summe von Erzeugung + Netzbezug = 7,4 kW (abzüglich des aktuell sehr kleinen Wertes für die Heizung).
Da es nur Unbekannt und Heizung gibt, müsste die Summe also dem Hausverbrauch entsprechen - hier steht 7,4 kW. Der echte Hausverbrauch ist aber 220 - 230 Watt. Ursache: Der Vorzeichenfehler bei (*)
Wenn man eine 1-phasige PV Messung macht, scheint es nochmal anders ausgewertet zu werden. Hierbei ist PV Erzeugung bereits bei der Messung negativ. Das ist zwar eine vermutlich technisch notwendige Sache, aber logisch bezüglich Vorzeichen leider falsch. Richtiger wird die ganze Rechnung dabei aber auch nicht.
Der Shelly Pro EM-50 ist einphasig, daher gibt es:
Ich denke, du kannst daher im Skript EMData.GetStatus ersetzen durch EMData1.GetStatus und EM.GetStatus durch EM1.GetStatus
id: 0 ist dann der 1. Kanal (CT) und id: 1 wäre der 2. Kanal, wenn du den auch auswerten möchtest.
Siehe:
https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen2/ShellyProEM/
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM1
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/EM1Data
Ich hoffe, das hilft dir schonmal weiter.
Ich habe leider keinen Pro EM-50 zur Hand um das Skript umgeschrieben selber zu testen.
Schwierig, deshalb geht es da auch nur so schleppend voran mit Fehlerbeseitigung.
Mir scheint, der Support basiert seine Argumente gern mal auf den Daten, die angezeigt werden, anstatt zu prüfen, ob die Werte überhaupt plausibel sein können 
Gute Fehlerberichte sind auf der anderen Seite auch nicht einfach zu schreiben. Das trifft aber m.E. nicht auf deinen Fall zu. Hier hatte ich gehofft, es ist für den Support recht einfach nachvollziehbar 
Blech ist i.d.R. wie ein Isolator für Radiofrequenzen…
Meine Erfahrung mit den Pro 3EM Shellys ist, dass trotz Blechtüren das WLAN noch erstaunlich gute Erreichbarkeit hat (bei mir so -70 bis -75, Shelly sieht ein Signal ab -80 RSSI und kleiner erst als kritisch an)
Auch BLU Gateway Kopplungen mit den Pro Shellys im Kasten funktionieren recht stabil (BLE nutzt ja auch 2.4 MHz).
Bei den RPC Methoden erscheint mir dies gelungen
Bei Aufruf dieser via http ist Groß-/Kleinschreibung sogar egal - was für viele die Nutzung sicher auch einfacher macht.
In einer Programmiersprache wie "Shelly-Script" ist sowas nur schwerlich machbar. Stimme dir daher voll zu, dass eine einheitliche Schreibweise von den Methoden wichtig ist (ob groß oder klein unterliegt sicher persönlichem Geschmack und dem Zeitgeist )
Wenn Bugs beseitig werden, muss man Skripte anpassen - keine Frage. Aber immer "mal wieder einfach so" aufgrund von Firmwareupdates ist frustrierend.
Ach, das ist gar nicht so schwer: Es braucht keine besondere Ausbildung, um Verdrahtungsfehler zu machen…
OT: Aber für die hohe Kunst der Vertuschung oder Ausrede hinterher bedarf es schon besonderer Fähigkeiten - oder vielleicht doch nicht ?
Nachtrag: Ab Firmware 1.6.x muss start() groß geschrieben werden:
BLE.Scanner.Start({duration_ms: BLE.Scanner.INFINITE_SCAN});Hier liegen (zumindest) zwei Fehler in der API Dokumentation.
Richtig lauten die beiden Methoden des BLE.Scanner Objektes zum starten und stoppen
BLE.Scanner.Start() und BLE.Scanner.Stop(). Großschreibung statt Kleinschreibung!
Da ich den Codeschnipsel aus einem bei mir laufenden Script kopiert hatte, wollte ich dir zuerst schreiben: Es geht beides. Habe ich dann sogar ausprobiert wie man hier in den Screenshots sieht:
Aber: Das stimmt aber nur für Firmware 1.5.1.
Ab 1.6.x funktioniert nur noch Großschreibung. Kein Wunder, dass die Doku nicht stimmt.
Ich finde es ziemlich ärgerlich, dass sowas geändert wird. Es gibt auch keinen Hinweis dazu in den Release-Notes.
Parallelbetrieb des Pro 3EM mit WLAN und LAN ist nicht zum empfehlen, das führt erfahrungsgemäß zu Netzwerkproblemen. Man könnte zwar denken, das wäre als Backup eine gute Idee, ist es aber netzwerk-technisch bedingt nicht.
Habe die Firmware von 1.5.1 auf Beta 1.6.2 geändert - kein Erfolg.
Die aktuelle Firmware ist 1.6.2 (ohne Beta) - wird dir diese nicht angeboten?
Hatte jetzt überlegt, ob ein Shelly LAN Switch eine Besserung bringen würde, um einen firmeninterne bessere LAN-Kommunikation zu ermöglichen?
Ich nutze mehrere Pro 3EM seit langem an einem Shelly LAN Switch - absolut stabil. Der LAN Switch unterstützt nur 10/100 MBit, da aber die PRO Shelly auch nur 100 MBit unterstützen, passt das gut zusammen.
Allerdings sollte es genauso gut mit jedem handelsüblichen Switch funktionieren.
Du kannst auch folgenden Aufruf nutzen um alle verfügbaren Componenten zu ermitteln:
http://<shelly-ip>/rpc/Shelly.GetComponents