Beiträge von Ray76200

VPN/Proxy erkannt

Es scheint, dass Sie einen VPN- oder Proxy-Dienst verwenden. Bitte beachten Sie, dass die Nutzung eines solchen Dienstes die Funktionalität dieser Webseite einschränken kann.

    Vlt macht dein Shelly morgens einen Reboot und es ist in den Einstellung "OFF nach Neustart" eingestellt. Dann geht er nicht wieder an.
    Hatte damit auch teilweise Probleme, das unregelmäßig einzelne Schaltzeiten nicht gingen. Habe mir damit beholfen, dass ich zusätzliche Ein-und Ausschaltzeiten jeweils eine Minute später angelegt habe. Also EIN-5:00 Uhr und dann EIN-5:01 Uhr.

    Löst nicht das Problem, verhindert aber die Auswirkungen

    Die Platine soll ja vorrangig als Träger für die Widerstände dienen. Wenn ich das dann in eine Dose "reinbiege" habe ich halt nicht die Belastung auf den Widerstandsbeinchen bzw. dem Bauteilkörper.

    Hallo zusammen,
    da ich aktuell dabei bin, eine Schaltung zu realisieren in der ich das Schaltsignal eines Bewegungsmelders abgreifen möchte ( BWM schaltet Lampe, Shelly-Input erkennt "Lampe an" und löst entsprechende Aktion aus) benötige auch ich den viel zitierten Bukowski-Draht.
    Anbei mal ein paar Bilder meiner Ausführung.
    Es sind 2 Widerstände mit 330K in Reihe. Die Anschlussfelder werden natürlich nach dem Verlöten der Anschlussleitung noch mit Schrumpfschlauch isoliert. Das kann ich aber erst machen, wenn ich das an der entsprechenden Stelle angepasst habe.

    Mein Ziel war eine höhere mechanische Belastbarkeit des ganzen. Die Grundlage ist ein Stück Streifenrasterplatine, die bearbeitet wurde.

    Habe jetzt nicht die gleichen Leuchten im Einsatz, habe aber auch schon schlechte Erfahrung mit LEDvance gemacht. Normale "Glühbirne" E27 LED alle 2 Tage kaputt in einer Außenleuchte ohne Dimmer, einfach nur an/aus.

    Habe jetzt auf Phillips umgebaut und die laufen schon fast ein Jahr.

    Vlt mal bei Philips nach passendem Leuchtmittel suchen.

    Also bei meinem Shelly 1 funktioniert Sonnenauf- und -untergang definitv ohne Cloudanmeldung. Internetzugang hat er und somit die Uhrzeit und die Geoposition hat er sich auch bis auf wenige Meter genau automatisch gezogen. Es mag sein, dass er sich diese Daten von einem Shelly-Server holt, aber definitiv braucht er nicht die Cloudanmeldung.

    Hallo zusammen,

    ich habe einen Shelly 1 als Zeitschaltuhr installiert. Schaltbedingung "Sunset ON", "22Uhr OFF".

    Das scheint soweit zu funktionieren, leider bin ich nicht zu den Schaltzeiten vor Ort.

    Nun habe ich versucht, über das Logfile rauszufinden, wann der Ausgang jetzt genau bei "Sunset" schaltet.

    Das Logfile unter <IP>/debug/log1 gibt aber nichts her, wenn ich morgens in das Logfile schaue, zeigt er mir Werte von 3 Uhr morgens, aber nicht weiter zurück.

    Unter <IP>/debug/log2 oder log3 sehe ich noch andere Werte. Gibt es irgendwo eine Auflistung, was diese logfiles aussagen?

    Gibt es eine Möglichkeit, wie ich den Schaltpunkt meines Shellys mit Zeitstempel sehen kann? Ist das Logfile immer voll mit diesen "minute-tick"?

    Hallo zusammen,

    in einem anderen Thread habe ich schonmal meine Probleme mit dem Shelly Plug erläutert. Dieser macht unregelmäßige Reboots und löscht somit seinen Speicher mit den Leistungsmessdaten.

    In die Cloud soll das ganz nicht.

    Gibt es eine "einfache" Lösung, diese Daten regelmäßig z.B. stündlich abzurufen und wegzuspeichern? Evtl auch mit einer Möglichkeit, fehlerhafte Werte z.B. nach einem Neustart geradezuziehen um daraus dann eine Tages/Wochen/Monatsauswertung zu zaubern?

    Ich habe eigtl nicht die Muße, mich mit einem Raspberry zu beschäftigen und bräuchte etwas, das auf einem Windowssystem läuft. Entweder auf einem Server oder einfach ein kleiner Client-PC, der halt immer läuft.

    Das ganze findet im betrieblichen Umfeld statt, somit ist ein Server eh vorhanden und separate Hardware könnte beschafft werden.

    Ich habe schon ein bißchen mit Excel und der API-Abfrage rumgespielt, das würde mir grundsätzlich schon genügen an Daten. Nur eben automatisiert und ein bißchen intelligenter.

    Wo kommt denn deine Zuleitung her? Für mich sieht es so aus, als ob die braunen Adern die Zuleitung zum FI und zu deinem oberen Sicherungsblock sind. Der untere Sicherungsblock ist mittels Stromschiene mit dem FI verbunden. Würde erklären, warum sich der Messwert nur ändert, wenn du unten einen Verbraucher einschaltest: Zuleitung(braun) -> Messklemme 3EM -> FI -> Stromschiene -> LS-Schalter -> Verbraucher

    Im oberen Block ist es dann: Zuleitung(braun) -> Messklemme 3EM -> FI -> zurück durch Messklemme 3EM -> LS-Schalter -> Verbraucher

    Wenn das so ist, dann heben sich die Ströme gegenseitig auf in der Messklemme.

    Ich würde sagen, die Adern mit den roten Aderendhülsen sind die Zuleitungsadern, erkennbar am N und am PE auf der Sammelschiene. Wenn du die Messklemmen nur um diese Adern machst, müsste es klappen.

    Der Test im heimischen Stromnetz war dahingehend erfolgreich, dass der Shellyplug da tadellos funktioniert hat, während er in der Firma nicht mal 24h Uptime geschafft hat.

    Also liegt es nicht am Plug, sondern daran, dass er empfindlich auf Netzstörungen reagiert.

    Ich werde mal abwarten, was unsere zentrale Filterlösung an Ergebnissen bringt. Ein bißchen Hoffnung habe ich noch...

    Also..

    Ein Kollege aus der IT hat mal 3 Stück mit nach Hause genommen, die bei uns immer wieder den Fehler brachten. Da habe ich aber noch keine Rückmeldung.

    Der Entstörfilter in der Verteilung kommt grundsätzlich wegen anderer Sachen, die Shellys profitieren im besten Fall mit davon.

    Störungen in unserem Netz kommen allgemein durch die Anlagen, hier trägt jeder Anlagenteil mit seinen Frequenzumrichtern ein wenig zum gesamten bei. Jede Anlage in sich ist mit Sicherheit normkonform bezüglich Netzqualität, EMV etc., es summiert sich halt dann auf und wird über N/PE/Fundamenterder im gesamten Gebäude "verteilt".

    Eine Untersuchung der Netzqualität ergab einen erhöhten Störbereich bei 8kHz-10kHz. Also recht hochfrequent. Vlt leitet das RC Glied nicht genug der Störung ab...

    Tja. die finale Lösung war es wohl doch noch nicht...

    Auch der umgebaute Plug hat gestern Abend einen Reboot gemacht.

    Er hat deutlich länger durchgehalten als der originale, aber eben auch nicht zuverlässig stabil.

    Habe jetzt mal beide Plug auf die *.8er Firmware upgedatet, mal schauen wie sich das auswirkt.

    Habe den Ecomode erstmal deaktiviert, da der ja immer mal wieder Fehler verursacht.

    Es gibt erste Erfolge.

    Umgebauter Plug und Plug im Originalzustand am selben Stromkreis nebeneinander in einer Doppelsteckdose.

    Umgebauter Plug speist einen Drucker, Original speist einen PC.

    Heute um 12:30 Uhr Reboot vom Original, der Umbau lief durch (ach ja, beide Geräte befanden sich im Standby, also ist das Thema Last auch nicht relevant)

    Da beide Plug direkt nebeneinander hängen ist das Thema WLAN gänzlich raus als Ursache.

    Ich werde weiter testen und berichten.