Sie sind sich keiner Schuld bewusst und beteuern keinen Eingriff gemacht zu haben!
Die Jungs glauben ich bin auf die 14er zurück gegangen und hab damit das Addon selbst rausgeworfen.
Der abgesicherte Modus kann es nicht sein da das Skript ausgeführt wird.
Am liebsten wäre mir die Firmware hätte einen Schlag aber ich hoffe nicht dass die Jungs über die Cloud eingegriffen haben und einzelne Einstellungen verändert haben wie oben beschrieben.
Ticket geht schon hin und her aber ist nicht wirklich hilfreich bzw. keine Unterstützung...
Den Factory Reset hab ich schon längst gemacht und die Reboots kommen auch bei anderen Usern mit der Beta vor.
Mein größeres Problem ist momentan warum sich Einstellungen ändern!
Das hat nichts mit dem Skript zu tun da der Reboot vor dem Skript auch schon war!
Es geht darum ob ein mehrmaliger Reboot von selber Einstellungen in der Shelly verändern kann: Websocket Debug aus; MQTT aus, Cloud aus und das Addon rausgeschmissen.
In meinem Fall handelt es sich um eine Pro3EM mit dem Saldierungs Script.
Das Problem ist ja dass ein Ankommen der Nachricht nicht überprüft wird und der Status undefiniert ist. Insofern kann ich sein Problem verstehen und ist sicher nicht unsinnig.
Die Überlegung mit den Beacon Mode hatte ich auch damit der Status regelmäßig nachzieht. Vermutlich stirbt man immer irgendeinen Tod... ( in dem Fall Batterielaufzeit)
Meine Server, Wlan usw. laufen auch auf einer USV damit Kurzunterbrechungen die Speicherkarten nicht schrotten. Somit haben beide Systeme (Sensor und Server) gleichwertige Stromversorgungen im Sinne der Datenübertragung.
In der Loxone haben wir die Möglichkeit einen Baustein auf Remanenz zu setzen damit der Status vorm Reboot hergestellt wird aber das ändert auch nichts wenn sich der alte Status zwischenzeitlich geändert hat.
Auch die feste Verdrahtung wird man nicht überall schaffen: Brandmelder, Wassersensoren usw.
Spannend ist ist dass sich bei mir der Websocket Debug, MQTT, Cloud deaktiviert hat und das Addon rausgeschmissen hat!
Das Skript war aktiv also kein Speicherproblem.
Entweder reagiert die Shelly selbständig oder Allterco hat eingegriffen!
die 6er Beta
die Release kann ich mir leider noch nicht ziehen oder hast einen Link?
Hab die 6er Beta drauf.
Hi,
hatte in letzter Zeit sehr viele Reboots die ich mir nicht erklären konnte und hab daher ein Ticket #49842 erstellt.
Komischerweise sind 1 Tag nach dem Ticket folgende Änderungen in der Pro3EM
Es wurde kein Werksreset duchgeführt da mein Script noch aktiv war.
Aus meiner Sicht gibt es 2 Möglichkeiten
die Shelly ist in einen Rescue Mode gegangen
oder
Allterco hat ohne meine Zustimmungen Änderungen durchgeführt
Noch jemand einer Idee?
Schaltet ihr den Websocket Debug aus damit Ressourcen gespart werden oder läuft der bei euch weiter?
Kann es sein dass sich der Debug alleine ausschaltet bzw. die Shelly in einen Rescue Mode geht nach einem mehrmaligen Reboot?
Dafür ist der json der Wetterstation lokal ganz ohne monatlich Fixkosten 
ja der User aus Post #77 ist uns bekannt
hab mir auch eine von Sascha bestellt um sie in die Loxone einzubauen (als Backup zur Elsner P03)
Der Intervall der Datenübertragung ist nur eine ganz kleiner Teil für eine PV Überschussregelung und völlig überbewertet.
Wenn deine Logik, Energiemanger usw. einmal pro Minute rechnet dann reicht das völlig aus. Falls du zu schnell regelst kommst du in Gefahr dass die Leistungen ins Schwingen geraten. Bei meinem Leistungssteller für die E-Patrone konnte ich im Sekundentakt regeln mit dem Ergebnis dass das einen Bezug auslöst. Letztendlich kommt in der Regelungszeit kein nennenswerter Bezug zum tragen.
Meine Empfehlungen in einem Wohnhaus:
Warmwasser E-Patrone stufenlos 1Minute
Wallbox mit Phasenumschaltung 5-10Minuten
Offset -100W
Wärmepumpen mit Ein/Ausschaltverzögerung 15 Minuten
Geschirrspüler ans Warmwasser (max. 60Grad)
Waschmaschine soll die Frau machen wann sie will bzw. einfach zur Mittagszeit
Jetzt kannst du dir aussuchen ob noch 10 Shellies grillst, die Leuchtstofflampe tauscht oder einfach keine Daten bekommst....
Die Probleme werden bei anderen Herstellern ähnlich sein wie Thomas schon erklärt hat.
Er sendet das wie in Post #46
Bei der Lieferung dürfte er sich verschluckt haben da hier eine größere Differenz ist im Vergleich zu meinem Verrechnungszähler:
Mir schmiert die Pro3EM immer noch sehr häufig ab und vielleicht hängt das mit dem Speicherintervall zusammen 
Genau warum baut man dann Shellies ein und nimmt die Empfehlungen nicht ernst?
Läuft :))
Würde auch gehen.
Haben einige User die keinen Broker betreiben und da könnte ich den Payload speichern und per Befehlserkennung zerlegen.
Simon Canins aktuell muss aber bei jeder Änderung im Skript der Zählerstand neu eingegeben werden sonst überschreibt er das wieder oder liege ich da falsch?
Direkt im Skript setzen gefällt mir ohnehin besser - DANKE
Könnte man den String auch per UDP senden?
Herzlichen Dank 
Zählerstand gesetzt damit ich das mit meinem Verrechnungszähler vergleichen kann.
