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.

    Der Shelly wechselte im DHCP-Bereich zwischen Fritzbox, Repeater im Keller und Repeater auf dem Dachboden.

    Ich denke da liegt das Problem.. Das passiert, weil du eigentlich 3 eigenständige WLANs mit gleichen Namen betreibst und der Shelly alle davon mehr oder weniger gut erreichen kann..

    die SSID, also der Name deines jeweiligen WIFI-Netzwerks ist ja aktuell gleich und jedes Mal, wenn der Shelly die Verbindung verliert (das kann passieren, wenn das Wifi Instabil ist oder es Funkstörungen gibt) verbindet er sich mit dem nächsten Wifi und das macht Probleme.

    Wenn du die tpPLC-Anwendung (TP Link Software) startest, dann könntest du bei den AV500 die SSID ändern, so dass du eigenständige WLANs hast.. dann wird der Shelly gezwungen sich mit dem einen für ihn bestimmten WLAN zu verbinden..

    Das würde ich aber nicht einfach machen, weil die Shellys dann unter Umständen erstmal gar kein WLAN erreichen und einen RESET bräuchten..

    Deutlich besser wäre es meines Erachtens die beiden AV500 gegen FritzPowerline Adapter mit WLAN zu tauschen, die bilden dann gemeinsam mit der FritzBox ein MESH-Netzwerk und das läuft mit großer Wahrscheinlichkeit erheblich besser..

    https://avm.de/produkte/fritzpowerline/

    Eigentlich funken die bei Events direkt, also z.b. Relay on/off, input Änderung (Schalter) ...

    ansonsten alle 15 Sekunden.

    Das kannst du aber in der REST-API prüfen / ändern

    shelly-ip/settings zum gucken

    shelly-ip/settings?coiot_update_period=20 um sie z.B. auf 20 zu ändern..

    Code
    "coiot": {
    "update_period": 15
    },

    wenn das bei dir verzögert ankommt könnten es "Latenzen" bei der Verarbeitung / beim Transport im Wifi/Lan sein.. bei mir klappt das eigentlich fast in Echtzeit.

    Das geht nur mit CURL (hatte ich weiter oben mal erwähnt) und über die Cloud.

    Da müssen die Daten via HTTP-POST als Variablen übergeben werden, daher mit dem "iexplore" in der Batch nicht machbar.

    Hier mal ein Beispiel:

    Code
    curl -s https://CLOUDSERVERURL/device/relay/control/ -d 'turn=on' -d 'channel=0' -d 'id=DEVICEID' -d 'auth_key=AUTHKEY'

    CLOUDSERVERURL, die DEVICEID und der AUTHKEY müssten entsprechend angepasst werden.


    volle Doku dazu hier:

    https://shelly.cloud/documents/deve…_api_access.pdf

    Nur der kleine Shelly 1PM ist weiterhin mucksmäuschenstill. Und ja, er (m/w/d???) ist erreichbar und fonktioniert.

    ist der direkt im Wifi oder über andere Komponten mit der SPS verbunden? Wenn da z.B. ein Switch, DLAN-Adapter oder ähnliches dazwischen hängt könnte es sein, daß da der Muliticast-Traffic blockiert wird..
    Hab selbst so einen Billig-Switch von TP Link (unmanged) hier rumfliegen, der den Traffic blockiert..

    So, hab mir mal das Handbuch zum tpPLC und die Quick_installation_guide.pdf angeschaut, leider steht da fast nichts Brauchbares drin...

    Grundsätzlich müsste es so sein, dass der Wifi-Extender beim Drücken der WPS-Taste die SSID und das Passwort kopiert und das WLAN quasi an anderer Stelle im Haus 1zu1 abbildet..

    Problematisch kann das an den Stellen im Haus werden, wo sich die WLAN-Kreise überschneiden, da für ein Endgerät zwei eigentlich unterschiedliche Wifi-Signale mit gleichen Zugangsdaten melden, die aber nicht wie bei einem MESH voneinander wissen.

    Sämtliche Daten bezüglich TCP/IP (also IP, Gateway, DNS, Subnetz) lassen sich nirgends konfigurieren, von daher wird er die Datenpakete einfach über die Stromleitung Richtung FritzBox weiterleiten..
    Warum das bei dir mit einer statischen IP und Gateway/DNS auf die FritzBox nicht funktioniert, bleibt mir ein Rätsel..

    was passiert denn, wenn du den Shelly auf DHCP stellst? Auch da sollte der AV500 den DHCP-Request an die FritzBox weiterleiten, da er ja offensichtlich keinen eigenen DHCP-Server integriert hat..

    Normal wäre alle 12 Stunden, wenn die Werte für Temperatur und Feuchte innerhalb der Schwellwerte bleiben. Maximal alle 10 Minuten, wenn sich die Werte außerhalb der Schwellwerte bewegen...

    Legst du ihn z.B. in den Backofen (hab ich mit 50 Grad getestet) sendet er ca. alle 10 Minuten, legst du ihn ins Eisfach genau das gleiche. So war es zumindest bei meinem Test-Szenario..

    Im Raum kommt es halt sehr darauf an, wie linear die Werte steigen oder fallen..

    Der Shelly1L braucht Dauerspannung auf L und Ausgang Richtung Lampe auf O...

    Alle angeschlossenen Schalter müssen zwingend von Sx oder O zum Schalter und dann zurück zum Shelly auf SW verkabelt werden..

    Sobald die Schalter/Taster von außerhalb des Shelly Spannung beziehen klappt es nicht, so hab ich zumindest SparkyMaster verstanden.

    Daher wird es mit deiner Kreuzschaltung nicht funktionieren.

    224.0.1.187 auf Port 5683
    Ob die SPS damit was anfangen kann ist fraglich, CoAp ist aber auch kein Broadcast im lokalen Netz sondern Multicast..

    Falls es dich im Detail interessiert und du Go Code lesen kannst:
    https://github.com/shelly-tools/coiot

    Ein Bespiel für den Listener liegt im example Ordner.

    Es gibt aber auch für andere Programmiersprachen entsprechende Libraries..

    Edit: wenn du die mitlesen willst geht es am einfachsten mit Linux von der Komandozeile:

    tcpdump udp port 5683 and host 192.168.222.148 -n -vv -X
    IP vom Shelly statt der 192.168... eintragen

    1) ja, das ist so

    2) er schickt seinen Status (/cit/s), Dokumentation https://shelly-api-docs.shelly.cloud/#shelly-family-overview -> bei jedem Device einzeln unter CoIoT

    3) nein, das ist eine generische Adresse, die in der CoAp RFC festgelegt wurde .. würde man die ändern, wäre es kein CoAp mehr ..

    Ich kann dir nachher mal einen Listener bauen, für welches Betriebssystem hättest du den denn gerne? Windows, Linux, MacOS und 32 oder 64bit? beim RaspBerry (Arm) müsste ich wissen, welcher Pi..

    Firmware ist denk ich im Juni das letzte mal updatet wurden.

    Dann ist das kein Bug, das war irgendwann Anfang 2019 würde ich meinen..
    Schubbie hat mich in einem anderen Beitrag aber dran erinnert:

    Der Shelly macht beim Drücken des Reset Button nach ca. 5 Sekunden einen AP auf, behält aber die Einstellungen.. der vollwertige Reset wird erst nach 10 Sekunden ausgeführt..
    Kann es ggf. daran liegen, dass du zu schnell losgelassen hast?

    Alternativ könntest du den Zugriff noch mit einem anderen Browser (Chrome, Firefox..) probieren, eventuell hast du da die Login-Daten gespeichert und der Shelly mag das nicht..


    Ansonsten versuch mal admin/admin oder admin und ohne passwort..

    Nach erfolgreichem Reset "rattert" das Relais kurz, das ist das akkustische Signal für einen erfolgreichen Reset.

    Wenn das so gemacht wurde wie du beschrieben hast, aber trotzdem nicht klappt. dann hast du vermutlich den Reset via Schalter im Gerät deaktiviert..

    Ich kenne aktuell zwei Methoden einen Shelly zu resetten, die über den Schalter und die aus der Weboberfläche.. beide sind hier offensichtlich nicht machbar..

    kannst du ggf. mal probieren, ob ein http://shelly-ip/reset noch geht? eventuell kommt da keine Passwort-Abfrage

    Eine weitere Möglichkeit wäre ein Recovery-Image auf den Shelly zu installieren, da aber das Webinterace und die API blockiert scheinen geht das nur per FTDI..