Beiträge von dewaldo

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...

Was ist denn GS ?

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.

Zitat

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

Hallo MarcKipp,

du hast die falschen Kontakte der beiden Taster verwendet. Die "Ausgänge" 12 und 22 sind jeweils NC. Für die Steuerung am Dimmer2 musst du aber die NO Kontakte verwenden, sprich 14 und 24.

Hinweis: Zum Verwenden von Blu Switches braucht es aber auch ein oder mehrere Bluetooth Gateways. Sowohl Dimmer2, als auch RGBW2 können dazu nicht dienen, aber vielleicht werkeln ja irgendwo noch ein paar Plus 2PM...

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.

Na dann passt das so doch am besten.

Wie in meinem Beitrag #5 erwähnt, hättest du z.B. auch die Möglichkeit über Tastendruck die Ausschalt-Action des Bewegungsmelders zu deaktivieren, sodass du z.B. sagen kannst, Tastendruck -> Licht an für 30 Minuten, und auch dann nicht ausschalten, wenn der Bewegungsmelder von EIN nach AUS wechselt (halt wenn man mal Dauerlicht haben will). Aber fürs Treppenhaus genügt wahrscheinlich die Variante so, wie du sie schon umgesetzt hast.

Gut, dass du das mit dem Script nochmal erwähnt hast, da wollte ich der Vollständigkeit halber nämlich auch noch drauf hinweisen. Und in Summe verstehe ich so auch die BTHome Integration.

Fazit: Sobald ihr im HA die Shelly Integration benutzt, um darüber BTHome zu nutzen, ist es faktisch dasselbe, wie der Ansatz eines BluToMQTT Scripts auf dem Shelly. Also genauso anfällig, was die Zuverlässigkeit der Übertragungen angeht, weil auch diese Variante halt einen Plus Shelly als Gateway nutzt, was eben leider momentan nicht zuverlässig läuft.

Was ich gemeint hatte im Zusammenspiel mit BTHome und HA ist, dass man ja nicht zwingend einen Shellly als Gateway nutzen muss, sondern zum Beispiel die eigene Bluetooth Fähigkeit eines Raspberry PI 4 oder sowas, und darüber die Bluetooth LE Frames zu empfangen und auszuwerten. Ist natürlich dann aufwendiger oder schwieriger, da man zur Empfangsabdeckung da auch mehr als 1 bräuchte... Gibt dazu auch eigene Projekte, z.B. mal googlen nach "OpenMQTTGateway".

Vom Preis wäre es eher 3:1. mit 80,00 EUR zu 25,00 EUR

Ich hatte aber auch beim letzten Post nur die Kurzform geschrieben ohne den Zusatz Dimmer, von daher bin ich dann auch nicht ganz unschuldig

Es ging hier aber um den Dimmer, nicht um das Pro - Relais. Ob das dort auch so ist ...