Hallo alle
Habe heute die blaue App installiert und wollte nun meine Geräte hinzufügen.
Die werden auch alle gefunden nur:
Wenn ich den Button "add device" drücke passiert nichts. Bzw. man muss ganz oft drücken, auch verschiedene und irgendwann reagiert dann einer und es geht weiter.
Kennt jemand diesen Bug?
Und warum muss ich dem Teil nochmal extra einen Namen geben wenn das Device eh schon einen Namen hat?
Gruss Ralf
Hat sich erledigt.
Ich habe auf den falschen Shelly geschaut. Der AP war doch noch enabled. Ich hab den aber nicht selbst enabled. Zumindest nicht dass ich wüsste. Ich dachte dass der eigene AP nur dann kommt, wenn der Shelly zurückgesetzt wird, damit man ihn im richtigen WLAN anmelden kann und er danach verschwindet. Wozu kann man den im GUI nochmal extra einschalten? Um ihn einzuschalten muss ich doch im internen WLAN sein und dann brauch ich ihn eh nicht...
Gruss Ralf
Hallo
Nachdem meine Shellys alle im internen WLAN sind und sich über ihrer Weboberfläche bedienen lassen,habe ich zwei Aktoren deren Accesspoint nicht verschwindet.
Das sollte doch aber eigentlich so sein nachdem man sie im internen WLAN eingebunden hat.
Ich kann also immer noch über den Shelly-eigenen initialen AP auf das Gerät zugreifen. HIer ein Screenshot der Weboberfläche mit dem Zugriff über das interne WLAN.
AP ist disabled, rechts sieht man die verfügbaren APs die der Laptop anzeigt, mit den zwei Shelly APs die da eigentlich nicht hingehören:
Wie kann ich denn dafür sorgen dass der verschwindet?
Gruss Ralf
Wieso ist das "verwirrend"?
Alle Raspberry PIs haben z.B. die IPs *17*
Alle Router und Switches 15*
Alle Hifi Geräte 13* usw.
Das ist für mich übersichtlicher als wenn die Geräte "irgend" eine IP bekommen würden, die sich die Fritzbox zwar merken kann aber ich nicht.
Und wenn ich dann morgen statt einer einer Fritzbox einen anderen Router oder einen anderen DHCP einsetzen möchte, würfelt das Gerät dann neue IPs für meine Geräte?
Das brauch ich nicht, will ich nicht. Ich möchte die IP bestimmen.
Das hat auch mit dem eigentlichen Thema bzw. Problem gar nichts zu tun sondern wäre eher als Workaround zu sehen.
Ich will ja das Problem des Shelly verstehen und nicht drumrum arbeiten. Das würde ich aber tun, wenn ich die Fritzbox die IP vergeben lassen würde.
Übrigens: Die Fritzbox die IP vergeben zu lassen und dann einzustellen "für dieses Gerät immer die gleiche IP verwenden" hat meiner Meinung nach nichts mit dem Terminus "feste IP" zu tun.
EIne feste IP ist am Gerät definiert und nicht an dem Gerät das die IPs vergibt. Diesen Prozess würde ich eher "gleiche IPs zuordnen" nennen aber nicht "feste IP vergeben". Mit "vergeben" meines ich den User der die IP dem Gerät fest gibt und nicht die Fritzbox die die IP immer auf die gleiche Weise zuordnet.
ZU den Fragen oben: Ich vergebe feste IPs immer in dem Bereich in dem die Fritzbox NICHT ihre IPs vergibt. Ergo kann es keine doppelten IPs geben; nur wenn ich selber blöd bin und eine IP doppelt vergebe. Und ich verwende für diese Geräte mit fester IP eben genau nicht die Option des Routers diese IP sich zu merken und immer wieder zu vergeben.
Aber das "warum" ist doch auch Wurst.
Das Problem kommt dann auf, wenn man im Userinterface des Shelly die IP des Geräts selbst bestimmt.
Das Komische daran ist: Genau dieses Vorgehen funktioniert bei meinen anderen Shellys. Nur nicht am Shelly Plus1PM
Was jetzt funktioniert hat:
* Shelly zurücksetzen
* NICHT das Handy verwenden um den Shelly in's WLAN einzubinden, sondern
* den Laptop mit dem AP des Shelly verbinden
* Auf die IP des Shelly gehen: 192.168.33.1
* Dann im Userinteface dir feste IP, die WLAN SSID und Password vergeben und speichen.
* WLAN wechseln.
* Im Browser die neue fest vergebene IP eingeben: Tataaaaa! Geht.
Bleibt die Frage: Warum ging es nicht so wie man es eigentlich machen sollte:
Also: Shelly per Shelly App in das WLAN einbinden, auf die Website des Shelly gehen, neue IP eingeben, speichern, ärgern?
Keine Ahnung. Würde mich aber schon interessieren.
Gruss Ralf
Mach ich morgen.
Accesspoint neu starten hat übrigens nicht geholfen.
Interessanterweise meldet er sich immer noch teilweise an der alten IP. Mehr als das was man im Screenshot sieht passiert aber nicht
Mal sehen ob ich es mit der Lösung
der direkten Konfig über Http hinbekomme
Gruss Ralf
Lässt sich das betroffene Shelly denn ohne Vorgaben statischer Daten ins WLAN einbinden?
Klar. Wenn ich DHCP eingestellt lasse, bekommt er die x.25 und alles funktioniert. Sonst haette ich ja auch nicht im Webinterface die IP ändern können.
Gruss Ralf
Hallo alle
Ich habe das einfach so eingestellt, dass die Fritzbox im zweistelligen Bereich die IPs vergibt und ab 100 ist frei für feste IPs:
Das hab ich immer schon so gemacht damit ich auch mal den Router wechseln kann und die Geräte immer noch die gleiche IP haben. Ausserdem kann ich mir dann die IPs leicher merken als wenn sie völlig willkürlich durch die Fritzbox vergeben würden.
Und ich denke es spricht auch nichts dagegen den Servern und Geräten die auch fest installiert sind (Smarthome, Aktorem, Sensoren , Hifigeräte, diverse Einplatinencomputer usw.) feste IPs zu vergeben. Hat ja auch bisher immer funktioniert bis auf diesen einen Shelly.
Nein, der Shelly antwortet weder auf Ping noch auf curl. Hab mal Laptop und Fritzbox neu gestartet: Nun ist weder ein Gerät mit .25 noch mit 196 angemeldet.
Ich denke dass es am Shelly liegen muss. Alles anderen Shellys sind genau so konfiguriert und funktionieren. Sind aber eben keine Plus Geräte sondern noch die alten Shelly1.
Das Userinterface ist hier ganz anders. Ev. hab ich was übersehen einzustellen?
Gruss Ralf
Hallo alle
Alle meine Shellys haben eine feste IP die mit 19* endet.
D.h. auch der neue Shelly Plus1PM hat nun die IP 192.168.111.196 bekommen, das Gateway entsprechend 192.168.111.1 und der DNS auch 192.168.111.1 (Fritzbox)
Netzwerkmaske ist 255.255.255.0
Das Ganze habe ich gespeichert und versucht den Shelly über die neue IP zu erreichen. Das funktioniert nicht. Der Browser timed out.
Wenn ich in die Fritzbox gehe, dann hat er scheinbar immer noch eine von der Fritzbox vergebene IP 192....25
Interessanterweise, wenn ich auf diese IP gehe dann sehe ich nur
Und irgendwann gibt es einen Timeout.
Was ist denn da faul?
Ich kann doch nicht mehr als das was ich oben genannt habe einstellen. Oder hab ich was übersehen?
Gruss Ralf
Vor allem ist Deine Lösung so praktisch: Da kann man den FB Kanal in Iobroker im IOT Addon einfügen und dann über Alexa steuern kann. Super!
Gruss Ralf
Hallo Stefan
Danke für Deine Geduld
Das Problem befand sich zwischen Stuhl und Monitor. Ich Volldepp habe die falsche IP verwendet. Ich war 100% sicher, dass sie richtig ist. War sie aber nicht. Menno! Zahlendreher...
Danke
Gruss Ralf
So?
Geht leider trotzdem nicht.
Gruss Ralf
Hallo Stefan
So funktioniert es im Browser:
http://IPADRESSE/relay/0?turn=onAlso muss man tatsächlich ~3d durch = ersetzen. Dachte dass das automatisch immer vom Empfänger interpretiert und umgesetzt wird.
Es geht sogar "http://192.168.111.191/relay/0?turn=toggle"
Also so gesehen erstmal perfekt. Danke!
Aber:
CUxD ist jetzt so eingerichtet (ich hatte noch Kanäle bei meinem CUXD Gerät für die Intertechno Lichter frei)
D.h. hier vwerwende ich wget -q -O - 'http://IPADRESSE/relay/0?turn~3don'
bzw. wget -q -O - 'http://192.168.111.190/relay/0?turn~3doff'
Hier funktioniert das Drücken der Taste dieses CUxD Kanals aber nicht.
Ich hab mal in's Syslog geschaut. Die letzen Einträge sehen so aus. Sind allerdings böhmische Dörfer für mich. Ev. hat's auch gar nicht damit zu tun:
May 23 16:06:01 homematic-ccu2 cron.info crond[141]: crond: USER root pid 6808 cmd /usr/local/addons/hm-watchdog/bin/hm-watchdog.sh >/dev/null 2>/dev/null
May 23 16:07:35 homematic-ccu2 local0.warn ReGaHss: WARNING: XMLRPC 'getDeviceDescription': empty interface URL (interface: 1009, params: {"System"}) [CallXmlrpcMethod():iseXmlRpc.cpp:2618]
May 23 16:07:35 homematic-ccu2 local0.err ReGaHss: ERROR: XMLRPC 'getDeviceDescription' call failed (interface: 1009, params: {"System"}) [CallGetDeviceDescription():iseXmlRpc.cpp:2192]
May 23 16:07:35 homematic-ccu2 local0.warn ReGaHss: WARNING: XMLRPC 'getDeviceDescription': empty interface URL (interface: 1009, params: {"System"}) [CallXmlrpcMethod():iseXmlRpc.cpp:2618]
May 23 16:07:35 homematic-ccu2 local0.err ReGaHss: ERROR: XMLRPC 'getDeviceDescription' call failed (interface: 1009, params: {"System"}) [CallGetDeviceDescription():iseXmlRpc.cpp:2192]
May 23 16:07:35 homematic-ccu2 local0.warn ReGaHss: WARNING: XMLRPC 'getDeviceDescription': empty interface URL (interface: 1009, params: {"System"}) [CallXmlrpcMethod():iseXmlRpc.cpp:2618]
May 23 16:07:35 homematic-ccu2 local0.err ReGaHss: ERROR: XMLRPC 'getDeviceDescription' call failed (interface: 1009, params: {"System"}) [CallGetDeviceDescription():iseXmlRpc.cpp:2192]
May 23 16:07:37 homematic-ccu2 local0.warn ReGaHss: WARNING: XMLRPC 'getDeviceDescription': empty interface URL (interface: 1008, params: {"BidCoS-Wir"}) [CallXmlrpcMethod():iseXmlRpc.cpp:2618]
May 23 16:07:37 homematic-ccu2 local0.err ReGaHss: ERROR: XMLRPC 'getDeviceDescription' call failed (interface: 1008, params: {"BidCoS-Wir"}) [CallGetDeviceDescription():iseXmlRpc.cpp:2192]
May 23 16:07:37 homematic-ccu2 local0.warn ReGaHss: WARNING: XMLRPC 'getDeviceDescription': empty interface URL (interface: 1008, params: {"BidCoS-Wir"}) [CallXmlrpcMethod():iseXmlRpc.cpp:2618]
May 23 16:07:37 homematic-ccu2 local0.err ReGaHss: ERROR: XMLRPC 'getDeviceDescription' call failed (interface: 1008, params: {"BidCoS-Wir"}) [CallGetDeviceDescription():iseXmlRpc.cpp:2192]
May 23 16:07:37 homematic-ccu2 local0.warn ReGaHss: WARNING: XMLRPC 'getDeviceDescription': empty interface URL (interface: 1008, params: {"BidCoS-Wir"}) [CallXmlrpcMethod():iseXmlRpc.cpp:2618]
May 23 16:07:37 homematic-ccu2 local0.err ReGaHss: ERROR: XMLRPC 'getDeviceDescription' call failed (interface: 1008, params: {"BidCoS-Wir"}) [CallGetDeviceDescription():iseXmlRpc.cpp:2192]
May 23 16:09:01 homematic-ccu2 cron.info crond[141]: crond: USER root pid 6938 cmd /usr/local/addons/hm-watchdog/bin/hm-watchdog.sh >/dev/null 2>/dev/null
May 23 16:10:01 homematic-ccu2 local0.err ReGaHss: ERROR: ScriptRuntimeError: Write(dom.GetObject(46717).State('')); [ExecError():iseESPexec.cpp:12723]
May 23 16:10:02 homematic-ccu2 local0.err ReGaHss: ERROR: ScriptRuntimeError: Write(dom.GetObject(46718).State('')); [ExecError():iseESPexec.cpp:12723]Hallo Stefan
Auf der Console hab ich die Anführungszeichen weggelassen. Sonderzeichen sind ja onst nicht enthalten. ? und Tilde müssten doch auch auf der Console funktionieren, oder?
Ich hab übrigens keinen Passwordschutz.
Hier nochmal
c:\>wget -O - http://IPADRESSE/relay/0?turn~3don
--13:48:24-- http://IPADRESSE:80/relay/0?turn~3don
=> `-'
Connecting to IPADRESSE:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 54 [application/json]
0K -> [100%]
{"ison":false, "has_timer":false, "timer_remaining":0}13:48:24 (52.73 KB/s) - `-' saved [54/54]Im CUxD hatte ich schon eine FB eingerichtet und dort die wget Strings wie im Thread beschrieben reinkopiert. Aber auch hier keine Reaktion (was mich jetzt nicht wundert).
Welche, wo angepinnten Themen meinst Du?
Unabhängig davon: Der String müsste doch für einen Shelly 1 funktionieren oder?
Gruss Ralf
Hallo
Ich bin heute auf diesen Thread gestossen und wollte das mal ausprobieren. Verbaut habe ich zwei Shelly 1 die eine feste IP bekommen haben.
Bevor ich die beiden in CUxD eingebunden habe, habe ich mal versucht den wget Befehl auf der Console auszuführen. Leider reagiert der Shelly überhaupt nicht.
D.h. er reagiert schon. Aber das Licht geht halt nicht an:
--13:26:20-- http://IPADRESSE:80/relay/0?turn~3don
=> `-'
Connecting to IPADRESSE:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 54 [application/json]
0K -> [100%]
{"ison":false, "has_timer":false, "timer_remaining":0}13:26:21 (52.73 KB/s) - `-' saved [54/54]Auch im Browser passiert nichts. Da kommt nur der JSON String zurück:
{"ison":false, "has_timer":false, "timer_remaining":0}Was mach ich da falsch?
Gruss Ralf