Beiträge von dewaldo

    Das kannst du direkt übers WebInterface einrichten.
    Findet sich im 3-Strich-Menü und dann "Actions" auswählen.

    Im Action Menü kannst du dann folgende Schritte durchführen:

    1.) Create Action
    2.) Auswahl, auf welches Event reagiert werden soll, also z.B. Input (0)
    3.) Im Feld "Action name" entsprechend einen gewünschten Namen für die Action eintragen
    4.) Darunter kann noch gewählt werden, ob die Action immer "Enable" ist, oder nur innerhalb von bestimmten Zeiträumen. Standardmäßig hier nur "Enable" Häkchen lassen
    5.) Beim Feld "Execute when..." wählst du dann aus, welcher Art der Signalwechsel sein muss, damit das Event ausgelöst wird, also am obigen Beispiel wäre das dann "Input toggled on". "Repeat when" kann genutzt werden, um eine zu häufige Ausführung abzufangen, kann hier auf "0" bleiben.
    6.) Im letzten Abschnitt "Then do" wählst du dann nicht Add URL, sondern "Add local action"
    7.) Unter "Action" wählst du dann "Control output" aus, nicht toggle und im Feld darunter, welcher Output (z.B. beim 2PM gäbe es ja 2 mögliche) und nochmal darunter setzt du die output state property auf "On". Dadurch wird bei Tastendruck des gewählten Inputs der gewählte Output eingeschaltet
    8.) Unter dem state property Feld gibt es dann noch das "set Flip value after property". Das kann man antippen und dort eine Zahl in Sekunden eingeben, nach welcher Zeit nach Ausführen der Action der Output wieder auf den anderen Zustand geschaltet werden soll.

    Ich müsste selbst auch mal ausprobieren, was passiert, wenn man unter Punkt 8 z.B. 300s einträgt und wenn man dann z.B. nach 240s erneut den Taster drückt. Normal sollte dadurch die Zeit wieder neu bei 300s starten und das Licht an bleiben und dann nicht 1 Minute später ausgehen.

    Du könntest im Shelly ganz einfach einen Local host Webhook anlegen für den Taster-Input in der Form, dass das Drücken des Tasters das Licht nicht toggelt, sondern immer das Kommando "EIN mit Ausschaltverzögerung" auslöst. Auf die Weise steht jedenfalls niemand im Dunkeln, aber es kann sich ggfs. jemand ärgern oder wundern, dass er das Licht nicht mehr aus bekommt am Schalter.

    Das wäre jedenfalls eine sehr einfache Möglichkeit, auch bei Komplettausfall deiner Smarthome Umgebung, HA, Internetverbindung und sogar bei komplettem WLAN Ausfall trotzdem am Schalter das Licht einschalten zu können. Im Gegensatz zu den GEN1 Shellies funktionieren localhost oder entsprechend IP 127.0.0.1 bei den GEN2 und GEN3 auch ohne aktive Netzwerkanbindung.

    Hi. Nochmal ein kurzes und finales Update von mir in Richtung Roaming Probleme, die mich jetzt seit gut 3 Jahren begleiten. Es ist wohl bei mir tatsächlich der managed switch, der diese Probleme macht. Ich habe jetzt alle APs auf einem kleinen POE Switch zusammengeführt und bin dann von diesem mit 1 Uplink zum Hauptswitch. Vorher war der Keller-AP nicht mit auf dem POE Switch, sondern separat direkt auf dem Hauptswitch, weil dieser AP verdrahtungsbedingt mit externem POE Injektor betrieben wird und ich den POE Port dann nicht unnötigerweise belegen wollte. Die Probleme habe ich bei mir aber vor allem beim Verlassen des Hauses durch die Garage gehabt, also beim Wechsel vom Keller-AP auf den Außen-AP. Jetzt, wo der Keller-AP auch mit auf dem kleinen Switch liegt, sind diese teils mehrere Minuten andauernde "Ausfälle" verschwunden. Beim Dauerping kommt es mal vor, dass 1 Antwort ausbleibt, aber sofort danach steht die Verbindung wieder, das war vorher nie der Fall.

    Ich vermute einfach wirklich, dass der Switch das irgendwie unterdrückt hat, wenn Pakete einer MAC Adresse plötzlich über einen anderen Port reinkommen als zuvor, bis dieser Zustand eine gewisse Zeit bestehen bleibt und dann scheint er die Pakete wieder entsprechend vom neuen Port aus weiterzuleiten. Komisch ist allerdings, dass ich umgekehrt das Problem nicht bemerkt habe, also beim Wechsel Außen-AP auf Keller-AP.

    Das bleibt jetzt jedenfalls übergangsweise so und irgendwann fliegt der alte Switch dann ganz raus.

    Habe den Beitrag zwar etwas überflogen, aber zumindest glaube ich, nicht gelesen zu haben, dass du irgendwo bestätigt hast, in der Dose der 3er Schalter-Kombi den Neutralleiter zu haben ?? Ohne den kann dort natürlich auch kein Shelly Mini, i4 etc... betrieben werden. Dass man ihn braucht, wurde hier schon erwähnt, aber es kam keine Reaktion von dir darauf, daher wollte ich das nochmal hervorheben, OHNE N bei den Schaltern auch kein "Sende-Shelly" dort nutzbar.

    Ja, das Forum hat sich leider etwas gewandelt durch die Tatsache, dass es seitens Shelly ein eigenes, offizielles Forum gibt, wodurch hier auch die Umbenennung in "Smarthome-Forum" erfolgt ist und eben auch einige Inhalte nicht mehr in der Form zu finden sind wie zuvor. Ich fühle mich dennoch "hier" meist besser aufgehoben und hoffe, das Forum wird seitens Shelly-Nutzern noch länger genutzt.

    Ein "Treppenlichtzeitschalter", gehen wir mal davon aus, es ist ein klassisches Eltako Stromstoßrelais, dann kann man das in der Regel meist 1:1 gegen einen Shelly austauschen, auch Dimmer2, was auch im Treppenhaus ja durchaus Sinn machen kann zu gewissen Uhrzeiten...

    Zu beachten ist aber etwas ganz wichtiges. Das Stromstoßrelais hat quasi 2 komplett getrennte Stromkreise intern. Die Spule des Relais ist autark und der vom Relais geschaltete Kontakt wiederum ist ein eigener Kreis. Dem Stromstoßrelais macht es also z.B. nichts aus, wenn die Taster, die die Spule beim Drücken bestromen, z.B. den Außenleiter L1 zum Relais durchschalten und das Relais selbst über den Schließer, der dann die Lampen bestromt, z.B. L2 wäre. Es gibt auch noch die Varianten (selbst schon erlebt), dass die Taster nicht alle dieselbe Phase geschaltet haben, sondern am Eltako dann L1 + L2 ankam, je nachdem, welcher Taster gedrückt wurde. Auch das macht der Eltako mit, solange nicht 2 Taster gleichzeitig gedrückt werden.

    Beim Shelly ist das aber ein Problem, hier dürfen nicht verschiedene Außenleiter gemischt werden. Versorgung des Shelly + SW Input müssen am selben Stromkreis sein. Abhilfe kann aber z.B. hier auch ein Trennrelais schaffen, wenn man auf Nummer sicher gehen will und den Istzustand nicht sicher kennt. Ich möchte damit nur darauf hinweisen, dass hier besondere Vorsicht geboten ist und man dies von einer Fachkraft machen lassen sollte.

    Nein, ich nutze keine Shelly App. Ich habe sie zwar auf dem Smartphone, aber dort tatsächlich nur diesen einen Shelly 2PM über die Cloud angebunden, quasi als Backup und für meine Frau, dass die nicht von VPN und Co. abhängig ist.
    Über die Shelly App kann ich den 2PM im Prinzip IMMER ansteuern, auch dann, wenn ich ihn per http-request oder sein WebInterface nicht mehr erreichen kann. Da sich der Effekt bei mir aber auch z.B. bei TASMOTA Geräten zeigt, kann ich Shelly Cloud und App gänzlich ausschließen.

    Bei dir und dem 3EM könnte ich mir vorstellen, dass der vielleicht einfach zu ausgelastet ist, wenn der von verschiedenen Teilnehmern aktiv abgefragt wird. Aber das müsste schon sehr massiv sein. Welche WLAN Signalstärke hat der 3EM denn ?
    Ansonsten "eigenes WLAN" für die Shellys heißt, du betreibst z.B. ein UniFi System oder was ähnliches ? Da ist nur wichtig, dass z.B. dein Smartphone und die Shellys sich gegenseitig "sehen" können, also im selben Subnetz sind und nicht isoliert voneinander. Die Shelly App erkennt glaube ich, wenn sie im lokalen WLAN ist und kommuniziert dann nicht immer über die Cloud mit einem Shelly und da könnte ich mir auch vorstellen, dass dadurch ein Shelly in der App als Offline gezeigt wird, obwohl es gar nicht so ist.

    Ach herrje ... Da wäre ich nicht drauf gekommen. Ich habe spekuliert, dass damit ein Raumthermostat gemeint sein könnte, welches seinen Messwert als analoge Spannung ausgibt ... Alles klar ;)

    g.seidel :

    Das Messen der Spannung sollte dann ja nicht das Thema sein, allerdings die grafische Darstellung dann schon. Sprich ohne übergeordnetes System wird das wohl nicht gehen. Die Shelly Cloud wird hier nicht die notwendige Abtastrate bieten, wenn die AD Werte des Uni überhaupt mit der Cloud protokolliert werden ?
    Von daher wirst du hier auf ein System wie ioBroker oder ähnliches zurückgreifen müssen, über das du zyklisch die aktuellen Messwerte vom Shelly abrufen und protokollieren kannst, um diese dann später entweder mit dortigen Bordmitteln direkt visualisieren zu können, oder die Werte als CSV z.B. mit Excel usw. darstellen kannst.

    Vielleicht kannst du deine Messanforderung auch mal etwas genauer erläutern, v.a. Thema Abtastrate kann dabei natürlich maßgeblich sein...

    So, gestern habe ich mal beim Managed switch alle Features deaktiviert, die ggfs. mit dem Problem zu tun haben könnten. Z.B. IGMP Snooping und Multicast features, storming, QoS, alles, was irgendwie mit Intelligenz des Switches zu tun hat. Nur VLAN musste ich lassen, das ist aber nur noch rein Port-basiert, quasi, um einen separaten 2. Switch einzusparen.

    Dann wieder getestet und erst mal happy, da es augenscheinlich danach 1A funktioniert hat beim Herumlaufen zwischen APs. Dabei konstant den Garagen-Shelly gepingt.

    Später am Abend dann die übliche Runde mit dem Hund, raus aus der Garage, Garage schließen... Nö, nix Garage schließen. Shelly wieder nicht erreichbar. Ebenso auch ein mit Tasmota geflashtes Wemos D1 am Zählerkasten. Dann kurz VPN aktiviert bei weiterhin gutem WLAN Empfang (OpenVPN über NAS) und schwupps, beide Teilnehmer sofort wieder erreichbar, aber direkt über den AP im Heimnetz nix. Bei der Rückkehr dann wieder ohne Probleme durchgehend erreichbar, auch OHNE VPN. Alles seltsam und ich werde nicht schlau draus.
    Übrigens, wenn ich das VPN konstant aktiv lasse, also auch im heimischen WLAN nicht trenne, dann habe ich die Probleme nicht, aber das ist natürlich nicht mein Ziel.

    Was ich auch kontrolliert habe ist die IP Adresse des Handys. Diese bleibt bei allen AP Wechseln konstant, per DHCP von der Fritzbox zugewiesen, auch bei Wechseln zwischen 5 GHz und 2,4 GHz ändert sie sich nicht.

    Muss dann doch bald mal einen Versuch starten, den Switch komplett abzuhängen. Muss fast schon an dem liegen, weil alle anderen Komponenten haben sich zwischenzeitlich geändert, aber das Problem blieb. Mein größtes Manko ist, dass ich das Verhalten nicht bewusst reproduzieren kann, was die Fehlersuche extrem erschwert.

    Ich habe bei mir 2 VLANs, deshalb aktuell etwas umständlich, den Switch zu umgehen, aber zum Testen Handy <-> Shelly sollte das kurzfristig gehen, mal was zusammenzustecken. Mal schauen, wenn die Chefin mal nicht zuhause ist ... ;)

    Was ich aktuell auch mal gemacht habe (konkret seit vorgestern), dass ich mal die Fast romaing features allesamt komplett abgeschaltet habe, also 802.11 v, k, r. Subjektiv habe ich den Eindruck, dass das Roaming dadurch zuverlässiger funktioniert (total Banane, aber werde das mal noch etwas beobachten). Irgendwo ist jedenfalls noch was faul...

    Die 1200AX hatten bei mir merklich mehr Sendeleistung als die GWN7660 + Outdoor 7660-LR. Wie geschrieben, die 4-5 dBm waren das auf jeden Fall bei sonst nahezu identischer Positionierung der APs.

    Die APs beim Fritz Mesh waren erst alle kabelgebunden, dann testhalber nochmal im Repeatermodus, also dann alle die gleichen WLAN Kanäle, was sogar letztlich zuverlässiger funktioniert hatte, als jeden Repeater per LAN Kabel mit dem Hauptswitch zu verbinden. Ich weiß bis heute nicht, warum dieses Setup bei mir so problembehaftet war. Die Fritzbox war / ist eine 5530 mit WIFI 6, dann 3 Stück 1200AX Repeater, trotzdem ständige, automatische Umkonfigurationen von Kanälen, Bandbreiten usw. Das finde ich so schade, dass AVM hier den früheren Expertenmodus nicht mehr so recht bietet. Früher konnte ich sagen, ich hätte gerne Kanäle 1, 6, 11 und zwar 20 MHz breit und fertig. Heute kann man quasi gar nichts mehr manuell konfigurieren. Klar, ich kann den Kanal manuell wählen, aber sobald die Fritzbox dann sagt, ey, Kanal 1 ist aber gerade in der Nachbarschaft auch genutzt, ich schalte jetzt auf Kanal 4, dann macht die das und man kann es nicht verhindern. Und hier glaube ich, dass das bei den GEN1 Shellies problematisch war.

    Ein bisschen habe ich auch noch Zweifel, ob nicht mein Switch auch mit Schuld hat. Das ist ein Netgear PS116v2, also ein managed Gigabit switch. Teilweise, wenn ich zwischen APs mit dem Smartphone wechsele und dabei z.B. einen bestimmten Shelly pinge, dann kommen die Pakete einfach nicht mehr an. Internet ist dagegen unterbrechungsfrei und auch andere Teilnehmer im Heimnetz erreiche ich unterbrechungsfrei, aber z.B. mal den Shelly der Garage nicht. Das dauert dann teilweise Minuten und dann klappt es plötzlich wieder. So als wüsste der Switch nicht, wenn jetzt die Pakete plötzlich an Port 4 statt 5 rein kommen, wie er die zum Ziel leiten muss. Ich kann dann z.B. das Webinterface des Shelly dann nicht mehr öffnen, nicht pingen, keine http requests absetzen, nix, als ob er offline wäre. Aber ich habe auch ioBroker mit VISU und wenn ich das Relais dieses Shelly dann über die ioBroker VISU übers Handy ansteuere, geht das sofort. Ebenso ist auch der Cloud Zugriff auf diesen Shelly durchgängig gegeben. Anfangs dachte ich, der Shelly hätte Probleme mit der 24V DC Versorgung, kann ich dadurch aber ausschließen.

    Aber auf jeden Fall war dieser Effekt beim AP Wechsel bei Nutzung der AVM Struktur ganz extrem, quasi ausnahmslos IMMER und die Zeiträume auch deutlich länger.

    Und ja, korrekt, die Grandstream Variante, die ich jetzt aktuell noch immer nutze, das ging von dir aus. Da hatte ich dich damals kurz gefragt, wie das mit dem Controller als Master abläuft, weil ich vor dem AVM Versuch lange Jahre Unifi hatte und beim Umstieg auch kurz Aruba getestet hatte. Ich muss sagen, mit der Grandstream Variante fahre ich bisher am besten, wobei die Signalstärken beim AVM Mesh bislang am höchsten und flächendeckendsten waren, da sind teilweise 4-5 dBm Unterschied bei gleichen Abständen gegenüber dem Grandstream mesh.

    Final mit allem zufrieden bin ich noch immer nicht, aber im Großen und Ganzen geht's.

    Ich habe halt von Problemen damit gelesen, wenn es aktiviert ist.

    Im Zusammenhang mit ESP32 habe ich mal gelesen, dass diese in manchen Szenarien, ich meine es war damals Unifi mit aktivierten Roaming features, die Unifi-APs inkorrekter Weise annehmen, dass der ESP32 5GHz fähig ist und den dann quasi mittels BTM vom aktuellen AP "kicken". Da gab es dann auch oftmals im Forum den Hinweis, Shellies können kein 5 GHz, von daher soll man ihnen wenn möglich, eine eigene SSID, ausschließlich im 2,4 GHz zuteilen.

    Ich hatte früher ein Fritz AX - Mesh und dort ständig seltsamste Effekte, teilweise waren ganzen Gruppen von Shellies plötzlich offline, teilweise für 1 Stunde, teilweise haben sie sich auch garnicht mehr verbunden. Das waren aber ausschließlich GEN1 Geräte.
    Letztlich habe ich die ganzen AVM Gerätschaften dann erst durch Aruba, später durch Grandstream APs ersetzt, ebenfalls WIFI 6. Und seitdem ist es zu 99% stabil. Hin und wieder habe ich immer noch kurze, unerklärliche Verbindungslücken. Durch diesen Thread hier kam ich wieder darauf und aktuell ist das eine kombinierte 2,4 + 5 GHz SSID und aktiviertem 802.11 (v,k,r). Vielleicht mache ich wirklich mal eine SSID, ausschließlich für die Shellies und deaktivierte dort die ganzen Features... Werde dann berichten, ob ich dadurch eine Veränderung bemerke

    Soweit ich das mitbekommen habe, unterstützen weder ESP8266, noch ESP32 fast roaming 802.11r. Der WIFI Stack unterstützt nicht 2 gleichzeitige Verbindungen, z.B. aktuelle AP Verbindung + zeitgleiches Scannen und Anmelden an einem 2. AP vor Trennung zum 1. Von daher wird es immer zu einer kurzen Offline-Zeit kommen beim AP-Wechsel. ESP32 sollten aber zumindest 802.11v unterstützen, um grundsätzlich den AP netzwerkgesteuert zu vollziehen.

    Aber ob das überhaupt sinnvoll ist, dass ein Shelly WLAN Gerät fast roaming unterstützt ? Meine verlassen selten ihre Unterputzdosen :)

    Das war genau die Anmerkung von mir, dass es pro oder contra Gen3 in Bezug auf den Preis natürlich immer auf das jeweilige Szenario ankommt. Ich habe ebenfalls nur normale Rollläden, keine virtuellen Komponenten und Matter "doesn't matter ;-)". Von daher liegt für meine Anwendung das bessere Preis / Leistungsverhältnis beim normalen Plus 2PM. Aber jemand mit Jalousien ist dann halt froh, dass er mit Gen3 diese Möglichkeit dann auch hat.

    Ja stimmt, das hatte ich auch gelesen und mir noch gedacht, dass der Chip mit mehr Speicher nicht der Grund sein kann, warum das nur die Gen3 Geräte können sollten. Da bin ich mir sicher, timing-technisch könnten das sicher auch die normalen Plus 2PM.

    Ich finde den Preis mit knapp 10 Euro mehr etwas zu hoch. Im Prinzip ist es dieselbe Hardware wie vorher, nur, dass der Speicher verdoppelt wurde, zusammen mit der Möglichkeit virtueller Komponenten und ggfs späterer Updatefähigkeit für Matter. Bräuchte ich persönlich beides nicht, aber kommt natürlich jeweils auf das Szenario an.