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.

    Bei einem der beiden Shelly's habe ich allerdings das Problem, dass sich beim Ein- / Ausschalten (nach ca. 4 Schaltungen hintereinander) dieser oftmals "aufhängt".

    wie schaltest du? mittelst Schalter oder mit der Shelly-App?


    Falls über Schalter:

    Ich bin mir grad nicht sicher aber bei 5x (kurz hintereinander) über den Schalter geht der Shelly meines Wissens für eine Minute in den AP-Modus..

    nimm mal den Haken unter Settings - Factory Reset bei "Enable Factory Reset from Switch" weg und prüfe, ob es dann besser wird.

    Scheinbar ist der Zyxel-Router auch inkopatibel :cursing:

    generell inkompatibel ist er vermutlich nicht, scheint aber nicht alle Clients sauber ins Internet zu lassen..

    Idee: WLAN am Zyxel aus, nur die Modem-Funktion nutzen und einen Router mit WLAN direkt in einen der LAN-Ports des Zyxel stecken..

    Der Huawei Router ist vermutlich inkompatibel mit den Shellys, zumindest bestimmte Modelle.. gibt hier sogar irgendwo im Forum eine Liste dazu.

    Was du mit den 4 anderen Shellys testen könntest:

    mit einem Smartphone einen mobilen Hotspot öffnen und darüber das Update probieren.

    Ich bin mir vergleichsweise sicher, dass es nicht generell an den Shellys liegt sondern die 4 Shellys aufgrund irgeneiner Konstellation in deinem WLAN nicht ins Internet kommen können, daher funktioniert weder Update noch wird die Uhrzeit gezogen..

    Andy_1960

    in deinem Debug-Log taucht der konkrete Grund auf:

    Disconnected, reason: 8

    Reason 8 bedeutet: Operating System moved the client to another access point using non-aggressive load balancing.

    Konkret hat also dein AP den Shelly disconnected und zumindest versucht ihn auf einen anderen AccessPoint zu verlagern (Roaming)..

    Das kann der im Shelly verbaute ESP8266 aber nicht. Roaming im Router / AccessPoint deaktivieren sollte das Problem möglicherweise lösen...

    Ich will kein spielverderber sein, aber bei TP-Link Omada ist das standardmäßig deaktiviert und ich habe dennoch massenhafte disconnects...

    bist du nicht, denn es ist auch nur einer der Gründe, warum es zu Disconnects kommen kann.. also Debug Log aktivieren und schauen, woran es liegt ;)

    sehr ungewöhnlich.

    das System mit der IP 10.0.0.138 hat also zwei Beinchen, eines in das 10.0.0-Subnetz und das andere direkt ins Internet? oder ist da irgendetwas zwischen?

    in 99,99% der Fälle (die ich kenne) haben Router die .1 oder die .254 am Ende, daher gehe ich mal vorsichtig davon aus, dass es sich dabei um eine "Bastellösung" handelt oder von welchen Hersteller ist dein Router?

    die ...long-id-shelly-devices..ist bei allen Shellys, die ausgeliefert werden vorinstalliert.. hab erst vor 2 Wochen einen frisch aus dem Karton genommen und konnte ihn problemlos einbinden / updaten.

    wenn das Einbinden der Shellys in dein WLAN geklappt hat, dann ist der Flash-Speicher im Shelly auch beschreibbar, Defekt würde ich zumindest hardware-seitig eher ausschließen..

    ich würde eher auf Routing-Probleme (falsche Netzmaske z.B.) tippen..

    10.0.0.143 ist die IP vom Shelly..

    wie lauten denn IP-Adresse & Subnetzmaske vom Router?

    Alternativ: hast du einen PC (Windows, MAC, Linux), auf dem man probeweise einen Webserver (ohne Installation) starten könnte?

    dann stell doch den Shelly auf DHCP statt statischer IP und schau, ob es danach geht..

    Wenn dir die entsprechenden EDV-Kenntnisse fehlen würde ich mal vorsichtig davon ausgehen, dass IP-Adressen, Funktion von Subnetz-Masken, Gateway etc. dir nicht wirklich etwas sagen..

    Gateway und DNS sind üblicherweise die IP-Adresse vom Router, je nach Netzwerk-Konstellation muss das aber nicht zwingend so sein..

    cloud":{"enabled":true,"connected":false}

    sagt zumindest mal, dass die Cloud nicht verbunden ist..

    update":{"status":"unknown"

    sagt, dass der Shelly api.shelly.cloud nicht erreichen kann..

    die IP ist statisch eingetragen? dann muss (für einen funktnierenden Internet-Zugang) auch Gateway und DNS-Server konfiguriert werden, außerdem muss in einer etwaigen Firewall der Zugriff von innen auf http://api.shelly.cloud  (Port 80, die reinen Software-Updates laufen über unverschlüsselte Verbindung) erlaubt sein..

    Update von einem lokalen Webserver probiert? der Shelly hat keinen Zugang zum Internet, da bin ich mir relativ sicher..

    http://<ip-vom-shelly>/ota?url=http://<localer-webserver>/SHSW-1.zip

    Beobachtet habe ich, dass auch nur 2 Befehle/Requests stabil funktionieren.

    das kommt auf Netzwerk-Latenzen an und man muss halt auch berücksichtigen, dass der im Shelly verbaute Microprozessor nicht multitasking-Fähig ist, er kann also nur einen Request gleichzeitig schicken..

    das lässt sich aber mit einem Stückchen Software (auf einem PC, der dauerhaft eingeschaltet ist) problemlos lösen..

    https://github.com/shelly-tools/ShellyActionRouter oder alternativ ioBroker, HomeAsistant, OpenHAB...

    Hatte schonmal einige Lampen auf Hue umgebaut, musste dann aber zurückrüsten da meine Frau immer den Lichtschalter drückt und somit die Lampen natürlich nicht mehr online sind.

    exakt aus dem Grund hab ich damals auch meine Hue-Lampen rausgeworfen..

    Meine damalige Lösung:

    alle Hue-Lampen ausgebaut, Shelly1 bzw. ShellyDimmer (hinter den Schalter) + einfache, dimmbare Leuchtmittel einbauen und das Problem ist gelöst.. Schalter funktioniert, App-Steuerung klappt, Sprachsteuerung geht...

    Alternative Lösung wäre z.b. eine Smarthome-Zentrale, die sowohl Zigbee als auch Wifi-Systeme ansprechen kann, damit ließe sich Shelly und Hue problemlos kombinieren.

    Ich hab hier aktuell HomeAssistant (auf einem Rapsberry) mit einem Zigbee-Stick laufen und nutze ein paar alte Zigbee-Komponenten (Fenster-Sensoren, Bewegungsmelder, Tradfri Fernbedienung..) um meine Shellys zu steuern.. Andersherum würde es natürlich ebenfalls funktionieren..

    hi,

    just tested with latest firmware: 20210323-110106/v1.10.1-gf276b51

    This syntax working fine for me :)

    mosquitto_pub -h localhost -u admin -P admin -m '{"brightness": 50, "turn": "on"}' -t shellies/shellydimmer-4200AA/light/0/set

    so maybe it's just the order of arguments (first brightness, then on) or the message isn't properly escaped?

    if I use another syntax only brightness is applied but on is ignored.

    Not working:

    mosquitto_pub -h localhost -u admin -P admin -m "{"brightness": 50, "turn": 'on'}" -t shellies/shellydimmer-4200AA/light/0/set

    Unicast hattest du probiert? Nach Änderung im Shelly muss man den Shelly neu starten..

    an meiner 7530AX hängt ein Rapsberry PI am LAN-Anschluss, darauf läuft ein HomeAssistant und die Coap-Pakete kommen da problemlos an..

    entweder hast du in der FB 7530 also eine Einstellung, die die Coap-Daten blockiert oder deine Shelly hängen z.B. im Gastnetz? dann muss der ioBroker-LAN-Port ebenfalls ins Gastnetz, weil die Fritzbox zwischen Gastnetz und Heimnetz nicht routet..