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 
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:
{"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?
auch, wenn du ihn jetzt nochmal rebootest?
Jap, gerade nochmal getestet geht!
auch die anderen 4 Geräte wo nicht gefunden wurden im ioBroker klappen jetzt wieder nach 1x downgrade und dann wieder Update. Vielen Dank!
Mhhh das scheint auch zu helfen, hab das Gerät nochmal auf die 1.10 jetzt gebracht, MQTT geht und ioBroker sieht ihn auch.
Dann geh ich mal alle nicht funktionierenden Geräte im ioBroker jetzt durch.
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
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):
Und so sieht der TCP Dump aus:
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).
Korrekt, MAC adresse vom WiFi gerät wird auf dem DHCP Server (was nicht zwingend der router sein muss) einer IP Addresse zugeordnet. So hat man ne zentrale IP Verwaltung
DHCP mit reservierung
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.
Kann ich dir filtern aber muss jetzt den 3.Satz Batterien reinstecken
wie meinst? oder war das net auf mich bezogen? 
OMG... ich hab shelly so gefeiert wegen der MQTT die möglichkeit
nie drüber nachgedacht ob es da nen plugin für node-red gibt.
Vielen Dank für diesen Thread!
Nen automatischen Trigger, der nur kommt sobald geöffnet/geschlossen wird, gibts nicht oder?
Also anstelle des dauerpollings?
Hier vielleicht noch ein Screen was ich so erhalte, wenn ich die Sensoren verbinde.
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?
Problem gefunden, Lag an einem falsch configurierten Switch in Node-RED... Loop über MQTT erzeugt.
Topic schließen, ist kein Shelly problem
