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.
Da hast du recht, aber ein Anfang ist gemacht: Ich finde erstmal gut, dass Shelly den Bedarf auch erkannt hat.
Finde ich auch gut dass ein "Projekt" gestartet wurde wo mal ein Anfang gemacht wurde. Wenn eine "Basis" mal vorhanden ist wird dann hoffentlich eh dran weiterentwickelt...
Im einfachsten Fall ist das eine Excel-Datei, wo schon mal aufgelistet ist, wo genau die Geräte verbaut sind und welche Funktionen sie haben...
Also ich persönlich bin der Meinung dass ein "händisches System" zum Scheitern verurteilt ist. Da ändert man dann im Laufe der Zeiten immer wieder Kleinigkeiten an den Konfigurationen und vergisst dort und da was man nun WIRKLICH eingestellt hat und ob mans auch wirklich bei "allen 60 Stk" gemacht hat.
=> So was muss leider automatisch funktionieren. Am Besten dann auch gleich noch mit Versionierung um bei einer Fehlkonfiguration auch den Zustand "von letzter Woche" wiederherzustellen.
Da liiiiiiiiiiebe ich dass bei mir so einiges über Home Assistant läuft welches in einer VM ist: da ist eben alles mit einem Snapshot gespeichert und im Wesentlichen auch versioniert. Wenn die Änderung von "letzter Woche" einen patschen hat, dann spiele ich hald die Konfigration davor ein und das Haus läuft wieder....
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.
