[Aufruf] Test Shelly Adapter
-
@e-s sagte in [Aufruf] Test Shelly Adapter:
@Stuebi
ich habe auch Probleme. Shutter am 2er und schalten von Licht an allen anderen funktioniert bei mir. Nur shutter am 2.5er reagiert bei mir überhaupt nicht. Angebunden über mqtt.
Im log kann ich auch bei debug nichts sehen, gibt nur setstate Eintrag, aber kein FehlerDamit ich Dich richtig verstehe, der Shelly 2 funktioniert und beim Shelly 2.5 gibt es Probleme im Shutter Modus? Wahrscheinlich mit dem Datenpunkt
shelly.0.SHSW-25#XXXXXX#1.Shutter.state?
Dieser wird laut Doku (https://shelly-api-docs.shelly.cloud/#shelly2-5-mqtt) beishellies/shellyswitch-<deviceid>/roller/0mit den Werten Close, Open, Stop gesetzt. Nur leider liefert Shelly per MQTT diese Werte nicht mehr inshellies/shellyswitch-<deviceid>/roller/0. Ich habe den Fehler an Shelly weitergegeben. -
@Stuebi
Richtig, Ich ändere bei iogo normalerweise nur die % Zahl. Komischerweise steht er jetzt nur auf 101%, obwohl er auf 0% stehen müsste. Beim normalen 2er ist alles wie vorher. -
@e-s sagte in [Aufruf] Test Shelly Adapter:
@Stuebi
Richtig, Ich ändere bei iogo normalerweise nur die % Zahl. Komischerweise steht er jetzt nur auf 101%, obwohl er auf 0% stehen müsste. Beim normalen 2er ist alles wie vorher.Shelly testet es Morgen. Habe gerade die Info erhalten.
-
Auch ich hatte nach dem Update auf 1.5.1 Probleme. Nach dem Update auf V1.5.2 habe ich gedacht, dass wieder alles in Ordnung ist.
Nun habe ich folgendes Problem mit meinen 2.5 im Shutterbetrieb:
Ich habe für meine Rolläden Blocklys geschrieben, die bei Tastendruck (Xiaomi Zigbeetaster) abfragen ob open oder close = true ist. Dann geht er auf pause, ansonsten gehts in die gewünschte Richtung. Hat bisher immer geklappt. Seit dem Update bekomme ich sie nicht mehr angehalten.
Die States sind und Waren als Button eingestellt. Wenn ich im Blocklyauf den zu steuernden Wert gehe sind alle 3 Werte (Open, Pause, Close) = "true" rot geschrieben.
Ich bin mir ziemlich sicher, dass vor dem Update als noch alles funktionierte 2 Werte false und einer true war (schwarze Schrift). Das wäre ja auch logisch.
Hat sich hier etwas geändert?
Meine der ganzen Smarthome Geschichte gegenüber sehr skeptische Frau ist sichtlich genervt
PS.: Bin mit CoAP drauf...
-
@DocGame , gebe ich an Shelly weiter.
-
@e-s sagte in [Aufruf] Test Shelly Adapter:
@Stuebi
Richtig, Ich ändere bei iogo normalerweise nur die % Zahl. Komischerweise steht er jetzt nur auf 101%, obwohl er auf 0% stehen müsste. Beim normalen 2er ist alles wie vorher.Shelly hat mich darauf hingewiesen, dass bei -1 oder 101% der Shelly nochmal kalibriert werden muss. Kannst du das bitte testen
-
Message von Shelly:
Alle die Probleme mit dem Shelly 2 zu d 2.5 im Shutter (Rollläden) Modus ab Firmware 1.5.1 bzw 1.5.2 haben, sollen diesen bitte einmal neu kallibrieren.
-
@Stuebi
Super, Jetzt geht wieder alles. -
@e-s sagte in [Aufruf] Test Shelly Adapter:
@Stuebi
Super, Jetzt geht wieder alles.dann kann ich Shelly zurückmelden, dass der Shutter Modus, d.h. Position und State (Close, open, Pause) per MQTT für den Shelly 2.5 wieder funktioniert?!
-
Heute morgen wurde die States von meinen Rollläden ohne Verzögerung erkannt und die Laufzeit korrekt berechnet.
Wenn es heute Abend auch wieder passt, scheint das delay von gestern nur eine Ausnahme gewesen zu sein. -
@Stuebi
Jupp -
Sorry das ich mich so spät melde....bin gerade erst nach hause gekommen.
Alle 3 Werte (Open, Close und Pause) sind noch auf true (in Rot). Aber wie gesagt... ich ziehe die Werte via CoAP (CoIOT) protocol.
Sonst müsste ich wie bei meinen Tasmotageräten auf MQTT umstellen. Ich fand gerade die zusätzliche App-Bedienung einen schönen Punkt vom Shelly.
Kann ja nicht viel sein, da es vorher ja ging. -
@DocGame sagte in [Aufruf] Test Shelly Adapter:
lle 3 Werte (Open, Close und Pause) sind noch auf true (in Rot). Aber wie gesagt... ich ziehe die Werte via CoAP (CoIOT) protocol.
Für den Shelly 2.5 gibt es seit ein paar Stunden die Firmware Version 1.5.3. Damit sollen die Rollladen (Shutter) Probleme im CoAP Modus behoben sein.
Funktioniert es bei Dir mit der Firmewareversion 1.5.3? -
Die 2.5'er im Shutterbetrieb lassen sich mit 1.5.3 über das Blockly wieder wie gewohnt stoppen usw.
Eine Frage noch zu den Shelly1:
weil ich einige unter Zigbeetastern (kein N) in der Dose habe war nachdem Update auf 1.5.1 alles tot.
Habe dann den Tip mit dem OTA Downgrade angewendet. Einer hat es leider nicht überlebt und ist scheinbar Tod (werde am Wochenende einen Hardwareseset versuchen). Habe an dessen einen neuen (mit Downgrade) eingebaut. Als das Update auf 1.5.2 kam habe ich ein update gemacht. Seitdem bekomme ich den nicht mehr in den Adapter. Wird einfach nicht angezeigt. In der App ist alles in Ordnung und auch CoAP ist eingeschalten. Apapter habe ich schon mehrfach neu gestartet. Ich habe gedacht, das hier ein Update auf die 1.5.3 wtwas bewirken würde. Bei den Shelly1 wird aber noch kein Update auf 1.5.3 angezeigt.
Hast du eine Idee was das sein könnte? -
@DocGame , klingt so als ob der Shelly 1 keine CoAP Nachrichten verschickt. Du kannst das Debugging für den Shelly Adapter aktivieren und schauen ob Meldungen für den Shelly 1 im Logfile erscheinen.
-
Irgendwie ignoriert er einige CoAP Daten....:
shelly.0 2019-08-24 14:06:03.768 debug CoAP data ignored: {"3332":"SHSW-1#93EAB0#1","3412":38400,"3420":1024,"Uri-Path":"cit/s"} / {"G":[[0,112,1],[0,118,0]]} shelly.0 2019-08-24 14:06:03.473 debug Set state SHSW-1#4A595C#1.uptime, Value: "1D01:01:23" for 192.168.178.33 (shelly1 / shelly1-4A595C / SHSW-1#4A595C#1) shelly.0 2019-08-24 14:06:02.985 debug CoAP data ignored: {"3332":"SHSW-25#73CC3E#1","3412":38400,"3420":11264,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,111,0.000000],[0,121,0.000000],[0,118,0],[0,128,0],[0,115,55.32],[0,116,131. shelly.0 2019-08-24 14:06:02.262 debug CoAP data ignored: {"3332":"SHSW-25#734426#1","3412":38400,"3420":15616,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,113,88],[0,111,0.000000],[0,121,0.000000],[0,118,0],[0,128,0],[0,115,53.46], shelly.0 2019-08-24 14:06:02.123 debug CoAP data ignored: {"3332":"SHSW-25#5DAFF5#1","3412":38400,"3420":768,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,111,0.000000],[0,121,0.000000],[0,118,0],[0,128,0],[0,115,52.87],[0,116,127.16 shelly.0 2019-08-24 14:06:02.069 debug Set state SHSW-1#93BEE6#1.uptime, Value: "2D22:52:45" for 192.168.178.143 (shelly1 / shelly1-93BEE6 / SHSW-1#93BEE6#1) shelly.0 2019-08-24 14:06:00.234 debug Set state SHSW-1#93EAB0#1.uptime, Value: "00:00:52" for 192.168.178.144 (shelly1 / shelly1-93EAB0 / SHSW-1#93EAB0#1) shelly.0 2019-08-24 14:06:00.084 debug Set state SHSW-25#5DAFF5#1.uptime, Value: "03:50:08" for 192.168.178.118 (shellyswitch25 / shellyswitch25-5DAFF5 / SHSW-25#5DAFF5#1) shelly.0 2019-08-24 14:05:59.919 debug CoAP data ignored: {"3332":"SHSW-1#93BEE6#1","3412":38400,"3420":2560,"Uri-Path":"cit/s"} / {"G":[[0,112,1],[0,118,1]]} shelly.0 2019-08-24 14:05:59.892 debug Set state SHSW-25#72ECFA#1.rssi, Value: -51 for 192.168.178.161 (shellyswitch25 / shellyswitch25-72ECFA / SHSW-25#72ECFA#1) shelly.0 2019-08-24 14:05:59.889 debug Set state SHSW-25#72ECFA#1.uptime, Value: "1D19:51:04" for 192.168.178.161 (shellyswitch25 / shellyswitch25-72ECFA / SHSW-25#72ECFA#1) shelly.0 2019-08-24 14:05:59.782 debug Set state SHSW-25#73CC3E#1.uptime, Value: "1D19:35:26" for 192.168.178.138 (shellyswitch25 / shellyswitch25-73CC3E / SHSW-25#73CC3E#1) shelly.0 2019-08-24 14:05:59.437 debug CoAP data ignored: {"3332":"SHSW-1#4A595C#1","3412":38400,"3420":4608,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,118,0]]} -
@DocGame , ja das Ist gewollt. Doppelte Nachrichten werden ignoriert.
-
@Stuebi sagte in [Aufruf] Test Shelly Adapter:
@Diginix , den Fehler bekomme ich leider nicht weg, da dieser nicht in Shelly Adapter hochkommt. Eigentlich, sollte der Adapter wenn dieser rot ist neu starten.
Kannst über die GitHub Katze die Version 3.0.9 installieren und schauen ob der Adapter restarted.Ich habe die 3.0.9 nun ein paar Tage laufen und weiterhin ca. 1mal am Tag die "Exception: Error: No reply in 247s", aber der Adapter startet dann selbst neu und ist wieder grün!
-
Wäre es möglich für RGBW2 Devices die Rolle von "Gain" statt "level" standardmäßig auf "level.brightness" zu konfigurieren? Das würde bei der iot-Google Home Anbindung helfen.
Klar kann ich das für mich auch manuell machen, aber die Konfiguration im Adapter wäre sicher die elegantere Lösung.
-
@siggi85 , kein Problem. Das werde ich heute Abend in der 3.0.9 Version aufnehmen.
