Test Adapter Shelly v4.0.3 (latest)

[Sascha12]

@harrym Verdammt, echt dumm, wer lesen kann..... Danke.
Aber ich habe eben keine Verbindung mehr zu CoaP.
Aber ich hatte vor dem Update keinerlei Probleme und nichts verändert eigentlich.
Irgendeine Idee wo ich anfangen soll zu suchen?
In der App wird alles korrekt angezeigt.
Sollte ich keine statischen IPs vergeben?
In der APP bzw im Router?

Shelly Adapter löschen und neu machen wird wohl auch nix bringen nehme ich an....

VG Sascha

[harrym]

@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 .....

[da_Woody]

@harrym kleiner nachtrag dazu: repeater erst nach router starten! hatten wir auch schon...

[Sascha12]

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?

[da_Woody]

@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...

[joergeli]

@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@8acf41b0

Frage:
Muß ich erst von V1.7.0 auf V1.8.0 updaten, damit mir anschl. die V1.8.3 angeboten wird?

Gruß
Jörg

[da_Woody]

@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.

[joergeli]

@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.3

Deshalb: Vorsicht ist die Mutter der Porzellankiste
Jörg

[BobBruni]

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]

@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.

[da_Woody]

@BobBruni deutet für mich auf einen falschen schaltflächentyp hin...

[BobBruni]

@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...

[da_Woody]

@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]

@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]

@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.

3. Setze ich das Objekt auf False wird dieses auch vom Shelly sofort übernommen.
   Dann geht die Geschichte wieder von vorne los.

[da_Woody]

@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.

[siggi85]

@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.

3. 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.

[da_Woody]

@siggi85 nur in der gruppe, oder auch bei einzelschaltung?

[Kusi]

@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 ms

PuTTY2020-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 ms

pi@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:5683

mehr kommt hier nicht.

[siggi85]

@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.