Test Adapter Shelly v4.0.3 (latest)
-
@Lokverführer said in Test Adapter Shelly v4.0.3 (latest):
Also er funktioniert und zeigt in seinem Webinterface oder Shelly Cloud auch Daten an
das wollt ich wissen. aber jetzt is ja cheffe da...
-
@da_Woody , 🤪
-
@Lokverführer stop den adapter, lösche den komplatten 3EM aus den objekten, schau das du auf Firmware 1.8.1 und Adapter 4.0.2 kommst. im adapter [IPv4] 0.0.0.0 - Listen on all IPs bei COAP. log mitlaufen lassen, adapter starten und posten was passiert im log.
bei mir läuft das genau in der konstellation. sieht dann in den objekten so aus:
-
@da_Woody
Ich habe den Adapter gestoppt und auch entfernt. 3EM ist auf Firmware 1.8.1.
Adapter 4.0.2 wieder installiert.
Es gibt wieder nur Objekte "connection" und "update" sonst nichts.
-
@Lokverführer hmm, lösch auf jeden fall mal das in der blacklist. ansonsten... @Stuebi ? @harrym ?
nur so nebenbei, der 3EM ist dein einziger shelly? dein system findet ja gar keinen shelly. node mal updaten? -
@da_Woody
Der Eintrag in der Blacklist ist ja der Standardeintrag. Aber auch wenn ich den lösche ändert sich nichts. Ich habe nur den 3EM, sonst keine Shellys.Beißt sich der Shelly-Adapter irgendwie mit Sonoff oder MQTT?
node ist auf 10.22.1
-
@Lokverführer du hast ein CoAP Problem in deinem Netzwerk. Für mal die gnzen Tests durch. Die zwei Datenpunkte werden vom Adapter selbst angelegt .... auch ohne Shellydevices.
-
@Lokverführer ok, keine andern shelly's, keine anderen einträge. logisch. wäre halt interessant zu wissen ob er einen anderen findet. anyway.
mit sonoff und mqtt hat das nix zu tun, das lööpt bei mir auch. -
Ping und CoAP-Test waren ja erfolgreich:
(von mir wurde die ID durch XXX ersetzt)
martin@NUCi3:/opt/iobroker/node_modules/iobroker.shelly$ node coaptest.js UDP Server listening on 0.0.0.0:5683 2020-09-19T10:20:19.316Z - 10.0.0.88:5683 - PH13citsm SHEM-3#XXX#2R{"G":[[0,9103,0],[0,1101,0],[0,4105,-409.74],[0,4106,20122.7],[0,4107,30416.7],[0,4108,234.57],[0,4109,1.99],[0,4110,-0.88],[0,4205,457.29],[0,4206,58448.8],[0,4207,0.0],[0,4208,234.55],[0,4209,2.22],[0,4210,0.88],[0,4305,15.79],[0,4306,22764.1],[0,4307,0.0],[0,4308,234.57],[0,4309,0.30],[0,4310,0.22],[0,6102,0]]} 2020-09-19T10:20:34.318Z - 10.0.0.88:5683 - PH23citsm SHEM-3#XXX#2R{"G":[[0,9103,0],[0,1101,0],[0,4105,-409.82],[0,4106,20122.7],[0,4107,30416.7],[0,4108,234.81],[0,4109,1.99],[0,4110,-0.88],[0,4205,442.22],[0,4206,58448.8],[0,4207,0.0],[0,4208,234.78],[0,4209,2.15],[0,4210,0.87],[0,4305,16.06],[0,4306,22764.1],[0,4307,0.0],[0,4308,234.83],[0,4309,0.31],[0,4310,0.22],[0,6102,0]]} 2020-09-19T10:20:49.328Z - 10.0.0.88:5683 - PH33citsm SHEM-3#XXX#2R{"G":[[0,9103,0],[0,1101,0],[0,4105,-409.08],[0,4106,20122.7],[0,4107,30416.7],[0,4108,234.74],[0,4109,1.99],[0,4110,-0.88],[0,4205,438.21],[0,4206,58448.8],[0,4207,0.0],[0,4208,234.83],[0,4209,2.14],[0,4210,0.87],[0,4305,15.70],[0,4306,22764.1],[0,4307,0.0],[0,4308,234.82],[0,4309,0.31],[0,4310,0.22],[0,6102,0]]} 2020-09-19T10:21:04.343Z - 10.0.0.88:5683 - PH43citsm SHEM-3#XXX#2R{"G":[[0,9103,0],[0,1101,0],[0,4105,-408.93],[0,4106,20122.7],[0,4107,30423.5],[0,4108,234.93],[0,4109,1.99],[0,4110,-0.88],[0,4205,451.49],[0,4206,58456.2],[0,4207,0.0],[0,4208,234.88],[0,4209,2.19],[0,4210,0.88],[0,4305,16.38],[0,4306,22764.5],[0,4307,0.0],[0,4308,234.99],[0,4309,0.31],[0,4310,0.23],[0,6102,0]]} 2020-09-19T10:21:18.242Z - 10.0.0.88:5683 - PH53citsm SHEM-3#XXX#2R{"G":[[0,9103,0],[0,1101,0],[0,4105,-409.29],[0,4106,20122.7],[0,4107,30423.5],[0,4108,235.08],[0,4109,1.99],[0,4110,-0.88],[0,4205,452.94],[0,4206,58456.2],[0,4207,0.0],[0,4208,234.99],[0,4209,2.19],[0,4210,0.88],[0,4305,16.62],[0,4306,22764.5],[0,4307,0.0],[0,4308,235.06],[0,4309,0.31],[0,4310,0.23],[0,6102,0]]} -
@Lokverführer bring den EM3 mal auf die letzte FW 1.8.4 .... http://repo.shelly.cloud/firmware/SHEM-3.zip
Ausserdem stell mal das adapter log auf debug und poste dann die zeilen mit dem EM3.
-
@harrym
Ich habe das Update auf 1.8.4 gemacht und hier ein paar Zyklen aus dem Log:
-
@Lokverführer du hast irgendwo rumgefummelt. bei der shelly id muss #1 und nicht #2 stehn... ich nehm mal an, das du beim adapterupdaten nicht gestoppt hast.
-
@da_Woody nö g dat passt schon so ... die #2 im log zeigt ja nur an, dass ne FW >= 1.8 am Shelly läuft ^^
-
Ich hänge mich mal hier rein, da ich keinen anderen Thread gefunden habe. Habe einen Shelly 2.5 (FW 1.8.3) in Betrieb genommen mit jeweils 3 LED-Spots an jedem Relay. Funktioniert mit Schalter, vom Handy, mit Alexa jeweils einzeln. Jetzt wollte ich alle Spots gleichzeitig ein und ausschalten. Habe in der Handy-App eine Gruppe erstellt und kann alle gleichzeitig ein und ausschalten. Nun wollte ich das gerne auch über Alexa schalten. Bereits bevor ich die Gruppe in der App erstellt habe, gab es eine Gruppe in iot. Diese hat alle Datenpunkte bis auf den Datenpunkt switch der beiden Relays. Unter alexa2.1 gibt es auch die Gruppe mit merkwürdigen Datenpunkten.
Was mache ich falsch? Geht das überhaupt? -
@klausiob alexa legt das hirnrissig an.
erstell am handy in der alexa-app eine gruppe "Licht Essdiele" und da hackst du die beiden relais an. -
@da_Woody Danke. So funktioniert es zumindest. Aber eigentlich sollte man doch alles im iot-Adapter anlegen. Hier und unter Alexa sieht man im iobroker die im Handy angelegte Gruppe nicht. Das ist doch dann etwas inhomogen oder unterstützt das iobroker nicht so richtig.
-
@klausiob naja, da ich teilweise die shelly-app (WAF) noch verwende, hab ich nur einige shelly im iot. z.b. die rolläden von der werkstatt. wenn du alles im iot anlegst, brauchst du die shelly-cloud/adapter nicht mehr.
aber eigentlich müsstest du auch die beiden relais im iot anlegen können.
bevor du da aber rumkünstelst, solltest du nachdenken ob nicht vorher alles im alias angelegt werden sollte. wenn ein shelly kaputt wird, brauchst du nur dort die ID zu ändern, alles andere greifst du nicht mehr an.
und so nebebei hab ich das terrassenlicht in der app und im iot und der alexa. (da ist der echo auch mit drinnen, drum 4)
-
@Stuebi
Ich möchte gern longpush mit CoAP nutzen. Ich nutze die Version 4.0.3
Bei meinen Tests bin ich auf folgendes Phänomen gestoßen und kann nicht verifizieren, ob das so gewollt ist.Wenn ich Longpush geschaltet habe und danach einen einfachen Schaltungsvorgang (Short) ausführe, wird zusätzlich noch mal Longpush gefeuert. Ist das normal?
on({id: "shelly.0.SHSW-PM#F27119#1.Relay0.longpush", change: "ne"}, function (obj) { log('longpush geschaltet'); }); on({id: "shelly.0.SHSW-PM#F27119#1.Relay0.Switch", change: "ne"}, function (obj) { log('Switch geschaltet'); });LogFile:
javascript.0 2020-10-03 15:32:52.155 info (24372) script.js.common.Shellys: longpush geschaltet ---> wird zusätzlich geschaltet javascript.0 2020-10-03 15:32:52.149 info (24372) script.js.common.Shellys: Switch geschaltet ---> Short geschaltet javascript.0 2020-10-03 15:32:47.610 info (24372) script.js.common.Shellys: longpush geschaltet --> Longpush gedrückt javascript.0 2020-10-03 15:32:47.168 info (24372) script.js.common.Shellys: Switch geschaltet ---> Short Ausschalten javascript.0 2020-10-03 15:32:45.200 info (24372) script.js.common.Shellys: Switch geschaltet --> Short EinschaltenButton-Type: Momentary,
Szenario
Ich steuere einen Raum per Bewegungsmelder und möchte aber bei bestimmten Tätigkeiten das Licht Dauerhaft einschalten, dafür wollte ich den Longpush nutzen und wundere mich gerade darüber, dass das Licht immer wieder erneut eingeschaltet wird, nachdem ich es eigentlich ausstellen wollen würde.Bei meiner Recherche konnte ich nicht herausfinden, ob das Event-Handling so von Shelly gewollt ist oder ob das ein Bug ist.
-
@Th3RockYeah kann das eventuell damit zusammen hängen?
-
@da_Woody Nein, das hat keine Auswirkungen auf das Verhalten. Ich habe es eben noch mal durchgespielt und bei beiden Szenarien passiert obiges Verhalten. Longpush wird nochmal nach dem ShortPush gefeuert.
