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.

    soll ich dir mal einen Listener compilieren? müsste nur wissen für welches OS.

    Ich hab das nämlich gerade nochmal getestet, das Event von eimem Shelly1 wird direkt nach Betätigen des Relais über die App ausgelöst.

    Eventuell kriegt deine SPF das einfach nicht mit oder ist mit der Anzahl der CoAp-Nachrichten überfordert.

    https://shelly-api-docs.shelly.cloud/#shelly1-1pm-coiot

    In der Doku sind oben jeweils Text-Dateien, da sind die Statusmeldungen (/cit/s) und auch die Beschreinungen (/cit/d) drin..

    im /cit/d gibt es im JSON zwei Bäumchen:

    BLK beschreibt das Gerät z.b. die Anzahl der relais

    SEN beschreibt die Felder, die über den Status mitgegeben werden.

    der erste Wert ist eigentlich immer 0, im Zweiten steht die Feld-Beschreibung, im Dritten der Wert

    1101 und 2101 sind z.B. die Werte für Output 0 und Output1 (also z.b. Relay0 und 1 bei einem Shelly 2.5.. der 3.te Wert dahinter ist entweder 0 für aus oder 1 für aus/an.

    1201 und 2201 wären die beiden Inputs (Schalter) usw.

    ein [0,1101,0] bedeutet also: Relay0 vom Shelly ist gerade aus.

    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..