Freak's
Naja, ich würde wohl mehr "Geek's" anstatt "Freak's" sagen, aber ich weiß was du meinst: der "normale Shelly-User" wird nicht über die Shelly-App hinausschauen. Und sogar innerhalb der Shelly-App gibts schon sooooooooo viele Menüs das es schwer wird etwas zu verwalten.
=> da müsste schon Shelly selbst "global" ein Backup & Recover/Replace-System einbauen das über die App verwaltet werden kann.
man kann via Zigbee den Switch-Zustand im Detached Mode nicht auslesen:
Wenn man da eine Lösung sucht:
Ist es somit NUR möglich einen Shelly I4 Gen4 einzusetzen oder würde es auch funktionieren den detached-Modus zu DEAKTIVIEREN um den Status zu erhalten? Natürlich würde dann das Relay mitschalten => aber da soltle ja eigentlich bei diesem eh nichts angehängt sein.
Edit: auweia, ich sehe gerade: es gibt ja gar keinen Shelly I4 Gen4 (incl. Zigbee), sondern nur einen Shelly I4 Gen3 
.
dann wirds zeit für einen Feature request. Der usecase tritt doch gelegentlich mal auf.
Jep, in den nächsten 5-10 Jahren werden "so einige Shelly's" das Zeitliche segnen - und da währe ein relativ simpler Austausch schon ein "Feature".
Die Szenen müssten sich noch anpassen lassen, da sie in der Cloud gespeichert sind. Nachdem du den neuen Shelly eingebunden hast, änderst du einfach die Szene und wählst an den entsprechenden Stellen den neuen Shelly aus.
Sry, ich verwende keine Cloud, aber mein "Gedanke" dabei: Man muss da erst einmal identifizieren wo welcher Shelly genau verwendet wurde und dann ALLEN betroffene Szenen anpassen - da könnte man mit etwas Hirnschmalz den Kunden Unterstützen beim z.b.: replace eines Shelly Plus 2PM gegen einen "neuen" Shelly 2PM Gen4
Darüber hinaus währe es praktisch wenn auch die Offline-Parameter (u.u. Konfiguration, aber vor allem Scripte, Actions, usw.) auch bei "Cloud-Nutzung" zumindest in der Cloud gebackupt würden - das würde ein Recovern mit einem Ersatzgerät deutlich vereinfachen und beschleunigen.
Ich vermute die WENIGSTEN User werden die Offline-Parameter/Scripte/Actions sauber lokal backupen.
also mit diesen Specs würde meine HA-Instanz (fast) nicht lauffähig sein:
z.b.: allein 1 Version eines "vollen" automatischen Backups braucht bei mir 5GB 
.
Es sind z.z. auch 2GB von 3GB RAM in Verwendung und das Ganze läuft bei mir auf 2 Cores eines ~8 Jahre alten Intel Core I3
Das Ganze ist bei mir in eine VM gepackt und kann somit bei Bedarf erweitert werden - aber offensichtlich kommt das Homey-System mit deutlich weniger Ressourcen aus.
ok, ich verwende keine Cloud: aber offensichtlich hat sich bei dir durch den "Totalausfall" auch irgendwie das Gerät dauerhaft aus der Cloud-Konfiguration verabschiedet??!?! Witzig...
Aber zumindest konnte man das mit einer Rekonfiguration wieder "beheben".
Ich hoffe dass da nach 1/2/3 FW-Updates solche Fehler nicht mehr auftreten...ich hab ja auch noch ein paar andere Fehler die beim Shelly BLU Distance nicht hinreichend funktionieren.
Wir hatten vor kurzen hier im Forum die Diskussion ob man "einen defekten Shelly gegen einen baugleichen Shelly ersetzen kann" und vor allem die "online gespeicherte Konfiguration" (= Szenen, ...) irgendwie ummappen kann => im Wesentlichen kam raus dass das leider nicht möglich ist.
Dass die "offline gepspeicherte Konfiguration" nicht rekonstruiert werden kann ist natürlich klar, die ist ja direkt auf dem lokalen Gerät gespeichert.
Du redest wirres Zeug.
Bitte auf die Tonwahl achten.
Hanterdro :
Also wenn ich dich richtig verstehe dann willst du eigentlich NUR den Tastendruck auswerten. Dafür währe ein Shelly I4 Gen3/4 am Besten geeignet (und ist relativ günstig), kann aber natürlich über jeden Shelly gemacht werden der einen Eingang hat.
Hast du den Taster nach folgendem Anschlussdiagramm verdrahtet (ignoriere die eingezeichnete Lampe und die Verdrahtung auf der "I"-Klemme):
Am "besten" ist mal du schaust direkt im Webinterface (NICHT in der Shelly-App) nach ob du überhaupt das Signal lokal dort zu sehen bekommst.
Frage: Hast du die Lampe über das Shelly-Relay "immer eingeschaltet" oder hast du den Dauerstrom "hart verdrahtet" am Shelly vorbei? Ich würde für Dauerstrom eine "harte verdrahtung" empfehlen, da du dir dann sparst dass das Relay des Shelly's 24h am Tag aktiv geschaltet werden muss.
naja, bei mir (in Home Assistant und Shelly BLE Debug-App) hat sich der Sensor GAR nicht mehr gemeldet, auch wenn ich mit dem Handy direkt daneben stand. d.h.: der hat auch keine neue "packet_id" gesendet => daher schlussfolgerte ich dass er komplett den Geist aufgegeben hat.
Auch ein Schütteln (=> Beschleunigungssensor) und ein Drücken der physikalischen Taste führten nicht zu einer neuen Messung, auch die LED am Gerät blieb dauerhaft aus.
=> zu diesem Zeitpunkt dachte ich schon fix dass der Akku leer sei oder das gesamte Gerät kaputt währe. Umso mehr war ich dann überrachst als nach einemkurzen Batterie raus+rein alles wieder gang "wie vorher".
Ist es im Matter-Modus möglich den SW-Eingang zu "detachen" und separat über Matter auszulesen?
Auch wenn es dir nichts mehr bringt:
Wenn du die Wetterstation eh an einen MQTT-Broker anbinden willst/musst: warum hast du dir dann nicht direkt die "original" Ecowitt Wittboy WS90 gekauft die das native unterstützt?
Es ist schon interessant dass alle deine IP's im Adressraum 192.168.1.xxx NICHT gehen und jene im Adressraum 192.168.0.xxx und 192.168.2.xxx schon.
=> u.u. funktioniert die Subnetzmaske da nicht richtig. Hast du auch mal eine Subnetzmaske 255.255.0.0 ausprobiert?
Verwendest du da auch unterschiedliche VLAN's oder nur einen größeren Adressraum bei den 0.xxx, 1.xxx und 2.xxx-Adressen?
Kannst du bei der Verwendung der Adresse 192.168.2.xxx auch mal das Gateway auslesen? Wird da wirklich 192.168.0.1 oder doch z.b.: 192.168.2.1 verwendet?
Die grün/gelb-LED-Farben sollen lt. Knowledge-Base nur anzeigen ob eine Cloud-Verbindung besteht. im WLAN sollten sie so aber erreichbar sein:
Mal schaun ob das öfters aufkommt - bis jetzt lief er zumindest mal durch.
wo steckt denn der BT-Adapter drinnen? Nicht dass aus irgendeinem Grund die USB-Versorgung des BT-Adapter adapters deaktiviert wird?!?
trotzdem noch die blöde Frage um auch die "Basisfunktion" abzufangen:
Wenn du die Rollos über das jeweilige Webinterface des Shelly's auf die gewünschte Position fährst, auch dann steht er "falsch"?
Und weil wir vorher davon gesprochen haben: wenn du nun 1x komplett rauf und direkt komplett runter (und vielleicht sogar nochmal direkt komplett rauf) fährst => auch dann ist die Position noch falsch?
das Script finde ich "interessant". Ich mache bei mir alles mit Node-RED und muss dort im Wesentlichen auch für solche "Abläufe" StateMachines händisch nachbauen, was leider sehr unschön ist. Zumindest kann man diese in Subflows packen und für alle Covers "reusen".
Zur Info/Optimierung:
Früher musste ich bei meinen Raffstores auch mehrere Positionen zur slat_control hintereinander anfahren. Ich habe bei mir wird aber das "warten auf Endposition" nicht mit einer hardcoded-Zeit gemacht sondern auf ein "position reached"-Signal vom Shelly gewartet => danach fahre ich die nächste Position an. Das erlaubt mir dass bei mir alle Covers unabhängig sind, so "schnell wie möglich" am Ziel ankommen und vor allem kann ich sie auch STOPPEN wenn ich hald gerade nicht will das das Rollo runterfährt - kommt auch ab und an vor.
=> Bei uns wird dann doch ab und an in der Küche/Wohnzimmer das automatische Runterfahren am Abend "abgebrochen" indem man hald auf den Taster drückt wenn es gerade nicht passt => dieser "Tastendruck" wird mittlerweile ausgewertet und die StateMachine wird ABGEBROCHEN.
wie tvbshelly bereits geschrieben hat: da stehts genau so wie im Video beschrieben drinnen. Es ist interessant dass es am Einstellset eine separate "Programmiertaste" gibt - die kann aber offensichtlich nur das rauf/runter-Getoggle mit den Tastern ersetzen, es funktioniert aber ja über die gleichen Leitungen.
Das ist schade , ich hoffte dass eine "Offsetkorrektur" beim Anfahren 1 Endpunktes auch hinreichend währe.
stiflers.mom : Aber da du ja eh mit HA arbeitest ist das nur noch 1 weiterer Schritt in der Automatisierung.
Ehrlich gesagt würde ich gerne wissen ob eine 1-Seitiger "Anschlag" hinreichend währe (wenn du lust auf diesen separaten Test hast). Z.z. trifft mich das selber noch nicht, aber auch ich fahre die meisten meiner Raffstore täglich von Position X auf Y und wieder zurück - je nach "lust und laune" kann es in Zukunft ja auch mal so werden dass wir nur noch zwischen z.b.: 10% und 80% hin und herfahren.
Dazu habe ich vor einigen Monaten schon mal Shelly geschrieben - leider ohne weitere Rückmeldung.
Das Problem besteht EWIG und mein Argument war das Gleiche wie du auch beschrieben hast:
Wenn man die ZEIT einfach "selber vermisst" (vielleicht sogar separat für aufwärts & abwärts), und dann noch ein paar Sekunden "Reserve" dazu addiert (um auch sicher in die Endlagen zu fahren), dann könnte man wohl die Meisten Shelly-Funktionen damit hinreichend abbilden.
Zur Info:
Shelly vermisst auch noch "irgendetwas" zusätzliches beim 2ten Durchlauf, da dort das Rollo öfters stehen bleibt und wieder anfährt. Was auch immer da vermessen wird kann hald nicht berücksichtigt werden.
Im wesentlichen hätte man hald eine geringe Ungenauigkeit. Ob man dann bei 50% oder 53% der Position steht ist relativ egal - aber es würde im Wesentlichen funktionieren.
=> Ich finde noch immer dass es eigentlich "relativ simpel" sein sollte so ein Feature zu unterstützen, leider gibt es z.z. keine Möglichkeit die Zeiten einzustellen.
OK, ich habe NICHT das gleiche Problem, kann mir aber vorstellen dass das "normal" ist:
Shelly kann ja die Position in "%" nur nach der ZEIT anfahren, d.h.: wenn du von 75% auf 10% fährst dann wird das Rollo z.b.: 10.3 Sekunden nach unten fahren.
=> damit akkumulierst du jeglichen Fehler immer weiter auf.
Als Beispiel kannst du dir vorstellen dass wenn du mit einem Zahlstab/Rollmeter am Boden immer 1cm "nach rechts" einen Strich gehst und dort nen Strich machst, dann von dieser Position weg wieder 1cm, usw. bis du 100x 1cm gemessen hast => dann kommt da leider auch nicht 1m raus, sondern eher sowas wie 99cm oder 101cm. Auchbeim "rückweg" wirst du nicht mehr bei der Ausgangsposition landen.
=> Natürlich ist es da besser gleich von Anfang an 1x1m zu messen um den Fehler so gering wie möglich zu halten.
Was macht also der Shelly um den aufakkumulierten Fehler zu "kompensieren":
Jedes mal wenn du in die Endlagen fährst kalibriert der Shelly 2PM Gen4 anscheinend seine interne Position (+Laufzeit?) nach.
Somit kann ich dir als "Lösungvorschlag" nur folgendes vorschlagen:
Fahre bei deiner Automatisierung in HA anstatt direkt auf "10%" einen "Umweg" :
1) Fahre auf 0%
2) Warte bis fertig => Shelly resettiert/rekalibriert die interne Position auf "0%"
3) Fahre auf Zielposition (= 10%)
Ich glaube nicht dass du die 2te Endlage auch dauernd anfahren musst, dies ist nur dann interessant wenn sich die gesamte "Verfahrzeit" ändern würde, was aber hoffentlich nur ein Alterungsthema ist.
Da dieser Lösungsvorschlag z.z. nur "theoretisch" ist würde ich mich freuen zu erfahren ob damit das Problem gelöst (bzw. umgangen) ist.
Die Küche mache ich dann (hoffentlich) mit dem Becker-Einstellset.
Aber soweit ich das bei meinem verlinkten Video gesehen habe muss man auch mit dem "Einstellset" die Programmiertasten vorher umstellen, oder täusch ich mich da?
Es wurde dort hintereinander erklärt:
1a) Obere und/oder untere Taster auf "Programmieren" einstellen
1b) Mit programmiergerät Endpositionen programmieren ODER mit dem Taster Endpositionen programmieren
2a) Obere und/oder untere Taster auf "Löschen" einstellen
2b) Mit programmiergerät Endpositionen löschen ODER mit dem Taster Endpositionen löschen
3) ....
