Das Scirpt-Problem scheint gelöst, zumindest habe ich da keine Ausfälle.
Aber weiterhin treten bei PlusPlugS, 1Plus und Pro1 Aussetzer im BeaconMode des BLU Door/Window auf. Fast kann man ein Muster erkennen, 180 Minuten Signal, dann 90 Minuten Pause. Ein mini1-Gen3 liefert dagegen durchgängig Daten.
Der Door/Window sendet dabei regelmäßig, das Prolem liegt eindeutig bei den Gateway-Shellys.
Naja, der print() funktionierte ja mit der 1.2 noch.
Nachdem ich jetzt eine Woche Logdateien geführt habe, bestätigt sich, dass die Aussetzter bei Bluetooth auf PlusPlugS und Plus1 regelmäßig auftreten. Mehrmals täglich 70 - 120 Minuten Empfangspause. Der Mini1Gen3 läuft dagegen fehlerfrei.
Getestet mit zwei BLU Door/Window, zwei PlusPlugS und einem Mini1Gen3.
Weiterhin keine Ausgaben im SCRIPT LOG mit der 1.2.1
Ich bekomme mit der 1.2.1 keinerlei Ausgaben im SCRIPT LOG.
auch mit der aktuellen FW für die Plus Gen2/3 ?
Seit gestern Abend ist die v.1.2.0 erschienen
Falls du mich meinst, ja Version 1.2.
Die besten Ergebnisse habe ich mit dem Mini1G3, da kommt im Schnitt alle 90 Sekunden ein Wert.
Beim PlusPlugS kommen nur sporadisch Daten an und er pausiert immer wieder komplett bis zu 60 Minuten.
Die DoorWindow senden kontinuierlich, das kann ich im BLE-Scanner sehen.
Alle Geräte sind in einem Raum.
Ab- und wieder anmelden löst das Problem, man gönnt sich ja sonst nichts.
Und das Shelly BLE Gateway der Geräte glänzt immer noch mit Aussetzern von bis zu 90 Minuten. Der Door/Window sendet korrekt, das sehe ich im meinem BLE-Scanner, aber beim Plus Plug, Plus1 oder Mini1-Gen3 kommt nichts an. Ich teste das seit einer Woche mit verschiedenen Konstellationen und auch das Update ändert nichts.
Diese Prognosen sind viel zu ungenau, darauf würde ich mich für dieses Vorhaben nicht verlassen
So ähnlich habe ich das mit meiner Heizung geregelt. Wenn in einem Raum geheizt werden soll, Thermostat öffnen und Heizung einschalten.
Ich habe allerdings ein etwas komplexeres Programm dazu entwickelt, dass Laufzeiten der Heizung genau berechnet und allerhand Parameter berücksichtigt.
Also mein Door/Window sendet mit der neuen Firmware jeden zweiten Event mit "0 Lux". Nach zwei Stunden macht er für 1-2 Stunden Pause. Das läuft jetzt sei 24 Stunden so.
Die Pausen hatte ich vorher auch, die 0-Events nicht.
Nachdem es jetzt mit der neuen Firmware einige Stunden beobachtet habe, sie haben es verschlimmbessert. Weiterhin macht der BLU nach 90-120 Minuten eine längere Pause von mindestens einer Stunde. Zusätzlich schickt er, wie erwähnt, abwechselnd den aktuellen LUX-Wert und 0 LUX.
Die Tage gab es ein Firmware-Update für den BLU D/W. Nachdem ich das gestern eingespielt hatte war der Beacon-Modus offenbar ganz zerschossen. Events kamen nur noch, wenn ich den Magntekontakt ausglöst habe.
EIn Factory Reset über die BLE-App hat zunächst nichts bewirkt. Nach einem weiteren über die Shelly-App sendet er jetzt abwechselnd 0 und den aktuellen Wert - mal sehen, wie lange.
Hat sich der Support schon mal dazu geäußert? Ich habe jetzt einen BLU D/W im Beacon-Mode laufen und er hat regelmäßig Aussetzer von ca. 2-3 Stunden, ich habe die Aktivzeiten mal protokolliert:
01:18 - 03:05
05:51 - 07:13
09:53 - 11:07
13:28 - 14:35
16:50 - 18:02
22:12 - 23:35
Ermittele, wie lange die Heizung normalerweise braucht, um von 20 auf 22 Grad zu kommen. Dann schaltest du die Heizung einfach bei erreichen der Schwelle für die entsprechende Zeitspanne ein.
Ich bin raus.
Besser ist's.
@alle
Wie so eine simple Frage nicht verstanden und dann noch überheblich abgebügelt werden kann - großes Kino.
Er möchte die JSON-Antwort der einzelnen Shelly-Typen wissen, um sie per Software auszuwerten. Dazu müsste er alle Shellys besitzen, was nicht der Fall ist, oder eben eine entsprechende Doku haben.
{"name":"Shelly-PRO1","id":"shellypro1-30c6f781fd38","mac":"30C6F781FD38","slot":1,"model":"SPSW-201XE16EU","gen":2,"fw_id":"20230912-082313/1.0.3-g6176478","ver":"1.0.3","app":"Pro1","auth_en":false,"auth_domain":null}{"name":"Shelly-4PM","id":"shellypro4pm-c8f09e88793c","mac":"C8F09E88793C","slot":0,"model":"SPSW-104PE16EU","gen":2,"fw_id":"20230912-082358/1.0.3-g6176478","ver":"1.0.3","app":"Pro4PM","auth_en":false,"auth_domain":null}Zumindest bei mir hat die FRITZ!Box (6591) ein deutlich schlechteres WLAN als die verwendeten AVM-Repeater (1200). Mit zwei kabelgebundenen APs decke ich ansonsten drei Etagen (Betondecken) mühelos ab.
Läuft. super Arbeit. 
Ich habe nur ein IPAD mit aktuellen IOS und kann das so nicht bestätigen
Die ShellyApp hatte auf meinem iPad keinen Standortzugriff. Nachdem ich den eingeschaltet habe, "findet" er die Shellys jetzt auch ohne Cloud. Das Problem ist reproduzierbar.
Ihr kauft Geräte, die erstmal von Haus aus für die Shelly-Cloud gedacht sind und schaltet die Cloud ab!? Was erwartet Ihr da?
Als ich vor fast fünf Jahren meinen ersten Shelly zum testen gekauft habe, war die Cloud eher eine Zusatzfunktion und längst nicht so präsent wie heute. Deshalb habe ich mich für dieses System entschieden. Inzwischen läuft es zunehmend auf den Zwang zu einem kostenpflichtigen Cloud-Abo hinaus.
So meldet die BLU-Serie ihre Daten an den verbundenen Shelly. Der kann sie zwar an die Cloud übermitteln, aber nicht per Http-Action im lokalen Netz weiterleiten oder für einen API-Aufruf zwischenspeichern? Die technische Begründung möchte ich mal hören. Das Scripting dürfte für die meisten Anwender keine Option sein und es ist ja fast alles in der Firmware vorhanden, da fehlen nur ein paar Einstellmöglichkeiten.
Was die neue App betrifft, so sind Geräte ohne Cloud-Verbindung hier auf dem iPad definitiv "offline" und das ändert sich auch nicht durch warten oder Neustart. Seltsamerweise funktioniert es auf dem iPhone (gleiches OS) nach kurzer Zeit, da liegt dann wohl ein Softwarefehler vor.
