2PM mit den Temperaturen (50°C) wirst Du kaum finden.
2PM G3 (Eco aus):
"temperature": { "tC": 52.5 }
Raumtemperatur: 28.6 ° C
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.
-
-
Habe soeben auf Kanal 1 umgestellt, danach konnte ich das WD nicht mehr erreichen....
WD Full Reboot gemacht oder besser noch: aus - warten - an ?
-
Ist an android 7 beim normalen
Ja, ro.build.version.release sagt Andoid 7.0 mit Security Patch 2018-05-05
... aaaaarrrrgggsss 
-
Vermutlich sollte man eine Beta Firmware "mit spitzen Fingern anfassen"
Du sagst es: Skript aus #24
1.5.1 Skript funktioniert: Events nur wenn man das Rollo steuert 1.6.2 Skript funktioniert: eine Menge Cover-Events (auch ohne Rollosteuerung) 1.7.0-beta1 ein paar wenige (circa 8 ) Cover-Events (auch ohne Rollosteuerung), dann Crash mit Reboot - reset_reason: 4 1.7.0-beta2 ein paar wenige (circa 8 ) Cover-Events (auch ohne Rollosteuerung), dann Crash mit Reboot "The script caused a device crash" - Script: "errors": ["crashed"] / reset_reason: 4 Es gibt in letzter Zeit einiges an Merkwürdigkeiten
Ja, wie man zwischen 1.5.1 und 1.6.2 (sowie den 1.7.0-beta1/2) sieht:
Bei 1.5.1 wurden Cover-Events nur ausgegeben, wenn sich was tat. Beginnend mit 1.6.2 wimmelt es auf der Console nur so von Cover-Events, egal ob was passiert oder nicht.
Habe ein Bug-Ticket eingereicht: Ticket number: 180604 - mal schauen
-
SImples Event-Skript crashed:
Code
Alles anzeigenfunction Check_Event(d) { // if (d.component == "cover:0") return; print (JSON.stringify(d)); } function Main() { print ("Main"); Shelly.addEventHandler(Check_Event); } Main();Ausgabe: ein paar wenige (circa
Cover-Events (auch ohne Rollosteuerung)Dann Crash mit Reboot: "The script caused a device crash"
Script.GetStatus -> Script: "errors": ["crashed"], "error_msg": ""
Sys.GetStatus -> reset_reason 4
Ticket number: 180604
siehe auch:
-
wo auch immer ich diese infos danach runterladen und auswerten kann
http://<WD-IP>/#/diagnostics
->
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
2.4 in betrieb, so auch für die 10 anderen Shelly's welche keine Probleme machen
Wichtig zu wissen: ESP Shelly (alle außer WD) sind ungleich Wall Display (andere Hardware & älteres Android)
Das WD ist bezüglich WLAN recht zickig.
Sofern machbar: versuch mal testweise die Standard-2,4 GHz Kanäle 1, 6 oder 11.
-
die Webseite und Updates sind zäh, aber bei MQTT bzw. dem Shellyplugin zu IoBroker
Ist da vielleicht der Unterschied zw. TCP und UDP ? Bin mir grad bei MQTT nicht sicher
-
Aber danke für den dBm Hinweis.
Nichtsdestotrotz ist meine persönliche Erfahrung, dass auch -78 dBm
bereits schlechte Erreichbarkeit bedeutet. -
Vermutlich sollte man eine Beta Firmware "mit spitzen Fingern anfassen"
Guter Hinweis - ich werde später mal verschiedene FW durchtesten.
-
Ist das das einzige Skript auf deinem Testshelly?
Ja, da läuft sonst nichts.
Code/rpc/Sys.GetStatus "ram_free": 70320, "ram_min_free": 51120,Code/rpc/Script.GetStatus?id=1 "mem_free": 25200,Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Aber es ist wohl der Schieberegler?
Ja, ist er. Mach mal das Fenster breiter, z.B. Handy im Querformat
-
Wo ist der Autostart für Scripte zu finden?
Auf der Skript Übersichtsseite: http://<shelly-ip>/#/scripts
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. -
Merkwürdigerweise führt bereits dieses simple Skipt bei 1.7.0-beta1 auf einem 2PM G3 nach kurzer Zeit zu einem Reboot mit "reset_reason": 4 :
Code
Alles anzeigenfunction Check_Event(d) { // if (d.component == "cover:0") return; print (JSON.stringify(d)); } function Main() { print ("Main"); Shelly.addEventHandler(Check_Event); } Main();eiche Hast du da irgendeine Idee was hier falsch läuft? Darf man sowas nicht machen?
-
Schade.
Bei mir führt selbst ein total runter gestripptes Script zwar zu einem Reboot, aber immerhin ist der Shelly danach wieder erreichbar,
-
Ist das bild aus der Shelly app
Das sieht man ja, das es nicht so ist
Das Bild ist m.E.n. aus HA - siehe auch Forums-Kategorie
-
Ok. Dann hatte ich das doch richtig verstanden.
Kann du mal folgenden RPC Call auf den nicht mehr erreichbaren 2PM abfeuern:
Codehttp://<shelly-ip>/rpc/Script.Stop?id=1Falls du mehr als 1 Skript auf dem Shelly drauf hast, müsstest du id=1 anpassen auf die richtige Skript Nummer.
Ist der Shelly kurz danach wieder erreichbar? Das setzt aber voraus, dass du kein Script Autostart aktiv hast.
-
Das funktioniert mit einem Blu Door bei mir. Dieser ist mit dem 2pm gekoppelt und die Adresse des Blu Door ist im Script angepasst.
Äh was? Ich denke es funktioniert nicht?
Welche Firmware ist auf dem Shelly, bei dem es funktioniert genau drauf? Und mit welcher Firmware gibt es jetzt Probleme?
Außerdem ist deine Fassung nicht Easy_Call alleine sondern das Kombi-Skript Easy_Call und Blu_Events.
-
Wenn man auf den Button "Net Metering" (neben dem Datumfeld) klickt, bekommt man ein ziemlich genaues Ergebnis der Verbrauchs.
Wenn du darunter den Hausverbrauch (nicht zu verwechseln mit Eigenverbrauch) verstehst, dann könnte der Wert stimmen - das kommt dann aber auf dein Setup an.
Generell ist dieser Wert aber falsch, weil man fehlendes Saldieren nicht durch "magische" Formeln im Nachhinein heilen kann (schon gar nicht über größere Zeiträume).
Beispiel bei mir heute:
Default Net-Metering eHZ Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen. Hausverbrauch laut Wechselrichter: 6.19 kWh
-
In addition, the non-Pro Shellys are not permitted to be used “ loosely” in an UV.
At the very least, you will need an additional DIN-rail holder (with the appropriate fire protection class).
