Beiträge von Seven of Nine

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.

  • Shelly DW2 schaltet sich ab

    so, nach ersten Tests sieht es so aus, als wenn der D&W2 einen Bug hat, das Coap-Payload [0,3109,-1] meldet den Tilt-Sensor grundsätzlich mit -1.

    Hab es im QA Bereich gemeldet, warte aktuell noch auf Validierung durch ein weiteres QA Team-Mitglied.. danach erstelle ich einen Bug-Report und dann ist es mit ziemlicher Sicherheit spätestens im nächsten Firmware-Update gefixt..

  • Shelly DW2 schaltet sich ab

    Aktivieren muss nicht zwingend bedeuten, dass es besser wird ;) Es kann auch genau das Gegenteil bewirken, deshalb unbedingt im Hinterkopf behalten.

    Wichtig wäre halt der Cloud-Test, da man damit sehen kann ob der Shelly tatsächlich ein Problem hat.

    Alternativ könnte man es mittels MQTT (nutzt TCP statt UDP-Verbindungen) oder Actions (nutzen ebenfalls TCP statt UDP) direkt im Shelly testen, falls du im OpenHAB entsprechende Configs hast..

  • Shelly DW2 schaltet sich ab

    Zitat von BGrosse

    Also ich hab ne FritzBox 7490 und nichts speziell konfiguriert an Blacklists, Whitelists, Gerätefiltern o.ä. Was könnte ich da noch prüfen?

    das (weil es sich auf UDP Multicast-Nachrichten auswirkt) hier könnnte z.B. Einfluß darauf haben:

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Deswegen wäre es eben so wichtig, es zunächst mal mit der Shelly.Cloud zu testen. Damit könnte man dann zumindest eingrenzen, ob der DW2 tatsächlich eine Macke hat oder eben dein Netzwerk die Ursache ist..

  • Shelly DW2 schaltet sich ab

    Zitat von BGrosse

    , Cloud nutze ich generell nicht, bei mir läuft alles in mein lokales System - OpenHAB.

    ok, aber diesen speziellen DW2 hattest du auch mit der Shelly.Cloud explizit getestet? wenn der nicht sendet, müsste er spätestens nach 24 Stunden als "Offline" in der Shelly.Cloud auftauchen.

    OpenHAB arbeitet über CoAp (UDP Multicast-Nachrichten), da kann es durchaus sein, dass deine Netzwerk-Infrastruktur die Nachrichten filtert / falsch gruppiert und möglicherweise nicht zum OH-Server durchlässt.. und das passiert dann nicht zwangsweise mit allen Geräten sondern durchaus auch mal nur mit einem einzelnen Shelly.


    Daher wäre es sehr wichtig, dass du das explizit mit der Shelly-Cloud testest.. Ausreichend WLAN-Empfang an der Stelle, wo er montiert ist, hat er aber?

    Zitat von BGrosse

    warum der neue jetzt zwar aufwacht und alles schickt, aber den Winkel nicht.

    Den Tilt-Sensor hattest du aber kalibriert?

  • Kurzes Tastendrück i3 nicht erkannt?

    mhh, du drückst so kurz, dass der InputEventCnt nicht hochgezählt wird? dann hatte der Schalter vermutlich gar keinen Kontakt und da kommt lediglich ein Coap-Status-Event..

    Du kannst ja mal probeweise die regulären Status-Nachrichten (kommen eigentlich alle 15 Sekunden) hochsetzen, dann irritieren sie nicht bei der Fehleranalyse.

    .../settings?coiot_update_period=600 (normal wäre 15 statt der 600)

  • Shelly Button1 und ioBroker

    ich hab in den letzten zwei Tagen damit rumexperimentiert und kann den Fehler, der beim Button1 auftritt nachvollziehen jetzt sogar mit einem anderen Shelly (i3, Shelly1) problemlos nachstellen.

    Konkret passiert folgendes:

    Die Theorie: man drückt den Button/Schalter, der Shelly wacht auf und schickt zwei Coap-Nachrichten.

    die erste enthält den beim InputEventCnt den initalen (oder alten) Wert, die zweite einen un 1 höheren Wert.

    Die Praxis: man drückt den Button/Schalter, der Shelly wacht auf und sicht zwei Coap-Nachrichten. Beide enthalten den gleichen alten Wert. Drückt man, solange der ShellyButton1 noch wach ist, weitere Male auf den Knopf funktioniert es, also InputEventCnt wird um 1 erhöht.

    Wenn man einen Shelly1, IX3 etc. rebootet und dann direkt den Taster drückt, passiert exakt das Gleiche.

    Die ersten zwei Coap-Nachrichten haben beide den Wert 1 beim InputEventCnt. Ab dann funktioniert es reibungslos.

    Beim Button1 ist es deshalb so problematisch, weil der in den DeepSleep geht und der Counter dabei immer wieder auf den initialen Wert zurückgesetzt wird (Volatile Memory)..

    Ich gehe mal davon aus, dass da ein initialer Counter falsch gesetzt ist und statt 0 eine 1 (oder umgekehrt) gesetzt wurde.

    Das hab ich heute Morgen dem Chef-Entwickler so geschrieben. Ich hoffe, dass es hilft und der Fehler dann doch mal beseitigt werden kann.

    Denn das ist ein genereller Fehler, der eigentlich alle Shellys betrifft, aber bei anderen Shellys eben (weil sie sich nicht schlafen legen) nur sehr schwer auffällt.

    Edit: auch mein eigener Code enthält manachmal Fehler:D

    alle anderen Shellys machen es richtig und starten mit 0 anstelle von 1.

    Der Fehler im Button1 ist aber trotzdem vorhanden: nach dem DeepSleep startet der Button1 mit 1 statt 0 beim InputEventCnt.

  • Shelly Button1 und ioBroker

    ich hab in den letzten zwei Tagen damit rumexperimentiert und kann den Fehler, der beim Button1 auftritt jetzt sogar mit einem anderen Shelly (i3, Shelly1) problemlos nachstellen.

    Konkret passiert folgendes:

    Die Theorie: man drückt den Button/Schalter, der Shelly wacht auf und schickt zwei Coap-Nachrichten.

    die erste enthält den beim InputEventCnt den initalen (oder alten) Wert, die zweite einen un 1 höheren Wert.

    Die Praxis: man drückt den Button/Schalter, der Shelly wacht auf und sicht zwei Coap-Nachrichten. Beide enthalten den gleichen alten Wert. Drückt man, solange der ShellyButton1 noch wach ist, weitere Male auf den Knopf funktioniert es, also InputEventCnt wird um 1 erhöht.

    Wenn man einen Shelly1, IX3 etc. rebootet und dann direkt den Taster drückt, passiert exakt das Gleiche.

    Die ersten zwei Coap-Nachrichten haben beide den Wert 1 beim InputEventCnt. Ab dann funktioniert es reibungslos.

    Beim Button1 ist es deshalb so problematisch, weil der in den DeepSleep geht und der Counter dabei immer wieder auf den initialen Wert zurückgesetzt wird (Volatile Memory)..

    Ich gehe mal davon aus, dass da ein initialer Counter falsch gesetzt ist und statt 0 eine 1 (oder umgekehrt) gesetzt wurde.

    Das hab ich heute Morgen dem Chef-Entwickler so geschrieben. Ich hoffe, dass es hilft und der Fehler dann doch mal beseitigt werden kann.

    Denn das ist ein genereller Fehler, der eigentlich alle Shellys betrifft, aber bei anderen Shellys eben (weil sie sich nicht schlafen legen) nur sehr schwer auffällt.

  • Jetzt möchte ich möchte mit einem 1PM einen anderen Shelly 1PM per URL steuern.

    Zitat von showa

    Noch eine Frage soll man für die Shellys eine feste IP Adresse Festlegen.

    nein, es gibt keinen Grund für eine feste IP:

    RE: Einsteiger-Empfehlung: DHCP statt static IP

    Zitat von funkenwerner

    kann die Reaktionszeit verbessern

    Sorry Werner, (ich schätze deine Elektro-Fachkompetenz sehr :love:) aber das ist kompletter Unfug..

    Die Reaktionsgeschwindigkeit zwischen zwei Netzwerk-Teilnehmern (meine Netzwerker-Kollegen sagen Latency dazu) hat absolut nichts damit zu tun, wie das jeweilige Gerät seine IP-Adresse bezogen hat.