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.
Vielleicht noch als ergänzende Info: Ich habe in meinen Shellies - außer beim Shelly Plus 1PM - unter Advanced Developer Options CoIoT aktiviert und als Peer nicht mcast sondern die IP von Nymea:5683 hinterlegt.
Wenn du hier eine einzelne IP stehen hast, da nn senden die Shellies per Unicast auch nur dahin. Deshalb ist es vollkommen korrekt, dass du keinen Multicast-Traffic sehen kannst.
bin damit sehr zufrieden, der ist bei mir in enem Kleinverteiler im Wäschekeller verbraut. der Wifi-AccessPoint steht zwei Räume weiter.
In der Luftline zwischen Shelly und dem AP sitzt der Hauptzählerkasten mit etlichen Leitungen sowie Wasserleitungen. Trotzdem ist der Empfang super:
Zu einem dreier Pack für gute 50 Euro würde ich ja gar nichts sagen.
Der Preis ist aber kein Wunschkonzert 
Der Betrieb der Cloud kostet monatlich Geld, der "Verdienst" ist eine einmalige Zahlung an den Hersteller. Man zahlt ja beim Kauf des Gerätes nicht nur das Stück Hardware sondern auch die Kosten für die Software-Entwicklung, den Vertrieb und den Betrieb der Cloud.
Wenn du auffallen solltest (aufgrund des MAC-Filters sehr wahrscheinlich) wird dein Cloud-Account dicht gemacht und du wirst mit ziemlicher Sicherheit Post vom Rechtsanwalt kriegen weil die gegen die Nutzungsrechte der Cloud verstößt. Im Text sind ja explizit Geräte aus der Shelly home automation series benannt:
Davon ab sind die GPIO-Pin-Layouts der Geräte unterschiedlich und die Gosund SP112 wäre direkt nach dem Flashen unbrauchbar
Bei der 0.12 letzte beta ist mir aufgefallen, dass es WIFI Verbindungsabbrüche gibt, bei beiden Shellys (teilweise nur durch Spannung Aus -> EIN zu beheben).
ok, aber genau das ist doch der Punkt wo man (wenn man schon die Beta testet) den Hersteller über den Fehler informieren sollte..
Da der Shelly gleichzeitig im Wifi sein kann und einen AccessPoint aufmachen kann hat man ja beste Voraussetzungen den Fehler einzukreisen:
1) Shelly ins Wifi hängen
2) zusätzlich AP-Modus anschalten
3) Warten bis die Wifi-Verbindung zum eigentlichen WLAN weggebrochen ist
4) mit einem Endgerät (PC, Smartphone) zum AP des Shelly verbinden.
5) im Webinterface auf "Diagnostics" gehen und das Debug-Log aktiveren
6) die Daten davon rauskopieren und entweder hier im Forum posten oder direkt per Ticket an den Hersteller geben
Mit etwas Glück lässt sich der Fehler aus dem Log ableiten und beheben, dann gibt es ein neues Update und alles ist wieder korrekt..
Nur mal so als Anregung
nein, die gibt es nicht aber welchen Grund hast du? kommt es irgendwo zu einem Fehler? dann sollten wir das dem Hersteller melden.
Bei so viel Bastelkram bin ich ab jetzt raus, der Fehler wird irgendwo zwischen PiHole, Browser und Konfiguration liegen.
dem Netzwerknamen kann die Schreibeise anders sein.
die muss ebenfalls zu 100% identisch sein.. ansonsten bleibt nur den Shelly zu resetten oder den alten Router temporär zusätzlich anzustecken und die Shellies dann umziehen. der muss ja nicht zwingend mit dem Internet verbunden sein.
Eine Frage zur neuen Weboberfläsche: Wo ist die Uhrzeitanzeige geblieben?
gibt es nicht mehr, aber braucht man die? ich wüsste ehrlich gesagt nicht wofür..
Lässt sich das Shelly 1L Relais auch mit der LEDVance App steuern?
Nein, das geht mit ziemlicher Sicherheit nicht.
Ohh! Auf der REST-API bekomm ich sofort einen Output!
Und jetzt?
hast du einen AD-Blocker im Browser integriert oder irgendetwas, was den Inhalt von Webseiten filtert? oder ggf. einen (transparenten) Proxy, der als Filter fungiert?
auch auf der REST-API?
für den TRV:
http;//<ip-von-trv>/status
bzw für den Plus
http;//<ip-vom-plus>/rpc/Shelly.GetStatus
Mit NMAP und telnet reagiert der Shelly TRV auf port 80.
ok, kannst du das mal mit cURL testen? wenn nmap und telnet auf Port 80 klappen bzw. antworten dann müsste es auch mit dem cURL gehen. Dann könnte das ein einfaches Browser-Problem deines Rechners sein.
Einzelne Clients sollten so vom VPN gar nichts mitbekommen.
naja, im VPN gibt es schon gravierende Unterschiede im Vergleich zum normalen Routing bei unterschiedlichen IP-Netzen und erst Recht im Vergleich zu enem einzelnen flachen Netz.
Multicast z.B. (mDNS und Coap, nutzen die Shellies beides) funktionieren im VPN nur dann, wenn man viel Aufwand dafür betreibt
Firewall-Logs muss ich erst schauen.
Das ist grundsätzlich die erste Amtshandlung, die man macht
Ganz schön viel unsinniges Zeugs hier zu lesen 
Die TRV (Sillicon Labs Low Energy Chip) befinden sich eigentlich immer im Halbschlaf und filtern das Netzwerk-Grundrauschen weg, also ja: das ist eine Art Firewall, die den Akku schonen soll.
Bei den Plus kann ich mir das ehrlich gesagt so nicht vorstellen. Hast du mal einen einfachen Test gemacht, ob der auf Port 80 reagiert?
z.B. mit nmap oder telnet? wenn das nicht geht: was sagt das Log deiner Firewall?
Man kann den Tastschalter nicht zufällig zum Taster umbauen?
Vermutlich nicht, aber wissen tue ich es auch nicht.
Kurzer Tastendruck wird als langer erkannt. Doppelter als kurzer Tastendruck.
das kling aber als hättest du einen Tastschalter angeschlossen. Also ein Taster, der wie ein Schalter arbeitet:
- einmal drücken: Taster bleibt eingerastet.
- zweites Mal drücken: Taster wird wieder geöffnet
Welche genaue Modellbezeichnung hat der von dir angeschlossene Taster (Tastschalter)? ist das ein 506TU?
Schaue mal, ob ich das Shelly ersetzen kann....
klingt eher nach einem Bug in der Software, den der Hersteller fixen sollte..
@Olsche hast du zufällig ein Testgerät, mit dem du das testen kannst? bei mir wird morgen der Zähler getauscht und solange wollte ich definitv warten bevor ich versuche den Bug nachzustellen und ggf. dem Hersteller zu melden.
Keiner hat noch eine andere Idee?
was sagt das Log from Broker? ich würde wetten da ist die Ursache..
ja, sollte für jeden der 3 Endpunkte, alo 0, 1 und 2 funktionieren. Ansonsten wäre es ein Bug.
hab jetzt nicht das ganze Topic von Anfrang bis Ende gelesen aber die Einstellung "factory_reset_from_switch" habt ihr zum Testen auch schon auf false gesetzt?
.../settings?factory_reset_from_switch=false
Wie kann ich die Summe reseten, denn mit http://192.168.1.180/EMETER/0/reset_totals geht es nicht.
das geht nicht, von der Syntax würde ich folgendes vermuten (ungetestet, da ich meinen nicht resetten will)
http://192.168.1.180/EMETER/0?reset_totals=1
