Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[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

[harrym]

@jolic ja .. wurde ja auch dieser CoAP delay behoben Jetzt flutscht das so wie früher gg

[da_Woody]

@jolic gefühlt gehts sogar schneller als jemals zuvor, auch über die cloud...

[FredF]

Nutzt jemand RGBW2 mit Firmware 1.8 und CoAP?
Bei meinem funktioniert nun der coaptest.js Test nicht und taucht dann natürlich auch nicht bei den Objekten auf. Vor dem Update mit einer älteren Adapter Version hat der RGBW2 funktioniert.
Wenn es durch die CoAP Änderungen mit FW 1.8 am Netzwerk (Unifi AP an FB 6490 Cable FW 7.2, ioBroker auf einer Proxmox VM) liegen sollte, wie kann ich das testen bzw. welche Einstellungen wären zu überprüfen?
Bin für jeden Tipp dankbar.

[da_Woody]

@FredF jo, nutze ich 3x. keine probleme. netzwerkänderungen wären mir nicht bekannt...

[FredF]

@da_Woody
Gut das es bei dir geht. Mangels weiterer Shellys kann ich CoAP nicht testen.
lästigerweise lässt sich der RGBW2 jetzt auch nicht downgraden

Im Netz habe ich so manche Probleme wg. CoAP gelesen, die Leute haben dann aufgegeben und stiegen um auf MQTT bzw. Tasmota

Vielleicht gibt mir noch jemand einen Tipp?

[FredF]

Oh Mann... den Unifi AP neu gestartet und nun gehts

Edit: Aber nur kurzzeitig...
nach dem Neustart taucht der RGBW2 in den Objekten auf, ist aber nicht steuerbar...
Der coaptest.js tuts wieder nicht...
Nix im Netz dazu gefunden (Unifi, CoAP, Multicast)
und auf MQTT umgestellt - läuft.

[canim]

@FredF hab das selbe problem..., hab neuen Router als Switch gesteckt, seitdem funzt bei mir Coap auch nicht. Hast ne Lösung gefunden?
Das ganze läuft ,wenn ich den Adapter neustartet, funktioniert das ganze fast 2min,Daten werden aktualisiert,danach wird nur Uptime und ab und zu Wlan Signal aktualisiert... aber der Energywert änder sich nicht. Wenn ich aber direkt über die ip des Shelly gehe, geht alles normal.

[FredF]

@canim sagte in Shelly Adapter 4.0 - Shelly Firmware 1.8 - Tester gesucht :

Hast ne Lösung gefunden?

Nein, hatte es aufgegeben und auf MQTT umgestellt.

[da_Woody]

@FredF ist tropsdem ein netzwerkproblem, nicht shelly, nicht adapter...

[FredF]

@da_Woody Das mag ja sein, hilft mir aber nicht weiter, wenn man das Netzwerkproblem nicht idenitifizieren kann und keiner einem diese Frage beantworten kann oder will.

@FredF sagte in Shelly Adapter 4.0 - Shelly Firmware 1.8 - Tester gesucht :

Wenn es durch die CoAP Änderungen mit FW 1.8 am Netzwerk (Unifi AP an FB 6490 Cable FW 7.2, ioBroker auf einer Proxmox VM) liegen sollte, wie kann ich das testen bzw. welche Einstellungen wären zu überprüfen?

[canim]

@FredF sehe ich genau so!

[da_Woody]

@FredF @canim da geht es nicht ums wollen, können ist das problem. deine/eure netzwerkstruktur kennt keiner, nur du/ihr.
ich hab weder eine fritte (von denen ich sowieso nichts halte), noch einen uni-ap. könntest du mir helfen wenn ich dir sage bei mir läuft ein synology-mesh mit einer nanostation und 2 renkforce? kleines beispiel:
ich hatte ein problem mit einem shelly-3em. zeigte für stunden daten an. plötzlich nicht mehr. nach neustart ging wieder für ne zeit. in der shelly-app kein problem, da cloud. selbst Dimitar von alterco/shelly konnte sich keinen reim darauf machen. irgenwann kam ich durch zufall drauf, das solange daten kommen, wie der 3em direkt am router eingeloggt war. sobald sich das ding auf den AP umgelogt hat war schicht im schacht. kontakt zu synology aufgenommen, nach termin vereinbarung dann eine remote session mit einer mandeläugigen. schwupp, fehler gefunden! sie schrieb mir dann ausfühliche anleitung wie ich das bis zum nächsten FW-update lösen kann. mühsam genug, musste die prozedur nach jedem neustart des netzwerks wieder neu gemacht werden. alles per SSH. 3 wochen später kam das FW update, einstellung gemacht, sache gefrühstückt.
ich denke das euch das problem mit netzwerken durch die geschichte bißchen klarer wird...
das es nicht am adapter, oder shelly FW liegen kann zeigt ja schon das bei fast allen kein problem herscht.
du kannst gerne den adapter auf 4.0.3 (latest) updeten, läuft bei mir seit wochen, wird aber dein problem nicht lösen.
offensichtlich werden bei euch die COAP daten nicht richtig weitergeleitet.

[SaAnMaFi]

@Stuebi said in Shelly Adapter 4.0 - Shelly Firmware 1.8 - Tester gesucht :

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.

Guten Tag sitze hier gerade mit meinem neuen Shelly Plug S und bekomme im Iobroker zwar das Gerät mit den allgemeinen Informationen angezeigt (uptime wird alle 5 sek aktualisiert) nur leider sind unter dem Verzeichnis Channel keinerlei Informationen.
Habe wie du hier beschrieben hast alle Punkte ausprobiert und sehe im Terminal auch "Traffic".

Installiert ist der Adapter 4.0.3 und der Plug S hat v1.8.3

Vielleicht kann mir ja jmd helfen.

@Stuebi said in Shelly Adapter 4.0 - Shelly Firmware 1.8 - Tester gesucht :

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.

[da_Woody]

@SaAnMaFi said in Shelly Adapter 4.0 - Shelly Firmware 1.8 - Tester gesucht :

nur leider sind unter dem Verzeichnis Channel keinerlei Informationen.

wo siehst du das? es gibt kein verzeichniss channel. nur relay0.

[canim]

@da_Woody hostname ist die Ip-Adresse