NEWS
Test Adapter Shelly v4.0.3 (latest)
-
OK, ich habe mal getestet. Vielleicht, dachte ich mir, sind die Router überfordert mit 3 Kameras von Motioneye. Also die abgeschaltet bze Motioneye deaktiviert.
Ebenso einen langsamen Orbi abgeschaltet, nun nur noch die 50er dranhängen.
Die Eingrenzung ist schwer, denn ich glaube das ganze funktioniert schon eine Weile nicht mehr. Ich habe mich seit ein paar Wochen schon gewundert, warum die Ansage der Waschmaschine mit dem Shelly Plug immer Zeitversetzt und öfters mal kommt....
Also kommt ein Coap durch, nur spät..... das zeigt imo auch meine Auswertung unten.Ich habe ca 60 Shellys dranhängen, und der Plan ist dass es noch mehr werden.
(Vielleicht ist der Wechsel zu MQTT eine Lösung, aber ich hätte schon gerne gewusst was das Problem mit CoaP ist)Hier die Screenshots:
Danach habe ich die 192.168.1.22 mal mit dem allgemeinen Befehl per Hand geschaltet, und dann taucht es im Log auf.....
Komisch....
Diese IP, wenn ich den Shelly Adapter wieder starte, meldet den status des "switch" nicht zurück....
@Edit: Doch, er geht zurück. Aber extrem Zeitversetzt und gefühlt nach einer Random Zeit.Vielleicht sind es einfach zu viele CopA Geräte....?
@harrym
Ich habe eine Fritzbox mit FW 7.20, ohne WLAN.
Dort ist per LAN ein ORBI RBR50 und 3 Sateliten angeschlossen für das Wlan.An der FRitzbox gab es ein Update, wie auch bei Netgear Orbi.
Ich downgrade mal die Orbi, vielleicht hilf das.
Dasss es an der Fritzbox liegt, kann ja kaum sein, die Datenpakete sollten ja nicht dort hin gehen, oder?@Sascha12 said in Test Adapter Shelly v4.0.3 (latest):
Vielleicht sind es einfach zu viele CopA Geräte....?
sicher nicht, ich hab ca.70 shellys hängen. + anderes zeuch.
hab jetzt nicht alles durchgelesen, ist der shelly in der cloud? wenn ja, nimm mal raus.
hatte nach langer testerei so einen fall mit nem shelly1 (ventilator im bad, gesteuert über luftfeuchte.) 2min gelaufen, 2 sec abgedreht, 2min gelaufen, ....alles mögliche und unmögliche getestet. aus der cloud genommen, siehe da, kein problem mehr. angeblich bin ich nicht der einzige mit so einem problem. ticket bei allterco ist erstellt... -
UPDATE: Firmware 1.8.3 is released for all main powered devices.
What issues we are resolve with it:
CoAP status delay is resolved. Now maximum delay time between status change and report is 200 miliseconds.@harrym
Moin,
Firmware 1.8.3 soll ja seit 12.08.2020 released sein.
In der V1.8.3 wäre für mich interessant, dass "CoAP status delay is resolved" ist.Auf meinen div. Shelly 1 und Shelly Plug S wird aber nur die V 1.8.0 als Firmwareupdate angeboten:
version 20200812-090904/v1.8.0@8acf41b0Frage:
Muß ich erst von V1.7.0 auf V1.8.0 updaten, damit mir anschl. die V1.8.3 angeboten wird?Gruß
Jörg -
@harrym
Moin,
Firmware 1.8.3 soll ja seit 12.08.2020 released sein.
In der V1.8.3 wäre für mich interessant, dass "CoAP status delay is resolved" ist.Auf meinen div. Shelly 1 und Shelly Plug S wird aber nur die V 1.8.0 als Firmwareupdate angeboten:
version 20200812-090904/v1.8.0@8acf41b0Frage:
Muß ich erst von V1.7.0 auf V1.8.0 updaten, damit mir anschl. die V1.8.3 angeboten wird?Gruß
Jörg -
@joergeli pöff, kann ich dir im moment nicht sagen, eigentlich sollte gleich 1.8.3 angeboten werden. versuchs mal mit einen shelly1, dann siehst du ja was passiert.
@da_Woody
OK, ich will aber vorher besser noch ein Backup-Image von der Micro SD-Karte in meinem Raspi 4 ziehen,
weil ich z. Zt. noch den Shelly Adapter 3.3.6 betreibe.Ab Shelly Firmware 1.8.0 ist ja zwingend der Shelly Adapter ab V 4.0 notwendig.
Mit anderen Worten: Ich muss den erst Shelly Adapter auf V 4.0.3 updaten, bevor ich die Firmware 1.8.0 installiere, um zu testen.
Dann spielen aber alle meine Shellys mit Firmware V 1.7.0 nicht mehr mit Adapter V.0.3Deshalb: Vorsicht ist die Mutter der Porzellankiste :face_with_rolling_eyes:
Jörg -
Wenn ich bei meinem Shelly-Dimmer1 das Objekt "Switch" auf True setze, schaltet der Dimmer, allerdings wird das Objekt in ioBroker sofort wieder auf False gesetzt. Der Dimmer bleibt an.
Setzte ich Ihn nun wieder auf True, bleibt der Shelly an und das Objekt bleibt auch in ioBroker auf True.
Sprich, bei jedem einschalten muss ich das Objekt zweimal auf True setzen, damit der Zustand in ioBroker bleibt... Jemand eine Idee?
-
@da_Woody
OK, ich will aber vorher besser noch ein Backup-Image von der Micro SD-Karte in meinem Raspi 4 ziehen,
weil ich z. Zt. noch den Shelly Adapter 3.3.6 betreibe.Ab Shelly Firmware 1.8.0 ist ja zwingend der Shelly Adapter ab V 4.0 notwendig.
Mit anderen Worten: Ich muss den erst Shelly Adapter auf V 4.0.3 updaten, bevor ich die Firmware 1.8.0 installiere, um zu testen.
Dann spielen aber alle meine Shellys mit Firmware V 1.7.0 nicht mehr mit Adapter V.0.3Deshalb: Vorsicht ist die Mutter der Porzellankiste :face_with_rolling_eyes:
Jörg@joergeli said in Test Adapter Shelly v4.0.3 (latest):
Ab Shelly Firmware 1.8.0 ist ja zwingend der Shelly Adapter ab V 4.0 notwendig.
jo, das stimmt allerdings! sorry, nicht dran gedacht. allerdings hab ich immer ein paar reserve shelly's rumliegen zum testen. dadurch besteht bei mir das problem nicht... da nicht produktiv.
allerdings solltest du sowieso updaten. mit der 1.8.3 ist die reaktionszeit bei CoAP auf max 200ms, also um einiges schneller geworden und in der 4.0.3 sind mal alle aktuellen API dingsbums drinnen. -
Wenn ich bei meinem Shelly-Dimmer1 das Objekt "Switch" auf True setze, schaltet der Dimmer, allerdings wird das Objekt in ioBroker sofort wieder auf False gesetzt. Der Dimmer bleibt an.
Setzte ich Ihn nun wieder auf True, bleibt der Shelly an und das Objekt bleibt auch in ioBroker auf True.
Sprich, bei jedem einschalten muss ich das Objekt zweimal auf True setzen, damit der Zustand in ioBroker bleibt... Jemand eine Idee?
-
@da_Woody meinst du damit den Button Type? Da habe ich schon alle durchprobiert... Keine Änderung!
Shelly komplett aus ioBroker entfernen / Shelly Adapter hat alles nichts gebracht...
@BobBruni hmm, hatte so was ähnliches mit den funkschaltern die ich kombiniert hab. da musste ich auch 2x drücken damits der shelly übernommen hat. button type geändert, dann gings.
sind deine shellys auch in der shelly cloud? die pfuscht auch gern rein... -
@Sascha12 wenn du nichts via CoAP bekommst, hast du einen Fehler im Netzwerk. Router mal neustarten. Falls Repeater mitspielen ... diese auch neu starten.
Dann mal nachdenken, ob sich innerhalb vom Netzwerk etwas geändert hat. Firmwareupdate oder sonstiges .....
@harrym
Da ic ja den Fehler nicht finde, und ich mqtt nicht so recht möchte weil ich die Shelly App von extern wirklich mag, werde ich wohl den Adapter wie auch die Shellys downgraden.... alles für den wichtigen WAF 😉
Viele Grüße
Sascha
Oder hier habe ich im Orbi ein Menü gefunden. Jemand eine Idee...?
-
@BobBruni hmm, hatte so was ähnliches mit den funkschaltern die ich kombiniert hab. da musste ich auch 2x drücken damits der shelly übernommen hat. button type geändert, dann gings.
sind deine shellys auch in der shelly cloud? die pfuscht auch gern rein...@da_Woody
Shelly Cloud ist nicht aktiv.
Ich habe nicht das problem, dass ich 2x drücken muss damit es der Shelly übernimmt. Sondern, ich muss 2x drücken damit der Zustand in ioBroker passt.Ich versuchs nochmal zu beschreiben:
1.Wenn ich in ioBroker das Objekt "Switch" auf True setze, wird dieses (ohne mein zutun auch kein Script o.ä.) sofort danach wieder auf False gesetzt. Der Shelly hat den Befehl aber übernommen und ist und bleibt aktiv.
2.Dann setze ich das Objekt mittels ioBroker erneut auf True. Diesmal bleibt der Zustand im Objekt. Auch der Shelly ist weiterhin eingeschalten.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
Dann geht die Geschichte wieder von vorne los.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
-
@da_Woody
Shelly Cloud ist nicht aktiv.
Ich habe nicht das problem, dass ich 2x drücken muss damit es der Shelly übernimmt. Sondern, ich muss 2x drücken damit der Zustand in ioBroker passt.Ich versuchs nochmal zu beschreiben:
1.Wenn ich in ioBroker das Objekt "Switch" auf True setze, wird dieses (ohne mein zutun auch kein Script o.ä.) sofort danach wieder auf False gesetzt. Der Shelly hat den Befehl aber übernommen und ist und bleibt aktiv.
2.Dann setze ich das Objekt mittels ioBroker erneut auf True. Diesmal bleibt der Zustand im Objekt. Auch der Shelly ist weiterhin eingeschalten.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
Dann geht die Geschichte wieder von vorne los.
@BobBruni very strange... ich habs gerade versucht mit shelly1 und shellydimmer. im shelly adapter und im alias. wert ändern und nichts springt zurück. weder ein, noch ausschalten. irgendwie fällt mir im moment dazu nichts ein. :face_with_head_bandage:
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
-
@da_Woody
Shelly Cloud ist nicht aktiv.
Ich habe nicht das problem, dass ich 2x drücken muss damit es der Shelly übernimmt. Sondern, ich muss 2x drücken damit der Zustand in ioBroker passt.Ich versuchs nochmal zu beschreiben:
1.Wenn ich in ioBroker das Objekt "Switch" auf True setze, wird dieses (ohne mein zutun auch kein Script o.ä.) sofort danach wieder auf False gesetzt. Der Shelly hat den Befehl aber übernommen und ist und bleibt aktiv.
2.Dann setze ich das Objekt mittels ioBroker erneut auf True. Diesmal bleibt der Zustand im Objekt. Auch der Shelly ist weiterhin eingeschalten.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
Dann geht die Geschichte wieder von vorne los.
@BobBruni sagte in Test Adapter Shelly v4.0.3 (latest):
@da_Woody
Shelly Cloud ist nicht aktiv.
Ich habe nicht das problem, dass ich 2x drücken muss damit es der Shelly übernimmt. Sondern, ich muss 2x drücken damit der Zustand in ioBroker passt.Ich versuchs nochmal zu beschreiben:
1.Wenn ich in ioBroker das Objekt "Switch" auf True setze, wird dieses (ohne mein zutun auch kein Script o.ä.) sofort danach wieder auf False gesetzt. Der Shelly hat den Befehl aber übernommen und ist und bleibt aktiv.
2.Dann setze ich das Objekt mittels ioBroker erneut auf True. Diesmal bleibt der Zustand im Objekt. Auch der Shelly ist weiterhin eingeschalten.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
Dann geht die Geschichte wieder von vorne los.
Ich habe ein ähnliches Verhalten seit ca. 6 bis 8 Wochen mit 4 RGBWs die ich per Gruppendatenpunkte gemeinsam schalte. Allerdings kam ich bis jetzt noch nicht zum Update auf die 1.8 Shelly/4.x Adapter, bin noch auf 1.7x/3.x. Ich wollte mit dem Troubleshooting warten, bis ich zumindest alles auf der aktuellen Version habe.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
-
@BobBruni sagte in Test Adapter Shelly v4.0.3 (latest):
@da_Woody
Shelly Cloud ist nicht aktiv.
Ich habe nicht das problem, dass ich 2x drücken muss damit es der Shelly übernimmt. Sondern, ich muss 2x drücken damit der Zustand in ioBroker passt.Ich versuchs nochmal zu beschreiben:
1.Wenn ich in ioBroker das Objekt "Switch" auf True setze, wird dieses (ohne mein zutun auch kein Script o.ä.) sofort danach wieder auf False gesetzt. Der Shelly hat den Befehl aber übernommen und ist und bleibt aktiv.
2.Dann setze ich das Objekt mittels ioBroker erneut auf True. Diesmal bleibt der Zustand im Objekt. Auch der Shelly ist weiterhin eingeschalten.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
Dann geht die Geschichte wieder von vorne los.
Ich habe ein ähnliches Verhalten seit ca. 6 bis 8 Wochen mit 4 RGBWs die ich per Gruppendatenpunkte gemeinsam schalte. Allerdings kam ich bis jetzt noch nicht zum Update auf die 1.8 Shelly/4.x Adapter, bin noch auf 1.7x/3.x. Ich wollte mit dem Troubleshooting warten, bis ich zumindest alles auf der aktuellen Version habe.
- Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
-
@Stuebi
Test durchgeführt, hier die Meldungen wenn Shelly´s mit dem alten Router verbunden sind (Shellys funktionieren einwandfrei mit ioBroker):10 packets transmitted, 10 received, 0% packet loss, time 10ms rtt min/avg/max/mdev = 1.833/16.567/135.218/39.571 msPuTTY2020-09-13T06:01:16.099Z - 192.168.1.54:5683 - P<23citsm lSHSW-25#76C597#2R{"G":[[0,9103,0],[0,1102,"open"],[0,1103,0],[0,2101,0],[0,2102,""], [0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4102,148.31],[0,4104,0], [0,6103,"normal"],[0,3104,57.51],[0,6101,0],[0,9101,"roller"]]}Test durchgeführt, Shelly mit dem neuen Router verbunden (mit anderer SSID, Shelly funktioniert mit ioBroker nicht):
10 packets transmitted, 10 received, 0% packet loss, time 22ms rtt min/avg/max/mdev = 1.970/25.353/114.871/43.712 mspi@raspberrypi:~ $ cd /opt/iobroker/node_modules/iobroker.shelly pi@raspberrypi:/opt/iobroker/node_modules/iobroker.shelly $ node coaptest.js UDP Server listening on 0.0.0.0:5683mehr kommt hier nicht.
-
@da_Woody sagte in Test Adapter Shelly v4.0.3 (latest):
@siggi85 nur in der gruppe, oder auch bei einzelschaltung?
Habe gestern Shellys und Adapter auf stable geupdatet und bisher konnte ich das Problem nicht mehr feststellen.
-
@siggi85 was so ein update alles bewirken kann! :joy: :joy: :joy:
fein das jetzt ruhe im karton ist...@da_Woody sagte in Test Adapter Shelly v4.0.3 (latest):
@siggi85 was so ein update alles bewirken kann! :joy: :joy: :joy:
fein das jetzt ruhe im karton ist...Da ich wusste, dass noch Updates ausstehen, wollte ich vorher auch nichts dazu im Forum schreiben. Als ich aber das von @BobBruni gelesen habe, dachte ich, es könnte sich um das gleiche Problem handeln. :)
-
Ich hab gerade erst bemerkt, dass der Shelly auf Version 1.8 geupdatet werden muss... :man-facepalming:
Warum wird mir diese nicht angeboten?
Wenn ich das Update händisch anstoße:
http://IP/ota?url=http://api.shelly.cloud/firmware/SHDM-1.zipbekomme ich das hier:
{"status":"updating","has_update":false,"new_version":"","old_version":"20191120-141347/v1.5.6-rc2@4776adad"} -
Seit der Firmware 1.8.x melden einige User, dass der Shelly Adapter im CoAP Modus die Shellys nicht mehr findet, nicht aktiv sind bzw. das ACK nach einer Aktion wie z.B. relelay0.Switch = true nicht auf true setzt.
Prüft bitte, ob ihr mindestens den Shelly Adapter 4.0.0 im Einsatz habt und die Shelly Firmware 1.8.0 oder höher ist! Ist das der Fall, dann ist folgendes zu prüfen.Schritt 1: Shelly erreichbar über ping
Ermittelt die IP Adresse von dem Shelly der in ioBroker nicht mehr aktualisiert wird. Die IP Adresse könnt Ihr z.B. in Eurem WLAN Router (z.B. Fritzbox), oder der Shelly APP, Tools zum LanScan, etc. finden. Auch in ioBroker steht die ip Adresse unter den Objekt hostname (Bsp.:shelly.0.SHDW-2#483FDAxxxxxxx#1.hostname) die sich hoffentlich nicht geändert hat. Nun versuche den Shelly per ping zu erreichen.
Öffne ein Terminalfenster auf dem Rechner wo ioBroker läuft (es muss umbedingt der ioBroker Rechner sein) und gebe folgendes ein:# ping -c 10 <ip_address_of_missing_shelly> ping -c 10 192.168.20.237 # Example, IP of Shelly is 192.168.20.237Wenn du so etwas wie unten siehst, dann ist der Shelly per ping erreichbar und du kannst mit Schritt 2 weitermachen. Wenn der Shelly nicht per ping erreichbar ist, hast du entweder die falsche IP Adresse gewählt oder du hast ein Problem mit dem Netzwerk.
Wichtig, beim Shelly wie z.B. DW2 oder Button geht der Ping nur wenn der Shelly gerade "aufgeweckt wurde". Also während des Tests den Shelly umbedingt aufwecken (z.B. Knopf drücken beim Button).64 bytes from 192.168.20.237: icmp_seq=12 ttl=255 time=1735.952 ms 64 bytes from 192.168.20.237: icmp_seq=13 ttl=255 time=731.547 ms 64 bytes from 192.168.20.237: icmp_seq=14 ttl=255 time=6.776 ms 64 bytes from 192.168.20.237: icmp_seq=15 ttl=255 time=8.171 msSchritt 2: Prüfen ob ioBroker CoAP Nachrichten empfängt
Stoppe die Shelly Instanz in ioBroker unter Instanzen (nicht ioBroker nicht deinstallieren!!!). Wenn möglich ermittelt die IP Adresse vom Shelly (siehe Schritt 1).
Öffne ein Terminalfenster auf dem Rechner wo ioBroker läuft (es muss umbedingt der ioBroker Rechner sein) und gebe folgendes ein:cd /opt/iobroker/node_modules/iobroker.shelly node coaptest.js # oder node coaptest.js | grep "<IP-OF-MISSING-SHELLY>" node coaptest.js | grep "192.168.20.237" # Shelly with IP 192.168.20.237Nun betätige Dein Shelly (z.B. Knopf drücken beim Shelly Button, oder Licht an/aus beim Shelly 1). Du solltest ähnliche Nachricht mit Timestamp und Name des Shellys den du vermisst sehen (z.B. SHDW2#483FDAxxxxx#2).
2020-08-24T11:15:48.140Z - 192.168.20.237:5683 - PR3citsm SHDW2#483FDAxxxxx#2RC{"G":[[0,9103,0],[0,3108,1],[0,3109,-1],[0,6110,-1],[0,3106,5],[0,3110,"dark"],[0,3101,24.90],[0,3102,76.82],[0,3115,0],[0,3111,100],[0,9102,["sensor"]]]}Siehst Du keine Nachrichten für den "vermissten" Shelly im coaptest.js, hast du ein CoAP Problem. D.h. der Fehler liegt im Netzwerk (z.B. Konfiguration, WLAN Router Einstellung, Switch, ....).
Schritt 3: Ping und CoAP Test waren erfolgreich oder auch nicht
Du hast den Schritt 1 und Schritt 2 durchgeführt und der Shelly der dir Probleme bereitet, ist per ping erreichbar und du siehst diesen auch in den CoAP Nachrichten, gebe bitte ein Issue hier auf.
Einer der Tests in Schritt 1 oder Schritt 2 waren nicht erfolgreich, dann gebe kein Issue auf. Es handelt sich hierbei um kein Problem des Shelly Adapters 4.0.0 (oder höher) sondern um ein Netzwerkfehler bzw. um einen internen Fehler des Shellys mit dem CoAP Protokoll. Wende Dich bitte an den Hersteller!Hinweis 1:
Es ist total irrelevant ob die mobile Shelly App und / oder das Webinterface des Shellys funktionieren, da diese nicht mit dem CoAP Protokoll arbeiten. Der ioBroker Shelly Adapter arbeitet mit CoAP oder MQTT, da Statusänderungen (z.B. Schalter an/aus) per Push an ioBroker übermittelt werden, d.h. man sieht die Änderungen fast in realtime in ioBroker. Das wäre mit http nicht möglich, da man hier pollen (in regelmässigen Abständen, z.B. alle 5 Sekunden den Status der Shellys abfragen) müsste.Hinweis 2:
als Hinweis für alle: Wenn ihr Timer (z.b.: auto on, auto off) setzt, passt bitte darauf auf, dass diese >= 3 Sekunden sind. Timer unter diesem Wert sind für das derzeitige CoAP der Firmware 1.8.x ein Problem und werden nicht bzw. falsch dargestellt.Hi,
ich habe ein Shelly 3EM und der ioBroker bekommt keine Daten.
Ich habe es mit Firmware 1.8.1 und Adapter 4.0.2 versucht, ebenso mit Firmware 1.8.4-rc2 und Adapter 4.0.2 als auch mit 1.8.4-rc2 und Adapter 4.0.4.Der Ping-Test ist ebenso erfolgreich wie der CoAP-Empfangstest der hier im Thread (https://forum.iobroker.net/post/478820) beschrieben ist.
Es werden aber keine Objekte angelegt.Nur für Dummies wie mich: Ich muss Restricted Access nicht aktivieren, oder? Das ist bei mir ausgeschaltet. Ich habe es allerdings auch schon mit dieser Option probiert.
Support us
730
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge