Beiträge von torsten_65

Ansonsten hier mal schauen: Anschlussschemen Shelly 1PM

Ist der zweite Draht von rechts aus gesehen deine Dauerphase? Liegen dort dauerhaft 230V an, egal ob du schaltest oder nicht? Vorsichtig bitte, Strom kann tötlich sein!

Schick mal eine Zeichnung, wie du den Shelly angeklemmt hast. Bei mir funktionieren alle Shellys mit v1.8.0.

Du kommst nur auf die WebGUI, wenn der Shelly angeschaltet ist? Es reicht völlig aus, dass der Shelly Phase und Null angeschlossen hat. Dazu muss er nicht via Schalter auf „ein“ stehen. Ich vermute, du hast falsch verkabelt. Schick mal ein Bildchen, wie du den angeklemmt hast.

Du hast aber auch deine IP Adresse im Browser eingesetzt und NICHT das Beispiel von Seven of Nine, oder?

Lokal an den SW angeschlossene Schalter werden auch bei WiFi Ausfall den Rollladen steuern. Aber jegliche Aktione als auch Log Einträge werden nicht funktionieren.

Shelly 2.5 und Shelly 1. Meine Dimmer sind noch auf dem Postweg. Alles mit nativer Firmware und über Homebridge auf Homekit.

telnet oder ssh. der unterschied ist doch nur, ob du verschlüsselt deine shell aufrufst (tcp port 22 ist ssh) oder unverschlüsselt (telnet tcp port 23). da ja nun das plugin drauf ist, kannst du jetzt die shellys mit v1.8er firmware einbinden. viel erfolg!

ssh ist die Shell App auf Port 22. Die ist m.E. schon da. Bin mir nicht so sicher, habe meine Homebridge schon mehrere Jahre laufen. Aber ssh gehört zu jedem Unix dazu. Versuche es einfach mit

ssh pi@a.b.c.d und a.b.c.d tauschst du gegen die IP des Pi.

ich habe eine ssh Shell auf meine Homebridge gemacht und

npm i homebridge-shelly

eingegeben. Anschließend noch einen Neustart der Homebridge und das wars dann schon. Der Update über die App klappte bei mir nicht.

Ich denke mal, dass du fit bist, was die WLAN Konfiguration und Gegebenheiten des 2.4 und 5 GHz angeht, wenn du solch professionelle WiFi Hardware einsetzt. Siehst du etwas in der Analyze Funktion deiner APs? Je nachdem, wie du die Shellys einsetzt, werden diese ja regelmäßig angesprochen (ich denke da jetzt mal an Homekit, welches ja regelmäßig seine Geräte über IP resp. die Homebridge kontaktiert) und somit fällt ein Ausfall schnell auf. Aber die Uptime? Das macht mich sehr stutzig. Die darf sich nur ändern, wenn es zu einem Neustart / Stromausfall gekommen war. Wenn die definitiv immer unter 48 Stunden bleibt, dann fällt mir da momentan leider nichts weiter ein.

Die fixe IP hat mit einem ARP nicht all zu viel zu tun. ARP ist als Protokoll so einfach und schon so alt - daran sollte es nicht liegen. Meine Shellys haben Uptime Werte > 48 Stunden. Beachte auch, dass Shellys bislang leider nur IP Version 4 können und noch kein IPv6. Die IPv6 Adressen brauchen deutlich mehr Platz, die Shellys können das noch nicht. Lass doch mal für länger als 48 Stunden einen deiner Shellys anpingen, dann würdest du Unterbrechungen ja auch bemerken.

Einen Accesspoint Ausfall würde ich da eher vermuten. Welchen Access Point Hersteller und Router Hersteller benutzt du denn? Wobei das wiederum nicht die Uptime des Shellys beeinflussen kann. Die Shelly Erreichbarkeit aber sehr wohl.

Kommst du mit einem Standard Browser auf deine Shellys? Einfach die IP des Shellys eingeben und du solltest auf der WebGUI landen. Die IP findest du auf deinem Internet Router. Die ersten 3 Bytes der IP sollten identisch sein mit der IP deines Rechners oder Smartphones, solange beide im gleichen Netz sind und du den vorgegebenen Standard (/24 bit Subnetmaske) nicht verändert hast. Der Shelly reagiert auch auf ping, also einfach mal anpingen. Dann sollten die Shellys auch in der App zu sehen sein. Cloud ist zum Anfang noch unwichtig, richte erst einmal alles ein (feste IP Zuordnung im Router kann nicht schaden, Raumzuordnung in der Shelly App, Gerät einen Namen geben usw).

Versuch doch mal, die Shellys nicht am Repeater, sondern direkt an der Fritzbox anzumelden (Repeater rausziehen und dichter mit dem Shelly an die Fritzbox, falls sich das machen lässt).

Aus meiner Sicht sind die anderen 4 Shellys direkt an der Fritzbox und hier versuchen die nicht funktionierenden Shellys, über den Repeater ranzukommen. Hat dein Repeater eventuell ein anderes WLAN pwd gesetzt? Resette mal den Repeater. Ist der Repeater im Mash Netz oder per Hand konfiguriert?

Versuche es mal über die WebGUI und nicht über die App. Die WebGUI hat mehr Einstellungsmöglichkeiten.

Du kannst jedem der Shellys ein login / pwd verpassen. Das hilft aber nur beschränkt, solange keiner mit einem Wlan Sniffer umgehen kann. Ist aber besser als nichts. Ein Mitarbeiter, der sich die App zieht und im lokalen Wlan ist, wird vorerst nicht auf deine Shellys zugreifen können, wenn du login und pwd vergibst.

Falls du direkt auf den Shellys eine feste IP Adresse vergeben hattest, solltest du darauf achten, den identischen IP Range zu nutzen wie zu der Zeit, als die Shellys noch erreichbar waren. Ansonsten reicht das aus, was Stefan geschrieben hat.

Übrigens: feste IP Adresse bei den Shellys bevorzuge ich, aber nicht im Shelly konfiguriert, sondern ich setze den Haken in der Fritzbox pro Shelly, damit er immer die gleiche IP zugeteilt bekommt. Dann merkt sich das auch besser, wenn man nicht die App, sondern die WebGUI benutzen möchte.

LG, Torsten

Hallo Segway,

ich hätte besser nicht nachgesehen... Nun ja, von IP Kommunikation haben die App-Entwickler wohl nicht viel verstanden.

Also das läuft in etwa so:

Die App (bei mir auf dem iPhone) schickt zwei Multicast ab. Einmal an 224.0.0.22 und einmal an 224.0.0.215. Beide scheinen mir aber wohl nichts damit zu tun haben, weil keine weiteren Aktionen darauf folgen. Wobei ein Multicast Ansatz genau der sinnvolle Lösungsansatz wäre. Aber dann...

Die App schickt an jeden (!) lokalen IP Host im Netz ein TCP_SYN auf Port 80 und wartet, wer da antwortet. Damit kann die App schon mal schauen, wo im Netz ein beliebiger Webserver auf Port 80 läuft. Manche Hosts antworten nicht (also das können schonmal keine aktiven Shellys sein), andere schicken ein Reset (RST) - ok, das sind wohl auch keine Shellys. All diese fallen aus der weiteren Betrachtung daher raus.

Kommt jedoch eine Antwort (ein SYN_ACK zurück), dann schickt die App an genau diese Hosts als Nächstes eine "HTTP Get /shelly HTTP/1.1" Meldung und wartet wiederum auf eine "sinnvolle" Antwort.

Nur Shellys antworten dann darauf mit einem "HTTP/1.1 200 ok" und schicken gleich ihre Infos mit an die App zurück (wie zum Beispiel die MAC Adresse des Shelly, den Typ (also shelly1 oder shelly2.5), die Firmware usw.). Eben diese Informationen filtert die App für sich heraus und bereitet diese Infos auf und "kennt" (oder besser scannt) somit das aktuelle shelly-Netzwerk. Daher werden auch Shellys gefunden, die "neu" sind, aber auf jeden Fall schon mal im aktuellen IP WiFi Range eine Adresse bezogen haben.

Die App muss also im lokalen Netz sein, weil sie sonst ja nicht mit diesem primitiven Rundruf starten könnte. Jetzt könnte man eine eigene App schreiben und der App sagen, dass diese Infos auch noch an andere (lokalen) Netzwerksegmente geschickt werden sollen.

Oder besser noch: du schreibst einen Proxy, welcher auf die Shelly HTTP GET Anfrage antwortet, diese aber zuvor forwarded in das zweite lokale Netz. Der Proxy müsste sich genau so verhalten wie die App selber, also anfangen, im anderen Netz HTTP GET /shelly Anfragen zu verteilen und die sinnvollen Antworten zurückzumelden.

Oder mit anderen Worten: Du wirst mit dieser App keine Shells sehen, welche nicht im gleichen Subnet sind wie die App selber. Tut mir leid, aber mit einfachen Mitteln wird das nichts.

Ich hoffe, das war nicht zu technisch.

Viele Grüße, Torsten

noch nicht. gib mir bitte noch etwas zeit, habe zu viel Arbeit auf dem Tisch...

gruppiert habe ich mit der Apple App Home+. Dort aber nur die Räume, nicht noch zusätzlich die darin vorhandenen Devices.