search

iobroker-community-adapters / ioBroker.shelly

Integrate your Shelly devices into ioBroker via MQTT or CoIoT
Other
168 stars 68 forks source link

Datenpunkte werden nicht aktualisiert #384

Closed cTech1987 closed 3 years ago

cTech1987 commented 3 years ago

Describe the bug
Die Datenpunkte Power und Energy aktualisieren sich seit 4.0.7 nicht mehr. Wird der Adapter neugestartet funktionieren sie kurzzeitig wieder und dann nicht mehr.

Versions:

schmupu commented 3 years ago

Es wäre schon von Interesse welche Shelly Geräte es betrifft

cTech1987 commented 3 years ago

Mist, dachte ich hätte es bei geschrieben.

Plug S

Wenn ich den Adapter manuell neu starte, funktioniert er wieder für eine kurze Zeit. Und dann bleiben die Werte stehen bzw. aktualisieren sich nicht mehr.

golisan commented 3 years ago

Hallo, ich habe das gleiche Problem mit den Shelly 1

cTech1987 commented 3 years ago

Korrigiere: mit der 4.0.7 scheint es zu laufen. Danach treten erst die Fehler auf. Ich teste weiter.

AlexKusnezov commented 3 years ago

habe das gleiche mit 4.0.7 Nach ein paar Stunden werden die Datenpunkte nicht mehr aktualisiert und ich muss den adapter neustarten. Habe zwei shelly dimmer 2 im coap modus (colot ist an) Node.js v12.22.1 NPM 6.14.12

Shelly-FW: v1.10.4 (2021.04.29)

sjfm-design commented 3 years ago

versucht mal die 4.0.8. da hab ich keine probleme. und so nebenbei: Shelly Firmware version: <2021.04.29> das ist keine aktuelle firmware. das ist die auslieferungsFW. schleunigst update auf 1.10.4

AlexKusnezov commented 3 years ago

@sjfm-design 2021.04.29 ist die 1.10.4 Kollege: image

Edit: bei mir war allerdings ein anderes Problem, verwende unicast mit iobroker und homebrdige und das was zuletzt gestartet ist hat die kontrolle, muss mir was anderes überlegen

wolfgang1962 commented 3 years ago

Bei mir betrifft es alle Shelly-Geräte, die ich im Einsatz habe: Shelly1, Shelly1PM, Shelly2.5, Shelly DW2, Shelly Plug S, Shelly Uni, Shelly I3 Entweder sind alle Datenpunkte aktuell, oder gar keine. Alle Shelly haben die aktuellste verfügbare Firmware (v1.10.4), COIOT multicast. Adapter ist 4.0.7 Irgendwann hört die Aktualisierung einfach auf - und auch das Ansteuern eines Shelly ist vom ioBroker aus nicht mehr möglich. NodeRed läuft auch als Adapter - dort habe ich immer Zugriff auf die Zustände der Shelly bzw. kann diese ansteuern (auch wenn der Shelly-Adapter "eingefroren ist"). Und über die Shelly-App sind die Geräte auch unterbrechungsfrei zu erreichen.

Ach ja - wenn ich den Adpter neu starte funktioniert er mehr oder weniger lange wieder. Mal ein paar Stunden, mal ein paar Tage, oft aber nur recht kurz. Wenn ich dann gar nichts mache, dann fängt er irgendwann tatsächlich wieder an und aktualisiert alle Shelly... bis er kurz darauf wieder aussetzt....

0xdefec71f commented 3 years ago

Bei mir genau das Gleiche wie bei @wolfgang1962 . Egal welches Gerät oder welcher Datenpunkt, es wird nach kurzer Zeit nichts mehr aktualisiert. Die Einstellung "aktualisiere auch Objekte, wenn es keine Änderungen an den Geräten gibt" ändert daran nichts.

cTech1987 commented 3 years ago

Ich korrigiere meine Aussage von oben, 4.0.7 macht auch den Fehler mit den nicht aktualisierenden Datenpunkten.

cTech1987 commented 3 years ago

Ich habe noch ältere Versionen probiert - leider auch der gleiche Fehler. Kann evtl. irgendwie an dee Firmware liegen? Wobei im App ist ja der Wert immer i.O nur der Adapter im ioBroker schmiert ab,

Blechbixn commented 3 years ago

Same here! Alles uptodate, vereinzelte shellys lassen sich nach undefinierbarer Zeit nicht mehr ansteuern. Per alexa oder shelly cloud kein thema.

0xdefec71f commented 3 years ago

Heute den JS Controller auf 3.3.15 geupdated. Alles ist aktuell, das Problem bleibt. Ich finde das besonders nervig, weil ich ein paar Shelly Flood täglich den timestamp der Datenpunkte auf Aktualisierung prüfe, um zu sehen ob sie online sind. Es betrifft offensichtlich viele Leute und der Adapter wird bei anderen Gelegenheiten noch gewartet. Warum tut sich hier nichts?

sjfm-design commented 3 years ago

Alle Shelly haben die aktuellste verfügbare Firmware (v1.10.4), COIOT multicast.

es wurde auf unicast umgestellt! grafik die IP deines ioBrokers rein, save. der port wird automatisch eingetragen.

cTech1987 commented 3 years ago

Also bei mir haben die Geräte die Firmware 1.11.2 oder 1.11.0 und dein angesprochener Menüpunkt ist nicht zu finden.

Micha-J commented 3 years ago

Ist nur direkt über die IP des Gerätes zu finden. Es steht unter dem Punkt Internet&Security.

wolfgang1962 commented 3 years ago

Also bei mir haben die Geräte die Firmware 1.11.2 oder 1.11.0 und dein angesprochener Menüpunkt ist nicht zu finden.

Den Menüpunkt findet man im WebUI des Shelly - nicht in der App.

0xdefec71f commented 3 years ago

Habe ich bei allen Geräten so eingestellt. Das löst aber leider das Problem nicht. Nach wenigen Tagen aktualisieren sich die Timestamps der Datenpunkte trotzdem wieder nicht.

wolfgang1962 commented 3 years ago

Genauso bei mir. Vor Allem werden einige Datenpunkte aktualisiert (z.B. UPTIME oder Temperature), aber dann der Relaiszustand nicht mehr... Sehr unbefriedigend - vor allem überhaupt nicht reproduzierbar. Zur Abhilfe hatte ich mir eine Art "Watchdog" per BLOCKLY programmiert, der dann den Adapter neu startet. Aber was nutzt es, wenn die überwachten Daten aktualisiert werden und etiche andere plötzlich nicht mehr...

Apollon77 commented 3 years ago

Schonmal Adater in Debug Log laufe lassen und geschaut ob da was zu sehne ist wenn es passiert?

wolfgang1962 commented 3 years ago

OK - ich habe den Log-Level von meiner Instanz shelly.0 von info auf debug geändert. Ich hoffe, es ist das, was du meinst, Apollon77. Beim Adapter selbst (v4.0.7) habe ich da keine Einstellungsmöglichkeit gefunden. (Admin V5.1.23)

Apollon77 commented 3 years ago

Ja genaus das meinte ich ... naja dann mal schauen was so passiert wenn es wieder abbricht

wolfgang1962 commented 3 years ago

Zumindest kommen jetzt mal Berge von Einträgen rein....

Apollon77 commented 3 years ago

Ja das Log wird nicht klein werden, schau das genug Plattenplatz da ist :-)

wolfgang1962 commented 3 years ago

Guten Morgen, eben hatte ich wieder die Situation, dass der Status/Input etc. diverser Shellys (Shelly 1, Shelly 2.5 hab ich getestet) nicht aktualisiert wurde. Die Werte für "uptime" und beim 2.5er für die Temperatur wurden allerdings gemäß der polltime von 60s weiterhin aktualisiert. Ich habe dann via App mehrere Schaltvorgänge ausgelöst. Die Shellys haben auch real geschaltet - im ioBroker kam es zu keinen Veränderungen der Werte "input" bzw. "switch". Dann habe ich einen "restart" des Adapters ausgelöst. Alle Werte werden wieder aktualisiert.

Beim Downloadversuch der heutigen Log-Datei (115MB) führt nun mein Raspberry4b 8GB jedesmal einen Restart durch. Ich habe den Log-Level der Shelly-Instanz wieder auf "info" zurückgesetzt - trotzdem komme ich an das Logfile nicht heran. Mir ist aufgefallen, dass bei der Auswahl der Logfiles nicht nur die Datumsangaben zur Auswahl stehen sondern an die von gestern jeweils ein "gz" an das Datum angehängt wurde. Das habe ich gestern nicht bemerkt. Weiter unten in der Liste wird mir auch "current" mit 23B Größe angeboten - auch da startet der Raspi neu...

M.E. kann es nicht an Speichermangel (RAM oder Plattenplatz) liegen. Angezeigt wird mir: Disk free: 93%, Total RAM usage: 1697 Mb / Free: 84% = 6655 Mb [Host: raspberrypi-IOB - 22 processes]

Da ich Null Ahnung von Linux habe kenne ich nun keinen Weg das Logfile auf andere Art und Weise einsehen zu können.

Apollon77 commented 3 years ago

Dann nimm nicht Admin sondern sscp poder ssh kram ... File liegt unter /opt/iobroker/logs/...

wolfgang1962 commented 3 years ago

Das will irgendwie nicht:

pi@raspberrypi-IOB:~ $ cd /opt/iobroker/logs/ -bash: cd: /opt/iobroker/logs/: Datei oder Verzeichnis nicht gefunden

ins opt-Verzeichnis komme ich noch rein:

pi@raspberrypi-IOB:~ $ cd /opt pi@raspberrypi-IOB:/opt $ cd /iobroker -bash: cd /iobroker: Datei oder Verzeichnis nicht gefunden

weiter komme ich nicht:

pi@raspberrypi-IOB:/opt $ ls -all insgesamt 16 drwxr-xr-x 4 root root 4096 Aug 30 2020 . drwxr-xr-x 22 root root 4096 Jun 30 15:57 .. drwxrwxr-x+ 8 iobroker iobroker 4096 Sep 8 14:47 iobroker drwxr-xr-x 7 root root 4096 Jun 30 11:33 vc

Was kann ich tun?

Apollon77 commented 3 years ago

Es ist /opt/iobroker/log

wolfgang1962 commented 3 years ago

Das hat nun funktioniert. Ich verstehe nicht, warum ich ins "opt"-Verzeichnis komme, aber nicht ins "iobroker"-Verzeichnis... Egal - ich konnte die Dateinamen nun sehen - zum Download auf meinen PC habe ich mir nun das Tool WinSCP installiert. Die log-Datei von gestern habe ich mir rüberkopiert und konnte sie auch (mit Hürden ob der Größe) in VisualStudioCode anzeigen. Der Download des (bisherigen) heutigen Logfiles ist auch erfolreich. Auch dieses kann ich mit dem Code-Programm ansehen. Wonach kann/sollte ich jetzt suchen?

Apollon77 commented 3 years ago

Ich verstehe nicht, warum ich ins "opt"-Verzeichnis komme, aber nicht ins "iobroker"-Verzeichnis...

ja weil ein cd /iobroker ... lso mit / am anfang immer im Filesystem root startet. ein cd /opt und dann cd iobroker geht bestimmt

Wonach kann/sollte ich jetzt suchen?

Nach nichts ... am besten mit per email senden (iobroker@fischer-ka.de) oder aussortiert und nur die shelly meldungen hier als File hochladen (auch mir senden am besten nur den shelly teil)

wolfgang1962 commented 3 years ago

Ich hab das Logfile per E-Mail geschickt. Hoffentlich hilf es.

Apollon77 commented 3 years ago

Ich versuche die Tage mal reinzuschauen

wolfgang1962 commented 3 years ago

Prima - bin gespannt. Schönes WE

HGlab01 commented 3 years ago

Wenn das Problem auftritt am besten folgende Schritte ausführen

Linux-Shell auf dem Server öffnen auf dem iobroker läuft und

cd /opt/iobroker/node_modules/iobroker.shelly iobroker stop shelly node coaptest.js | grep "SHxx-xx#xxxxxxxxx" -a

wobei SHxx-xx#xxxxxxxxx durch den Device-Namen zu ersetzen ist, die Stelle(n) nach dem letzten Hashtag inkl. dem Hashtag weglassen (also nicht SHxx-xx#xxxxxxxxx#1 sondern nur SHxx-xx#xxxxxxxxx)

Poste mal was da dann auf der Console ankommt! Und am besten im Vergleich zu einem Zeitpunkt zu dem es funktioniert

Ich tippe auf ein Netzwerkproblem (Router/Switch) und auf kein Shelly-Adapter Problem

HGlab01 commented 3 years ago

Zusatzinfo: Shelly 1 SHSW-1# – Uptime läuft weiter, Status input und switch werden nicht aktualisiert. Shelly 2.5 SHSW-25# – Uptime und Temperatur aktualisiert weiter, Status input, switch, power werden nicht aktualisiert.

Interpretation: SHSW-1: Uptime --> HTTP nicht COAP Relay0.Input --> COAP only

SHSW-25: Uptime --> HTTP nicht COAP temperatureC --> HTTP und COAP Relay0.Input --> COAP only Relay0.Power: COAP only

--> COAP klappt nicht; HTTP klappt --> Netzwerk issue? --> https://github.com/iobroker-community-adapters/ioBroker.shelly/issues/384#issuecomment-919459961

0xdefec71f commented 3 years ago

Die Interpretation, dies soll netzwerkbezogen sein, kann ich nicht nachvollziehen. Die Verbindung ist TCP, nicht UDP. Ich sehe auch keinen Zusammenhang, warum dies immer erst nach Tagen und dann durchgehend auftritt. Auch der Fakt, dass es durch Neustart des Shellyadapters wieder behoben wird zeigt eindeutig, dass dies nichts mit Routern oder Switches zu tun hat. Ist ein bisschen zu einfach, es so abzuweisen.

HGlab01 commented 3 years ago

Niemand hat etwas abgewiesen ;-) Aber gerne einfach mal das oben beschrieben ausführen, dann sehen wir anhand der reinkommenden Pakete ob der Shelly Adapter die passenden Daten bekommt. Danke!

wolfgang1962 commented 3 years ago

Hallo HGlab01,

eben kam ich heim und konnte oben angegebene Vorgehensweise direkt nachvollziehen:

Im folgenden ist Kanal 2 (also Relais 01) eines Shelly 2.5 betroffen gewesen.

Hier das, was "reinkam", als es nicht funktionierte: Switch-Status wurde im Adapter nicht aktualisiert. Ich habe mehrfach aus und wieder eingeschaltet und am Schluss kamen dann Meldungen, ohne dass ich etwas getan habe.

node coaptest.js | grep "SHSW-25#68C63AFA1B2B" -a 2021-09-15T10:33:33.043Z - 192.168.178.192:5683 - PR 3citsm l SHSW-25#68C63AFA1B2B#2RC {"G":[[0,9103,5],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,63.49],[0,6101,0],[0,9101,"relay"],[0,4108,243.58]]} 2021-09-15T10:33:40.767Z - 192.168.178.192:5683 - PR 3citsm l SHSW-25#68C63AFA1B2B#2RC 3citsm l5T10:33SHSW-25#68C63AFA1B2B#2RC {"G":[[0,9103,5],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,63.49],[0,6101,0],[0,9101,"relay"],[0,4108,243.58]]} 2021-09-15T10:33:57.199Z - 192.168.178.192:5683 - PR3citsm l SHSW-25#68C63AFA1B2B#2RC {"G":[[0,9103,5],[0,1101,0],[0,1201,1],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,63.49],[0,6101,0],[0,9101,"relay"],[0,4108,243.58]]} 2021-09-15T10:34:12.211Z - 192.168.178.192:5683 - PR3citsm l SHSW-25#68C63AFA1B2B#2RC {"G":[[0,9103,5],[0,1101,0],[0,1201,1],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,63.62],[0,6101,0],[0,9101,"relay"],[0,4108,243.25]]} 2021-09-15T10:34:27.212Z - 192.168.178.192:5683 - PR3citsm l SHSW-25#68C63AFA1B2B#2RC {"G":[[0,9103,5],[0,1101,0],[0,1201,1],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,63.62],[0,6101,0],[0,9101,"relay"],[0,4108,243.25]]} 2021-09-15T10:34:42.214Z - 192.168.178.192:5683 - PR3citsm l SHSW-25#68C63AFA1B2B#2RC {"G":[[0,9103,5],[0,1101,0],[0,1201,1],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,63.76],[0,6101,0],[0,9101,"relay"],[0,4108,243.25]]}

Nach Neustart (des kompletten ioBrokers, da ich nicht wußte, wie ich den Shelly-Adaper wieder an Laufen bringen konnte) wurde der Switch-Status wieder korrekt angezeigt/übernommen und nach o.g. Befehlsfolge kam dann rein:

node coaptest.js | grep "SHSW-25#68C63AFA1B2B" -a 2021-09-15T10:44:29.695Z - 192.168.178.192:5683 - PR@3citsm l SHSW-25#68C63AFA1B2B#2RC{"G":[[0,9103,5],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,61.76],[0,6101,0],[0,9101,"relay"],[0,4108,244.16]]} 2021-09-15T10:44:32.512Z - 192.168.178.192:5683 - PRA3citsm l SHSW-25#68C63AFA1B2B#2RC{"G":[[0,9103,5],[0,1101,0],[0,1201,1],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,61.76],[0,6101,0],[0,9101,"relay"],[0,4108,244.16]]} 2021-09-15T10:44:36.143Z - 192.168.178.192:5683 - PRB3citsm l SHSW-25#68C63AFA1B2B#2RC{"G":[[0,9103,5],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,61.89],[0,6101,0],[0,9101,"relay"],[0,4108,244.16]]} 2021-09-15T10:44:38.588Z - 192.168.178.192:5683 - PRC3citsm l SHSW-25#68C63AFA1B2B#2RC"G":[[0,9103,5],[0,1101,0],[0,1201,1],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,61.89],[0,6101,0],[0,9101,"relay"],[0,4108,244.16]]} 2021-09-15T10:44:41.027Z - 192.168.178.192:5683 - PRD3citsm l SHSW-25#68C63AFA1B2B#2RC{"G":[[0,9103,5],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,2986],[0,6102,0],[0,4201,0.00],[0,4203,14307],[0,6202,0],[0,3104,61.89],[0,6101,0],[0,9101,"relay"],[0,4108,244.16]]}

Auch hier sind - allerdings erst nach einer ersten selbst reingekommenen Meldung - mehrere Schaltvorgänge.

Ich hoffe, dies ist hilfreich für Euch Spezialisten.

Viele Grüße, Wolfgang

HGlab01 commented 3 years ago

Hallo Wolfgang @wolfgang1962 , verstehe ich dich richtig, dass die Meldungen zuerst gar nicht kamen und dann zeitverzögert eingetroffen sind?

Kannst mir bitte noch das Ergebnis zu http://IPADRESSE/cit/d (einfach im Browser) dem betroffenen Device schicken. Solange es funktioniert. Danke!

wolfgang1962 commented 3 years ago

Hi - deine Frage verstehe ich nicht ganz. Vom Shelly kommen halt alle paar Sekunden Datenpakete. Inwiefern die verzögert sind kann ich schlecht beurteilen. Ich hatte halt bei der Situation, als es nicht funktionierte, direkt nach der Eingabe der Befehlszeile via App hin- und hergeschaltet. Als es wieder ging hatte ich erst ein paar Sekunden gewaret und da war das erste Datenpaket schein eingetroffen...

Aktuell funktioniert es und ich bekomme folgende Rohdaten im Browser:

{"blk":[{"I":1,"D":"relay_0"},{"I":2,"D":"relay_1"},{"I":4,"D":"device"}],"sen":[{"I":9103,"T":"EVC","D":"cfgChanged","R":"U16","L":4},{"I":1101,"T":"S","D":"output","R":"0/1","L":1},{"I":1201,"T":"S","D":"output","R":"0/1","L":2},{"I":2101,"T":"S","D":"input","R":"0/1","L":1},{"I":2102,"T":"EV","D":"inputEvent","R":["S/L",""],"L":1},{"I":2103,"T":"EVC","D":"inputEventCnt","R":"U16","L":1},{"I":2201,"T":"S","D":"input","R":"0/1","L":2},{"I":2202,"T":"EV","D":"inputEvent","R":["S/L",""],"L":2},{"I":2203,"T":"EVC","D":"inputEventCnt","R":"U16","L":2},{"I":4101,"T":"P","D":"power","U":"W","R":["0/2300","-1"],"L":1},{"I":4103,"T":"E","D":"energy","U":"Wmin","R":["U32","-1"],"L":1},{"I":6102,"T":"A","D":"overpower","R":["0/1","-1"],"L":1},{"I":4201,"T":"P","D":"power","U":"W","R":["0/2300","-1"],"L":2},{"I":4203,"T":"E","D":"energy","U":"Wmin","R":["U32","-1"],"L":2},{"I":6202,"T":"A","D":"overpower","R":["0/1","-1"],"L":2},{"I":3104,"T":"T","D":"deviceTemp","U":"C","R":["-40/300","999"],"L":4},{"I":6101,"T":"A","D":"overtemp","R":["0/1","-1"],"L":4},{"I":9101,"T":"S","D":"mode","R":"relay/roller","L":4},{"I":4108,"T":"V","D":"voltage","U":"V","L":4}]}

HGlab01 commented 3 years ago

Ich hatte halt bei der Situation, als es nicht funktionierte, direkt nach der Eingabe der Befehlszeile via App hin- und hergeschaltet.

Du hast hin und her geschaltet und es kamen gar keine Daten in der Shell an? Verzögerung sollte kleiner 1 Sekunde sein

wolfgang1962 commented 3 years ago

Nee - jedes Paket fängt ja mit 2021-09-15T... an Als der Adapter nichts mitbekam hatte ich nach dem "node coaptest..." sofort den Shelly per App geschaltet und dann kam auch sofort das erste Paket. Dann kam sofort nach jedem Schalten ein Paket und als ich aufgehört hatte umzuschalten kamm dann alle paar Sekunden von selbst ein Paket nach dem anderen.

Als der Adapter wieder lief hatte ich nach dem Befehl "node coaptest..." erstmal nix gemacht und abgewaret. Nach wenigen Sekunden kamen dann auch wieder die Pakete rein... schön regelmäßig. Und dann - mit jedem Schalten des Relais - kamen dann auch immer sofort Daten rein. Die Verzögerungen - wenn ich geschaltet hatte - waren immer nur Bruchteile einer Sekunde... quasi sofort...

HGlab01 commented 3 years ago

Understood!

HGlab01 commented 3 years ago

good news: Pakete kommen an - kein Network issue bad news: image in den COAP Nachrichten gab es nur einen einzigen wechsel von 0 (false) auf 1 (true) -->ersten beiden auf 0 und der Rest auf 1

Im zweiten Log passt dann alles image

Logisch ist das ganze damit aber nicht. Vor allem wenn es wieder funktioniert wenn man den Adapter neu startet. Anderseits kann der Adapter nur das interpretieren was er von den Shelly-Devices bekommt und er bekommt im ersten Teil keine korrekten Daten.

Firmware ist aktuell?

wolfgang1962 commented 3 years ago

Firmware ist 1.11.0 - ich traue mich noch nicht auf 1.11.4 zu aktualisieren.

Komisch ist halt, dass die Statusänderungen auch dann beim Node-Red-Adapter und in der App korrekt ankommen, wenn der Shelly-Adapter nix mitkriegt. Mittlerweile habe ich auch einige Shellys auf MQTT in Betireb - da htte ich bisher noch gar keine Aussetzer.

HGlab01 commented 3 years ago

und der Node-Red Adapter läuft auf COAP oder auf MQTT?

wolfgang1962 commented 3 years ago

Der läuft auf COAP - mit MQTT mache ich erst seit Kurzem Gehversuche. Als MQTT- Broker läuft auch ein Adapter im ioBroker... In NodeRed habe ich sowohl mit den Shelly-Nodes getestet, als auch mit den ioBroker-In-Nodes, die dann Datenpunkte vom ioBroker abholen... MQTT habe ich in Node-Red noch nicht ausprobiert.

0xdefec71f commented 3 years ago

Bei mir sind alle Shellys (1, 2.5, Dimmer, Flood, Gas) auf der jeweils aktuellen Firmware. Der Adapter läuft auf COAP. Für MQTT nutze ich nur Tasmota, nicht die Shellys. NodeRed benutze ich nicht. Vielleicht kann man ein paar Dinge ausschließen, die nicht in unserer Schnittmenge sind. Ich habe auch versucht eine Log Datei mit Debug zu erstellen, aber die hat nach wenigen Stunden den Speicherplatz gesprengt.

wolfgang1962 commented 3 years ago

Hallo nicomania, bei mir sind auch (wie weit oben beschrieben) alle Shellys (1, 1PM, 2.5, I3, DW2) betroffen. Ich hatte für die Daten nur exemplarisch den einen 2.5er hergenommen. Anfangs hatte ich weder Node-Red noch MQTT. Ende letzten Jahres habe ich dann Node-Red aktiv genutzt - aber nur die ioBroker Datenpunkte gelesen/gesteuert. Keine Shelly-Nodes eingesetzt. Als ich dann bemerkte, dass die Datenpunkte nicht aktualisiert wurden, habe ich getestet, ob die Shelly-Nodes zuverlässiger arbeiten. Dort kamen bisher immer alle Veränderungen an. Was mich halt an der Node-Red -Umgebung stört ist, dass ich die Shellys immer aktiv abfragen muss. Die dort einstellbare Polltime funktioniert m.E. gar nicht und wenn ich über inject eine Abfrage initiiere, dann bekomme ich alle Daten - aber halt erst dann. Und nicht dann, wenn sie passieren. Es ist also ein Jonglieren die richtigen Abfrageintervalle zu finden, ohne das Netz zu sehr zu belasten. MQTT habe ich dann bei einigen neuen Shelly aktiviert, die vorher überhaupt noch nie im Netz waren - und dort habe ich auch bisher keine Ausfälle registrieren können. Wie gesagt, die Probleme habe ich seit Ende 2020 (und ich vermute immer noch, dass es mit meinen DW2 - also batteriebetrieben - zusammenhängt.) Wie hast du denn bei dir die Polltime im Adapter eingestellt. Ich hatte mal irgendwo den Hinweis gelesen, dass 60s ausreichend sei, da ja bei Veränderungen sowieso Nachrichten vom jeweiligen Shelly geschickt werden...

HGlab01 commented 3 years ago

Ok, dann nutzt "Node-Red" nicht COAP sondern benutzt das http-interface mit Polling.

Ich denke wir müssen eine Ebene tiefer auf die Netzwerk-Ebene um zu sehen was über das Netzwerk kommt! Dazu in der Linux-Shell am Server sudo tcpdump '(udp port 5683) and (src IP-ADRESSE-DEVICE)' -A Abbrechen kann man mit STRG+C Shelly Adapter ganz normal laufen lassen!

Wenn da Pakete in der Shell auftauchen, dann statt Ausgabe auf dem Bildschirm abspeichern in einer Datei: sudo tcpdump '(udp port 5683) and (src IP-ADRESSE-DEVICE)' -A > /home/YOURUSER/shellydump.txt Mit der Datei erkennt man dann wie die Pakete aussehen solange es funktioniert und wie die Pakete aussehen wenn es nicht mehr funktioniert. Auf der Netzwerkebene spielt Shelly noch keine Rolle.

Verwendet ihr unicast oder multicast für die COAP Nachrichten? image Bei mcast interessiert sich das Shelly-Device für den Server gar nicht, es schickt die Pakete einfach in die Welt. Bei unicast könnte (theoretisch) der Adapter das Device beeinflussen. Aber nur sehr theoretisch.