Beiträge von dewaldo

Es sind ja Schalter, keine Tasten, wenn ich das richtig aufgeschnappt habe

Hab ich das falsch in Erinnerung, oder gab es mit einem der letzten Update für die GEN2 Shellies auch die "Rückkehr" der unsicheren http API ohne Digest ?

Normal sollte das inzwischen funktionieren, dass man die Weboberfläche mit Passwort versieht, aber trotzdem die Device to device URLs gehen nach dem alten Schema der GEN1 Shellys, also nicht über RPC.

Edit:

Gerade nachgeschaut. Das sollte im August letzte Jahr mit der Firmware 1.0.0. eingeflossen sein.

Der Shelly RGBW schaltet Low-side, also Richtung Masse.

Kannst du mal Bilder posten, wie es am Shelly angeschlossen ist in Kombination mit dem 12V Netzteil?

Was du auch mal tun kannst, ist dir die Statusinfo anzuschauen.

Das kannst du per Browser z.B. am Handy, sofern im selben Netz wie die Shellys.

Einfach als Adresse eingeben:

http://IPAdresseDesShelly/Status

Dann bekommst du eine Textausgabe im sogenannten JSON Format.

Und darin findest du etwa in der Mitte die Angabe darüber, welchen Zustand der Shelly von dem oder den Tastern bekommt. Du hast laut Bild 2 Taster angeschlossen.

Entsprechend wäre der Taster an SW1 dann der erste Eintrag, der an SW2 der 2. Eintrag.

Das sieht etwas so aus:

[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}]

Die Angaben innerhalb der ersten geschweiften Klammer gehören zu SW1, die anderen entsprechend zu SW2.

Hier am Beispiel siehst du hinter input: jeweils eine 0. Das heißt, hier im Beispiel wären beide Tasterzustände 0, also AUS.

Du kannst das mal machen und dann 1 Taster umschalten und dann die Abfrage des Status erneut ausführen und schauen, ob sich die Zustände dann dort ändern.

Damit kannst du schon mal sicher prüfen, ob die Tasterzustände vom Shelly erkannt werden.

Ich denke, das Thema ist festgefahren.

Tomarr:

Wenn man alles so hopplahopp macht ohne Struktur, das kann nix werden!

Du hast anfangs geschrieben, dir gehen die Ideen aus, du hättest alles resettet usw.

Aber dann schreibst du, du hättest mal eine Zeitsteuerung konfiguriert und dass die noch immer funktionieren würde.

Das kann aber nicht sein !

Folgende Fakten von meiner Seite, vielleicht bringt es dir ja noch was:

1.) ZEITPLÄNE kann ein Shelly nur ausführen, wenn er aktiv mit einem Netzwerk mit Internetzugriff verbunden ist. Wenn du ihn in deiner Prozedur stromlos hattest, und er hätte danach kein Netzwerkzugriff, kann er sich auch keine Uhrzeit beziehen, um überhaupt zu wissen, wann er schalten soll! Shellys haben keine Echtzeituhr.

2.) Ein RESET, den du angeblich durchgeführt hast, würde dazu führen, dass ein Shelly auch die konfigurierten Zeitpläne löscht, also dann auch nichts mehr zeitgesteuert ausführt !

3.) Ein RESET würde auch dazu führen, dass er nicht mehr im Netzwerk ist, also keine Uhrzeit, kein Zeitplan usw...

Da er bei dir aber das noch macht, kann er folglich nur noch immer erfolgreich im Netz sein !

Folgende Vermutung, die evtl. zutreffen könnte. Mal angenommen, du hast diese 2 Shellys am selben Tag zuhause installiert und hast beim Einrichten DHCP verwendet.

Es kann theoretisch sein, dass das Lease für die IP Adressen abgelaufen ist und beide Shellys einfach nur jetzt 2 andere IP Adressen haben als vorher.

So könnte ich mir zumindest erklären, dass er noch immer nach Zeit schaltet...

Also, vielleicht bringt's dir was, vielleicht besinnst du dich auch nochmal und wir fangen bei Null an. Die Community hier ist 1A und wir sind immer hilfsbereit.

Aber ein gewisser Respekt und Struktur braucht es halt, gilt nicht nur für's Forum !

Die Doppelpunkte, ja, das ist eigentlich auch nur eine Schreibweise.

Wir hatten eher gemeint, die Art der Aufteilung, also 8-4-4-4-12 = 32 Nibbles = 16 Bytes, passt zu einer IPv6 Darstellung.

Ich denke auch, dass dem so ist.

Aber ich sage mal, wenn du unterm Strich jetzt erreicht hast, was du wolltest, und alles klappt so ...

Hi Schubbie.

Danke. Ja, Family link nutze ich / wir seit gut 2 Monaten. Da hat unsere Große ihr erstes Handy mit Vertrag bekommen. Da funktioniert das auch überraschend gut.

Bei den Tablets geht es um Amazon Kids. Das ist ja eine App in sich und die lädt die Apps aus dem Amazon Appstore nach, das geht dann an Google vorbei.

Aber ich habe gestern nochmal getestet mit dem FB-CheckPresence Adapter klappt die Zugangskontrolle recht problemlos.

Genau. Bei unseren Geräten ist die Geräteadresse auch fix eingestellt für das Haus-WLAN.

Momentan überwiegt noch klar Vertrauen statt Kontrolle, aber bei permanent aktivem Internet ist die Verlockung einfach groß, neue Apps und Spiele zu installieren, und darum geht es hauptsächlich.

Mit 6 und 10 Jahren dauert es hoffentlich noch ein bisschen, bis sie auf solche Sachen kommen

Im Moment würden die Kids auf die Frage, was eine MAC-Adresse ist wohl noch antworten: "Na das ist da, wo ein McDonalds ist"

So, ein kurzer Versuch zeigt, über die TR-064 kann ich das Gäste-LAN nicht steuern. Und den managed switch kann ich auch nur direkt über Webinterface konfigurieren.

Aber, über TR-064 kann man die Netzwerkteilnehmer in der FritzBox kontrollieren und so z.B. den Internetzugang sperren. Hab es kurz getestet und das klappt tatsächlich ganz gut.

Leider ist das alles MAC-basiert und z.B. die meisten modernen Endgeräte variieren die ja jedesmal. Zudem auch noch 2 MACs pro WLAN Frequenzband.

Aber konkret für mein Anliegen, die Tablets der Kids zu beschränken, klappt das gut. So kann die entsprechende SSID einfach durchgehend aktiv bleiben.

Daher mein Vorschlag schon relativ am Anfang, mal in der Netzwerkübersicht zu schauen, was sich da an Geräten sonst noch tummelt.

Falls du keine FritzBox nutzt, kannst du auch z.B. die App "PingTools" nehmen, die listet das lokale Netzwerk relativ gut auf.

Blöderweise haben die ganzen Espressif Chips keine besonders eindeutigen MAC-Adressen, hier gibt es schier endlose Kombinationen, sodass man die schlecht sortieren kann.

Aber mit bisschen Fleißarbeit sollte das herauszubekommen sein, wer da der Übeltäter ist.

Was ich noch komisch finde ist, dass du ja vor der Deinstallation mal den Port von 1883 auf 1882 geändert hattest und da aber diese Meldungen noch immer gekommen sind.

Aber vielleicht wurden da die Änderungen nicht richtig übernommen.

Zitat von Dr.Pie

Ich habe einfach mal den Port von 1883 auf 1882 geändert, doch die Errors kommen noch immer.

Also wenn du den Server-Port im Shelly Adapter geändert hast für deine Shelly.1 Instanz und trotzdem kommen diese Meldungen noch, dann kann das kein "echtes Gerät" sein.

So ganz nachvollziehen kann ich das zwar nicht.

Eine Frage noch. Du hast eine Shelly.1 Instanz. Dann wird es ja vermutlich auch eine Shelly.0 Instanz geben, vermutlich für die GEN1 Shellys wegen Cloud Anbindung ohne MQTT ?

Ich würde an deiner Stelle dann einfach mal die Instanz Shelly.1 deinstallieren und neu installieren, dann halt wieder mit Port 1883 und den alten Einstellungen, dann sollten ja alle Objekte wieder passen.

Vielleicht hilft das ja. Wie gesagt, wenn die Portänderung nicht dazu führt, dass diese seltsamen Telegramme eintrudeln, dann können die nicht von einem Endgerät kommen, weil nach Portänderung ein solches sich ja nicht mehr mit dem MQTT Server (Broker) verbinden könnte.

Ansonsten gebe ich Whity recht, die Struktur passt zur IPv6. Ich hatte kurzzeitig auch solch einen Eintrag in den Netzwerkgeräten innerhalb der FritzBox. Ich glaube auch, dass er zu einem Plus 2PM gehört hatte, aber seltsamerweise nur dieser 1. Ich hatte seitdem die inaktiven Geräte in der Liste entfernt, danach war der Eintrag weg.

Falls du eine FritzBox nutzt, kannst du ja mal dort in der Netzwerkübersicht schauen, ob du diesen Hostnamen dort wiederfindest.

Ich glaube aber wie gesagt nicht mehr dran, dass hier ein echtes Gerät dahintersteckt, das ist durch Portänderung eigentlich ausgeschlossen.

Kannst du deine Beschreibung aus Beitrag #16 bitte mal auf einem Blatt skizzieren und das Bild hier einstellen ? Klingt alles etwas verwirrend beim Lesen ...

Vielen Dank für den Hinweis mit dem Gäste-LAN, guter Vorschlag.

Meine FritzBox hat zwar nur 3 LAN Ports, aber müsste dort auch klappen, einen Port als separates Subnetz für ein Gastnetz zu konfigurieren.

Ja, meine beiden Switches sind managebar, ich könnte also tatsächlich dann mit der 2. Anbindung an die FritzBox den Zugang des Gastnetzes als separates VLAN setzen.

Aktuell nutze ich 2 VLAN-IDs. Die Grandstreams können das ja auch.

Ich müsste dann nur schauen, ob per TR-064 vom ioBroker aus die Möglichkeit besteht, das Gäste-LAN bedarfsmäßig zu aktivieren und deaktivieren, dann könnte ich darüber meine gewünschte Funktion auch abbilden. Gäste WLAN geht, aber Gäste-LAN muss ich erstmal schauen.

Werde berichten, wenn ich neue Erkenntnisse habe. Jetzt bin ich erst mal froh, dass die wichtigen Dinge sauber funktionieren und aktuell habe ich das "Gäste-WLAN" per Zeitsteuerung laufen, das reicht für den Übergang erst mal. Wenn ich Zeit und Muße habe, schaue ich weiter.

Das ist in der Tat seltsam. Habe ich leider spontan auch keine Idee dazu.

Die ID mit 16 Bytes ist auch seltsam. Sicher, dass nicht auf einem deiner Plus 1PM ein Script läuft, was da sowas lostreten könnte ?

Versuch mal spaßeshalber bei all deinen Shellys (ich weiß, bisschen aufwändig) einfach mal den Server-Port der MQTT Konfiguration zu ändern, also von 1883 einfach mal auf 1999.

Dadurch kann weder der Shelly nativ, noch ein ggfs. vorhandenes Script etwas an den Shelly Adapter übermitteln.

Und dann halt schauen, ob dann immer noch was ankommt.

Wenn dann tatsächlich noch immer was käme, müsstest du mal in deiner Netzwerkumgebung alle Teilnehmer durchsehen, vielleicht fällt dir da ein Gerät auf, was du nicht auf dem Schirm hast.

Ggfs. kannst du auch als 1. Schritt mal den Port am Server umstellen anstatt bei allen Shellys und schauen, ob dann nach Adapter-Neustart die Meldung ausbleibt, wovon ich aber ausgehen würde. Aber dann weißt du zumindest schon mal, dass es ein "echtes Telegramm" sein muss.

Ich weiß es auch nicht. Gab schon einige Rückmeldungen, dass bei anderen diese oder eine ähnliche Kombi keine Probleme macht. Vielleicht liegt's an meiner FritzBox als Mesh-Master. Ist eine 5530 Fiber. Eigentlich performant und sonst klappt auch alles. Ich bleibe jetzt erstmal bei den Grandstreams, ich glaube, mit denen könnte ich warm werden auf Dauer.

Muss mal schauen, ob ich per ioBroker die Geräteprofile in der FritzBox ansprechen kann, um darüber ggfs. den Internetzugang für einzelne Geräte programmatisch zu sperren.

Oder auch die Blacklist im Grandstream mal testen, ob die per Telnet änderbar ist, ohne, dass bei der Anpassung die APs ihre Dienste wieder komplett neu starten.

Oder ich erstelle Voucher und verteile die an die Kids

Bevor es so weit käme, würde ich wahrscheinlich eher ganz auf WLAN verzichten

Je nach Lampenart bzw. Sockel, z.B. GU10, hast du ja vielleicht auch die einfache Möglichkeit, mal 1 der 5 Lampen durch eine der alten Halogen zu ersetzen, damit ist dann die Mindestlast sichergestellt für den Betrieb ohne N.

Aber wenn der Aufwand vertretbar ist, würde ich auch den Tipp von apreick umsetzen und testweise mit N mal fliegend aufbauen. Reicht ja, wenn du einfach L und N am Shelly anschließt. Last muss nicht sein für die Einbindung in dein WLAN.

Anschließend dann wieder an Ort und Stelle installieren, dann siehst du ja, ob er wie zuvor erreichbar ist oder nicht.

Ich meine, der Dimmer2 hat auf seiner Unterseite eine kleine rote LED, die bei aktivem WLAN durchs Gehäuse durchleuchtet, aber da bin ich mir nicht mehr sicher...

Starte sicherheitshalber mal die Adapterinstanz shelly.1 neu, vielleicht hat sich im Adapter selbst was "aufgehangen"....

Wenn diese Telegramme jetzt permanent im Log kommen, müsstest du notgedrungen halt der Reihe nach deine Shellys durchgehen und bei jedem Mal kurz MQTT deaktivieren oder je nach Häufigkeit genügt es auch, jeden Shelly 1x zu rebooten und dabei live zu schauen, wann die Telegramme ausbleiben, um den "Schuldigen" zu ermitteln.

Die DeviceID sieht jedenfalls seltsam aus, wie eine IPv6 Adresse...

Der Shelly Adapter auf MQTT eingestellt arbeitet ja entsprechend als MQTT Broker über den von dir konfigurierten Port und Zugangsdaten.

Kann es sein, dass du versehentlich ein anderes Gerät via MQTT eingebunden hast und dem die Daten vom Shelly MQTT Adapter gegeben hast?

Ich habe bei mir z.B. WemosD1-Mini Module mit TASMOTA im Einsatz, die auch über MQTT mit ioBroker arbeiten, aber halt über einen separaten MQTT Broker.

Und um den Unmut noch zu erhöhen von mir der Hinweis aus mehrfach eigener Erfahrung.

Ein PIR hat eine ziemlich empfindliche Verstärkerschaltung, um das Signal der PIR Sensoren auszuwerten. Und wenn ein Shelly zu nah beim PIR installiert wird, reicht die WLAN Sendeleistung des Shelly aus, um die Verstärkerschaltung des PIR zu triggern. Heißt, der PIR schaltet, obwohl gar keine Bewegung stattgefunden hat. Bei mir war der Shelly ca. 20 cm vom PIR in einer Zwischendecke installiert, das hat im Flur EG und Flur OG zu ständigem Licht an / Licht aus geführt mit entsprechenden Kommentaren meiner Frau...

Habe den PIR danach um 1 Meter versetzt, dann war Ruhe und seither achte ich von vorne herein darauf.