UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Stuebi]

@eierfeile , ich habe die Übersicht verloren mit deinem Shelly Plug S, daher ein paar Fragen?

1. Welche Firmware hat der Shelly Plug S?
2. Ist der Shelly Plugs S im selben Subnets wie ioBroker?
3. Wie ist die IP Adresse und Netmask vom Shelly Plug S und vom ioBroker?
4. Warum nutzt du kein DHCP beim Shelly Plug S?
5. ioBroker läuft auf der der NAS und ist über LAN Kabel oder WLAN verbunden?
6. Kannst Du von ioBroker aus, den Shelly Plug S mit ping erreichen?
7. Hast Du mit tcpdump auf dem ioBroker Server nach den Shelly Plug S Paketen gesucht?

[eierfeile]

@Stuebi
Danke für eure Hilfe! Zu deinen Fragen:

1. Sind 3 Plug S mit 1.8. Die Shelly 1 haben auch 1.8.
2. Ja. Ip iobroker = 192.168.188.27, IP Plug S = 192.168.188.71
3. s. oben
4. Keine Absicht. Stört mich bis dato nicht.
5. Ja im Docker. über LAN. NAS > Switch > Fritzbox. Die Shellys hingegen natürlich über WLAN > Repeater/LAN -Bridge > Fritzbox
6. Ja
7. Nein. Noch nie gehört. Müsste ich mir mal anschauen wie das genutzt wird. coaptest hab ich allerdings mehrfach gemacht. Da werden nur die shelly 1 gefunden.

[Stuebi]

@eierfeile , okay klingt ja schon einmal gut. Alle Shellys haben die Firmware 1.8 und sind per ping erreichbar. Also ist es ein Problem mit Multicast.

1. Hast Du versucht die Plug S so aufzustellen, dass diese sich direkt an der Fritzbox am WLAN anmelden und nicht über die WLAN Repeater?
2. Die WLAN Repeater, sind nicht über LAN Kabel mit einem Switch / Fritzbox?
3. Du hast nicht noch etwas wie LAN über Steckdose etc. im Einsatz? 4. Hängt ioBroker direkt an der Fritzbox oder sind dazwischen noch Switches?

tcpdump ist ein Sniffer. Dann musst Du die Shelly Instanz nicht stoppen.

# Install tcpdump if it is not installed
sudo apt-get update
sudp apt-get install tcpdump

# tcpdump with IP address of Shelly device on network device eth1
sudo tcpdump -i eth1 src <IP-OF-SHELLY> and port 5683 -A   

# tcpdump with IP address of Shelly device 
sudo tcpdump src <IP-OF-SHELLY> and port 5683 -A

# tcpdump of all Shelly devices on network device eth0
sudo tcpdump  -i eth0 port 5683 -A

[eierfeile]

@Stuebi ok, wir kommen der Sache näher.

1. Ja. coaptest findet jetzt den Plug S. Hab ihn im Keller eingesteckt, dort is auch die Fritzbox bzw dessen WLAN.
2. Die Repeater sind via LAN Kabel über ein Patch-Panel mit der Fritzbox verbunden.
3. Du meinst sowas wie Powerline...nein, hab ich nicht im Einsatz. Iobroker läuft im Docker aus dem NAS. Das hängt an diesem Switch: https://www.amazon.de/dp/B00YMTNVEM/ref=pd_lpo_147_t_1/262-7648433-8957167?_encoding=UTF8&pd_rd_i=B00YMTNVEM&pd_rd_r=a2402691-7298-4cbb-881d-80f4e861605b&pd_rd_w=rs157&pd_rd_wg=2qBt6&pf_rd_p=d5c9797d-0238-4119-b220-af4cc3420918&pf_rd_r=0C2KCX8P6RFT4A7GJ8CS&psc=1&refRID=0C2KCX8P6RFT4A7GJ8CS

Bzgl multicast hab ich hier keine Aussage gefunden. Hätte ich als nächstes getestet das nas direkt anzuschliessen. Aber offenbar lieg es ja am repeater. Es ist der FRITZ!WLAN Repeater DVB-C. Wobei ich den schon immer habe. Vor dem Shelly-Update ging ja auch alles.

P.S.: Hab das nas gerade direkt angeschlossen. Ändert aber nichts. Plug S werden nicht erkannt.

[Stuebi]

@eierfeile , okay wenn jetzt der coaptest den Shelly Plug S der im Keller angeschlossen ist findet, sollte dieser auch in ioBroker im Shelly Adapter sichtbar sein wenn Du den coaptest beendest und den Shelly Adapter startest. 1. Ist das Fall? 2. Ich schließe aus Deiner Aussage, dass alle Shelly 1 nicht über die WLAN Repeater im WLAN sondern direkt über die Fritzbox im WLAN sind?

[eierfeile]

@Stuebi Ja, der ist jetzt im iobroker. Die Shelly 1 sind über den 2. Repeater angebunden. Dort scheint es zu gehen. Das ist der 1750E. Der 2. Repeater ist m.W. der gleiche Repeater nur mit DVBC. Aus irgendeinem Grund scheint er das shelly update aber nicht zu vertragen.

[da_Woody]

@eierfeile im https://shelly-support.eu/ gibts eine liste in der steht welche router und co probleme mit shelly dingens haben. gibt z.b eine fritte die mit shelly absolut nicht will...

[eierfeile]

@da_Woody das komische ist ja mit shelly klappt alles. nur werden die daten dann halt nicht mehr in iobroker übertragen. aber muss jetzt wohl ein neuer repeater her oder umstieg auf mqtt.
Trotzdem danke für eure Hilfe!

[Stuebi]

@eierfeile , das liegt an dem CoAP Protokoll. Die Shelly Cloud arbeitet http , daher funktioniert dieses.
Wenn Du die Shelly Cloud nicht nutzt, stellst Du die Shellys und den Shelly Adapter auf MQTT um. Dann geht es auch mit den Plug S. Du erreichst ja alle Shellys mit Ping.
Ich habe den Shelly Adapter auch im MQTT Modus laufen. Die Shelly Cloud nutze ich nicht. Alexa und Apple Homekit geht auch mit dem IoT und Yahaka Adapter.

[Rocko84]

Hallo zusammen, ich beobachte momentan, dass alle meine dw und dw2 mit der fw 1.8.2 ihre tilt Kalibrierung nach ein paar Öffnungs und Schließungszyklen verlieren und keinen Winkel mehr anzeigen. Eine rekalibrierung wiederholt nur das Problem. Hat zwar nichts mit dem Adapter zutun, aber wollte das nur mal los werden. Ticket ist geschrieben. Hat jemand ähnliche Probleme?

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

Nachtrag:
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.

[harrym]

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 ein Problem und werden nicht bzw. falsch dargestellt.

[jolic]

@harrym: Danke, hatte das Problem auch gestern mit meinem Shelly1 Relais für ein Toröffner. Habe den Timer Auto Off von 1 auf 2 Sekunden setzen müssen.

[da_Woody]

@jolic ist anscheinend / leider nicht wirklich genug aus dem shellyforum kommuniziert worden. da wurde schon vor eineinhalb jahren die empfehlung von min 2sec gegeben. war damals mein erster shelly und seither 0 probleme.
inzwischen sinds 70... ;)

[jolic]

@da_Woody: Ja gut zu wissen. Vor der Firmware 1.8 hatte das bei mir mit einer Sekunde ohne Probleme funktioniert (habe die Dinger seit März). Nutze allerdings nur 7 Shellys, alles andere rennt per zwave.

[Kueppert]

ich nutze aktuell nur 1 Shelly, wollte ich mal ausprobieren. Ansonsten hab ich schon alles gehabt...HM, HM-IP, Zigbee-devices, Z-Wave hatte ich auch. Z-Wave bin ich wieder von weg, weil mir die Geräte zu teuer waren.

[Stuebi]

@Kueppert , ich habe viele Shellys 1, 1PM, 2 und 2.5 im Einsatz, aber halte nichts von WLAN betriebenen Geräten mit Batterie oder Akku. Die Laufzeit der Batterien / Akkus ist zu kurz und der Wakeup Prozess der WLAN Geräte ist einfach zu lang. ich möchte ja nicht erst 3-5 sek wissen ob die tür offen ist. manchmal klappt der wakeup prozess auch überhaupt nicht.

[Strobelix]

Könnt ihr die neuen Endpunkte für Dimmer einbauen?
MQTT/REST
dim=up/down/stop/cycle

Danke

[harrym]

@Strobelix erstellst du bitte ein Issue auf GIT

[jolic]

Hi, seit Shelly Firmware 1.8.3 funktioniert bei mir wieder Timer Auto Off 1 Sekunde :+1: