Beiträge von vistalba

Hallo zusammen

Ich suche nach eine schlauen Lösung meine bestehende Stehlampe mit einem Shelly zu verstehen.

Wichtig ist:

- Ein/Aus über physischen Schalter und App

- Dimmen über Schalter und App

Das hier steht auf dem Dimmer:

Wenn ich das richtig verstehe habe ich zwei Probleme:

a) Input ist hier 240V und Output 9-21V somit müsste der Dimmer ja vor den Transformer hier. Aber da das ein Dimmer ist, wird das wohl nicht einfach so gehen.

b) Wenn ich ein RGBW nehme, dann müsste der am Output hängen... aber dann hätte ich ja ein Dimmer vorne dran. Und den RGBW kann ich wohl nicht über den Lichtschalter betreiben?

Habt Ihr Ideen wie man so etwas hinkriegen könnte?

Hallo zusammen

Ich will euch von einem Problem berichten das ich hatte.

Ich habe einige Shellys erhalten. Einer meiner brand neuen Shelly H&T konnte aber einfach nicht mit der Cloud verbunden werden.

Es erschien eine Fehlermeldung, dass das Gerät bereits mit einem anderen Cloud Account verknüpft ist.

Das Problem hängt mit der DeviceID zusammen.

Diese besteht heute aus den letzten 6 Zeichen der MAC-Adresse. Als man sich vor mehr als 3 Jahren dazu entschieden hat, hat niemand gedacht, dass so viele Shellys verkauft werden würden.

Das Problem das nun auftaucht ist:

Eine MAC-Adresse besteht aus insgesamt 12 Zeichen. Die ersten 6 sind dabei "Vendor"-Teil und die zweiten 6 sind quasi Laufnummern.

Da nun sehr viele Shellys im Umlauf sind, wurden mehrere Vendor-Teile verwendet. Das führt dazu, dass die Laufnummern nun plötzlich doppelt vorkommen können. Und ab dann ist eine DeviceID doppelt und dieses Device kann sich nicht mit der Cloud verbinden.

Es wird deshalb ein Update geben, dass eine "LongID" generiert, welche aus den ganzen 12 Zeichen besteht.

Alle heute mit der 6-Zeichen DeviceID registrierten Geräte werden mit einer 6-Zeichen ID bleiben. Neue Geräte werden aber die 12 Zeichen DeviceID erhalten.

Mein Shelly H&T hat jetzt eine Test-FW bekommen, die das Problem gelöst hat.

Gruss

vistalba

Mich würde es für Feller Taster/Schalter interessieren. Habe aber leider keinen rumliegen um zu messen :(. Falls die gleich einer rumliegen hat.

Ich habe auch keine Ahnung warum ich so komische Effekte habe.

Aber wenn nicht Mal mehr der physische Taster an der Wand geht um die Rolladen zu bedienen sinkt der WAF ins bodenlose.

Ich hoffe das kommt nicht nochmal vor.

Hallo zusammen

Ich dachte, ich starte Mal den Thread zum 1.5.9 was ja eigentlich das Bugfix Release zu 1.5.8 ist.

Ich habe bei mir seither folgende Probleme die ich zumindest bei 1.5.7 nicht hatte:

Dimmer:

- beide DImmer die ich im Einsatz habe sind immer Mal wieder offline in der Shelly App. Zugriff mittels Homeassistant und direkt auf das WebGUI funktionieren aber weiterhin ohne Probleme. Ein "Disable/Enable Cloud" im WebGUI oder ein "Reboot" des Shellys löst das Problem kurzerhand. Nach ein paar Stunden ist der Shelly wieder offline.

Shelly 2.5:

- heute morgen war einer von 9 Shelly 2.5 offline und hat folglich die Rolladen nicht gesteuert. Auch das steuern über den Wandschalter war nicht mehr möglich. Shelly komplett unerreichbar. Kein WLAN, WebGUI. Keine Reaktion auf inputs auf "SW". Sicherung Raus/Rein hat geholfen. Shelly ist zurück online und tut als wäre nie was gewesen.

Was habt Ihr so für Erfahrungen gemacht? Ich frage mich gerade, ob ich besser wieder ein Downgrade mache.

Zitat von TheNightman

CoAP ist kein "Multicast Protokoll" sondern basiert auf UDP (UDP und multicast sind zwei ganz verschiedene Dinge). Ja, für CoAP gibt es auch eine Möglichkeit multicast für spezielle Dinge zu nutzen, siehe RFC 7252 Section 12.8

Mein openHAB läuft mit dem Shelly Binding. openHAB System und Shelly sind in verschiedenen VLANs mit unterschiedlichen IP Netzen und Router mit mDNS Reflector sowie Firewall-Regeln dazwischen.

Ich dachte auch immer, Shelly braucht nur mDNS, http und udp5683.

Genau so wollte ich das eigentlich machen:

SSID1: WPA-Enterprise mit dyn. VLAN. VLAN 100 = Clients (Smartphone, Notebooks etc.))

SSID2: WPA-PSK mit statisch VLAN 101 für IoT (und sonstigen legacy mist) => also auch die Shelly.

Beide VLANs an opnsense angehängt. mDNS Repeater auf beiden Interfaces aktiv.

Testweise zwei Rules gemacht:

VLAN 100 -> VLAN 101 / ANY (mit Log)

VLAN 101 -> VLAN 100 / ANY (mit Log)

Leider hat das mit meinen Shellies nicht funktioniert Aber wenn du jetzt sagst das es geht.. werde ich das nochmal testen.

Zitat von TheNightman

In der Unifi Controller Software kann man für eine Site einen mDNS Reflector einschalten (funktioniert nur, wenn man auch ein Unifi USG hat). Der Reflector spiegelt dann die mDNS Pakete von einem LAN ins andere.

Ich nutze das eine (bisher einzige) 2.5 Shelly komplett ohne Cloud und ohne MQTT (openHAB hat ein Binding, was das CoApp Protokoll unterstützt, was ja die Shellys nun auch können). Funktioniert bis auf die Timeouts bei schnellem hin und her schalten hervorragend.

Das von mir beschriebene WLAN Roaming (oder eben nicht-roaming) ist auch besser, seitdem ich die SSID des IoT WLAN broadcaste. Zumindest bucht sich der Shelly 2.5 dann immer in den stärkeren Access Point ein (so wie ich das auch erwarte).

USG habe ich keine. Nutze opnSense. Aber auch hier gibt es einen mDNS reflector.

Nur... das reicht leider eben nicht, da ja CoAP ein Multicast Protokoll ist.
Es gäbe zwar ein IGMP Proxy.. aber den nutze ich bereits für IPTV.

Daher bisher leider noch alles im gleichen Subnetz:-(

@da_Woody

Überlesen nicht... da ich aber die Synology APs nicht kenne, kann ich dazu nicht viel sagen

Auf die schnelle finde ich nur das hier: https://www.synology.com/en-us/knowledg…terApp/wireless

Was zeigt denn dein Scan?
Mach bitte einen Scan pro AP-Umgebung. Also ... pro "Sendegebiet".

TheNightman

Danke für deine Inputs. Genau das wollte ich mit Wie finde ich den besten WLAN Kanal für mich? beschreiben.

Grundsätzlich bleibt nur folgendes übrig:

- Soviel wie nur irgendwie möglich über Ethernet-Kabel abwickeln. Entlastet das Übertragungsmedium "Luft".

- 5GHz WiFi verwenden (insbesondere für alles was irgendwie Bandbreite braucht).

- mehr APs/kleinere Funkzellen mit weniger "Sendeleistung" -> dadurch können "weit" entferne APs die gleichen Kanäle brauchen ohne sich zu stören.

- Mit den Nachbarn sprechen, ob sie ihre WiFi Kanäle ändern würden/könnten

- Hoffen, dass Nachbarn WiFi-APs verwenden, die automatisch (und schlau) Ihr Kanal wählen... dann weichen sie deinem WiFi vielleicht aus

Ich habe übrigens ein ähnliches Setup. Aber IoT und Clients LAN ist noch nicht vollständig getrennt.

Wie hast du das mit Multicast bei den Shellys gelöst? Nur Cloud? Nur MQTT oder wie machst du das?

Zitat

hi!

ok, aber da kommt ja wieder das problem mit fremd wlans. ich bin ja extra auf den 1er geflüchtet weil um den 6er alles andere rumfleucht. dars würde im umkehrschluss bedeuten das ich bei 1x router 3x ap 4 saubere kanäle brauchen würde. bisschen unrealistisch, oder? ok, da auf dem land ist das ja eh nicht so wirklich das problem, aber in wien konnte ich mir nur einen kanal aussuchen der "möglichst" clean war.

aber abgesehn davon, bei meinem synology dingens wäre mir noch nie aufgefallen wo ich für einen ap einen anderen kanal einstellen könnte. oder kann das damit zusammen hängen, das die sowieso einen 2. 5MHz haben für interne kommunikation?

Also ich habe vor ein paar Wochen hier Mal einen Beitrag dazu geschrieben:

Wie finde ich den besten WLAN Kanal für mich?

Was du erwähnt, ist eben leider genau das Problem der 2,4GHz Frequenzen.

Kurz: Es gibt zwar 13 Kanäle die man auswählen kann. Aber leider überlagern sich diese Kanäle. Somit sind nur 1, 6 und 11 nutzbar ohne die benachbarten Kanäle zu stören.

Wenn du jetzt 3 APs auf dem gleichen Kanal (z.B. 1) betreibst. Dann störst du mit AP 1 den AP 2 & AP 3, sowie alle anderen in der Umgebung und umgekehrt.

Einfach gesagt: Luft ist nur ein Übertragungsmedium. Sprich wie beim Funkgerät. Wenn irgendeiner deiner APs oder Clients auf Kanal 1 sendet, müssen alle anderen "ruhig" sein. Ansonsten kann es dazu führen, dass das Signal so gestört wird, dass nichts mehr ankommt und die Kommunikation muss wiederholt werden.

Am besten scannst du im Empfangsbereich jedes APs die Umgebung und entscheidest, welcher Kanal hier am besten ist.

Wichtig: Ich habe z.B. bei meinen UniFi APs die Sendeleistung für 2,4GHz sogar runtergeschraubt. Mehr Sendeleistung heisst nicht, dass es besser funktioniert. Wenn ich z.B. die Sendeleistung auf "Hoch" habe, empfange ich mein WLAN noch an der Bushaltestelle die gut 100m vom AP entfernt ist. Nur... das WLAN funktioniert auf dem Smartphone extrem langsam oder gar nicht. Aber, das Smartphone bleibt im WLAN. Das ist kontraproduktiv... denn dann habe ich teils gar kein Internet mehr. Das Problem dabei: Die APs senden in aller Regel stärker als es ein Client (ein Smartphone, ein Shelly) kann. Damit ist zwar der "Empfang" möglich, aber den Gerät kann nicht antworten.

Zitat von TheNightman

Repro Setup:

- 2 Unifi AP im selben Netz mit selber SSID - SSID ist versteckt (kein SSID broadcast)

- 1x AP mit Wifi Kanal 1 und 1x AP mit Wifi Kanal 6

- AP mit Wifi Kanal 6 ist der vom Shelly bevorzugte AP (hier wurde der Shelly auch eingerichtet und dann später im Haus an einen anderen Ort gebracht - und dabei natürlich der Shelly auch neu gestartet)

- AP mit Wifi Kanal 1 ist eindeutig näher am Shelly und hat auch nach connect die deutlich bessere Empfangsleistung

Kann das jemand reproduzieren?

Zusatz nach weiteren Tests:

mit SSID broadcast (also nicht versteckter SSID) funktioniert dass Einbuchen in den AP mit der besseren Empfangsleistung.

Alles anzeigen

Ich würde dir Empfehlen den SSID Broadcast zu aktivieren.

Meine Shellys haben nämlich keine Probleme mit dem. Ebenfalls Unifi APs (UAP-AC-Pro), unterschiedliche Kanäle. Angelernt wurden alle in einem Raum wo der AP quasi gleich neben an ist. Die buchen sich nur auf dem schwachen ein, wenn ein AP Mal nicht verfügbar ist.

Aber: Dann bleiben sie für immer auf dem. Sie wechseln nie wieder zurück. Also nach jedem Unifi Firmware upgrade boote ich mit einem Script alle Shellys neu.

Zitat

aber eine andere frage: warum die unterschiedlichen kanäle in einem wlan? kann mir nicht vorstellen das das reibungslos ist.

Gleiche SSID mit unterschiedlichen Kanälen ich absolut die korrekte Konfiguration (solange sich die Kanäle nicht überlagern) also z.B. 1, 6 und 11.

So hast du (normalerweise) mehr Funkkapazität zur Verfügung.

Zitat von TheNightman

Shelly 2.5 Rollershutter - Verzögerungen beim schnellen Umschalten.

Bei meinem neuen Shelly 2.5 treten im Rollershutter Modus mit dieser Firmware nach einigen Schaltvorgängen Verzögerungen von bis zu 10 Sekunden in den Schaltvorgängen auf, wenn ich schnell nacheinander umschalte (schnell = mit ca. 0,5-1 Sekunde Pause). Es ist das selbe Verhalten mittels der Device-Weboberfläche als auch per openHAB (mit Shelly Binding). Die Befehle werden wohl in einer Queue gehalten, denn sie werden dann zeitversetzt später ausgeführt. Während der Verzögerung sind in der Weboberfläche des Shelly dann um die Schaltknöpfe (open/unten/pause) sich bewegende gestrichelte Kreise zu sehen.

Scheint ein Bug in der Firmware zu sein.

btw: Bin ganz neu hier im Forum und es ist auch mein erstes Shelly Device. Ich nutze openHAB auf RasPI mit HomeMatic CCU2 etc.

Das Problem habe ich sporadisch auch.

Mir fällt es besonders auf, wenn ich am Taster nach unten lasse (Taste fixiert) und dann "nach oben" drücke um zu stoppen und danach noch etwas leicht nach "oben" will um die Lamellen zu öffnen.

Der "verschluckt" er sich manchmal ... und reagiert verzögert/komisch.

Zitat von MIHO

Wenn du ganz runter Dimmst über den Taster, kommt dann der Auszustand?

Ja, aber nur bei den zwei Wandleuchten. Die beiden Einbausports brennen weiter (1-5%).
Das Problem ist aber nur beim Dimmen über Taster vorhanden. Wenn ich mit der App Dimme, kann ich nicht unter die definierten 5% (min. brightness) und alles funktioniert wie es soll.

Soll ich Mal beim Support ein Bug melden?

Zitat von pschumi

Hallo vistalba,

nach meinen Erfahrungen können die Wandlampen, durch längeres Festhalten beim abdimmen an einem externen Taster, sich nicht ausschalten! Das geht nur durch kurzes Tippen=Kurzimpuls am Taster. Das kannst Du sehr gut in der App erkennen, da dort die Leistung (W) beim dimmen angezeigt wird.

Auch ist es sehr stark davon abhängig, welche (dimmbaren) Leuchtmittel Du eingesetzt hast.

Habe selbst LED´s von Osram und Philips getestet, wobei die besser dimmbaren unverkennbar die von Philips bei mir sind. Diese lassen sich viel "sanfter" und gleichmäßiger dimmen und haben m. E. eine schönere Lichtfarbe bei 2700k, als wie die Osram. In zwei Wandlampen sind bei mir je einheitlich 3 x 6W/ E14 LED im Einsatz. Nach Kalibrierung ist bei mir die visuell wahrnehmbare und minimal einstellbare Wert (Minimum brightness) 20%, anstatt wie bei Dir die 5%. Alles weniger als 20%, funktioniert mit den bei mir eingesetzten LEDs (visuell) nicht mehr bzw. machen die LED-Leuchtmittel nicht mehr mit. Erfahrungen mit älteren Glühwendel-Leuchtmittel habe ich leider keine.

Hast Du verschiedene Leuchtmittel/ Lampen/ 12V-Trafos usw. am Shelly-Dimmer angeschlossen?

Hast Du schon die Calibration-Varianten durchgeführt bzw. ausprobiert?

Alles anzeigen

Ich glaube du hast mein Problem falsch verstanden.

Am Dimmer hängen insgesammt 4 Leuchtmittel. 2 Einbausports (GU10) und 2 Wandlampen mit eingebauten LEDs. Diese sind über einen einzelnen Lichtschalter (Taster - an 3 Orten) schaltbar. Alle zusammen.

Dimmen funktioniert tiptop zwischen 5% - 100%. Wenn ich unter 5% Dimme, dann gehen die beiden Wandlampen komplett aus. Die beiden Einbausports bleiben jedoch auf der tiefen Dimmstufe an.

Also setze ich als "min. Brightness = 5%" dann sollte ich ja nie unter die 5% kommen (was wirklich schon sehr wenig Licht gibt und somit kein Problem für mich ist).

Das Problem wo ich feststelle ist jedoch, dass der Wert "min. Brightness" nicht eingehalten wird, wenn ich an einem der vorhandenen Taster dimme. Wenn ich über die Software Dimme, funktioniert es. (geht nicht unter 5% - egal wie weit nach unten ich den Regler ziehe).

Zitat von MIHO

Ich bin in der QA Gruppe zum testen.

Mit 1.5.8 rc2 ist aber schon ein Unterschied zu sehen gegenüber 1.5.7.

Wenn du jetzt mit dem Taster runter Dimmst unnter Minimum Brightness , geht zumindest der Status auf aus. War bei der 1.5.7 noch nicht so war. Dort blieb er auf an. Obwohl die Birne kein Licht mehr erzeugen konnte.

Morgen soll nochmal eine Rc3 kommen. Vielleicht geht es da schon.

Okay. Also ich kann leider keine Veränderung feststellen. Aber ich denke, es schaltet bei mir nicht aus... zwei von vier Leuchten brennen ja noch.

Zitat

hi!

na wenn du hardware mässig drunter fährst kann das die software nicht ausgleichen. da müsstest du einen nagel als anschlag reinschlagen.

Ach mist, keinen Nagel zur Hand. Kann ich auch eine Schraube nehmen? Oder vielleicht doch besser einen Zahnstocher?

Zitat von MIHO

Bekannter Bug. Allterco testet gerade. Das ist mit ein Thema.

Perfekt... dann warte ich Mal ab. Ist ja nicht schlimm im Moment

Dachte ich mir eben schon, dass das wohl ein Bug in der Software ist.

Hab gerade 1.5.8-rc2 drauf gemacht. Da ist der Bug zumindest noch drin.

Woher hast du die Info?

Zitat von 66er

Aber kalibriert hast Du?

Unterschiedliche Leuchtmittel an 1 Dimmer sind aber eh suboptimal.

ja, kalibriert habe ich. Ist leider so... kann ich nicht ändern. Der Gang und die beiden Lampen im Treppenhaus sind auf dem gleichen einen Schalter.

Lustig ist aber... das ganze funktioniert in der Software ja tiptop.

Wenn ich "min. Brightness" auf 5% stellt ist alles okay. Einschalten, Ausschalten und Dimmen in der App sind i.O. Sobald ich aber am Taster dimme... merke ich, dass die Helligkeit weiter runter geht als in der App. Meine Vermutung ist, dass "min. Brightness" nicht funktioniert am Taster.

Hallo zusammen

Habe heute meine ersten Shelly Dimmer verbaut. Funktionieren auch tiptop bisher. Kann man wirklich nicht mekern. Und erst recht nicht zu dem Hammer Preis.

Ein Problem habe ich jedoch nun an einem Ort.

Der Dimmer ist an einem Platz mit drei Tastern. Insgesammt sind da dann 4 Lampen angeschlossen. Jedoch unterschiedlichen Typs (EB Spot Decke & Wandlampe im Treppenhaus).

Nun, das Dimmen funktioniert soweit gut. Jedoch benötigen die Wandlampen eine "minimum Brightness" von "5%" damit sie angehen und bleiben. Dimme ich tiefer schalten sie komplett ab.

Also habe ich im Shelly die min. Brightness auf 5% gestellt. Funktioniert auch beim Einschalten ganz gut. Wenn ich aber an einem der Taster runterdimme, dann geht er leider trotzdem immer bis auf 1% runter. Das führt dann dazu, dass die Wandlampen ausschalten.

Kennt das Problem von euch auch schon jemand? Hat man da schon eine Lösung gefunden?

Genau das wollte ich probieren.

Habe erst (wie bei allen anderen) nur L/N angeschlossen.

Als ich kein WLAN gefunden habe paar Mal rebooted (also Strom getrennt und wieder zugeschaltet). Als da nicht half habe ich den Taster an SW angeschlossen.

Strom weg, Strom an, 5 Mal drücken... nichts passiert.

Auf SW ist Strom drauf sobald der Shelly auch Strom hat.

Also wohl defekt.... super -.-

Hallo zusammen

Ich habe diese Woche ca. 15 neue Shellys erhalten. (1, 1pm, 2.5 und Dimmer).

Bevor ich die Shellys verbaue, schliesse ich diese immer kurz mit L/N an und mache die Konfiguration wie WLAN, IP-Adresse, Beschrifen etc.

Einer der Shelly 1 erstellt jedoch beim anschliessen von L/N kein WLAN. Ich habe deshalb kurz einen Taster an SW gehängt um ein Reset zu machen. Der Shelly reagiert aber überhaupt nicht darauf, das auf SW Strom anliegt.

Ist das Ding defekt? Habt Ihr noch eine Idee? Kann man noch etwas probieren/repasieren oder bleibt mir nur noch der Gang zum Support?

Tadaaa.... so einfach wärs. Hab zwar mit Drücken & Halten probiert aber anscheinend zu wenig lange. Dankeschön!

Mh... jetzt stehe ich auch da.

Ich habe iOS und Widgets erstellt. Mir passt die Sortierung nicht. Die ist einfach in der Reihenfolge in der ich die Sensoren/Switches in das Widget aufgenommen habe.

Da ich keine Möglichkeit gefunden habe es so zu Sortieren wie ich will dachte ich, ich lösche alles und füge sie in der gewünschten Reihenfolge wieder hinzu.

Nur... wie kann ich denn ein Sensor/Switch wieder vom Widget entfernen?