VPN/Proxy erkannt
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.
mcast geht sofort.
unicast keine Chance.
kann ich bestätigen, hab es mal mit dem Adapter 4.0.7Beta3 probiert, da kommt über Uniciast nix an.
Selbst der Motion wird bei mir über Unicast nicht als Datenpunkt angelegt. -> edit: hat nur ewig gedauert, bis der da aufgetaucht ist..
Mein eigener Coap-Listener (auf der selben VM, alternativ mal statt des Adapters gestartet) kriegt sowohl Unicast als auch Multicast-Pakete mitgelesen, von daher kann ich ein generelles Netzwerk-Problem ausschließen.
nein, laut Google ist der darin verbaute Sensor ein Pt100 ..
das TempAddon unterstützt derzeit entweder bis zu 3 DS18B20-Sensoren oder einen DHT22.. Andere Sensoren werden nicht unterstützt.
@hklausilein
mit welcher Smartphone-App (IOS oder Android) arbeitest du denn?
Das blaue Blinken am Anfang ist normal, der Shelly blinkt und möchte dir damit sagen: ich bin im Werkszustand und möchte in dein WLAN eingefügt werden..
Es gibt diverse Videos, wie man einen Shelly via App in sein eigenes WLAN einbindet:
https://www.youtube.com/results?search…+wlan+einbinden
Falls es damit immer noch nicht klappen sollte:
Von welcher Firma ist dein Router? Enthält deine WLAN-SSID oder das WLAN-Passwort ein oder mehrer Sonderzeichen?
An welcher Stelle hakt es und welche Fehlermeldung kommt ggf?
(und ja, der Plug-S ist verpolungssicher)
Hi, die Polltime auf 3600 gestellt, funktioniert auch nicht. Ich habe fast das gefühl, dass meine FritzBox den Port 5683 im Heimnetz nicht routet.?
welche Firmware-Version hat denn dein ioBroker-Adapter? immer noch 4.0.7beta-1? mach mal ein Update auf 4.0.7beta3..
Eventuell läuft der Adapter auch auf der falschen IP oder steht da 0.0.0.0 drin?
ch hoffe mal, im Final-Release wird der Bug dann hoffentlich behoben sein.
ja, das ist ein seit gestern bekannter Fehler und der wird zur Final-Version gefixt sein.
Ich bekomme damit keine Verbindung mit FHEM mehr zustande.
machst du MQTT über Hostname oder IP-Adresse?
wenn der Shelly per DHCP die IP bekommt, dann wird statt des lokalen DNS ein Google-DNS benutzt (Bug in RC5) und damit ist der lokale MQTT-Server über den Namen vermutlich nicht mehr erreichbar.
ok, die ist laut Hersteller definitv dimmbar und sollte in der Theorie problemlos laufen:
allerdings nicht mit Leading Edge, sondern Trailing Edge
Das Webinterface ist erreichbar? dann könntest du mal unter Settings auf Kalibrierung gehen..
Wenn das nicht klappt:
probeweise eine andere dimmbare LED probieren. wenn es dann immer noch nicht klappt würde ich vermuten, dass der Dimmer einen Defekt hat.
Zuverlässiger ist MQTT/REST, komplett richtig erkannt 
das muss aber nicht zwangweise bedeuten, dass da temporäre Störungen im WLAN dadurch überbrückt werden können.. auch da gibt es Timeouts..
Gaaanz simple HTML-Seite mit ein bisschen Javascript, geht ja dank dem neuen Feature "Allow Cross Origin Ressource Sharing" mittlerweile ganz einfach..
Das sollte also gehen.
Sollte ist relativ.. ist die Leuchte explizit als Dimmbar ausgewiesen? vermutlich nicht, oder?
Hängt ein Neutralleiter am Dimmer? wenn nicht, Bypass angeschlossen?
ja, die Update-Intervalle für MQTT und Coap sind absichtlich 1x stündlich und auch nicht änderbar... das ist alles absolut richtig so.
REST-API Abfragen kann man machen, wenn man es maximal im gleichen Interval wie MQTT oder Coap (1x je Stunde) tut.
Coap, MQTT und Actions sind in etwa gleichwertig..
Coap hat "minimale" Vorteile, weil es auf UDP basiert. Das funktioniert nach dem Prinzip "Fire and Forget", also Daten raus.. ob die nun korrekt ankommen oder nicht spielt keine Rolle.
MQTT und HTTP (egal ob Actions oder anders herum, also REST-Abfragen) sind beides TCP-basierte Protokolle, die das Zustellen der Pakete (notfalls auch mit Fehlerkorrektur) sicherstellen. Dementsprechend kann es zu minimalen Verzögerungen kommen, wenn Übertragungsfehler auftreten oder die Gegenstelle nicht erreichbar ist (Timeouts)..
Grundsätzlich halte ich es für die sinnvollste Variante, den Motion selbst die Daten senden zu lassen.
wenn aber z.B. REST-API abfragen erfolgen sollen, dann auf jeden Fall Coap + MQTT deaktivieren und maximal 1x pro Stunde.
Dein Dimmer hat laut settings den Pulse_mode 1 erkannt, das entspricht Leading Edge und passt so gar nicht zu einer LED..
Bitte mal den Hersteller / Modell der LEDs raussuchen, ich würde fast darauf wetten, dass die nicht dimmbar sind oder eine eigene Elektronik zum Dimmen haben, die aber nicht für Phasenanschnitt/Phasenabschnitt gedacht ist..
oder du hast ggf. (nicht dimmbaren) Trafo zwischen LED und Dimmer?
Mein "Haupt" WLAN (2.4 GHz & 5 GHz, separate SSID) ist auch sehr langsam, unterirdische Pingwerte. Ich verstehe es nicht wirklich.
wenn nicht benötigt einfach CoIoT abschalten (braucht man nur für ioBroker, OpenHAB, HomeAssistant..).
das reduziert den lokalen Datenverkehr der Shellys erheblich, hab es heute selbst erst komplett deaktiviert
das ist nicht die Ausgabe von /status bzw. /settings sondern die von /shelly..
denke du meinst den Selbsttest-Modus, um den zu verlassen:
- Kalibriert ist er?
- mit oder ohne N angeschlossen?
- mit oder ohne Bypass angeschlossen?
- Welche & wie viele Verbraucher hängen dran (Hersteller, Type, Watt-Zahl)?
-
was hast du denn für eine URL angegeben? Ein Shelly kann nur http, nicht https.. außerdem nur HTTP GET Variablen, aber kein POST oder PUT
Aber trotzdem schuppst doch der Controller die Clients von einen auf den anderen AP?
mit welcher Einstellung sollte er das denn machen?
bei mir wechseln die Clients nicht, es sei denn ich reboote sie oder sorge händisch im AP für einen Disconnect.
Eigentlich ist doch der CloudKey für das Roaming zuständig.
würde ich da aber dringend abschalten, ESP8266 beherrschen kein 802.11 k/v/r..
