Beiträge von Hiegeix7

    Zunächst einmal sollte man begrifflich unterscheiden:
    feste IP-Adresse“: fest konfiguriert im Gerät (in der Shelly)

    „reservierte IP-Adresse“: der DHCP-Server teilt dem Gerät (der Shelly) immer dieselbe IP-Adresse zu

    Ich persönlich bin ein Fan vom Konzept „es gibt nur eine Stelle der Wahrheit“. Dies ist hier der DHCP-Server, wo eine Liste aller reservierten IP-Adressen gepflegt wird. Auf diese Weise vermeide ich

    • mehrere Listen mit potentiellen Abweichungen
    • durch DHCP werden Fehler bei Netzmaske und Default-Gateway vermieden
    • versehentlich doppelt vergebene IP-Adressen

    Der Aufwand bei einem Router-Wechsel diese Liste übertragen zu müssen, wiegt meiner Meinung nach dagegen weniger schwer.
    Und auch bei einem Reset der Shelly bekommt sie gleich wieder die richtige reservierte IP-Adresse.

    Siehe auch meine Beiträge hier und hier.

    Hallo. Ist leider ein bekanntes Problem und taucht ja z.B. nur beim update des HT auf.

    Momentan keine Lösung durch shelly in Sicht. Hat was mit dem internen Bootvorgang zu tun.

    Bei normaler Stromversorgung via USB funktioniert er aber. (Auch bei aus- und einstecken).

    Dies ist bei meinen 3 H&T's welche ich über USB angeschlossen jedoch leider nicht der Fall. Wenn ich diese von der Stromversorgung trenne und wieder einstecke, springt er mir jedes mal kurzzeitig auf die 999.9 Grad (Firmware ist bei allen 3 H&T's die aktuellste).

    Auch bei mir hat der Fehler nichts mit einem Update zu tun. Sobald die USB-Stromversorgung angestöpselt wird habe ich einen Peak von -100°C.
    Vor drei Monaten hatte ich deshalb das Ticket #S-22097195 erstellt. Es wurde allerdings ohne Lösung geschlossen, und das halte ich für eine Frechheit. (Telekom und Vodafone machen das auch gerne)

    Diverse Versuche, das Ding sowohl per Hard (SW-Schalter) als auch Soft zu resetten, waren ebenfalls ohne Wirkung.

    Ich kenne nur eine Methode für den Werksreset:

    • Shelly spannungsfrei schalten
    • Shelly mit Spannung versorgen
    • innerhalb einer Minute 5 mal auf Anschluss SW schalten
    • als Bestätigung klackt das Relais ein paar mal

    Hast du das so gemacht?

    Unabhängig vom Thema, aber vielleicht doch ganz interessant:

    Da dynamische DHCP-Adressen von allen DHCP-Servern (die ich kenne) „von unten nach oben“ vergeben werden, bin ich dazu übergegangen die reservierten DHCP-Adressen „von oben nach unten“ zu vergeben. Auf diese Weise treffen sich die beiden Bereiche „in der Mitte“, und ich kann bei Kollisionsgefahr „die Mitte“ nach oben oder unten verschieben.

    Beispiel: im Netzwerk 192.168.178.0/24 lege ich den dynamischen DHCP-Bereich auf 192.168.178.2 bis 192.168.178.127. Die dynamischen Adressen darin werden von DHCP aufsteigend vergeben.

    Meine reservierten DHCP-Adressen vergebe ich nun absteigend von 192.168.178.254 bis 192.168.178.128.

    Je nachdem, welcher der beiden Bereiche sich nun schneller füllt, ist es auf diese Weise leicht die Grenze 127 nach oben oder unten anzupassen.

    Deshalb habe ich mir diese Seite nachgebaut und den DNS umgebogen

    tichachm hat meinen Ehrgeiz gepackt :P

    Daher habe ich eine eigene Implementation in Ruby gebaut. Mit Rack bringt das Programm seinen eigenen Webserver mit, d.h. es ist kein Apache oder Nginx notwendig.

    Wer also Ruby-Ambitionen hat – bitteschön :S  
    Support kann ich aus Zeitmangel aber nur bedingt leisten.

    (die beiden txt-Dateien sollten in rb-Dateien umbenannt werden)

    tichachmalso ich bekomme das script nicht zu laufen auf meinem DS220+

    ich konnte es zwar mal aufrufen mit der ipvonNAS.tzinfo und da kam "Wrong Parameter!" , das wars aber auch schon. Da fehlt mir leider das Wissen um das umzusetzen

    Ich bin zwar nicht tichachm, aber trotzdem:

    Also, wenn du Wrong Parameter! im Browser siehst, dann läuft das Skript ja bereits erfolgreich. ;)

    Der richtige URL ist:
    http://<ipvonNAS>/timezone/tzinfo?tz=Europe/Berlin&time=1648363919  
    wobei bei time= der aktuelle Unix-Timestamp einzutragen ist.

    Ich vermute: es ist einfach zu aufwendig für eine kleine Shelly, zu ermitteln, ob gerade Sommerzeit herrscht, oder nicht.

    Der Overhead ist ja auch nicht ohne: Es müsste auf der Shelly eine Datenbank vorhanden sein, um zu ermitteln, in welcher konkreten Zeitzone wann welche Verschiebung in Kraft tritt – und das idealerweise für alle existierenden Zeitzonen. Das Verzeichnis /usr/share/zoneinfo auf einem Linux-Rechner beispielsweise ist knapp 5 MB groß. Im Vergleich dazu ist die komplette Shelly-Firmware typischerweise 1 MB groß.

    Bleibt also: die Shelly fragt regelmäßig im Internet – konkret von shelly-eigenen Servern – ab, welcher Offset aktuell für die konfigurierte Zeitzone auf die UTC, die der NTP-Server übermittelt, aufzuschlagen ist.

    Perfekt wäre, wenn jemand die entsprechende Kommunikation analysiert. Dann könnte man damit einen eigenen Dienst im LAN anbieten, und den DNS-Namen darauf umbiegen. (ich habe aktuell keine Zeit dafür)

    Lol, ich habe extra den Begriff "Tastschalter" vermieden um genau diese Diskusion und Nachfrage zu umgehen.

    Ich halte nichts davon – unabhängig von diesem Kontext – korrekte Fachbegriffe zu vermeiden. Ja ganz im Gegenteil: ich verwende immer die korrekten Fachbegriffe, und wenn ich vermute, dass ein Laie damit ein Problem haben könnte, liefere ich gleich eine Erklärung mit.

    Am meisten schmerzen mich die laxe und falsche Verwendung von Lampe/Leuchte, Nullleiter/Neutralleiter, Phase/Außenleiter, und das von Personen, bei denen man eigentlich Fachwissen vermutet.

    Ein Laie kann hinzulernen und freut sich wahrscheinlich sogar darüber. Mich erinnert dieser Sachverhalt immer an einen Deutschen, der einen Ausländer mit „du nix bei rot gehen, sonst Polizei kommen“ anredet.

    Das verwendete Bedienelement ist bei dem von Gira genannten "Tastschalter" aber nicht so eindeutig am Namen zu erkennen. Der Name enthält ja sowohl den Begriff "Schalter" als auch "Tast(er)".

    Sei mir nicht böse, aber: Doch. Das ist Deutsch:

    • Suppengemüse ist Gemüse
    • Gemüsesuppe ist Suppe
    • und ein Tastschalter ist ein Schalter

    Wenn schone feste IP, dann im Shelly direkt festlegen.

    Da bin ich anderer Meinung.
    IP-Adressen im DHCP-Server zu reservieren hat folgende Vorteile:

    • man hat das Konzept „eine zentrale Quelle der Wahrheit“ verwirklicht
    • man muss nicht in jeder einzelnen Shelly etwas konfigurieren, sondern jede Shelly läuft bereits im Werkszustand per DHCP
    • man hat keine Chance versehentlich Adressen doppelt zu vergeben, da die Software des DHCP-Servers das üblicherweise verhindert
    • man muss keine Buchhaltung führen über die IP-Adressen, denn das passiert bereits im DHCP-Server
    • man muss nicht sicherstellen Default-Gateway und Netzmaske korrekt in jeder einzelnen Shelly zu konfigurieren, und dabei Fehler zu machen
    • Änderung des Netzwerkes ist leicht (beispielsweise von 192.168.178.0/24 nach 192.168.1.0/16)
    • Wechsel eines Routers (welcher eventuell ein anderes Netzwerk konfiguriert hat) ist nicht schwer – man muss nur die MAC-Adressen und die IP-Adressen übertragen

    Lediglich bei Shelly Button 1 bin ich für eine fixe IP-Adresse, da DHCP die Reaktionszeit verlängert. Trotz fixer IP-Adresse reserviere ich diese aber dennoch zusätzlich, damit obige Punkte greifen.

    Hast du mal im Router nachgesehen, ob er eventuell unter einer anderen IP läuft?

    Das schrieb fnbalu bereits in Posting #1

    Speichert der Shelly auch die Schaltzeiten intern?

    Die Schaltzeiten, die direkt per Web-UI auf der Shelly selbst – also im Browser auf der IP-Adresse der Shelly – definiert werden, werden freilich auf der Shelly selbst gespeichert.

    Wie das mit Schaltzeiten ist, die per Händi-App definiert werden, weiß ich nicht. Ich verwende die App nicht. Ich kann mir aber nicht vorstellen, dass das in diesem Fall anders sein sollte.

    Shellys brauchen einen Zeitserver (das kann auch der eigene Router sein) nur beim Booten. Anschließend läuft die Shelly-Uhr einfach weiter.

    Lediglich die automatische Uhrumstellung zur Sommer- und Normalzeit benötigt Zugriff auf shelly-eigene Server im Internet. Kann man auf die Umstellung verzichten, braucht man gar keinen Internetzugang.