Beiträge von nicedevil

    Wohl war, aber derjenige der Smarthome betreibt, wird voraussichtlich auch eher der geneigte "Heimadministrator" sein wie der normale Laie der nur ne LED Lichterkette mit ner Fernbedienung kauft :P

    Ich meine sogar, selbst ne verk....te Fritzbox kann NTP... echt ein Armutszeugnis von Sophos für eine "NEXT gen firewall"

    Problem gelöst.... Zeitserver war nicht vorhanden...

    Hatte einen Wechsel von einer Sophos UTM auf eine Sophos XG... die UTM hat nen NTP provided und die XG nicht mehr...

    Falls wer mal auf ein ähnliches Problem stößt, hier 2 Lösungsansätze:

    1. eigenen NTP Server irgendwo deployen (auf nem Raspberry Pi z.B.) => habe chrony dafür installiert und in der settings datei dazu "allow x.x.x.x/24" eingetragen (ergänzen durch eigenen IP Bereich zu hause), dienst neustarten fertig

    2. bissle spzieller auf meinen Fall => https://martinsblog.dk/sophos-xg-xg-a…ver-workaround/

    Hallo und guten Abend,

    ich bin gerade dabei meine Verbrauchswerte endlich einmal richtig zu erfassen.

    Leider muss ich feststellen, dass einer meine PlugS als energy den Wert 0 ausgibt. Und das durchgehend.

    Ist das Gerät defekt oder hat es den Maximalwert erreicht und fängt nicht wieder von vorn an?


    EDIT1:

    Code
    {"power":296.09,"overpower":0.00,"is_valid":true,"timestamp":0,"counters":[0.000, 0.000, 0.000],"total":0}

    EDIT2: Finde es sehr komisch, dass 7 von 8 Geräten genau dieses Problem zeigen und nur 1 einziges den Wert noch ausgibt?

    EDIT3: Nach Firmwareupdate vom einzige PlugS der funktionierte, verlierte dieser auch den Wert!

    EDIT4: Selbst ein Downgrade bringt hier keine Abhilfe :( Was ist zu tun?

    probier mal ob ein Downgrade das MQTT wieder ans Rennen bringt..

    hier im Firmware-Archich links im Menü findest du ältere Versionen, alternativ auch auf http://archive.shelly-tools.de (SHPLG-S als Typ auswählen.)

    Uhhhh Cool, wusste gar net das das mitlerweile so einfach geht, hatte noch im Kopf mit irgendwas fileserver aufsetzen um ne URL zu erzeugen! bin am testen :)

    Seven of Nine hat geklappt, MQTT geht wieder (instant!).

    Also haben wir einen bug gefunden?

    Hallo ihr 2 :)

    martner:

    ja kompletter Werksreset schon probiert.

    Seven of Nine (sehr lustig, gestern mit raumschiff voyager staffel 7 fertig geworden :D)

    1. nein, leider nicht

    2. MQTT Server mit IP Adresse eingetragen

    3. 1.10 (mit 1.9.4 lief noch alles)

    4. ja beide sind im 10.0.4.0/24er

    5. ja, 2 plug S direkt nebeneinander, der eine geht, der andere nicht, gleicher AP (Unifi)

    Habe gestern auch einmal probiert, den ioBroker seinen Shelly Adapter komplett neu zu machen, ohne Erfolg, der findet jetzt auch NUR noch 4 von 9 Geräten :( Hätte ich mal lieber das Update 1.10 gelassen :(

    Hallo allerseits,

    habe 9 PlugS im Einsatz. Einer von diesen scheint absolut kein MQTT mehr zu senden und empfangen zu können.

    Bevor die Frage aufkommt, ja die Zugangsdaten wurden mehrfach geprüft und abgeglichen (u.A. auch mit dem was ich in den anderen PlugS eingestellt habe). Weiterhin lasse ich gerade einen TCPDUMP auf meinem MQTT Broker laufen... Ich sehe von jedem PlugS Nachrichten auf Port 1883 eingehen, allerdings nicht von dem besagten "defekten".

    Über HTTP lässt sich der Shelly nach wie vor ein/ausschalten (z.B. mit ioBroker). Nur mein MQTT will hier nicht. Gibt es einen Tipp woran sowas mal scheitert?

    So hier habe ich die Settings gesetzt (default):

    pasted-from-clipboard.png


    Und so sieht der TCP Dump aus:

    pasted-from-clipboard.png

    Selbst wenn Username und Passwort für MQTT falsch wären, würde ich ja die Message im TCP Dump sehen.

    könnte auch am Router liegen ...

    Router ist ne Sophos UTM mit Unifi Accesspoints. Habe keine Ahnung wie das die Ursache sein kann, wenn ich 9 Shellys im Einsatz habe und 3 davon verlieren random die WiFi Connection seit 1.9.4. Vorher war das nie ein Problem.

    Gibt es irgendwelche debugmöglichkeiten hierzu?

    Hallo allerseits, also ich habe nun die Version 1.9.4, die 1.10RC1 und die 1.10RC2 getestet, allesamt sorgen bei ca. 50% meiner Shelly PlugS für regelmäßige WiFi losses. Nach einem aus und einstecken funktionieren diese wieder für eine gewisse Zeit, dann fängt der Spaß von vorne an. Komisch dabei ist, dass es immer die gleichen Geräte sind, die diese Probleme zeigen.

    Und nein die Reichweite zum AP kann es nicht sein, habe 2 Shelly PlugS nebeneinander, der eine hat das Problem der andere nicht.

    Gibts hierzu vielleicht noch andere die derartige Probleme immer noch haben?

    Das Verhalten spricht dafür, dass der D&W2 jedes Mal einen Full-Wifi-Scan (dauert ca 10 Sekunden) macht anstatt die gecashten Daten (dauert ca. 2-3 Sekunden) zu nutzen..

    Welchen Router/AccessPoint nutzt du?

    Is sone blöde Unitymedia Connectbox... Wir testen das mal. Bei meiner eigenen Umgebung mit ner Sophos UTM hab ich die "normalen" (find die eigentlich auch arsch langsam wenn man ZigBee zeug gewohnt ist) 2-3 sec. (inkl. DHCP ohne fixe IP).

    Hallo allerseits,

    habe nun den 2. Door/Window Sensor in Betrieb genommen. Leider dauert die Rückmeldung ob die Türe geöffnet oder geschlossen ist an dem 2. Gerät viiiiiiiiiiiiiiiiiiiiiiiiiiel zu lange 9-11 Sekunden.

    Der erste den ich genau gleich eingerichtet habe und die gleiche Firmware drauf habe ist da mit 2-3 Sekunden zwar auch langsam aber immernoch Welten schneller.

    Gibt es ein Setting wo ich übersehe oder ist das Gerät defekt?

    Vielen Dank für Eure Hilfe.

    Hallo allerseits,

    ich habe nun einen DW2 mir mal geholt zum testen. Leider kriege ich über MQTT keine Nachricht über den offen/zu Status gemeldet.

    Ich nutze MQTT im Node-RED für meine ganzen Shelly Plug S und da is das quasi super :)

    Grundsätzlich bekomme ich MQTT messages von dem DW2 über die Temperatur, die Helligkeit und ob er ne Verbindung hat (paradoxon.... würde ja keine haben, wenn MQTT net ankommt, aber ok), leider aber keine Nachricht über den status ob geöffnet oder geschlossen.

    Kann hier jemand nen Tipp geben?

    Oh und wenn ich eh gerade hier schon einmal was zusammenschreibe: Wie sieht es aus, ist es grundsätzlich energiesparender wenn ich jedes mal ne HTTP Seite aufrufen lasse anstelle einer MQTT nachricht zu versenden wenn sich der status ändert?