Test Adapter Shelly v4.0.2 (latest)
-
Aktuelle Test Version 4.0.2 Veröffentlichungsdatum 19.08.2020 Github Link https://github.com/schmupu/ioBroker.shelly Changelog
-
Bitte Version 4.0.3 installieren!
https://forum.iobroker.net/topic/36200/test-adapter-shelly-v4-0-3-latest -
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.237Wenn 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 msSchritt 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.237Nun 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!Hinweis 1:
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.Hinweis 2:
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 der Firmware 1.8.x ein Problem und werden nicht bzw. falsch dargestellt. -
@Stuebi Ich verwende schon fast ewig Deinen Adapter und bin immer wieder sehr zufrieden
Danke dafür!!!Ich hätte mal eine Frage zu dem Energy und Power Object im Adapter.
Power ist wohl der aktuelle Verbrauchswert in Watt.
Energy ist wohl der konsumierte Watt Wert in Stunden (Wh) - doch wieviele Stunden beinhaltet der Wert?Ich frage, weil ich einer Art Statistik erstellen möchte, wo ich die Werte als History nutzen kann. Jedoch würde in meinem Fall der Wert Energy nicht stimmen.
Ich habe hier z.B. einen Brunnen für meine Katzen laufen, der in etwa 3 Watt verbraucht. Jetzt um 9 Uhr zeigt die Shelly App auf Android 27 Watt Tagesverbrauch an (was ja von 0 Uhr bis 9 Uhr stimmt).Das Object im Shelly Adapter zeigt allerdings 54 Wh an. Wird dieses automatisch resetet? Wenn ja, wann?
Danke,
SKB -
@SKB , die Frage ist ganz einfach zu beantworten der Wert in Energy (z.B. in Relay0.Energy beim Plug S) wird vom Shelly per CoAP oder MQTT vom Shelly direkt in Wmin angeliefert. Dieser wir im Shelly Adapter auf Wh "umgewandelt" und auf 2 Nachkommastellen gekürzt. D.h. der Energy Wert wird nicht vom Shelly Adapter berechnet sondern angeliefert. Frage bitte Shelly warum dieser unterschiedlich in der App ist.
Welchen Shelly nutzt du denn?
-
@Stuebi Danke für Deine Antwort.
Ich nutze hier einen Shelly Plug S.Du meinst also, der Wert vom Shelly
3477 (Wmin) / 60 Minuten -> 57,95 Wh entspricht dann genau den Einheiten von oben?Dann würde ja in der Shelly App etwas nicht stimmen. Wie findet man dies wohl am Besten heraus?
-
@Stuebi
Shelly Adapter 4.0.2
Shelly Switch 1 mit Firmware 20200812-090904/v1.8.0@8acf41b0Hallo, habe gerade meinen ersten Shelly 1 in Betrieb genommen. Er soll einen Badlüfter per Taster steuern. Als Button Type ist Momentary eingestellt. Funktioniert soweit. Um mal zu sehen, wie er sich so verhält, werden diverse Ereignisse getriggert:
//on({id: DEV_SHELLY_SW1 + '.Switch', change: 'ne'}, function(obj) { on({id: DEV_SHELLY_SW1 + '.Switch', change: 'any'}, function(obj) { writeLog('Ereignis Shelly1 Switch: ' + String(obj.state.val), 1); }); on({id: DEV_SHELLY_SW1 + '.Input', change: 'any'}, function(obj) { writeLog('Ereignis Shelly1 Input: ' + String(obj.state.val), 1); }); on({id: DEV_SHELLY_SW1 + '.longpush', change: 'any'}, function(obj) { writeLog('Ereignis Shelly1 longpush: ' + String(obj.state.val), 1); });Wenn man den Taster nur kurz betätigt, wird 2x das Switch-Ereignis ausgelöst. Ereignis Input dagegen gar nicht:
2020-08-26 10:03:40.284 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Switch: true 2020-08-26 10:03:40.286 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Switch: trueHält man den Taster länger gedrückt, wird neben dem Longpush auch das Input Ereignis getriggert. Aber alle Ereignisse doppelt:
2020-08-26 10:04:24.258 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Switch: true 2020-08-26 10:04:24.261 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Input: true 2020-08-26 10:04:24.267 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 longpush: true 2020-08-26 10:04:24.269 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Switch: true 2020-08-26 10:04:24.271 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Input: true 2020-08-26 10:04:24.283 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 longpush: true 2020-08-26 10:04:26.717 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Input: false 2020-08-26 10:04:26.718 - info: javascript.0 (1060) script.js.Test.#Luefter_Bad: LOG:> Ereignis Shelly1 Input: falseDas mit den doppelten Nachrichten kann man rausfiltern indem man change: 'ne' statt change: 'any' nimmt. Ist bloß unnötiger Traffic. Liegt vermutlich an der Shelly Firmware?
Auch dauert es 1-2s bis die Ereignisse getriggert werden. Wenn man kurz hintereinander 2x den Taster betätigt, wird kein Ereignis getriggert.
-
a) den Hinweis 3 oberhalb hast du gelesen?
b) gibt es eine Einstellung, wie sich das Relay bei longpush verhalten soll. -
@harrym sagte in Test Adapter Shelly v4.0.2 (latest):
a) den Hinweis 3 oberhalb hast du gelesen?
Hinweis 3? Post 3 oder Schritt 3?
Der Shelly funktioniert ja. Ping und CoAP Test waren erfolgreich. Wollte bloß auf die doppelten Ereignisse hinweisen. Aber das war wohl falscher Alarm. Nachdem ich den Shelly-Adapter neu gestartet habe, ist das Phänomen weg.b) gibt es eine Einstellung, wie sich das Relay bei longpush verhalten soll.
Danke für den Tipp. Der Shelly soll einen Lüfter per Taster ein/ausschalten. Außerdem soll beim Einschalten ein Timer starten, der den Lüfter wieder ausschaltet. Die Zeit des Timers soll per Taster nachgetriggert werden können. Mit dem Haken bei "Don't activate if the button is long pushed." kann jetzt per longpush der JS-Timer nachgetriggert werden.
-
Ich bin derzeit absolut frustriert.
Seit fast 2 Jahren bin ich mit meinem Raspi (inzw. 4 mit 4GB) und dem IOBroker unterwegs, habe immer brav alle Updates installiert, Backups zum Glück auch angelegt.
Nun kam der Tag, an dem Murphys Gesetze zugeschlagen haben.
Ein Update ist dazu da Fehler zu beseitigen und Neue zu produzieren, die vorher nicht da waren.Mit den Shelly 1 hatte ich begonnen mein Haus smart zu machen, erst mal nur die Lichtschalter, dann die Rolladen und mit dem PlugS auch die Dekolampen.
Nun wurde in diese Woche der großer Versionswechsel sowohl im Adapter als auch in der FIRMWARE von Shelly eingeläutet.
Bis brauchte ich mich um die Integration der neuen Shellys kaum kümmern, sie wurden erkannt und ich konnte Sie in meinen Scribts ansprechen - PRIMA.Bis zum Upgrade der Firmware auf 1.8.0 - leider erfährt man erst wenn nix mehr geht, dass da auch im IOBroker etwas neu gemacht werden muss.
Version 4 soll alles richten, aber mein Adapter erkennt die die Komponenten, aber die Instanz bleibt rot...Nun versuchte ich die noch nicht unter latest bereitgestellte aktuelle Version 4.0.3 über GitHub zu installieren, bekamm aber die Version 4.0.4 übergebügelt.
Beim Deinstallieren kamen Fehlermeldungen und nun bin ich aufgeschmissen - der Adapter lässt sich nicht mehr installieren, arbeiten will er auch nicht.Hier die Fehlermeldung im Log:
Zu allem Unglück wurde auch meine Visualisierung durch das letzte Update beschädigt, da der VIS-Server nicht mehr startet.
Ich muss jetzt zu Fuß mein Licht ausmachen... Wie fürher, als alles analog war.Frage: Muss ich jetzt wieder alle neu aufsetzen oder hat einer einen Tip wie ich den Adapter wieder zum Laufen bringe. Ist es jetzt notwendig im Shelly ein Zugangspasswort einheitlich zu verwenden? Habe irgendwo gelesen, dass sonst der Adapter nicht mehr auf den Shelly zugreifen kann..
Wie gesagt das Thema Firmwareupdate und nur Version 4 für die neue FW ist mir klar, aber der Adapter liest ein und dann wird er rot.
Was nützt das Smarthome, wenn ein einziges Update alles vernichtet
-
@Tom63 tja .... iobroker fix und eventuell mal guggen, ob da am RP die SD Karte nicht am schlappmachen ist. Sind mMn keine Adapter Fehler.
Die Ankündigung bzgl. FW 1.8 und den gravierenden Änderungen haben wir lange genug vorher schon in diversen Kanälen publiziert.
-
Ich habe jetzt den Adapter 4.0.3 über putty installiert bekommen.
Er ist auch derzeit grün, werde mal beobachten, ob die neue Version 4.0.3 jetzt funzt.Leider hat das externe Update der Adapter auch wieder den Socketio angehoben, der wohl derzeit nicht sauber zum VIS / Webserver agiert..
Trotzdem erstmal vielen Dank ... Aufgeben kann jeder..
Bin eigentlich Systemadmin / datzenbankprogrammierer und MS und in der Linuxwelt nicht so firm...
-
@Tom63 soketio/web/vis und auch die scriptengine machen derzeit einigen etwas kopfweh. und als tipp: installiere dir sofort die fw 1.8.3 auf die shelly, wenn sie dir angeboten wird
-
Ja sie rufen inzwischen täglich. Was ich aber sehr bewundere, selbst die allerersten Shellys, die ich noch direkt in Bulgarien bestellt habe, werden mit angehoben.
Sehr gut finde ich jetzt die Device Name Vergabe, damit man die Dinger sauber zuordnen kann.Bin dir sehr dankbar, fixe gerade den Raspi. Er läuft in Kooperation mit dem ConBeII - der als Zigbee Broker für die Sensoren und Schalter sehr effektiv mit den Shellys harmoniert.
Meine Nacht kann kommen, Licht geht wieder aus wann ich es will
-
@Tom63, glaube uns, wir haben uns auch nicht über das massive Shelly Firmwareupdate gefreut. Das kostet uns, bzw. hat es @harrym viel Arbeit und Zeit gekostet. Nochmals Danke dafür!
Der Shelly Adapter so aufgebaut, dass wir im Regelfall neue Shellys oder neue Objekte ohne Programmierung über eine Konfigurationsdatei einbinden können.
Genau das ist auch beim Shelly 4.0.0 Adapter passiert. Es wurde an der Programmierung nichts geändert, sondern "nur" an allen Konfigurationsdateien (für jedes Shelly Device gibt es eine).
Der Shelly Adapter 4.0.0 hätte also ganz normal laufen müssen, im schlimmsten Fall werden die Shelly Devices bei Firmware < 1.8 nicht eingebunden. Ich weiss nicht wie viele hunderte Anpassungen @harrym vorgenommen hat. Das da auch Fehler passieren (Tippfehler), ist ja klar.
Warum der Shelly Adapter 4.0.2 bei dir nicht funktioniert können wir nicht so einfach sagen. Dazu benötigen wir ein paar Infos, wie die Versionen von node, npm und js-controller, dann ob du CoAP/MQTT nutzt, die firmware der Shellys usw. Auch ein Auszug aus dem Logfile wäre hilfreich. Am besten ein GitHub Issue aufgeben (Fehlerticket).
Installiere lieber keine Version direkt von GitHub, außer wir sagen es Dir. Im schlimmsten Fall geht danach bei dir nichts mehr
Wenn Du noch Hilfe benötigst, melde Dich. -
-
@Stuebi 2020-08-27T18_26_23_183Z-debug.log
Habe das Logfile mal gesichert.
Ich habe wirklich Hochachtung vor Eurer Leistung, inzwischen macht es wirklich Sinn.Alles kam durch den nachträglichen Einbau von shelly2.5 hinter meiner Somfy Rolladensteuerung, da diese 20 Jahre per Funk arbeitet.
Die ersten Motoren sind jetzt gestorben und wenn ich schon mal dran bin..... Smart ist
cool..
Mit der Leistungsmessung und Calibrierung kann ich jetzt natürlich auch per VPN und ohne Cloud meine Rolladen genau ansteuern.
Die Dinger sind echt genial und auch Preis/Leistung stimmt. Mit etwas Elektroverständnis kann das jeder auch nachträglich verbauen.Wie gesagt unter Modus latest wurde der 4.0.2 vorhin noch ausgerollt, im Protokoll habt ihr bereits 4.0.3 angekündigt und empfohlen..
Da war es nur mal ein Versuch ... der fast ins
ging.
Da ich selber Lösungen entwickle, weiß ich welcher Aufwand ein Firmwareupdate bedeutet ...Gerne teste ich weiter und gebe Infos zu weiteren Ideen...
besten Dank und bleibt gesund!
-
@Stuebi sagte in Test Adapter Shelly v4.0.2 (latest):
@Tom63 , wir haben nun auch einen #Shelly Kanal zum chatten auf Discord. Noch eine weitere Plattform um mit uns in Verbindung zu treten.
Da habe ich mich registriert, bin aber irgendwie im Wald stehen geblieben und wieder hierher zum IOBroker Forum gekommen...
Aber ich schaue es mir in Ruhe an versprochen...
Erfahrung ist alles das, was man nicht googeln kann.. -
@Tom63 , die Version 4.0.2 ist in stable, und 4.0.3 in latest. Du hast wahrscheinlich stable bei ioBroker eingestellt, was ja auch vernünftig ist.
Da es bisher wenige Fehlermeldungen zur 4.0.3 gab, werden wir diese demnächst auch in stable überführen. -
@Tom63 said in Test Adapter Shelly v4.0.2 (latest):
Ja sie rufen inzwischen täglich. Was ich aber sehr bewundere, selbst die allerersten Shellys, die ich noch direkt in Bulgarien bestellt habe, werden mit angehoben.
warum ist das bewundernswert? warum sollten die nicht upgedatet werden?
ich bin jetzt seit november 2018 mit shellys unterwegs. grundlegendes an der hardware hat sich ja nicht geändert (fast) der rest ist (magie) firmware.
ich mag dimitar und seine jungs. er hat mir mal rund um die uhr 4 tage support geleistet bei einem widerspenstigem teil. ich hab ihm videos geschickt. es war unfassbar. am 4. tag war das problem einfach weg, keiner weis warum. er hat gelacht, war aber froh zu sehn was da passieren kann. auch letztens bei einem shelly1. der lässt sich nicht updaten, 1.7.0 hat er, mehr geht nicht. witziger weise hat er aber das sync name drinnen. gibts erst seit rc1.7.7. alles versucht. dimitar war mitten in der nacht da und hat es selber per fernzugriff versucht, am nächsten tag mit seinen jungs gesprochen, w.o. gegeben. keiner weis wie das sein kann.
aber da fängt das problem bei allterco an. dimi und die jungs wollen es allen recht machen! und schau dir mal die karte an wo auf der kugel shellys verwendet werden! das dadurch dann mal unerwartete probleme auftauchen ist normal. siehe ja auch die letzten tage hier...
nur mal ein kleiner einblick wies da hinter den kulissen zugeht...
