Test Adapter Shelly v4.0.3 (latest)

[Ruud2019]

@harrym
Okay, tut mir leid.
Es lag am Admin-Adapter. Bin wieder runter auf 4.1.6. Jetzt funktioniert es wieder.

[Stuebi]

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

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

Schritt 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.237

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

[harrym]

Wir sind jetzt auch via Discod am ioBroker Server mit einem eigenen Channel (#shelly) vertreten.

Hier der Link: https://discord.gg/gF8ddbK

[harrym]

https://www.facebook.com/groups/ShellyIoTCommunitySupport/permalink/3017335681699109/?comment_id=3063004663798877

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]

Der neue Shelly UNI (SHUNI-1) ist ja bereits angekündigt und wird auch ab dem 25.9. seitens Allterco versendet.

Unser Adapter ist bereits darauf vorbereitet.

Hier die Beschreibung zu dem UNI ... shelly_uni.pdf

[BlueBook]

Hi @Stuebi und @Diggewuff

kurz auch noch einmal als Rückmeldung von mir.
Mit der neuen 4.03 Version funktioniert bei mir auch wieder alles.
Warum dies zwischenzeitig nicht so war - weiß ich nicht...

Selbst der Button mit dem Update für die Mehrfachevents läuft jetzt perfekt über CoAP!

Danke für die Erweiterung!
Super

Schönes WE
BB

[Sascha12]

Hallo,

bei mir updaten sich die Datenpunkte leider nicht. Ich bin entsprechend der Anleitung oben durchgegangen, die Shelly-IPs sind erreichbar.
Aber am Schritt 2 hängt was.
Ich bekomme diese Fehlermeldung:

Leider kenne ich mich damit überhaupt nicht aus.
Kann mir hier jemand weiter helfen?

(Wenn ich den Adapter stoppe und starte, aktualisieren die DP ein Mal)

VG
Sascha

[harrym]

@Sascha12 der coaptest.js läuft nur, wenn du die Shellyadapterinstanz gestoppt hast. Wenn du das nicht machst, ist der Port belegt und nicht für den coaptest.js verfügbar.

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