Beiträge von dewaldo

Huch, seltsam. Eigentlich dachte ich, ich bin der erste, der auf den Thread antwortet ... Bin gerade etwas irritiert. Nach Absenden meines Beitrags sehe ich die ganzen Antworten jetzt...

Na ja , dann ist das Thema ja schon durch

Wenn du schreibst, stehen auf "Verbinden", woher stammt diese Info ? Vom Shelly Webinterface ?

Meine Vermutung wäre grundsätzlich, dass nach dem ganzen Neugestarte der FritzBox vermutlich die Shellys alle neue IP-Adressen bekommen haben vom DHCP Server der FritzBox.

Ich weiß nicht, wie die App das macht, ob die sich die IP Adressen merkt, die beim Anlernen zugewiesen wurden und deshalb die Shellys nicht mehr "sieht", oder ob das rein über die Shelly ID und Cloud-Anbindung synchronisiert wird.

Zitat von uwe60rtg

History:

- 6 Shelly S funktionierten problemlos, neuste Firmware vor ca. 1 Woche aufgespielt/update, 6er IP´s

Und was meinst du mit 6er IP's ?

Die Shellys unterstützen jedenfalls kein IPv6, falls du das meinst. Aber ohne "Absicht" schaltet man normalerweise nicht die IPv4 Unterstützung im Heimnetz aus.

Internet kann natürlich sein, dass du nur noch eine öffentliche IPv6 hast, aber das sollte die Cloud-Anbindung nicht behindern.

Weiß nicht, ob du das schon gemacht hast, aber du kannst auch mal die Shellys neu starten, dass diese aktiv neu die ausgehende Verbindung zur Cloud aufbauen.

Noch ein Hinweis, aber auch hier passiert das nicht "aus Versehen". Die Shellys können kein 5GHz WLAN. D.h. sicherstellen, dass das 2,4GHz WLAN aktiv ist und dass die Shellys auch die richtigen Zugangsdaten haben, nicht dass diese bei dem "Internetproblem" aus Versehen geändert wurden.

Mich hätte es eigentlich umgekehrt interessiert. Heißt Shelly App starten, aber Shelly Relais per App noch auf "AUS".

Dann den Ping starten und wenn der läuft, dann per App das Relais EIN schalten und schauen, wie lange die Ping Antwort dann ausbleibt.

Ansonsten noch der Hinweis. Du brauchst deine IP Adressen nicht zu schwärzen, das sind bei IPv4 private Adressen, die gelten nur innerhalb deines Heimnetzes, damit kann "draußen" keiner was anfangen. Anders gesagt, fast jeder mit FritzBox hat 192.168.178.x. Bei Speedport 192.168.1.x usw... Kannst es aber auch schwärzen.

Aber bitte nochmal so durchführen, wie ich es anfangs auch beschrieben habe. Das "EINSCHALTEN" des Relais braucht mehr Leistung an den 24V als das Ausschalten.

Zum Thema "mehrmaliges Hin und Her-Klackern". Der "SW-Input" am Shelly1 ist ganz sicher offen, heißt, da ist auch kein Draht oder etwas dran angeschlossen am Switch-Input ?

Bei mir hatte ich jetzt sehr lange kein Flackern mehr, aber betreibe die LEDs auch seitdem höchstens auf 30% Helligkeit (aufgrund der Jahreszeit).

Das einzige, was konkret auffällt ist, dass die Helligkeit der LEDs recht stark variiert zwischen verschiedenen Einschaltvorgängen. Heißt, ich schalte das Licht ein, es ist recht schwach. Ich schalte es aus und 2 Minuten später wieder mit selbem Helligkeitswert ein, dann ist es deutlich heller, fast so, als hätte ich von 15% auf 25% gewechselt.

Manchmal regelt die Helligkeit auch nach, dass es erst dunkler ist und nach 2-3 Sekunden einen kleinen Sprung macht und heller wird, dann bleibt es aber dabei und flackert nicht.

Im Flur sind dann noch Bewegungsmelder beteiligt und da merkt man es am stärksten, wenn man nachts aufsteht und Helligkeit passt, angenehm schwach. Aber beim nächsten Mal kann's dann sein, dass es deutlich heller ist und schon etwas unangenehm.

Ich / wir leben aber jetzt mal damit und gibt schlimmeres. Aber diese Helligkeitsunterschiede gab es definitiv VOR dem aktuellen Updaten NICHT.

Das klingt alles ein bisschen unsystematisch.

Versuch mal bitte folgendes, soweit das möglich ist.

1.) An einem PC, der im selben Netzwerk, wie die Shellys hängt, die Kommandozeilenkonsole starten (CMD)

2.) Dort einen dauerhaften Ping auf die Adresse des problematischen Shelly anstoßen (ping ShellyIP -t), also z.B. ping 192.168.178.204 -t

--> Der Shelly sollte ja erreichbar sein und dir ab jetzt dauerhaft auf den sekündlichen Ping antworten.

3.) Jetzt in deiner Shelly Cloud App das Relais dieses Shellys einschalten

--> BEOBACHTEN, was in dem Moment mit dem Ping passiert. Wenn jetzt die Antworten ausbleiben, wäre meine Annahme mit Abbruch der Verbindung bzw. ggfs. Neustart des Shelly wahrscheinlich. Kommen die Antworten weiterhin ohne Pause, dann hat es tatsächlich mysteriöse, andere Gründe, die man dann Richtung Cloud und App-Einstellung untersuchen müsste.

Aber da du schreibst, nur bei 24V DC ist das so, bei 230V nicht, gehe ich stark davon aus, die Ping-Antwort wird ausbleiben, wenn du das Relais einschaltest.

Bin gespannt

Worauf basiert deine Annahme, dass das Relais seinen Schaltzustand hält, bis du die App startest ?

Ich würde mal evtl. eine kleine Glühbirne testhalber über den Relaiskontakt mit anschließen.

Ich vermute eher, dass die 24V nicht stabil sind und das Einschalten des Relais den Shelly aus der Bahn wirft. Die App aktualisiert den Schaltzustand dann nicht, weil der Shelly keinen neuen, aktuellen Schaltzustand mehr sendet.

Irgendwann in der Zwischenzeit startet der Shelly dann vermutlich neu und das Relais ist wieder deaktiviert. Die App lädt dann die aktuellen Daten und zeigt das Relais als AUS, obwohl es wahrscheinlich schon die ganze Zeit aus war. Daher "echte" Lampe schalten und schauen, ob wirklich deine Vermutung stimmt, dass die Lampe dauerhaft an bleibt und erst ausschaltet, wenn du die App wieder neu öffnest.

Wie äußert sich denn das "Nicht funktionieren", wenn alle 4 Innengeräte eingeschaltet werden ?

Kannst du dann 3 starten und das vierte läuft dann nicht mehr an ?

Die Innen- und Außeneinheit sind ja im Normalfall nur über die Kältemittelleitung verbunden, wissen also eigentlich garnix voneinander. Die angegebene Leistung des Außen- und der Inneneinheiten beziehen sich auf die Kälteleistung von Verdichter und Verdampfer, nicht auf die elektrische Leistung. Daher kann ich im Moment noch nicht ganz nachvollziehen, warum bei 4 Geräten NICHTS mehr geht ?

Shelly nutzen, um einzelne Inneneinheiten abzuschalten sehe ich als keine sinnvolle Lösung, vor allem, weil man ja nicht weiß, ob die Inneneinheit gerade läuft. Wäre höchstens 1PM sinnvoll und dann zentral ausgewertet, z.B. ioBroker. Aber ich würde erstmal Ursachenforschung betreiben...

SebMai:

Danke für den Hinweis. Stimmt, über /settings sieht man nur, ob es aktive Actions gibt, aber nicht die URLs, die sieht man erst so, wie du angegeben hast.

Also Hofmann.J , bitte nochmal mit dem korrekten Befehl prüfen, sorry...

Noch einen Hinweis, den ich dir ans Herz legen kann, wenn man oft zwischen verschiedenen Shellys im Webbrowser wechselt.

Der Browser hat die dumme Angewohnheit, zu merken, dass die Oberfläche der Shellys sehr ähnlich sind und das führt dazu, dass der teilweise Seitenteile puffert und falsche Inhalte anzeigt, wie z.B. eine URL, die gar nicht drin steht.

Daher, um ganz sicher zu gehen, z.B. im Chrome oder Firefox mit STRG + F5 die Seite erneut laden und dabei den Cache zu erneuern.

Dann merkst du auch, dass es teilweise sogar einige Sekunden dauert, bis die Shelly Webseite ganz übertragen ist. Dann bist du aber sicher, dass was du siehst, ist auch drin.

Ich weiß nicht, was die "App" alles im Hintergrund macht, wenn man darüber solche Szenarien definiert. Jedenfalls geht die App ja über die Cloud, daher mein Hinweis mit den Zugriffsrechten in der FritzBox.

Du könntest mal bitte noch folgendes machen.

Ruf mal im Browser deines PC die Einstellungen auf und vergleiche darüber die URL Strings.

Konkret wie folgt:

http://IPShelly/settings

Das führst du entsprechend für die beiden Shellys aus, also erst für den Shelly1, der nicht tut, was er soll und danach mit dem i3, der die Action schickt.

Du erhältst in beiden Fällen als Anzeige einen JSON String zurück. In den Strings gibt es jeweils Objekte für die URL Actions.

Am besten kopierst du dir den Inhalt der Rückgabe aus dem Webbrowser und fügst ihn z.B. im Notepad++ ein, den kennst du vermutlich.

Für diesen gibt es ein JSON Plugin, der den ganzen String vernünftig und lesbar formatiert.

Und dann würde ich mal aus beiden die URL Einträge vergleichen, ob die wirklich in beiden Shellys auch identisch abgelegt sind. Nicht, dass dort einfach eine Interpretation der Zeichen anders abläuft... Dass es am Ende ggfs. sogar am Browser liegt oder der Cloud in der Art der Übertragung zum Shelly.

Was du noch prüfen kannst, was aber unwahrscheinlich ist. Da du dem Shelly1 per DHCP die Adresse zuweist, mal prüfen, ob du evtl. in der FritzBox diesem Shelly irgendwelche Zugriffe beschränkt hast, z.B. halt Internet, wenn du das über die Cloud machst.

Hast du ggfs. noch einen anderen Shelly (1 oder 2.5 etc.), dass du bei deinem problematischen Shelly einfach mal anstatt der URL zum Aufruf deines Scripts auf der Synology einfach ein Relais eines anderen Shellys toggelst ? Einfach um zu prüfen, ob der Shelly 1 überhaupt wie erwartet die Actions auslösen würde ?

Beim Test mit dem i3, hast du das dann auch über die "App" probiert, oder direkt über das WebInterface des Shelly die Actions definiert ?

Danke für's Feedback, und durch die ganzen produktiven Rückmeldungen hat sich Verdacht ja auch erhärtet, dass die Ursache eher im Netzwerk, als beim Shelly selbst zu suchen ist.

Warum einfache http-Request als "Bedrohung" geblockt werden sollten, wundert mich zwar, aber wenn's so ist ...

Hallo osulivanDE,

dieser eine problematische Shelly, was stellst du mit dem denn konkret an über NodeRed und Home Assistant ?

Ich frage speziell wegen folgendem. Du kannst ja z.B. das Relais schalten, oder Zeitverzögerungen setzen etc.... Diese Dinge "tun dem Shelly nicht weh".

Ich habe aber z.B. gemerkt, dass, wenn man dem Shelly nicht nur reine Schaltbefehle sendet, sondern stattdessen auch Settings per HTTP setzt, dass das ihm nicht so gefällt.

Bei einem Dimmer2 habe ich das mal gehabt, dass ich bei Schalten eines Bewegungsmelders eine http-Action URL per HTTP geändert habe.

Das lief zunächst super, wurde dann von Tag zu Tag immer träger, bis letztlich gar nichts mehr ging.

Der Relaiskontakt hat keinen Rückmeldekontakt, von daher, wenn in der App auch ersichtlich ist, dass er AN/AUS/AN/AUS ... schaltet, würde ich schonmal die Relaisansteuerung an sich als Ursache ausschließen.

Eher wahrscheinlich ist ein Verdrahtungsfehler, der dazu führt, dass ein Schalten des Relais den shelly selbst triggert, seinen Zustand erneut zu ändern.

UniFi nutze ich auch und habe auch für die Shellys und einige andere Gerätschaften, die zur Hausinstallation gehören, ein separates Netz gegeben, ist also wohl sehr ähnlich bei dir.

Interessant wäre mal, wenn du z.B. noch einen Shelly1 oder so übrig hast, dort dieselbe Action URL mal zu konfigurieren, ob der das Türschluss dann ansteuern kann ?

Aber schließe mich aktuell deinem Standpunkt an, ist sehr merkwürdig das Ganze....

Mein Bauchgefühl sagt, der i3 erreicht netzwerktechnisch den Türschalter nicht, warum auch immer.

Was wir noch gar nicht als Frage hatten ? Wie sind denn die i3 eingebunden, per feste IP in den Shellys, oder per DHCP ?

Falls DHCP, vielleicht ist echt was schief gelaufen mit der Adressvergabe ...

Bzgl. IP Range möchte ich nochmal nachhaken, nur, um Dinge auszuschließen.

Ich gehe davon aus, dass du dann nicht einfach eine FritzBox hast, um WLAN aufzubauen, sondern irgendwas "besseres", damit du 2 separate Netzwerke hast?

Die Frage deshalb, weil am Beispiel FritzBox gäbe es ja die Möglichkeit auch, ein LAN als privates LAN zu nutzen (wo die Geräte sich untereinander sehen) und ein 2. Netz, das dann meistens das Gäste-Netzwerk ist und in einem anderen Subnetz liegt, wo dies dann nicht der Fall wäre.

Nicht, dass dein 192.168.1.0/24 Netz ein Gästenetzwerk ist, wo sich die Teilnehmer untereinander nicht erreichen können, was ja eine Erklärung für das "Nicht-Auslösen" wäre.

Wenn du mit deinem Client im 192.168.0.0/?? Netz auf das Shelly Web-Interface kommst, hast du dort offenbar ein anderes Subnetz, dass du auch auf das 192.168.1.0/24 zugreifen kannst, umgekehrt ginge es ja nicht laut Subnetzmaske?

Vielleicht kannst du deshalb im Web-Browser in deinem Client die URL händisch ausführen, weil du den Nuki darüber erreichst, aber vielleicht kann der Shelly das eben nicht ?

nicx*

Was mir noch auffällt ist, dass in deinem Log steht, verbunden mit 192.168.0.150, aber die auszuführende URL ist 192.168.1.52.

Heißt, 2 IP aus unterschiedlichen Netzen.

Passt deine Subnetzmaske in den Shellys dazu, dass deine Shellys auch das 192.168.1.0 Netz erreichen können ?

Auf dem Screenshot ist der Input1 gerade aktiv.

Hast du den Taster gedrückt gehalten, während du den Screenshot gemacht hast ?

Evtl. liegt das Problem an der Button Konfiguration, dass dort entweder falsche Art oder evtl. Reverse Inputs gewählt ist...

Der ganze Thread erinnert mich SEEEHR an einen anderen Thread mit fast identischer Symptomatik.

Dort war es so, dass der Thread-Ersteller leider über Seiten hinweg mit keinem Wort erwähnt hatte, dass er ioBroker im Haus am laufen hat.

Damals war die Ursache für das ständige Rebooten, dass der Shelly-Adapter im ioBroker eine Option hat, die erkannten Shellys automatisch zu upgraden.

Und das funktioniert nicht immer, sodass es dort zu einer Art "Upgrade-Schleife" kam, wonach der eine Shelly immer wieder versucht hat, seine Firmware zu upgraden und dabei immer wieder neu gebootet hatte.

Daher einfach mal die Frage, ob evtl. ein übergeordnetes System wie ioBroker aktiv ist ?