Beiträge von mcm57

Ich nicht - liegt aber eher an den wenigen Infos :-).

Sag doch bitte mal welche(n) Shelly(ies) du wie verbaut hast.
Und zumindest mir sagt Solakon mal nichts - ist das ein Wechselrichter, Akku, etc ?

Zitat von schreckus

der Punkt ist sehr einfach und auf bewerte Weise gelößt -> dafür sind die 4 kleinen Löcher am LSS vorgesehen.

Die sind aber nicht standard. Weder meine LS von Hager noch jene von Merlin weisen diese Löcher auf.
Aber ja es gibt noch andere Systeme um ein Wiedereinschalten mechanisch zu verhindern. Und wie geschrieben - ein Fachmann wir an dem Problem sicher nicht scheitern oder sich gefährden. Eher schalte er wegen der "Kleinigkeit" dier er zu tun hat gar nicht aus 😇

Zitat von borsti0

"Leider" ist die MCB-Variantte mit 1TE "nur" als BLU+ZB bzw. Wave-Variante zu haben.
Mit den BLU-Problemen der letzten Monate würde ich nicht meine komplette Hausinstallation darauf umbauen.

Welche BLU Problem sprichst du an?

Da ich einen Shelly PRO 3 EM sowieso im Verteiler installiert habe würde dieser als BLU Gateway sehr nahe sitzen. Da sollte die Verbindungsstärke wohl unkritisch sein.

Zitat von borsti0

Und ich bin FROH DRUM dass man nicht aus der Ferne die Dinger wieder einschalten kann => wie soll denn sonst der Elektriker noch bei dir/mir zuhause arbeiten können wenn er sich nicht darauf verlassen kann dass ein ausgeschalteter LS auch ausgeschaltet bleibt. Der Punkt "Gegen wiedereinschalten sichern" würde dann ziehmlich schwer werden.

Ich stimme dir zu, dass der MCBs keinesfalsl als Lastrelais gedacht ist.

Aber gegen Wiedereinschalten zu sichern sollte wohl jeder Fachmann schaffen, auch wenn ein Ferneinschalter installiert ist. Immerhin gibt es dafür zugelassene Geräte die auch automatisch wieder einschalten (mit einer begrenzten Anzahl von Versuchen), z.B. Fernschaltautomat Type FSA, 230VAC - Online Shop - Schrack Technik Österreich

Aber ich glaub es wird hier mal OT. Bin nur gespannt wann die MCBs in den Shop kommen. Die MCB sind dort ja auch noch nicht dirnnen obwohl doch schon länger vorgestellt.

Mich würde bei den MCBs (1E) nur interessieren ob man die Ausschaltfunktion deaktivieren kann (z.B. in der Konfig). Persönlich sehe ich weit mehr Risiken durch ein ungewolltes Abschalten als echte Anwendungsfälle (ok, der vergessene Beadezimmerstrahler mag ein Grund sein ). Ich mach mir mehr Gedanken dass durch ein falsche oder irrtümliches Antippen der 'Schalterfläche' in der App der Stromkreis der Küche (incl. Gefrierschrank) bei längerer Abwesenheit abgeschaltet wird ...

Ein Deaktivieren in der Konfig würde das verhindern. Da wären dann wohl zumindest 2 Schritte fürs Ausschalten notwendig die nicht durch bloßes tippen ausgelöst werden können.

Aber ansosten seh ich die Dinger als sehr interessant an. Mal schaun was sie dafür nehmen ...

Ich habe nunmehr folgende Rückmeldung erhalten:

Hallo M. M.

Vielen Dank, dass Sie uns kontaktiert haben!

Wir haben das Problem direkt an unser Entwicklerteam zum Reproduzieren gemeldet, sobald wir weitere Informationen erhalten teilen wir Ihnen dies umgehend mit.

Der weitere Werdegang der Reklamationsabwicklung sowie ein eventueller Ersatz sind davon abhängig, ob der Fehler eindeutig und reproduzierbar nachgestellt werden kann.

Bitte haben Sie hier noch etwas Geduld.

Sollten Sie weitere Unterstützung benötigen, zögern Sie bitte nicht, uns erneut zu kontaktieren.
Wir stehen Ihnen weiterhin zur Verfügung!

Mit freundlichen Grüßen,

Shelly Support Team

Ich gehe mal davon aus dass der Satz "sowie ein eventueller Ersatz sind davon abhängig, ob der Fehler eindeutig und reproduzierbar nachgestellt werden kann." nicht ganz wörtlich gemeint ist. Da die Shellies "tot" (= defekt) sind und kein unzulässiger Einsatz (elektrische Überlast o.ä.) vorliegt sollte der Austausch eigentlich kein Thema sein...

Hier mal vorab eine WARNUNG - vorab da ich noch keine Rückmeldung von Shelly habe und natürlich auch ein Problem vor dem Bildschirm vorliegen könnte:

Ich habe in den letzten Stunden 1x Shelly Plug S Gen 3 und 1x Shelly Plug PM Gen 3 per SW geschrottet.

Beide Plugs zeigen keinerlei Reaktion mehr, d.h. keine Led Aktivität, keine Erreichbarkeit via WLAN, AP oder Bluetooth. Auch ein Powerdown (>10 Minuten) und mehrere Versuche ein Factory Reset durchzuführen zeigen keinerlei Reaktion.

Gemeinsam ist, dass der Ausfall nach dem Versuch den Nightmode via mqtt zu aktivieren aufgetreten ist. Anscheinend gibts da einen Softwarebug der tödlich zu sein scheint. Das hier ein SW Problem den Ausfall verursacht wurde mir leider erst nach dem zweiten Defekt klar...

SW Stand der Plugs:

Plug PM Gen 3: 20250903-120341/g6a304a9
Plug S Gen 3: 20260120-145240/1.7.4-gf9878b6

'Tödlicher' MQTT Request:

Topic: shellyplugsg3-e4b3xxxxxxxx/rpc
Payload: {"id":8,"src":"iobroker","method":"PLUGS_UI.SetConfig","params":{"config":{"leds":{"night_mode":{"enable":true,"brightness":100}}}}}

Der Request entspricht meiner Ansicht nach der Spec. Selbst wenn er nicht richtig sein sollte, darf meiner Anc#sicht nach aber ein Totalsaufall so nicht ausgelöst werden können.

Ein Ticket wurde bei Shelly eröffnet (@Admins - ist es sinnvoll die Ticketnummer hier zu veröffentlichen?).

Ich gebe Bescheid sobald ich eine Rückmeldung erhalten habe.

Zitat von tvbshelly

OT: Wäre gut, wenn Shelly mal seine Facebook "Affinität" überdenkt.

Wenn die Infos hier Shelly nicht interessieren dann erspar ich mir einen ausführlicheren Kommentar.

FB ist für mich KEIN Kommunikationskanal ernsthafter Natur.

Hi borstiO
Danke für deine Hilfe.

Wie oben geschrieben hat sich das Problem schon gelöst. Der PiHole Raspie hatte schlicht und einfach noch eine falsche Netzwerkmaske und damit wurden die IPv4 DNS Requests der Gen 1 Shellies blockiert. Die Gen 2+ haben ihre DNS Anfragen über IPv6 geschickt und damit gingen sie.

Den Thread kannte ich nicht. Das Problem schon

Hoff die Frage ist hier jetzt nicht zu OT:

Hast du Magenta Festnetz auch? Kennst du eine preisgünstige Lösung das Magenta Festnetz das ja nur als POTs / Amt am RJxx Kabel verfügbar ist in ein VoiP zu wandeln? Alle Fritzboxen neuer als 7590 haben ja keinen analogen Telefon-INPUT (= Amtsanschluss) mehr. Bei mir bildet die 7590 die DECT Basis und leifert den Anrufbeantworter. Auch wenn das analoge Telefon kaum mehr benutzt wird möcht ich es eigentlich nicht auflassen.

Erstmal herzlichen DANKE an alle die Rückmeldungen gegeben haben.

Und ja der Tipp mit DNS war ein voller Erfolg. Ich hatte die Netzwerkmaske von einiger Zeit von D auf C Netz erweitert (255.255.255.0 auf 255.255.0.0). Allerdings hatte ich seither keinen PiHole Raspi noch nocht rebootet. Und dieser scheint sich auch über einen Reboot der Fitzbox die alte Maske gemerkt zu haben.

Kurz:
Ich hab jetzt mal die Fritzbox direkt als DSN Server im Netz via DHCP verteilen lassen. Und siehe da - die bisher getesteten Gen1 gehen sofort online. Anscheinend haben sich die GEN 2+ die DNS Infos via IP6 Netz geholt und waren daher von der Umstellung nicht betroffen.

Also 'Fehler war ein inkonsitentes / falsches DNS Setup' das bei Gen 2+ Geräten vermutlich wegen IPv6 nicht auffiel.

Zu sonstigen Anmerkungen:

Ja, das 10.x.x.x Netz ist ungewöhnlich, Ich habe meine Rechner aber schon seit ca 30 Jahren in diesem Netz angesiedelt - damals wohl nach dem Motto größer schadet nicht. Allerdings hat sich das 10er im Zuge von VPN Strukturen zu mehreren privaten Standorten) durchaus bewährt. Technisch ist es ja zulässig und als provates Netz registiert.

Das WLAN hatte ich kurz getestet - da aber die Probleme eindeutig von der IP Addresse abhingen war es eher unwahrscheinlich dass der WLAN Chip, Antenne etc. da mitspielen. Schlechtes WLAN Signal hatte ich auch in Vermutung - aber übersioedeln von Shellies hat da nichts gebracht.

Testfunktionen konnte ich bei Shelly Gen 1 nicht finden.

Fritte ist ne 7590. Ja ist schon äklter,m aber ich hoffe sie lebt noch länger da die neuen Boxen kein POTs (analoges Amt beim Telefon) mehr können und ich zwar das Telefonsignal via Kabel erhalte, der Provider aber nur den analogen Anschluss zur Verfügung stellt und keine VoiP Daten rausrückt (Magenta Kabel Wien). Und ein POTs (Amtseite) zu VoiP (Richtung Apparat) ist eher schwer zu finden / releativ teuer.

Ich habe folgendes Problem und hoffe dass mir jemand einen Tipp geben kann. Ich bin nicht sicher wo das Problem wirklich hinpasst, da es anscheinend ALLE Shelly GEN 1 betrifft. Ich bitte daher Admins die Frage ggF zu verschieben.

Kurzfassung:

Shellies GEN 1 bauen nach IP Wechsel keine Verbindung mehr zur Cloud auf, konkret am Beispiel eines Shelly Plug

Langfassung:

• Ich betreibe eine Fritzbox. Die Adresse der Fritzbox ist 10.17.2.1 mit Netzwerkmaske 255.255.0.0.
• Die Shellies erhalten ihre IP über den DHCP Server der Fritzbox als quasi statische IP, das Flag 'immer gleiche IP zuweisen' ist aktiv.
• Bisher hatte ich meine Shellies unter der IP 10.17.2.2xx, im konkreten Fall eines Plug unter 10.17.2.221. Mit dieser Adresse ist der Shelly lokal via Webbrowser unter 10.17.2.221 und via App / Cloud erreichbar. Lt. Shelly Webinterface ist er mit der Cloud verbunden. (Also alles wie zu erwarten und ok).
• Wenn ich nun in der Fritzbox zu dem Gerät zugewiesene IP auf 10.17.3.221 ändere, die Information abspeichere und den Shelly reboote so ist der Shelly (wie zu erwarten) via Browser unter der Webadresse 10.17.3.221 erreichbar. Allerdings verbindet sich der Shelly nicht mehr mit der Cloud und ist daher ind er App 'offline'.
• Auch wenn ich die (neue) IP Adresse direkt im Shelly eingebe ("feste IP Adresse verwenden") verbindet sich der Shelly nicht mit Cloud, der Zugriff via Browser ist unter der neuen Adresse aber voll funktionsfähig.
• In Fritzbox ist der Internetzugriff auf 'unbeschränkt' eingestellt, es liegen also keine Kinderfilter etc. an.
• Sobald ich in der Fritzbox wieder die alte xx.xx.2.xx Adresse einstelle geht die Cloudverbindung sofort auf online.
• Das Verhalten habe ich bei 2x Shelly Plug und einmal Shelly EM (Gen1). Weitere Gen 1 hab ich bisher noch nciht getestet,
• Und "das Beste zum Schluss": Mit einigen Gen 2+ Geräten (pro3em63, mini Gen 4) funktionierte die Umstellung problemlos und wie erwartet. Die Cloudverbindung ging mit neuen IP sofort online.

Falls wer eine Idee hat was da abgeht bitte melden.

An sich sollte ja die lokale IP in der Cloud mal irrelevant sein und damit die Cloudseite wohl kaum die Verbindung blocken. Die Shelly Gen 1 selbst verdauen die größere Netzwerkmaske (255.255.0.0) wohl und die Webverbindung vom Laptop (10.17.2.xx) zum Shelly funktioniert ja auch. Also eine Beschränkung auf ein 255.255.255.0 Netz kann nicht vorliegen.

Im Moment bin ich ein wenig ratlos. Vor allem weil die idente Vorgangsweise bei Gen 2+ funktioniert und bei Gen 1 reproduzierbar nicht.

Danke für jede Idee.

mcm1957

An sich bist du mit solchen Fragen im ioBroker Forum besser aufgehoben (https://forum.iobroker.net). Ich warte den ioBroker Adapter und habe diesen Beitrag hier nur zufällig gefunden.

Falls das Problem noch existiert, prüfen bitte ob die COAP Einstellungen auf UNICAST gestellt sind und die richtige IP Addresse (die des ioBroker Hosts) eingetragen ist. Der Online Status wird durch http ping des Shellies ermittetl - er sagt daher nur aus, dass der Shelly im Netz sichtbar ist, nicht aber ob der Shelly den ioBroker Host erreichen kann.

Im Zwefel poste mal die COAP Einstellungsseite

Das Problem ist offensichtlich bei Shelly bekannt bzw. konnte verifiziert werden. Ich habe folgende Rückmeldung vom Support erhalten:

Zitat

Hallo N. N.,

Vielen Dank, dass Sie uns kontaktiert haben!

Wir Arbeiten bereits mit Hochdruck an der Lösung des von Ihnen genannten Problems, sobald wir weitere Informationen erhalten teilen wir Ihnen dies umgehend mit.

Sollten Sie weitere Unterstützung benötigen, zögern Sie bitte nicht, uns erneut zu kontaktieren.
Wir stehen Ihnen weiterhin zur Verfügung!

Mit freundlichen Grüßen,

Shelly Support Team

Alles anzeigen

Powermeatering wurde bei den RGBW Plus / Pro PM ergänzt.

Zum Testen steht aber sofort Version 10.6.0-alpha.7 zur Verfügung.

Diskussionstopic dazu: https://forum.iobroker.net/topic/80649/te…a-versionen/192

Nochmals:

Welche Version des Adapters hast du installiert?
An sich sollte da in der aktuellen Version nichts fehlen. Wenn doch, leg bitte ein Issue um Repository an und haäng gleich eine Log mit Level DEBUG an.

Danke

EDIT:

Ahhh ... verstehe

Unter rgb bzw. rgbw sind die Wetrte wirklich nicht konfiguriert.

Hab mir ml ein Issue erstellt. Kommt mit nächster oder übernächster Version.
[Bug]: Power values missing at components rgb / rgbw · Issue #1339 · iobroker-community-adapters/ioBroker.shelly

DANKE für die Nachfrage

Der Shelly1L veröffentlicht MQTT-tOPICS, um den Status des Ausganges anzuzeigen. Die Informationen, die unter dem Topic: shelly1lg3-xxxxx/status/switch:0 gesendet werden, sind inkorrekt – die Statusinformationen beim Attribut outputsind invertiert.

Die auf der Webseite und in der App angezeigten Informationen sind korrekt und entsprechen dem physischen Zustand des Relais. Nur das MQTT-Status-Topic ist invertiert.

Das Setzen des AUSGANGS (Relais) auf EIN über die App oder die Weboberfläche führt dazu, dass die folgenden Topics veröffentlicht werden:

2026-01-23 20:00:17.748 debug [MQTT] Publish: 10.17.2.251 (shelly1lg3 / shelly1lg3-b08184xxxxxx / shelly1lg3#b08184xxxxxx#1)

topic: shelly1lg3-b08184xxxxxx/events/rpc, qos: 1, payload: {"src":"shelly1lg3-b08184ebf45c","dst":"shelly1lg3-b08184xxxxxx/events","method":"NotifyStatus","params":{"ts":1769194817.78,"switch:0":{"output":true,"source":"HTTP_in"}}}

2026-01-23 20:00:17.755 debug [MQTT] Publish: 10.17.2.251 (shelly1lg3 / shelly1lg3-b08184xxxxxx / shelly1lg3#b08184xxxxxx#1)

topic: shelly1lg3-b08184xxxxxx/status/switch:0, qos: 1, payload: {"id":0, "source":"HTTP_in", "output":false,"temperature":{"tC":54.9, "tF":130.9}}

Bei Setzen des Ausgangs auf off ist es genauso falsch nur umgekehrt.

Problem existiert mit Version 1.7.1 und 1.7.4.beta2

Kann das noch wer bestätigen?
Ist das Problem ggF bekannt?
Wurde das bei anderen Shellies auch beobachtet?

Ein Ticket hab ich mal aufgemacht. Aber falls mich hier wer auf einen Fehler meinerseits hinweisen kann kann ich dieses ja ggF schließen um dem Support Arebit abzunehmen.

DANKE für die Info.

Ich habe versucht via Suche hiezu was zu finden - aber entweder mit den falschen Begriffen oder es gibt noch keine Antwort...

Shelly 2.5 (GEN1) ermöglicht im Cover Modus Favoritenpositionen via API auszulesen / anzufahren.

Bei den Gen2+ Devices (z.B. 2KM Plus) können zwar soweit mir bekannt Favoritenpositionen ind der App festgelegt werden, ich konnte aber in der Shelly Api Dokumentation keinerlei Hinweise auf einen API Zugriff auf die Favoriten finden - weder via rpc / rest noch mqtt.

Kann da wer was dazu sagen?

Ist ein Auslesen / Setzen / Anfahren der Favoritenpoistionen bei Shellies Gen 2+ im Cover Modus per Programmierschnittstelle (API) möglich ?

Im Kern würde mir schon ein kurzes ja geht / nein nicht oder nur via cloud möglich reichen. Aber natürlich wär ich über einen Link zur Doko / Referenz nicht unglücklich.

DANKE

Der Adapter logged prinzipiell alle Connect / Disconnects. Du kannst den Loglevel des Adapters aber anpassen wenn du keine Infomeldungen sehen willst.

Prinzipiell bist du zu Fragen die den ioBroker Adapter betreffen im ioBroker Forum besser aufgehoben:

Shelly Adapter - genereller Support