Beiträge von Thomas_1978

Ich hatte vor einer Woche in einem bestehenden Thread eine Frage gestellt und bis heute keine Antwort darauf bekommen, obwohl ich von vor der Umstellung weiß, dass die User hier so etwas oftmals wissen bzw. gute Verbindungen zu Allterco haben. Früher gab es oft schon innerhalb weniger Minuten Antworten, manchmal dauerte es auch ein paar Stunden, aber ne ganze Woche ohne Antwort ist schon ungewöhnlich. Oder kann die Frage wirklich niemand beantworten? Falls es jemanden interessiert, es handelt sich um diesen Thread.

PS: Zu dem Thread kam ich per Google-Suche, also nicht direkt über die Forensuche.

Hallo,

bei mir hat sich heute auch der erste Duo nach einigen Monaten Nutzung mit dem selben Fehlerbild aus dem Spiel genommen. Insgesamt hatte ich letztes Jahr im Juli 6 Duos bestellt, von denen 5 unter einer Spanndecke montiert sind und einer als Reserve gedacht war.

Weiß jemand, ob Allterco die Fehlerursache mittlerweile behoben hat? Ich habe keine Lust in ein paar Wochen/Monaten die nächsten Geräte zu reklamieren bzw. wenige Monate nach Tausch aus der Gewährleistung raus zu sein und dann mit leeren Händen dazustehen wenn die neuen Duos absehbar auch kurzfristig das Zeitliche segnen.

Die Auto-Update Funktion ist zum Glück aber per default deaktiviert. Nach den letzten FW-Releases wäre es auch Unverantwortlich gewesen, wenn das anders wäre.

Stimmt, ich war gedanklich bei meiner Antwort beim Werksreset, und das ist ja von Modell zu Modell unterschiedlich.

Das ist von Shelly Gerät zu Gerät unterschiedlich. Steht aber in der Bedienungsanleitung der jeweiligen Geräte.

apreick

Ich mache den Usern, welche die Beta-FW testen, keinerlei Vorwürfe, aber der Hersteller verdient damit sein Geld und liefert die FW letztendlich auch aus. Okay, das ein abgeschaltetes WLAN Probleme bis hin zur nicht Erreichbarkeit auch beim wieder eingeschalteten WLAN produzieren kann, hatte man nicht unbedingt im Testparcour mit drin, aber wie du schon selbst geschrieben hast, gab es in der Vergangenheit leider schon mehrfach Probleme mit Firmware-Updates.

Das man im Fehlerfall kein Downgrade auf die letzte installierte FW machen kann, ist wirklich ein Unding. Sowas kann ich verstehen wenn durch ein FW-Update die Speicheraufteilung komplett neu angeordnet wird und es dadurch zu Problemen bei einem Downgrade kommt, aber das ist ja nicht die Normalität bei einem FW-Update.

@De kat

Vielen Dank für den Hinweis, aber wie du selbst geschrieben hast, gibt es diese Funktion erst ab 1.2.x und vorher hatte man diese Möglichkeit nicht. Ich hoffe das das, was über den Feedback-Link beim Hersteller landet, auch wirklich gelesen wird. Werde die Funktion aber auf jeden Fall testen sobald es eine wirklich stabile Version von 1.2.x gibt.

Ja leider.

Ich hatte letztens eine Mail zugeschickt bekommen in der ich gefragt wurde, ob ich an einer kleinen Umfrage über meine Zufriedenheit mit Shelly Produkten teilnehmen würde. Habe da auch mitgemacht, aber einen für mich ganz wichtigen Punkt gab es in der Umfrage nicht - nämlich ob es irgendetwas gibt, das mich an bei Shelly Produkten (grundsätzlich) stören würde.

Ich finde es schade, dass man zwar abfragt wie wahrscheinlich es wäre, das ich die Produkte weiterempfehlen würde (das würde ich, ohne Zweifel), aber das man nicht fragt, ob man selbst Verbesserungsvorschläge hätte oder ob es Probleme bei der Nutzung von Shelly Geräten gibt. Wenn man schon so eine Umfrage macht, dann bitte auch richtig und nicht nur mit Fragen, die konkrete Probleme aufgreifen könnten.

Und es gibt einige Punkte, die man anführen könnte. Da wären die neuen Gen3 Geräte, die in einem zeitlich wirklich sehr kurzem Abstand zu den Gen2 Geräten auf den Markt gekommen sind, obwohl es bei Gen2 und sogar noch bei Gen1 sehr viele Baustellen gibt. Der Wechsel auf Gen2 wurde ja unter anderem schon mit dem begrenzten Speicher der Gen1 Geräte begründet, und ein knappes Jahr später wirft man bereits die nächste Generation auf den Markt? Dann die Updates, die mittlerweile beim Kunden reifen - und das bei Geräten, die bei den meisten Kunden fest verbaut werden.

Ich nutze Shelly Geräte weil sie ohne Cloudzwang funktionieren, weil man, wenn man möchte, Cloud und lokale Steuerung gleichzeitig verwenden kann und weil die Geräte sich in viele Heimautomatisierungslösungen sehr gut integrieren lassen. Ich sehe das wie allinm auch: Erscheint eine neue Firmware heißt es zuerst einmal abwarten und andere die Versuchskaninchen sein lassen, ehe man dann selber aktualisiert. Aber im Gegensatz zu Microsoft, deren Betriebssystem auf einer schier endlosen Anzahl an Hardwarekonstellationen funktionieren muss, kennt Shelly die eigene Hardware. Hier kann es wenn nur zu Problemen mit den Routern der Kunden kommen. Gibt es Probleme bei Heimautomatisierungslösungen, so ist das nicht primär die Aufgabe des Geräte-Herstellers für eine reibungslose Funktion zu sehr, sondern die der Programmierer der HA-Software.

Wenn man aber beim Update seiner Shellys mit der Firmware des Herstellers schon befürchten muss, dass das Gerät im Anschluss nicht mehr (richtig) funktioniert, dann macht der Hersteller eine Tests im Vorfeld der Veröffentlichung nicht richtig. Und gerade wenn jeder so wie hier Beta-Firmwares testen kann, was ja wirklich schon ein sehr guter Weg ist, dürfen solche Fehler bei einer Stable-Version nicht mehr vorhanden sein.

Hallo,

in unserer Wohnung wurde der Flur renoviert / neu gestaltet - neuer Boden, Wände neu tapeziert und gestrichen, neue Decke und in dem Zuge auch die Deckenbeleuchtung neu gemacht. Und um eben diese Deckenbeleuchtung soll es hier gehen.

Bis zur Renovierung gab es unter der Decke eine Lampe mit 5 LED-Spots auf einer langen Schiene. Die Deckenbeleuchtung kann an drei Stellen im Flur mittels Kreuz-/Wechselschaltung ein- und ausgeschaltet werden. Das war für die alte Beleuchtung auch völlig in Ordnung.

Jetzt ist es so, dass wir anstelle der alten Beleuchtung insgesamt 5 Shelly Color Bulp installiert haben. Damit wir die Vorzüge der neuen Beleuchtung auch voll nutzen können, dürfen wir aktuell die Lichtschalter im Flur nicht benutzen, da die Lampen im stromlosen Zustand natürlich nicht auf Sprachbefehle reagieren können. Ich habe hier jetzt drei Shelly 1 mit jeweils einem einfachen Wall Switch und den passenden Rahmen vor mir liegen und mir stellt sich gerade die Frage, wie ich die Schalter montieren soll. Gibt es dazu eine Anleitung, bzw. viel wichtiger wäre erst einmal die Frage ob das überhaupt so funktioniert? Oder gibt es eine bessere Variante den Dauerstrom herzustellen (z.B. "Totlegung" von zwei der bisherigen Schalter und Dauerstrom beim verbliebenen Schalter)?

Wie würdet ihr vorgehen?

Vorweg, ich selber bin zwar nicht unerfahren in der Hausinstallation, habe es aber nie gelernt. Mein Bruder ist zwar gelernter Elektriker, übt den Beruf praktisch aber seit über 10 Jahren nicht mehr aus und muss sich da auch immer erst wieder rein denken. Die Chance, das sich hier jemand findet, der so etwas bei sich selbst schon einmal umgesetzt hat, ist also deutlich größer. Mein Bruder würde mir bei der Umsetzung zwar auch helfen, aber wenn er weiß, was wie zu machen ist, geht er da auch deutlich beruhigter dran.

Ich freue mich auf eure Vorschläge

Zitat von SvenT

?!? ich steh grade auf dem Schlauch. Zu welchem Thema soll ich ein Ticket erstellen ?

Zum Thema Authentication - je mehr Tickets bei Allterco dazu aufgemacht werden, desto wahrscheinlicher ist ein schnellerer Fix mit einem FW-Update.

So, gerade habe ich Antwort vom Support Team bekommen:

Zitat

Dear Thomas,

Thank you for reaching out to us!

Yes, we are aware of these modifications and the impact.

The revert changes are expected to be released with a new firmware version until the end of the week.

As of the moment, Gen 2 device are not subject to downgrade.

Thank you for your time and understanding!

Best Regards,

Shelly Support Team

Alles anzeigen

Bis zum Ende der Woche kommt also eine neue FW-Version raus, mit der die betreffenden Änderungen wieder rückgängig gemacht werden.

Den Hinweis darauf, das derzeit für Geräte der 2. Generation kein Downgrade möglich sei, scheint sich auf die Downgrade-Möglichkeit innerhalb der Firmware zu beziehen, da ich bei mir problemlos von 1.03 auf 0.14.1 via flashen mit externer Firmwaredatei zurück gehen konnte.

Mir gefällt das extrem lange Update-Intervall der Werte auch nicht. Gerade in Home Assistant ist es sehr irritierend wenn sich die Werte anderer Geräte sekündlich ändern und der Gesamtverbrauch über viele Sekunden unverändert bleiben. Gerade bei Schwankungen beim Balkonkraftwerk ist das extrem auffällig. Habe dazu gerade auch ein Ticket bei Allterco eröffnet, mal schauen was als Antwort kommt.

Da hier ja über OpenDTU und Shellys im Zusammenspiel mit geschrieben wird, habe ich mal eine Frage an euch. Ist es bei euch auch so, dass die Werte von Shelly und der OpenDTU stark abweichen? Ich nutze einen Hoymiles HM-1500 und habe da drei PV-Module á 370 Wp angeschlossen (für das vierte Modul ist mein Balkon leider nicht breit genug). Ist der Etrag über das BKW noch niedrig, dann halten sich die Abweichungen in Grenzen (so ca. 2-3 Watt), aber je mehr Strom erzeugt wird, desto größer wird auch die Abweichung. Bei 600 W können das schon einmal 30 W Unterschied sein. In dem Fall messen die Shelly-Geräte Plug S sowie EM Pro 3 identisch, der gemeldete Wert von der openDTU, der ja direkt aus dem Wechselrichter ausgelesen wird, liegt bei der Menge jedoch grundsätzlich niedriger - bei 600 W sind das um die 35 W Differenz, die sich dann auch in den Saldierungen bemerkbar machen. Bei um die 5 W Unterschied könnte ich damit ja leben, aber 35 W sind schon ne andere Hausnummer, und wenn ich das BKW demnächst mit 800 W laufen lassen kann, dann wird die Abweichung ja nur noch größer.

Könnt ihr das bei euch auch beobachten und wie hoch sind eure Unterschiede?

Die 6690 hat auch ordentlich Dampf unter der Haube, die läuft hier mittlerweile auch und hat von Vodafone seit ein paar Tagen das Update auf 7.50 spendiert bekommen. Mein /22 Netz besteht schon ein paar Jahre, da hatten die Fritzboxen noch bedeutend schwächere CPUs verbaut gehabt. Die aus meiner Sicht erste potente Fritzbox war die 7490 für DSL, bzw. 6490 Cable für Kabelkunden. Wirklich vergleichbar mit der 6690 Cable empfand ich bisher aber nur die 6591 Cable.

Aber wir driften so langsam vom eigentlich Thread-Thema ab, und bevor hier wegen uns die Putzkolonne durchwischt, sollten wir besser wieder zum Thema zurück

Ich habe gerade mal die IP-Adressen 10.0.1.201 - 10.0.1.209 angepingt, da kommt von keiner Adresse eine Antwort.

Anfangs wusste ich noch nicht wie sehr mich das Shelly Fieber packen könnte als ich mit ein paar Plug S angefangen hatte. Um von vornherein Strukturkonflikte zu vermeiden, fing ich an, diese im 1er Bereich "von hinten" mit IP-Adressen zu versorgen. So bekam dann mein erster Plug S die IP-Adresse 10.0.1.254 und die nächsten Plug S dann .253, .252 usw. Irgendwann war dann aber der Punkt gekommen, wo ich dafür zu viele Geräte hatte um diese noch einigermaßen systematisch zuordnen zu können und ich organisierte mich um. Bei der IP-Adressvergabe im 1er Bereich war die höchste von vorne vergebene Adresse die .102 und ich entschied mich, die Shellys von .200 an zu vergeben. Im Nachhinein betrachtet war selbst der Bereich von 54 Geräten arg knapp bemessen, denn es gibt ja so viel, was man mit Shellys smart machen kann.

Insofern bin ich mir auch ziemlich sicher, dass ich die IP-Adressen .201 - .209 noch nie vorher vergeben habe.

Ein /18 Netz ist nicht uninteressant, das muss ich zugeben. Ich hatte mein Netz damals auf ein /22 begrenzt, da ich im Netz einige Berichte gelesen hatte, dass die (damaligen) Fritzboxen mit zu großen Netzen überfordert wären, bzw. sich das negativ auf die CPU-Leistung und Reaktionsfähigkeit der Fritten auswirken würde. Da es bei dir funktionert, ist das mittlerweile wohl kein Thema mehr.

Wofür soll die Fritte denn hinter dem DHCP-Bereich noch Adressen zur Verfügung halten? Das wäre mir neu, dass da ein Bedarf besteht (zumindest bei meiner Konfiguration).

Ich nutze folgende IP-Adressbereiche, von denen der, ich sage mal 3er Bereich, exklusiv für DHCP genutzt wird.

10.0.0.1 - 10.0.0.254

In diesem Bereich habe ich alle Netzwerk- und Servergeräte untergebracht. Das beinhaltet Router, AccessPoints, Switche, Server.

10.0.1.1 - 10.0.1.254

In diesem Bereich befinden sich meine Client-Computer, Laptops, Drucker, Backup-NAS sowie Heim-Automatisierungsgeräte.

10.0.2.1 - 10.0.2.254

Hier habe ich alles untergebracht was mit Unterhaltungselektronik zu tun hat (meine E2-Receiver, Surroundanlage, TV-Geräte, usw.)

10.0.3.1 - 10.0.3.254

Dieser Bereich ist ausschließlich DHCP vorbehalten und beherbergt Smartphones, Tablets (eigene wie auch von Besuchern - benötige hier kein Gäste-WLAN) sowie alle Geräte, die sich erst einmal mittels DHCP im Heimnetz anmelden, bevor sie dann von mir eine feste IP-Adresse erhalten.

Gateway ist immer 10.0.0.1, Subnetzmaske ist 255.255.252.0, DNS-Server ist 10.0.0.3 (mein PiHole mit Unbound) und 2. DNS-Server ist meistens 8.8.8.8 oder 9.9.9.9

Bei den Shellys ist der erste DNS-Server allerdings nicht das PiHole sondern direkt 8.8.8.8, da die Shellys mit dem PiHole öfter mal Probleme haben/hatten.

Okay, zugegeben, der 2er Bereich ist eigentlich überflüssig, da sich hier nicht sooo viele Geräte tummeln. Wahrscheinlich werde ich die paar Geräte in naher Zukunft in den 1er Bereich verschieben und die komplette Heimautomatisierung in den 2er Bereich packen. Das würde nach aktueller Lage mehr Sinn machen und auch mehr Ordnung in die Struktur bringen. Aber als ich die Struktur mal festgelegt hatte, hatte ich lediglich Zigbee Geräte im Heimnetz, die aber in einem völlig eigenen Netzwerkbereich funken.

Einen Versuch ist es wert, auch wenn ich mit dem AVM-Support jetzt nicht nur positive Erfahrungen gemacht habe - seitdem kommt mir auch nur noch eine Miet-Fritte von Vodafone ins Haus, sollen die sich doch mit dem Support herumschlagen. Und zumindest scheint man mit der 7.50er Firmware bei den Kabelfritten dieses lästige TR-369 unterbinden zu können, womit Vodafone neben detaillierten Messwerten auch sämtliche Daten zu Geräten, Netzwerk und WLAN auslesen kann.

Aber noch etwas anderes - ich hatte hier vorhin vom Update 0.14 für Gen2 Geräte gelesen. Das wurde mir in der Cloud für meine Gen2 Geräte auch angezeigt, mit Ausnahme des Pro 3EM, welcher die neue FW selbst nach Suche über das WebUI nicht finden konnte. Jetzt, mit neuer IP-Adresse, wird mir das Update sofort angezeigt. AVM scheint hier echt nur die Kommunikation nach außen bei den entsprechenden IP-Adressen zu unterbinden, nicht aber die Erreichbarkeit innerhalb des Heimnetzes.

Backbe - YOU ARE MY MAN....

Zitat von Backbe

Kurzes Update von mir:

Alle Shelly´s haben jetzt eine feste IP und sind in der Cloud. Was damals wie gestern schief lief: Komischer Weise können sich Geräte, die die "End-IP" .201-.209 haben nicht mit dem Internet verbinden, obwohl der DHCP Bereich nur bis .200 geht?? Hab jetzt bei 210 angefangen und alles war bestens. Vielleicht hilft dies irgendwie irgendwann irgendwem irgendwo!

Ja, mir heute... und ich bin schon seit Wochen auf der Suche nach der Ursache, warum mein Shelly Pro 3EM keine Verbindung in die Cloud aufbauen kann, bzw. diese immer nur sporadisch und ohne erkennbaren Grund wieder weg war, obwohl die WebUI jederzeit aus dem Heimnetz erreichbar war/ist.

Der Pro 3EM hat(te) die feste IP-Adresse 10.0.1.201 und der DHCP-Bereich meiner Fritzbox 6690 Cable geht von 10.0.3.1 - 10.0.3.254 (Subnetzmaske 255.255.252.0 oder einfacher ein /22 Netz), womit eine Doppelbelegung praktisch ausgeschlossen ist, da ich jede händisch vergebene IP-Adresse in eine Excel-Tabelle eintrage. Wäre hier tatsächlich eine Doppelbelegung vorhanden, dann hätte ich zudem auch Zugriffsprobleme aus dem heimischen WLAN auf den Pro 3EM haben müssen, das war aber niemals der Fall gewesen. Auch nutze ich auf der Fritzbox kein VPN, da ich mittels Wireguard, welcher auf meinem Unraid-Server läuft, die VPN-Verbindung von außerhalb ins Heimnetz aufbaue. Ebenso ist keinem angelegten Benutzer in der Fritzbox die Nutzung der VPN Funktion der Fritzbox erlaubt (Haken sind bei allen raus).

Insgesamt erstreckt sich mein Heimnetz mit dieser Subbetzmaske über den IP-Adressbereich 10.0.0.1 (Router) bis 10.0.3.254

Seit ich jetzt vor ca. einer halben Stunde die IP-Adresse von 10.0.1.201 auf 10.0.1.210 umgestellt habe, funktioniert der Pro 3EM wieder tadellos. Und ich war schon drauf und dran den Fritz!Repeater 6000 näher an den Pro 3EM zu bringen, damit dieser ein stärkeres WLAN-Signal empfängt, hätte aber letztendlich auch nichts gebracht, da der Pro 3EM ansonsten ja tadellos per WLAN zu jeder Tages- und Nachtzeit erreichbar war.

Mein Fazit: Die Fritzbox reserviert anscheinend in allen IP-Adressbereichen mindestens die IP-Adressen .201 - .208, eventuell auch .209, selbst dann, wenn man die Fritzbox interne VPN Funktion gar nicht nutzt. Das ist für den betroffenen User extrem schwer herauszufinden, da dies so auch nicht in der Dokumentation von AVM beschrieben steht.

In meinem Fall befindet sich die Fritzbox im IP-Adressbereich 10.0.0.1 - 10.0.0.254, betroffen ist bei mir aber die Adresse im IP-Adressbereich 10.0.1.1 - 10.0.1.254

Ist schon okay, ich hatte ja auch nicht genau geschrieben was ich an der bisherigen AP-Umsetzung bemängel.

Hatte den TRV zuerst sich mittels DHCP am AP des Plus 1 anmelden lassen und stellte dann fest, dass der AP dem TRV bei jedem Aufwachen und Verbinden eine neue IP-Adresse zugewiesen hatte, was für das Aufrufen der WebUI innerhalb des AP-Netzes eine unnötige Hürde darstellt, da man erst über die Cloud die aktuelle IP-Adresse herausfinden musste, bzw. auf die da hinterlegte sogar noch das vierte Segmente um 1 erhöhen musste (die IP-Adresse erhöhte sich im vierten Segment bei jedem Aufwachen um 1, bei mehreren Geräten im AP-Netz konnten das aber auch größere Sprünge je Gerät sein). Hatte dann dem TRV eine feste IP-Adresse zugeteilt, was zumindest den Zugriff aufs WebUI von innerhalb des AP-Netzes ermöglichte.

Um Zugriff auf den TRV von außerhalb des AP-Netzes zu erhalten, muss man ja die IP-Adresse des Plus 1 gefolgt vom durch den Plus 1 vergebenen Port in die Adresszeile des Browsers eingeben, woraufhin man dann auf die WebUI des TRV weitergeleitet wurde. Dummerweise ändert sich dieser Port ebenfalls bei jedem Aufwachen und Verbinden des TRV mit dem Plus 1 - also kam ich vom normalen Heimnetz nach dem ersten Aufwachen nicht mehr auf den TRV im AP-Netz und auch die Kommunikation des TRV mit anderen Shellys im normalen Heimnetz funktionierte nicht mehr.

Das sind im Großen und Ganzen die beiden Punkte, die ich beim AP-Modus der Plus und Pro Geräte bemängel. Hier wäre ein Register schön, wo der AP sich merkt, welchem Gerät im AP-Netz er welche IP-Adresse und welchen Port zugewiesen hat. Aber so wie es zu meinem Test war, war die Funktion für mich komplett nutzlos.

Zumindest hattest du mich bei deiner Antwort zitiert: RE: Unterschied Shelly 3em vs. Pro 3em ??

Danach sieht es für mich so aus, als hättest du auf meine Aussage reagiert...

Zitat

Manchmal verstehe ich die Anforderungen an ein Hausautomationsgerät nicht, sorry.

Für Netzwerkfunktionen nehme ich Netzwerkkomponenten und keine Hausautomationsgeräte!

Bisher hatte ich doch noch gar nicht geschrieben worauf ich mich genau beziehe. Insofern kann ich auch nicht nachvollziehen, was du in meine Antwort interpretiert hast.

Als ich zuletzt den AP eines Plus 1 genutzt hatte, der sich empfangstechnisch im stabilen Grenzgebiet meines WLAN befand, wollte ich damit den TRV im benachbarten Raum, der schon nicht mehr stabil ins WLAN kam, in die Cloud mit aufnehmen. Das funktionierte einigermaßen gut, aber eben auch nur einigermaßen. Wie sich herausstellte, bekam der TRV bei jedem Aufwachen eine neue IP-Adresse aus dem internen Pool des AP, was es mir mit dem Smartphone, sofern ich damit im selben AP des Plus 1 eingeloggt war, extrem umständlich machte, auf die WebUI des TRV zu gelangen. Ebenso bekam der TRV auch jedes Mal einen neuen Port zugewiesen, der es mir ebenfalls extrem erschwerte, die WebUi von außerhalb des AP-Netzes aufzurufen.

Hier wünsche ich mir entweder eine statische IP-Adressen innerhalb des AP, oder aber zumindest eine Memory-Funktion für die IP-Adressen, sodass Geräte innerhalb des AP-Netzes nicht random neue Adressen und für den AP-externen Zugriff random Ports zugeteilt bekommen.

Ich habe diese Funktion allerdings seit den letzten beiden FW-Updates nicht mehr benutzt, da ich meine Wohnung mit einem generell stärkeren externen AP erweitert habe, wodurch auch der entfernte TRV eine stabile Verbindung zum WLAN halten kann.