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.
Docker Container : OH 2.5.12 / InfluxDB / Grafana / Fonttail-OH
Docker macht es komplizierter, generell ist es aber lösbar..
- Zunächst muss der Port 5683 (Coap/CoIoT) in den Container geforwarded werden.
- zusätzlich muss im H&T unter Internet Settings - Developer Settings - das CoIoT umgestellt werden von "mcast" auf die IP-Adresse des Docker-Hosts.
Also, the time on the WebIf is in 'AM/PM' mode, whilst the time in the API is 24h.
(My location was correctly determined to be EU)
From the screenshot I'd assume you live in a country where AM/PM is default time format, UK, Ireland or so?
With TZ Europe/Berlin the device shows 24-hour-format for both API and GUI.
I think WebUI is based on local time (which is user-friendly) and API is based on ISO 8601 (which is developer friendly).
Now, I'm not interested in what *was* the case, it should return if the action was successful, and the relay is now in the requested state.
- successfull is the APIs answer with valid JSON response, any additional information is IMHO useless.
What is the benefit if there's something like "applied": true, "current_state": on in the the JSON?
- was_on is important for me: if you send a request to turn it 'on' and it was already on this information can be helpful for software developers.
was_on 'true' after a 'turn on' request: -> relay was already on, no change.
was_on 'false' after a 'turn on' request -> relay state changed from off to on
....
But if you don't like it you can still use the old API URLs to get a more detailed state:
http://<ip>/relay/0?turn=toggle should still work..
My browser is not allowed to remember the login password.
This is intentionally (not a bug), the html input field has the autocomplete="off" attribute. Probably security reasons..
About saving modifications to the URL for a WebHook, I think you might have tried this only by verifying if the URL has changed when 'Apply Webhook', and then immediately viewing the URL again.
Validated, I'll create a bug report 
Alterco hat den Fehler im Ticket bestätigt und sagt es wäre ein "brandneues" Gerät und es würde ein Fix kommen, vielleicht macht es Sinn das man sowas im Beta Test erfassen.
wird mit der nächsten Version gefixt, hat mir gestern einer der Entwickler bestätigt..
PS: die ersten 1000 sind quasi ein öffentlicher (erweiterter) Beta-Test 
In Anbetracht des Umfangs der komplett neuen Software finde ich aber erstaunlich wenig Fehler bisher
für reine Messungen (auch negative) nimmt man einen ShellyEM, der kann das
Also, the time on the WebIf is in 'AM/PM' mode, whilst the time in the API is 24h.
(My location was correctly determined to be EU)
can you take a screenshot from the WebUI? not sure where to check that..
1. for Ethernet (Eth) it's similar: it doesn't work
you probably used the wrong Syntax, ethernet is working fine:
curl -X POST -d '{"id":1, "src":"user_1", "method":"Eth.SetConfig",
"params":{"config":{"enabled": true, "ipv4mode": "static", "ip": "192.168.178.199", "netmask": "255.255.255.0", "gw": "192.168.178.1"}}}' http://192.168.178.93/rpcwhilst both are connected to the same network)
this is probably causing internal routing issues.. in general no network client should be connected to the same network with two different interface (ip addresses).
Something strange with the inputs. When none are active, this is the results I get:
id 4 is not a valid id.. not sure why id 0 reports "null" for you. I've tested wih Firmware 0.6.10 and get false as result:
"Apply Webhook" complains the Webhook already exists (which is true, but I simply wanted to update the modified URL).
From my tests the message is weird because the URL will be updated. So yes, this is a bug..
.../relay/0?turn=toggle&timer=100 z.b. geht weiterhin
die RPC-Schnittstelle ist Mongoogse-OS Standard und ich find es eigentlich gut, dass man da keinen komplett eigenen Weg mehr geht sondern vorhandenes nutzt.. Auf Dauer beschleunigt das die Entwicklung erheblich..
der "alte" 1PM kann aktuell noch mehr LongPush/ShortPush
meinst du bei den Actions? bei den Schedules gab es doch noch nie ShortPush / Longpush..
die DEVs wissen Bescheid, ein Fix ist in Arbeit..
Schade das die gewohnen URL Befehle nicht gehen, aber da muss man durch.
Was hättest du gern für Befehle? hab den ja schon länger hier und kann eventuell helfen bei der entsprechenden API-Syntax.
Ah, Ok. aber das passiert erst ab einem bestimmten FW Stand oder war das Problem schon immer da?
das Problem war schon immer da, hängt aber mit den verwendeten Netzwerkkomponenten (Router, Switche, APs..) und deren Firmware zusammen..
Wenn nicht (mehr) alle Komponenten wissen, wer alles Teilnehmer einer IGMP-Gruppe ist oder diese Gruppe(n) dynamisch aufräumen geht dann plötzlich irgendwann etwas schief.
Unicast hat den riesengroßen Vorteil, dass man zielgerichtet an ein Gerät schickt und da spielt es keine Rolle, wo sich der Empfänger (z.B. der ioBroker) befindet..
Solange die Ziel-IP per Routing erreichbar ist klappt das wunderbar, egal ob der ioBroker dann im lokalen (gleichen) Netzwerk, in einer demilitarisierten Zone, irgendwo im Internet oder in einem Docker-Container betrieben wird.
This is a known bug.. I've reported yesterday evening and direclty forwarded to the DEVs..
Workaround until it gets fixed: use curl command line tool to set the fixed IP via API.. this is an example request for the wifi interface (sta):
curl -X POST -d '{"id":1, "src":"user_1", "method":"WiFi.SetConfig",
> "params":{"config":{"sta":{"ipv4mode":"static","ip":"192.168.178.137","netmask":"255.255.255.0","gw":"192.168.178.1","nameserver":"192.168.178.1"}}}}' http://192.168.178.137/rpcfor Ethernet (Eth) it's similar:
https://shelly-api-docs.shelly.cloud/gen2/Component…mComponents/Eth
If you find additional issues please report here.. I'll validate an create bug reports in their internal bugtracking system..
ich würde die HuE aus der Lampe werfen und gegen eine herkömmliche dimmbare LED tauschen, dann einen ShellyDimmer2 (der kann auch ohne Neutralleiter und dem reichen 10 Watt) hinter den Taster.
Mit einer entsprechend starken LED sollte das dann auch ohne Bypass klappen..
https://shelly-api-docs.shelly.cloud API-Docs wurden für die Neue Generation aktualisiert
ja, alles neu, und fast alles anders 
beim Togglen bleibt fast alles identisch:
zusätzlich zum http://<ip>/relay/0?turn=toggle kann man (muss man aber nicht) jetzt auch ein http://<ip>/rpc/Switch.Toggle?id=0 benutzen
Bei den Settings ist aber alles anders Außerdem kein Coap mehr, dafür Websockets über RPC.
Aber warum läuft der i3 erst auf mcast mit der neuen FW und dann nicht mehr.
weil einige Netzwerkkomponenten Probleme mit IGMP-v2 Daten haben und Pakete urplötzlich (ohne erkennbare Gründe) nicht mehr zustellen / filtern..
das ist der Hauptgrund, warum wir (primär Markus Michels - Entwickler des OpenHAB-Bindings und ich) die Shelly-Entwickler überzeugen konnten Unicast zu implementieren 
Wenn der Reset nicht funktioniert bleibt meines Erachtens nur Ausprobieren von Username & Passwort (siehe oben) oder mittels FTDI ein Revovery-Image flashen (ist eher etwas für erfahrene Anwender).
naja, auf den Screenshots sieht es so aus als wolltest du den Shelly der Cloud / App hinzufügen und das schlägt vermutlich fehl, weil das Login nicht korrekt ist..
Strom (über Sicherung) aus / Strom an, dann innerhalb einer Minute 5x den Schalter betätigen -> macht einen Reset..
Einen Shelly habe ich im Browser mit Namen und Passwort versehen und dieser macht die Probleme
ok, also nicht direkt so gekauft..
- Groß- und Kleinschreibung beachtet (sowohl im Passwort als auch im Usernamen wichtig)?
- Großstelltaste bei Vergabe aktiv gewesen?
- versehentlich Leerzeichen am Ende?
- Sonderzeichen im Passwort drin? falls ja, eventuell gab es da ein Problem mit dem Encoding..
eventuell blöde Frage: hat der Shelly das direkt nach dem Auspacken gemacht oder hattest du selbst ein Kennwort eingeben?
normal werden die ohne Username / Kennwort ausgeliefert.. wenn der von Anfang an geschützt war: wo hast du ihn gekauft?
Bei Betrieb mit einem Taster je Dimmer:
Taster kurz Drücken: an / aus
Taster lang drücken Dunkler / Heller (im Wechsel)
Bei Betrieb mit zwei Tastern je Dimmer:
Taster 1 kurz Drücken: an
Taster 1 lange drücken: heller
Taster 2 kurz Drücken: aus
Taster 2 lange Drücken: dunkler
Für mich persönlich fülht sich das irgendwie komisch an, wenn ich eine Lampe über einen Taster an und nur über den anderen wieder ausschalten kann. Daher betreibe ich alle meine Dimmer mit nur einem Taster.
mit einem Schalter lässt sich der Zustand des Dimmers (an/aus) ändern.
Dabei spielt es keine Rolle welche Helligkeit der Dimmer aktuell hat (wird beibehalten) und ob das Licht gerade an oder aus ist. Einstellung wäre in dem Fall dann "Edge"..
