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.
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
Was außerdem in der gedruckten Anleitung steht, ist wirklich in die Irre führend:
Zitat
Following the diagram on fig. 1 install the current transformer CTA around the Phase A cable to the load(s), CTB around the Phase B cable to the load(s) and CTC around the Phase C cable to the load(s). Install the CTN around the Neutral cable from your load(s). Mount the Device onto the DIN rail.
Plug the cables of the CTA, CTB and CTC into the Device IA, IB and IC input connectors respectively. Plug the CTN cable into IN.
Zitat
Nach dem Schema in Abb. 1 installieren Sie den Stromwandler CTA um das Kabel der Phase A zu dem/den Verbraucher(n), CTB um das Kabel der Phase B zu dem/den Verbraucher(n) und CTC um das Kabel der Phase C zu dem/den Verbraucher(n). Installieren Sie den CTN um das Neutralleiterkabel von Ihrem(n) Verbraucher(n). Montieren Sie das Gerät auf der DIN-Schiene.
Stecken Sie die Kabel von CTA, CTB und CTC jeweils in die Eingangsanschlüsse von Device IA, IB und IC. Stecken Sie das CTN Kabel in IN.
Ich habe es mit einem Power Strip Gen4 getestet: bei dem sind beide MAC komplett verschieden. Die Device ID ist die MAC von Wifi1/2.
Gleiches gilt für einen PRO mit LAN Anschluss (der LAN Anschluss hat natürlich eine eigene MAC): auch hier entspricht die Device ID der MAC von Wifi1/2.
Damit ist auch klar, dass man im DHCP Modus den Nameserver nicht per Wifi.SetConfig setzen kann, sondern dies zwingend über den DHCP Mechanismus durch den Router erfolgen muss.
Im Mongoose OS ist dieser Status Response so dokumentiert - man muss aber dazu sagen, dass sich Shelly OS und Mongoose OS durchaus etwas unterscheiden:
Code
"ip": "", // Static IP Address
"netmask": "", // Static Netmask
"gw": "", // Static Default Gateway
"nameserver": "", // DNS Server
Die App kann das alles und erkennt auch recht schnell, ob ein Gerät nur noch lokal erreichbar ist.
Letztendlich ist hier das Problem, dass das dieser Mechanismus nicht bei jedem Nutzer funktioniert, iOS ist hiervon stärker betroffen.
Es scheint "irgendeine" unglückliche Kombination zwischen dem lokalen Netzwerk / Router und dem Fallback-Mechanismus in der App zu geben, weshalb es bei manchen Nutzer nicht klappt.
Zudem scheint es auch noch einen Unterschied zu geben, ob man bei einem Shelly nur die Cloud abschaltet und dann mit der App lokal versucht zuzugreifen, d.h. die App selber noch mit der Cloud verbunden ist und alle weiteren Shellys über die Cloud erreichen kann oder ob das Internet weg ist und somit auch die App selber nicht mehr mit der Cloud verbunden ist und dann auch Shellys lokal erreichen muss, bei denen die Cloud aktiviert ist.
Wie man sieht, steht hier auch keine IP Adresse drin, obwohl eine per DHCP vergeben wurde. gw und netmask müssten auch gesetzt sein, sonst würde der Shelly nichts im lokalen Netz und im Internet erreichen.
Ich habe das bisher so interpretiert, dass im ipv4mode dhcp die Werte für ip/netmask/gw & nameserver bei dieser Ausgabe leer sind, obwohl sie intern vorhanden sind. Diese Werte werden nur ausgegeben, wenn man static IP vergibt und alles zu Fuß konfiguriert hat.
Ehrlich gesagt habe ich keine Lust, mir das Wort im Mund umdrehen zu lassen - du hast Wallbox geschrieben und wir sind im passenden Forumsbereich für das portable Shelly Ladegerät.
Ein tragbares 11kW-Ladegerät für Elektrofahrzeuge, flexibel und leistungsstark. Es kann direkt in eine handelsübliche CEE‑16A-Drehstromsteckdose eingesteckt werden.
