NEWS
[Aufruf] Test Shelly Adapter
-
@Stuebi sagte in [Aufruf] Test Shelly Adapter:
@maniac , du findest die die % Angabe unter dem Datenpunkt shutter und dann Position.
Ich selber habe aber keine Rollläden in weiterzuhelfen.
Da habe ich ja geschaut. War/Ist nicht vorhanden der Punkt.
Im Moment laeuft es ja eh nicht :)
-
@Stuebi sagte in [Aufruf] Test Shelly Adapter:
@maniac , hattest du den Namen der Shellys angepasst?
Ja, aber bei allen. Es lief ja auch "immer".
Habe jetzt V3.0.1 installiert. Jetzt laeuft der Adapter wieder durch.
Aber keine Shutter %
Gruß Frank…
-
@Stuebi sagte in [Aufruf] Test Shelly Adapter:
@maniac , hattest du den Namen der Shellys angepasst?
Ja, aber bei allen. Es lief ja auch "immer".
Habe jetzt V3.0.1 installiert. Jetzt laeuft der Adapter wieder durch.
Aber keine Shutter % -
Hallo,
ich nutze folgende Konfig:
Raspberry3
iobroker - Version 3.6.2?
Shelly Adapter - Version 3.0.6
Shelly PlugS - Firmware 20190711-084501/v1.5.0-hotfix4@3b4f7414Zur Zeit sind zwei PlugS im Einsatz (PlugA und PlugB). Folgendes Script nutze ich:
on({id: "shelly.0.SHPLG-S#7AE7B6#1.Relay0.Power"/*Power*/, change: "ne", ack: true}, function (obj) { var value = obj.state.val; var oldValue = obj.oldState.val; if (getState("shelly.0.SHPLG-S#7AE7B6#1.Relay0.Power").val > 20) { setState("shelly.0.SHPLG-S#7ADFCD#1.Relay0.Switch"/*Switch*/, true); } if (getState("shelly.0.SHPLG-S#7AE7B6#1.Relay0.Power").val < 50) { setState("shelly.0.SHPLG-S#7ADFCD#1.Relay0.Switch"/*Switch*/, false); } });Das Script habe ich mit Blockly erstellt.
Ich realisiere damit eine Master/Slave Funktion. Wenn der Fernseher angeht (an PlugA), soll PlugB eingeschaltet werden.
Das ganze funktionierte zuerst auch gut. Nach ein paar Tagen ist mir aufgefallen, das PlugB nicht eingeschaltet wurde. Per Shelly App geht es. Darin habe ich die Master/Slave Funktion auch mal nachgebaut und die läuft dort stabil und fehlerfrei.
Gerade hat die Funktion per ioBroker mal wieder nicht funktioniert, im Log sieht man auch nicht, das etwas getriggert wurde. Normalerweise geht es wieder, wenn der Adapter neugestartet wird. Aus diesem Grund wird der Adapter nun einmal in der Nacht neugestartet.
Angesteuert werden die PlugS per COAP.
Im Webinterface der PlugS ist folgende Option nicht aktiviert:Enable action execution via CoAP (CoIOT) protocol
Muss das vielleicht gemacht werden? Wenn der Adapter neugestartet wird, finde ich folgenden Eintrag im Lof-File:
error: host.iobroker instance system.adapter.shelly.0 terminated with code 156 ()
Danach sehe ich, das ein Adapter (PlugA) gefunden und verbunden wird. Der zweite Adapter (PlugB) taucht im Log nicht auf. Das erklärt, warum er nicht angesteuert wird. Aber wieso erkennt der Adapter den PlugB nicht?
Wie kann ich am besten vorgehen um das ganze stabil zum laufen zu bekommen? Per Shelly App sind beide PlugS immer steuerbar.mfg
srkonusUpdate: Beide Adapter sind in der Sektion "Objekte" als online aufgeführt, das Script wird aber trotzdem anscheinen nicht ausgeführt. Die nachgebaute Funktion per Shelly App funktioniert tadellos
-
Hallo,
ich nutze folgende Konfig:
Raspberry3
iobroker - Version 3.6.2?
Shelly Adapter - Version 3.0.6
Shelly PlugS - Firmware 20190711-084501/v1.5.0-hotfix4@3b4f7414Zur Zeit sind zwei PlugS im Einsatz (PlugA und PlugB). Folgendes Script nutze ich:
on({id: "shelly.0.SHPLG-S#7AE7B6#1.Relay0.Power"/*Power*/, change: "ne", ack: true}, function (obj) { var value = obj.state.val; var oldValue = obj.oldState.val; if (getState("shelly.0.SHPLG-S#7AE7B6#1.Relay0.Power").val > 20) { setState("shelly.0.SHPLG-S#7ADFCD#1.Relay0.Switch"/*Switch*/, true); } if (getState("shelly.0.SHPLG-S#7AE7B6#1.Relay0.Power").val < 50) { setState("shelly.0.SHPLG-S#7ADFCD#1.Relay0.Switch"/*Switch*/, false); } });Das Script habe ich mit Blockly erstellt.
Ich realisiere damit eine Master/Slave Funktion. Wenn der Fernseher angeht (an PlugA), soll PlugB eingeschaltet werden.
Das ganze funktionierte zuerst auch gut. Nach ein paar Tagen ist mir aufgefallen, das PlugB nicht eingeschaltet wurde. Per Shelly App geht es. Darin habe ich die Master/Slave Funktion auch mal nachgebaut und die läuft dort stabil und fehlerfrei.
Gerade hat die Funktion per ioBroker mal wieder nicht funktioniert, im Log sieht man auch nicht, das etwas getriggert wurde. Normalerweise geht es wieder, wenn der Adapter neugestartet wird. Aus diesem Grund wird der Adapter nun einmal in der Nacht neugestartet.
Angesteuert werden die PlugS per COAP.
Im Webinterface der PlugS ist folgende Option nicht aktiviert:Enable action execution via CoAP (CoIOT) protocol
Muss das vielleicht gemacht werden? Wenn der Adapter neugestartet wird, finde ich folgenden Eintrag im Lof-File:
error: host.iobroker instance system.adapter.shelly.0 terminated with code 156 ()
Danach sehe ich, das ein Adapter (PlugA) gefunden und verbunden wird. Der zweite Adapter (PlugB) taucht im Log nicht auf. Das erklärt, warum er nicht angesteuert wird. Aber wieso erkennt der Adapter den PlugB nicht?
Wie kann ich am besten vorgehen um das ganze stabil zum laufen zu bekommen? Per Shelly App sind beide PlugS immer steuerbar.mfg
srkonusUpdate: Beide Adapter sind in der Sektion "Objekte" als online aufgeführt, das Script wird aber trotzdem anscheinen nicht ausgeführt. Die nachgebaute Funktion per Shelly App funktioniert tadellos
@srkonus , kannst du einmal schauen ob Power Werte in ioBroker für den Shelly Plug S noch angepasst werden, sobald Dein Blocky nicht mehr geht.
Leider werden die Daten zu Power per CoAP vom Shelly nicht mitgeliefert. Daher hole ich mir die Power Werte alle paar Sekunden per http Abfrage vom Shelly. Dieser Prozess läuft in einer Endlosschleife. Vielleicht wird die Schleife irgendwann nicht mehr durchlaufen. Das muss ich mir einmal genauer anschauen und testen -
Strange... Jetzt den Adapter wieder auf 3.0.6 geupdatet und er laeuft stabil wieder.
Jetzt können wir wieder das Shutter Problem angehen :grinning:
@maniac sagte in [Aufruf] Test Shelly Adapter:
Strange... Jetzt den Adapter wieder auf 3.0.6 geupdatet und er laeuft stabil wieder.
Jetzt können wir wieder das Shutter Problem angehen :grinning:
Kommando zurück :(
Der Adapter war zwar grün, ich konnte aber nix schalten. Hab ich erst gesehen, als ich nach Hause kam.
Mittlerweile ist es so, dass der Adapter wieder hin und her springt.
Log:
shelly.0 2019-07-18 22:05:30.132 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:05:30.132 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ... shelly.0 2019-07-18 22:05:30.092 info Error on status check for shelly.0.SHSW-1#1D9450#1 with IP 192.168.223.142, consider offline ... shelly.0 2019-07-18 22:05:30.071 info Error on status check for shelly.0.SHSW-1#1D90CC#1 with IP 192.168.223.143, consider offline ... shelly.0 2019-07-18 22:05:29.914 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.12.0 shelly.0 2019-07-18 22:04:59.637 warn Exception: Error: "name" argument must be a string shelly.0 2019-07-18 22:04:59.637 error Error: "name" argument must be a string at Resolver.getHostByAddr [as reverse] (dns.js:238:13) at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7) at shelly. shelly.0 2019-07-18 22:04:59.637 error uncaught exception: "name" argument must be a string shelly.0 2019-07-18 22:04:53.529 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:04:53.528 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ... shelly.0 2019-07-18 22:04:53.499 info Error on status check for shelly.0.SHSW-1#1D9450#1 with IP 192.168.223.142, consider offline ... shelly.0 2019-07-18 22:04:53.482 info Error on status check for shelly.0.SHSW-1#1D90CC#1 with IP 192.168.223.143, consider offline ... shelly.0 2019-07-18 22:04:53.359 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.12.0 shelly.0 2019-07-18 22:04:23.053 warn Exception: Error: "name" argument must be a string shelly.0 2019-07-18 22:04:23.053 error Error: "name" argument must be a string at Resolver.getHostByAddr [as reverse] (dns.js:238:13) at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7) at shelly. shelly.0 2019-07-18 22:04:23.053 error uncaught exception: "name" argument must be a string shelly.0 2019-07-18 22:04:15.041 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:04:15.040 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ...Ich habe jetzt das Backup von letzter Woche! eingespielt. Für ALLE Systeme(Win2012 Server, DNS, Unifi, IOBroker, Firewall)
Trotzdem funktioniert es nicht?! Ich habe absolut keine Idee mehr. :(
Die einzige Änderung dürfte jetzt der neue Shelly sein. Wobei ich den auch ausschliessen möchte, da ich ihn auch schon in ein anderes WLAN gesetzt hatte.
Ich muss vielleicht noch sagen, dass die Shellys in einem VLAN laufen, der Adapter auf einem Slave IOBroker im gleichen VLAN.
Funktionierte bisher einwandfrei.
Seitdem ich den neuen Shelly drin habe treten die Probleme auf.Jemand noch eine Idee?
-
@srkonus , kannst du einmal schauen ob Power Werte in ioBroker für den Shelly Plug S noch angepasst werden, sobald Dein Blocky nicht mehr geht.
Leider werden die Daten zu Power per CoAP vom Shelly nicht mitgeliefert. Daher hole ich mir die Power Werte alle paar Sekunden per http Abfrage vom Shelly. Dieser Prozess läuft in einer Endlosschleife. Vielleicht wird die Schleife irgendwann nicht mehr durchlaufen. Das muss ich mir einmal genauer anschauen und testen -
@maniac sagte in [Aufruf] Test Shelly Adapter:
Strange... Jetzt den Adapter wieder auf 3.0.6 geupdatet und er laeuft stabil wieder.
Jetzt können wir wieder das Shutter Problem angehen :grinning:
Kommando zurück :(
Der Adapter war zwar grün, ich konnte aber nix schalten. Hab ich erst gesehen, als ich nach Hause kam.
Mittlerweile ist es so, dass der Adapter wieder hin und her springt.
Log:
shelly.0 2019-07-18 22:05:30.132 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:05:30.132 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ... shelly.0 2019-07-18 22:05:30.092 info Error on status check for shelly.0.SHSW-1#1D9450#1 with IP 192.168.223.142, consider offline ... shelly.0 2019-07-18 22:05:30.071 info Error on status check for shelly.0.SHSW-1#1D90CC#1 with IP 192.168.223.143, consider offline ... shelly.0 2019-07-18 22:05:29.914 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.12.0 shelly.0 2019-07-18 22:04:59.637 warn Exception: Error: "name" argument must be a string shelly.0 2019-07-18 22:04:59.637 error Error: "name" argument must be a string at Resolver.getHostByAddr [as reverse] (dns.js:238:13) at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7) at shelly. shelly.0 2019-07-18 22:04:59.637 error uncaught exception: "name" argument must be a string shelly.0 2019-07-18 22:04:53.529 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:04:53.528 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ... shelly.0 2019-07-18 22:04:53.499 info Error on status check for shelly.0.SHSW-1#1D9450#1 with IP 192.168.223.142, consider offline ... shelly.0 2019-07-18 22:04:53.482 info Error on status check for shelly.0.SHSW-1#1D90CC#1 with IP 192.168.223.143, consider offline ... shelly.0 2019-07-18 22:04:53.359 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.12.0 shelly.0 2019-07-18 22:04:23.053 warn Exception: Error: "name" argument must be a string shelly.0 2019-07-18 22:04:23.053 error Error: "name" argument must be a string at Resolver.getHostByAddr [as reverse] (dns.js:238:13) at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7) at shelly. shelly.0 2019-07-18 22:04:23.053 error uncaught exception: "name" argument must be a string shelly.0 2019-07-18 22:04:15.041 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:04:15.040 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ...Ich habe jetzt das Backup von letzter Woche! eingespielt. Für ALLE Systeme(Win2012 Server, DNS, Unifi, IOBroker, Firewall)
Trotzdem funktioniert es nicht?! Ich habe absolut keine Idee mehr. :(
Die einzige Änderung dürfte jetzt der neue Shelly sein. Wobei ich den auch ausschliessen möchte, da ich ihn auch schon in ein anderes WLAN gesetzt hatte.
Ich muss vielleicht noch sagen, dass die Shellys in einem VLAN laufen, der Adapter auf einem Slave IOBroker im gleichen VLAN.
Funktionierte bisher einwandfrei.
Seitdem ich den neuen Shelly drin habe treten die Probleme auf.Jemand noch eine Idee?
@maniac sagte in [Aufruf] Test Shelly Adapter:
@maniac sagte in [Aufruf] Test Shelly Adapter:
Strange... Jetzt den Adapter wieder auf 3.0.6 geupdatet und er laeuft stabil wieder.
Jetzt können wir wieder das Shutter Problem angehen :grinning:
Kommando zurück :(
Der Adapter war zwar grün, ich konnte aber nix schalten. Hab ich erst gesehen, als ich nach Hause kam.
Mittlerweile ist es so, dass der Adapter wieder hin und her springt.
Log:
shelly.0 2019-07-18 22:05:30.132 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:05:30.132 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ... shelly.0 2019-07-18 22:05:30.092 info Error on status check for shelly.0.SHSW-1#1D9450#1 with IP 192.168.223.142, consider offline ... shelly.0 2019-07-18 22:05:30.071 info Error on status check for shelly.0.SHSW-1#1D90CC#1 with IP 192.168.223.143, consider offline ... shelly.0 2019-07-18 22:05:29.914 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.12.0 shelly.0 2019-07-18 22:04:59.637 warn Exception: Error: "name" argument must be a string shelly.0 2019-07-18 22:04:59.637 error Error: "name" argument must be a string at Resolver.getHostByAddr [as reverse] (dns.js:238:13) at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7) at shelly. shelly.0 2019-07-18 22:04:59.637 error uncaught exception: "name" argument must be a string shelly.0 2019-07-18 22:04:53.529 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:04:53.528 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ... shelly.0 2019-07-18 22:04:53.499 info Error on status check for shelly.0.SHSW-1#1D9450#1 with IP 192.168.223.142, consider offline ... shelly.0 2019-07-18 22:04:53.482 info Error on status check for shelly.0.SHSW-1#1D90CC#1 with IP 192.168.223.143, consider offline ... shelly.0 2019-07-18 22:04:53.359 info starting. Version 1.0.0 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.12.0 shelly.0 2019-07-18 22:04:23.053 warn Exception: Error: "name" argument must be a string shelly.0 2019-07-18 22:04:23.053 error Error: "name" argument must be a string at Resolver.getHostByAddr [as reverse] (dns.js:238:13) at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7) at shelly. shelly.0 2019-07-18 22:04:23.053 error uncaught exception: "name" argument must be a string shelly.0 2019-07-18 22:04:15.041 info Listening for Shelly packets in the network shelly.0 2019-07-18 22:04:15.040 info Error on status check for shelly.0.SHSW-1#500637#1 with IP 192.168.223.141, consider offline ...Ich habe jetzt das Backup von letzter Woche! eingespielt. Für ALLE Systeme(Win2012 Server, DNS, Unifi, IOBroker, Firewall)
Trotzdem funktioniert es nicht?! Ich habe absolut keine Idee mehr. :(
Die einzige Änderung dürfte jetzt der neue Shelly sein. Wobei ich den auch ausschliessen möchte, da ich ihn auch schon in ein anderes WLAN gesetzt hatte.
Ich muss vielleicht noch sagen, dass die Shellys in einem VLAN laufen, der Adapter auf einem Slave IOBroker im gleichen VLAN.
Funktionierte bisher einwandfrei.
Seitdem ich den neuen Shelly drin habe treten die Probleme auf.Jemand noch eine Idee?
So, nach einer nacht Schlafen kam mir dann doch noch eine Idee.
Ich schreib das, damit jemand (oder ich ) mit ähnlichen Problemen es findet :)Ich hatte/habe ja Multihost laufen. Nachdem auch ein Einspielen eines kompletten Backups nichts geholfen hat, habe ich nochmal den Adapter komplett gelöscht und dann die Multihost verbindung aufgehoben.
Auf dem Slave war dann noch die V1.0.0 vom Adapter installiert. Diesen habe ich dann auch komplett gelöscht. Da muss wohl irgendwas beim hin und her installieren über geblieben sein.
Danach neu installiert und er lief und hat die Shellys gefunden. Auch gleich die Shutterposition.Adapter wieder gelöscht, Multihost aufgesetzt, Adapter installiert und nun scheint es zu funktionieren.
Kann es zwar noch nicht sehen, da ich nicht zuhause bin, sieht aber bisher wieder gut aus. -
Neues Update.
Grundsätzlich läuft der Adapter wieder. Allerdings startet der Adapter alle 5min neu, bzw. stürzt ab und startet dann wieder.
Siehe Log. Das passiert alle 5min.
Version hab ich jetzt die 3.0.6 laufen.Eine Idee?
shelly.0 2019-07-19 14:06:14.446 info Listening for Shelly packets in the network shelly.0 2019-07-19 14:06:14.446 info Stating Shelly adapter in CoAP modus. shelly.0 2019-07-19 14:06:14.215 info starting. Version 3.0.6 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.16.0 shelly.0 2019-07-19 14:05:43.801 info Closing Adapter shelly.0 2019-07-19 14:05:43.801 error Error: No reply in 247s at Timeout._onTimeout (/opt/iobroker/node_modules/coap/lib/retry_send.js:74:16) at ontimeout (timers.js:498:11) at tryOnTimeout (timers.js:323:5) at Timer.listO shelly.0 2019-07-19 14:05:43.801 error uncaught exception: No reply in 247s shelly.0 2019-07-19 14:05:43.369 debug Set state SHSW-1#1D9450#1.uptime, Value: "222T01:09:19" for 192.168.223.142 (shelly1 / shelly1-1D9450 / SHSW-1#1D9450#1) shelly.0 2019-07-19 14:05:43.319 debug CoAP data ignored: {"3332":"SHSW-1#1D90CC#1","3412":38400,"3420":512,"Uri-Path":"cit/s"} / {"G":[[0,112,1]]} shelly.0 2019-07-19 14:05:43.011 debug Set state SHSW-1#1D90CC#1.uptime, Value: "02:27:25" for 192.168.223.143 (shelly1 / shelly1-1D90CC / SHSW-1#1D90CC#1) shelly.0 2019-07-19 14:05:42.777 debug Set state SHSW-1#500637#1.uptime, Value: "222T22:52:24" for 192.168.223.141 (shelly1 / shelly1-500637 / SHSW-1#500637#1) shelly.0 2019-07-19 14:05:42.431 debug CoAP data ignored: {"3332":"SHSW-1#1D9450#1","3412":38400,"3420":32005,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]} shelly.0 2019-07-19 14:05:42.425 debug CoAP data ignored: {"3332":"SHSW-1#50014E#1","3412":38400,"3420":7936,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]} shelly.0 2019-07-19 14:05:41.462 debug CoAP data ignored: {"3332":"SHSW-1#500637#1","3412":38400,"3420":45829,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]} shelly.0 2019-07-19 14:05:41.270 debug CoAP data ignored: {"3332":"SHSW-25#693077#1","3412":38400,"3420":49152,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,113,100],[0,111,0.000000],[0,121,0.000000]]} shelly.0 2019-07-19 14:05:41.233 debug Set state SHSW-1#50014E#1.uptime, Value: "8T20:19:31" for 192.168.223.140 (shelly1 / shelly1-50014E / SHSW-1#50014E#1) shelly.0 2019-07-19 14:05:40.715 debug Set state SHSW-25#693077#1.uptime, Value: "1T04:47:34" for 192.168.223.144 (shellyswitch25 / shellyswitch25-693077 / SHSW-25Gruß Frank…
-
@Stuebi Hi,
vielen Dank für deine Antwort. Ich werde es die Tage beobachten und dir schreiben. Ist MQTT dann vielleicht die bessere Wahl?
@srkonus sagte in [Aufruf] Test Shelly Adapter:
@Stuebi Hi,
vielen Dank für deine Antwort. Ich werde es die Tage beobachten und dir schreiben. Ist MQTT dann vielleicht die bessere Wahl?
Also, auch nach 2 Tagen ohne Unterbrechung werden regelmässig die Werte bei mir angezeigt. Ich kann keine Auffälligkeit entdecken. Wie sieht es bei Dir aus?
-
Neues Update.
Grundsätzlich läuft der Adapter wieder. Allerdings startet der Adapter alle 5min neu, bzw. stürzt ab und startet dann wieder.
Siehe Log. Das passiert alle 5min.
Version hab ich jetzt die 3.0.6 laufen.Eine Idee?
shelly.0 2019-07-19 14:06:14.446 info Listening for Shelly packets in the network shelly.0 2019-07-19 14:06:14.446 info Stating Shelly adapter in CoAP modus. shelly.0 2019-07-19 14:06:14.215 info starting. Version 3.0.6 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.16.0 shelly.0 2019-07-19 14:05:43.801 info Closing Adapter shelly.0 2019-07-19 14:05:43.801 error Error: No reply in 247s at Timeout._onTimeout (/opt/iobroker/node_modules/coap/lib/retry_send.js:74:16) at ontimeout (timers.js:498:11) at tryOnTimeout (timers.js:323:5) at Timer.listO shelly.0 2019-07-19 14:05:43.801 error uncaught exception: No reply in 247s shelly.0 2019-07-19 14:05:43.369 debug Set state SHSW-1#1D9450#1.uptime, Value: "222T01:09:19" for 192.168.223.142 (shelly1 / shelly1-1D9450 / SHSW-1#1D9450#1) shelly.0 2019-07-19 14:05:43.319 debug CoAP data ignored: {"3332":"SHSW-1#1D90CC#1","3412":38400,"3420":512,"Uri-Path":"cit/s"} / {"G":[[0,112,1]]} shelly.0 2019-07-19 14:05:43.011 debug Set state SHSW-1#1D90CC#1.uptime, Value: "02:27:25" for 192.168.223.143 (shelly1 / shelly1-1D90CC / SHSW-1#1D90CC#1) shelly.0 2019-07-19 14:05:42.777 debug Set state SHSW-1#500637#1.uptime, Value: "222T22:52:24" for 192.168.223.141 (shelly1 / shelly1-500637 / SHSW-1#500637#1) shelly.0 2019-07-19 14:05:42.431 debug CoAP data ignored: {"3332":"SHSW-1#1D9450#1","3412":38400,"3420":32005,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]} shelly.0 2019-07-19 14:05:42.425 debug CoAP data ignored: {"3332":"SHSW-1#50014E#1","3412":38400,"3420":7936,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]} shelly.0 2019-07-19 14:05:41.462 debug CoAP data ignored: {"3332":"SHSW-1#500637#1","3412":38400,"3420":45829,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]} shelly.0 2019-07-19 14:05:41.270 debug CoAP data ignored: {"3332":"SHSW-25#693077#1","3412":38400,"3420":49152,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,113,100],[0,111,0.000000],[0,121,0.000000]]} shelly.0 2019-07-19 14:05:41.233 debug Set state SHSW-1#50014E#1.uptime, Value: "8T20:19:31" for 192.168.223.140 (shelly1 / shelly1-50014E / SHSW-1#50014E#1) shelly.0 2019-07-19 14:05:40.715 debug Set state SHSW-25#693077#1.uptime, Value: "1T04:47:34" for 192.168.223.144 (shellyswitch25 / shellyswitch25-693077 / SHSW-25 -
@maniac , ich habe in die Version 3.0.7 einen Timeout für die http Requests mit eingebaut. Ich hoffe, dass behebt den Fehler.
Es gibt auch ein Issue zu dem Thema:
https://github.com/schmupu/ioBroker.shelly/issues/71@Stuebi ich habe jetzt für ein paar Tage auch das Problem gehabt, dass der Adapter alle 4 Minuten abstürzt und neu startet: uncaught exception: No reply in 247s at Timeout... usw.
Ich verwendete die Version 3.0.5 und habe ein Update auf 3.0.7 gemacht weil ich gehofft habe, dass die Fehlerursache dadurch behoben wird. Leider wird das eigentliche Problem nicht behoben - lediglich die "uncaught exception" wird nun behandelt, und zwar insofern, dass der Adapter sich 4 Minuten nach Start selbst beendet, aber nicht mehr von alleine neustartet. Auf diese Weise ist der Shelly-Adapter unter dieser Fehlersituation unbrauchbar geworden, da ich als Anwender ihn von nun an alle 4 Minuten händisch starten muss.
Ergo habe ich wieder auf 3.0.5 downgegradet - jetzt stürzt er zwar nach wie vor alle 4 Minuten ab, startet aber wenigstens von alleine neu.
Nachdem ich schon sehr viel im iobroker und im Adapter erfolglos probiert hatte, habe ich nun in letzter Instanz aus reiner Hilflosigkeit den heimischen Switch stromlos gemacht und 30 Sek. später wieder gestartet (ein D-Link 8-Port Gigabit PoE-Switch). Und siehe da: auf einmal sind alle Shellys im Netzwerk wieder funktionstüchtig und auch iobroker kann sie wieder steuern. Der Adapter stürzt nun auch nicht mehr ab.
Was meinen Switch angeht vermute ich einen Überlauf der Routing- oder ARP-Tabelle oder einen simplen Software-Absturz. Per TCP/IP und http-Protokoll waren alle Shellys die ganze Zeit (z. B. über den Webbrowser) steuerbar, aber anscheinend gingen von einigen Shellys keine Multicast UDP-Pakete mehr über den Äther sodass Coap versagte.
Was den Shelly-Adapter angeht muss aber etwas an der Fehlertoleranz geschehen. Wenn ein Shelly plötzlich im Netzwerk nicht mehr erreichbar ist, sollte nicht gleich der ganze Adapter den Dienst quittieren.
Nachdem der Switch jetzt rebootet ist und alle Shellys wieder laufen, wird die nachträgliche Fehlersuche natürlich schwieriger, trotzdem biete ich mich gern für's Debugging an :)
Schöne Grüße
Thomas -
@Stuebi ich habe jetzt für ein paar Tage auch das Problem gehabt, dass der Adapter alle 4 Minuten abstürzt und neu startet: uncaught exception: No reply in 247s at Timeout... usw.
Ich verwendete die Version 3.0.5 und habe ein Update auf 3.0.7 gemacht weil ich gehofft habe, dass die Fehlerursache dadurch behoben wird. Leider wird das eigentliche Problem nicht behoben - lediglich die "uncaught exception" wird nun behandelt, und zwar insofern, dass der Adapter sich 4 Minuten nach Start selbst beendet, aber nicht mehr von alleine neustartet. Auf diese Weise ist der Shelly-Adapter unter dieser Fehlersituation unbrauchbar geworden, da ich als Anwender ihn von nun an alle 4 Minuten händisch starten muss.
Ergo habe ich wieder auf 3.0.5 downgegradet - jetzt stürzt er zwar nach wie vor alle 4 Minuten ab, startet aber wenigstens von alleine neu.
Nachdem ich schon sehr viel im iobroker und im Adapter erfolglos probiert hatte, habe ich nun in letzter Instanz aus reiner Hilflosigkeit den heimischen Switch stromlos gemacht und 30 Sek. später wieder gestartet (ein D-Link 8-Port Gigabit PoE-Switch). Und siehe da: auf einmal sind alle Shellys im Netzwerk wieder funktionstüchtig und auch iobroker kann sie wieder steuern. Der Adapter stürzt nun auch nicht mehr ab.
Was meinen Switch angeht vermute ich einen Überlauf der Routing- oder ARP-Tabelle oder einen simplen Software-Absturz. Per TCP/IP und http-Protokoll waren alle Shellys die ganze Zeit (z. B. über den Webbrowser) steuerbar, aber anscheinend gingen von einigen Shellys keine Multicast UDP-Pakete mehr über den Äther sodass Coap versagte.
Was den Shelly-Adapter angeht muss aber etwas an der Fehlertoleranz geschehen. Wenn ein Shelly plötzlich im Netzwerk nicht mehr erreichbar ist, sollte nicht gleich der ganze Adapter den Dienst quittieren.
Nachdem der Switch jetzt rebootet ist und alle Shellys wieder laufen, wird die nachträgliche Fehlersuche natürlich schwieriger, trotzdem biete ich mich gern für's Debugging an :)
Schöne Grüße
Thomas@DreamForce , danke für die genaue Analyse. Zu dem Thema gibt es ein Issue (https://github.com/schmupu/ioBroker.shelly/issues/71). Leider bin ich bei der Lösung des Fehlers auf andere Libs angewiesen. Daher muss ich warten, bis dort der Fehler behoben wird.
In der 3.0.7 der Shelly Adapter startet der Shelly nicht neu. Das kann ich aber in Version 3.0.8 wieder einbauen. -
@DreamForce , danke für die genaue Analyse. Zu dem Thema gibt es ein Issue (https://github.com/schmupu/ioBroker.shelly/issues/71). Leider bin ich bei der Lösung des Fehlers auf andere Libs angewiesen. Daher muss ich warten, bis dort der Fehler behoben wird.
In der 3.0.7 der Shelly Adapter startet der Shelly nicht neu. Das kann ich aber in Version 3.0.8 wieder einbauen.@Stuebi weiß Du denn, woher der Timeout genau kommt? Also welcher Request könnte ins Leere laufen? Mit dieser Information könnte ich vielleicht besser nachvollziehen, warum hier im Netz einige Shellys versagten und ggf. kann ich die Situation ja dann sogar nochmal nachstellen.
-
@Stuebi weiß Du denn, woher der Timeout genau kommt? Also welcher Request könnte ins Leere laufen? Mit dieser Information könnte ich vielleicht besser nachvollziehen, warum hier im Netz einige Shellys versagten und ggf. kann ich die Situation ja dann sogar nochmal nachstellen.
@DreamForce , schaue Dir einmal den Issue https://github.com/schmupu/ioBroker.shelly/issues/71 an. Dort hat @foxriver76 netterweise das Logfile zur Verfügung gestellt. Es kommt aus der CoAP Lib (https://github.com/mcollina/node-coap).
-
Ich habe gestern Abend auf die 3.0.5 geupdatet und alle shelly1 auf die Firmware 1.5 gebracht. Seit dem geht nichts mehr. Kein einziger shelly lässt sich noch schalten.
Auf dem WebIF der shelly s lassen Sie sich schalten. In der shelly App auch. Im WebIF habe ich auch schon testweise sie Coap Funktion aktiviert. Hilft aber leider auch nicht.
Warum geht es in der neuen Version nicht mehr über iobroker? -
Ich habe gestern Abend auf die 3.0.5 geupdatet und alle shelly1 auf die Firmware 1.5 gebracht. Seit dem geht nichts mehr. Kein einziger shelly lässt sich noch schalten.
Auf dem WebIF der shelly s lassen Sie sich schalten. In der shelly App auch. Im WebIF habe ich auch schon testweise sie Coap Funktion aktiviert. Hilft aber leider auch nicht.
Warum geht es in der neuen Version nicht mehr über iobroker?@Sascha-Tiedemann , um dir diese Frage zu beantworten, müsste ich wissen von welcher Shelly Version du kommst, ob du MQTT oder CoAP nutzt und ich benötige das Logfile mit den Fehlern, falls es welche gibt.
-
ich meine, dass ich von Version 1.05 komme.
Wo kann ich das jetzt noch sehen?Ich nutze CoAP und http im shelly Adapter
Ich habe iobroker mal neu gestartet. Das ist der Log zum Suchbegriff "shelly"
host.WIN2016 2019-07-23 22:20:21.421 info Restart adapter system.adapter.shelly.0 because enabled host.WIN2016 2019-07-23 22:20:21.421 error instance system.adapter.shelly.0 terminated with code 7 (Adapter already running) host.WIN2016 2019-07-23 22:20:20.641 info instance system.adapter.shelly.0 started with pid 2298 host.WIN2016 2019-07-23 22:19:50.615 info Restart adapter system.adapter.shelly.0 because enabled host.WIN2016 2019-07-23 22:19:50.614 error instance system.adapter.shelly.0 terminated with code 7 (Adapter already running) host.WIN2016 2019-07-23 22:19:49.893 info instance system.adapter.shelly.0 started with pid 1816 host.WIN2016 2019-07-23 22:19:19.870 info Restart adapter system.adapter.shelly.0 because enabled host.WIN2016 2019-07-23 22:19:19.870 error instance system.adapter.shelly.0 terminated with code 7 (Adapter already running) host.WIN2016 2019-07-23 22:19:19.170 info instance system.adapter.shelly.0 started with pid 1289 host.WIN2016 2019-07-23 22:18:49.142 info Restart adapter system.adapter.shelly.0 because enabled host.WIN2016 2019-07-23 22:18:49.141 error instance system.adapter.shelly.0 terminated with code 7 (Adapter already running) host.WIN2016 2019-07-23 22:18:48.429 info instance system.adapter.shelly.0 started with pid 802 host.WIN2016 2019-07-23 22:18:18.402 info Restart adapter system.adapter.shelly.0 because enabled host.WIN2016 2019-07-23 22:18:18.402 error instance system.adapter.shelly.0 terminated with code 7 (Adapter already running) host.WIN2016 2019-07-23 22:18:17.669 info instance system.adapter.shelly.0 started with pid 255 host.WIN2016 2019-07-23 22:17:47.656 info Restart adapter system.adapter.shelly.0 because enabled host.WIN2016 2019-07-23 22:17:46.032 info instance system.adapter.shelly.0 started with pid 32362 history.0 2019-07-23 22:17:45.139 info enabled logging of shelly.0.SHSW-PM#E640C7#1.Power (Count=7), Alias=false history.0 2019-07-23 22:17:45.085 info enabled logging of shelly.0.SHSW-PM#E640C7#1.Power (Count=7), Alias=false shelly.0 2019-07-23 22:17:43.281 info Listening for Shelly packets in the network shelly.0 2019-07-23 22:17:43.281 info Listening for Shelly packets in the network shelly.0 2019-07-23 22:17:43.280 info Stating Shelly adapter in CoAP modus. shelly.0 2019-07-23 22:17:43.279 info Stating Shelly adapter in CoAP modus. shelly.0 2019-07-23 22:17:43.266 info starting. Version 3.0.5 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.15.1 shelly.0 2019-07-23 22:17:43.257 info starting. Version 3.0.5 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.15.1 shelly.0 2019-07-23 22:17:43.246 warn Reconnection to DB. shelly.0 2019-07-23 22:17:43.245 warn Reconnection to DB. Adapter 2019-07-23 22:17:40.481 info shelly still running Adapter 2019-07-23 22:17:39.482 info shelly still running shelly.0 2019-07-23 22:14:06.343 info Listening for Shelly packets in the network shelly.0 2019-07-23 22:14:06.284 info Stating Shelly adapter in CoAP modus. shelly.0 2019-07-23 22:14:06.276 info starting. Version 3.0.5 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.15.1 host.WIN2016 2019-07-23 22:14:05.485 info instance system.adapter.shelly.0 started with pid 30260 host.WIN2016 2019-07-23 22:14:02.962 info instance system.adapter.shelly.0 terminated with code 0 (OK) shelly.0 2019-07-23 22:14:02.948 info Closing Adapter shelly.0 2019-07-23 22:14:02.946 info Closing Adapter host.WIN2016 2019-07-23 22:14:02.945 info stopInstance system.adapter.shelly.0 killing pid 30131 host.WIN2016 2019-07-23 22:14:02.945 info stopInstance system.adapter.shelly.0 host.WIN2016 2019-07-23 22:14:02.945 info object change system.adapter.shelly.0 shelly.0 2019-07-23 22:13:44.915 info Listening for Shelly packets in the network shelly.0 2019-07-23 22:13:44.840 info Stating Shelly adapter in CoAP modus. shelly.0 2019-07-23 22:13:44.831 info starting. Version 3.0.5 in /opt/iobroker/node_modules/iobroker.shelly, node: v8.15.1 host.WIN2016 2019-07-23 22:13:44.045 info instance system.adapter.shelly.0 started with pid 30131 host.WIN2016 2019-07-23 22:13:41.523 info instance system.adapter.shelly.0 terminated with code 0 (OK) shelly.0 2019-07-23 22:13:41.514 info Closing Adapter shelly.0 2019-07-23 22:13:41.511 info Closing Adapter host.WIN2016 2019-07-23 22:13:41.510 info stopInstance system.adapter.shelly.0 killing pid 17887 host.WIN2016 2019-07-23 22:13:41.510 info stopInstance system.adapter.shelly.0 host.WIN2016 2019-07-23 22:13:41.509 info object change system.adapter.shelly.0 host.WIN2016 2019-07-23 22:17:47.656 error instance system.adapter.shelly.0 terminated with code 7 (Adapter already running) -
@DreamForce , danke für die genaue Analyse. Zu dem Thema gibt es ein Issue (https://github.com/schmupu/ioBroker.shelly/issues/71). Leider bin ich bei der Lösung des Fehlers auf andere Libs angewiesen. Daher muss ich warten, bis dort der Fehler behoben wird.
In der 3.0.7 der Shelly Adapter startet der Shelly nicht neu. Das kann ich aber in Version 3.0.8 wieder einbauen.@Stuebi sagte in [Aufruf] Test Shelly Adapter:
@DreamForce , danke für die genaue Analyse. Zu dem Thema gibt es ein Issue (https://github.com/schmupu/ioBroker.shelly/issues/71). Leider bin ich bei der Lösung des Fehlers auf andere Libs angewiesen. Daher muss ich warten, bis dort der Fehler behoben wird.
In der 3.0.7 der Shelly Adapter startet der Shelly nicht neu. Das kann ich aber in Version 3.0.8 wieder einbauen.Bei mir auch noch immer das gleiche und ähnlich wie bei @dreamforce habe ich alle Shellys stromlos gemacht, danach lief es wieder.
Wenn man nun aber weis woran es liegt, kann man ja reagieren.
Da die Shellys ja noch über das Webinterface reagieren, dachte ich mir das man die dann neu startet per http-Request?
Geht das irgendwie?
Support us
699
Online32.4k
Benutzer81.6k
Themen1.3m
Beiträge