Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

True /False state does not update after a while #13

Closed
stefan-sylt opened this issue Dec 4, 2018 · 58 comments
Closed

True /False state does not update after a while #13

stefan-sylt opened this issue Dec 4, 2018 · 58 comments

Comments

@stefan-sylt
Copy link

When the shelly adapter is restarted, the current state (true / false) will always be displayed correctly. But after a while, the old state stays the same all the time. Say it does not update the state anymore. Manuel I can change the state of iobroker and the shellys react too
@Apollon77
Copy link
Member

Please provide more details. I do not understand your problem. Manually changing state always works but not when you use sayit? But sayit in only voice output?!

@Apollon77
Copy link
Member

or do you mean that when you control the device manually the status is not updating anymore?

Can you provide debug log?

@stefan-sylt
Copy link
Author

stefan-sylt commented Dec 4, 2018 via email •
edited

@Apollon77
Copy link
Member

Hm ... dann wäre ich bei einem Debug log weil da siehst Du was an Shelly-Meldungen im Netzwerk ankommt. Wenn keine UDP Pakete mehr ankommen dann kann der Adapter nichts sehen.

@stefan-sylt
Copy link
Author

stefan-sylt commented Dec 4, 2018 via email

@Apollon77
Copy link
Member

Wer auch immer sowas empfiehlt... blödsinn. Es sei denn man will den Adapter nicht nutzen. Da der Adapter aber da ist sollte er auch tun und er tut so lange wie das Gerät Daten ins Netzwerk sendet und iobroker sie empfangen kann.

Debug log kann aber gross werden sage ich gleich! Die Shelly senden sehr oft das gleiche Paket raus ...

@Daniel110382
Copy link

das ist mein log. anfangs ging es noch aber ganz am schluss wurde der wert bei iobroker wieder nicht aktualisiert
hoffe das hilft weiter

@Daniel110382
Copy link

Im netzwerk sind alle online. kann auch im iobroker ein und ausschalten. aber wenn ich manuel am schalter drücke wird der wert nicht geändert

@Daniel110382
Copy link

Ach ja noch was. Ich finde euch echt spitze. Ihr seid stets bemüht die fehler zu finden. Ich bin neuling auf diesem gebiet und finde eure arbeit echt bemerkenswert was Ihr alle da so auf die füße stellt. Ohne euch würde das nie was werden mit meinem Smart Home. Und ja ich gebe dir recht ich möchte diesen adapter von shelly sehr gerne benutzen da er sehr übersichtlich und einfach für mich ist. wie gesagt ihr macht echt eine tolle Arbeit. mir ist es auch nur durch zufall aufgefallen da er nach einiger zeit nicht mehr den stand aktualisiert. ich habe einen skript geschrieben das wenn ich alles aus sage über alexa, das skript alles ausschaltet und nach 3 sek. überprüft ob auch alles aus ist und mit über alexa eine antwort gibt. hab dann innerhalb der 3 sek einfach ein licht eingeschaltet und es kam aber keine antwort, was mich dann stutzig machte. nur durch dieses skript ist es mir erst aufgefallen das die daten nicht mehr aktualisiert werden. ansonsten funktioniert der Adapter tadellos.

@Daniel110382
Copy link

Daniel110382 commented Dec 4, 2018 •
edited

also hab festgestellt immer wenn der befehl nicht funktioniert wird im debug log geschrieben:

       
shelly.0 2018-12-04 17:24:46.151 debug system.adapter.admin.0: logging true

und danach werden keine logs mehr geschrieben. aber 10 sekunden danach wurde wieder in die logs geschrieben.

@Apollon77
Copy link
Member

Also zu deinem Log. Auf die Schnelle sehe ich nichts auffälliges. Für dich wie es zu lesen ist (dann kannst Du vllt bissl experimentieren!!

shelly.0 CoAP status package received: {"3332":"SHSW-21#32B122#1","3412":38400,"3420":32000,"Uri-Path":"cit/s"} / {"G":[[0,112,1],[0,122,0],[0,111,0]]}

Bedeutet das ein Update vom Shelly Gerät gekommen ist. das in klammern am Ende sind die Datenpunkte und die Werte. Falls eine Meldung mit "CoAP data ignored" steht dann ist es eine Wiederholung einer vorherigen Nachricht die aussortiert wurde.

Wenn sich ein Wert ändert hast Du nach dem obigen immer ein

debug: shelly.0 Status update received for SHSW-21#32B122#1: {"G":[[0,112,0],[0,122,0],[0,111,0]]}
debug: shelly.0 stateChange shelly.0.SHSW-21#32B122#1.Relay0.Switch {"val":false,"ack":true,"ts":1543938865354,"q":0,"from":"system.adapter.shelly.0","lc":1543938865354}

was bedeutet das der Adapter einen State Wert aktualisiert hat. Den müsstest Du dann auch sehen. In dem Fall heisst ein "statechanged" mit eiune "ack:true" das der Adapter den Wert geschrieben hat der vom Device kam. Ein "ack:false" wäre eine Schaltaktion die du per ioBroker ausgelöst hast und die an das Gerät gesendet wird (da kommen dann diese "REST Response" Zeilen dahinter). Dann sollte aber vom Shelly eine "Bestätigung" wieder in Forum eines "ack:true" stateChange kommen.

Die Beschreibung das Werte nicht aktualisiert werden bzw "mit starker verzögerung" wäre das erste was zu prüfen ist. Je nachdem wo Ihr das prüft (Im Admin unter "Objekte"? oder wo) könnten auch verzögerungen gar nicht am Adapter sondern am Admin liegen!

Also bitte teste mal noch etwas rum und für jede Änderung die du machst solltest Du ein "Status update received" geforgt von einem "stateChange" im log bekommst!
Am besten schau Dir das Logfile auf der Platte unter /opt/iobroker/log/iobroker..log an (mit tail -f an der Shell.
Dann mache was und schaue ob und wann die Dinge kommen. Wenn Du parallel dein Admin offen hast sollte die Aktualisierung im Admin auch parallel zum Log da sein. Ich würde gern sicherstellen das Logfile und Admin passen nicht das der Fehler beim Datenupdate im Admin liegt!

@Daniel110382
Copy link

ja ich prüfe die werte unter Admin in Objekte

@stefan-sylt
Copy link
Author

stefan-sylt commented Dec 4, 2018 via email •
edited

@stefan-sylt
Copy link
Author

stefan-sylt commented Dec 4, 2018 via email

@Daniel110382
Copy link

hi stefan,

sind deine shellys direkt mit deinem router verbunden oder über einen repeater?

@stefan-sylt
Copy link
Author

stefan-sylt commented Dec 4, 2018 via email •
edited

@Daniel110382
Copy link

ok. dann kann es schon mal nicht an meinem repeater liegen. vielen dank

@Daniel110382
Copy link

mich wundert es das es sofort nach neustart des shelly adapters wieder funktioniert ein paar mal.

@Apollon77
Copy link
Member

Ok, dann schauen wir die nächste Ebene und finden heraus ob es dam Adapter Prizess liegt oder am Shelly/Netzwerk.

Sicherstellen das nodejs installiert ist.
Das folgende Skript als Datei speichern:

var PORT = 5683;
var HOST; // = '127.0.0.1';

var dgram = require('dgram');
var server = dgram.createSocket('udp4');

server.on('listening', function () {
    var address = server.address();
    console.log('UDP Server listening on ' + address.address + ":" + address.port);

    server.setMulticastLoopback(true);
    server.addMembership('224.0.1.187');
});

server.on('message', function (message, remote) {
    console.log(remote.address + ':' + remote.port +' - ' + message.toString('ascii'));
});

server.bind(PORT, HOST);

Wenn man jetzt das skript startet (node ) dann empfängt es auch die ganzen Shelly UDP Pakete. Da ist bissl unlesbarer kram dabei aber das ist ok, man sieht genug das man es vergleichen könnte.

Also: Vergleichen der Ausgaben vom Skript mit dem was im Log auftaucht (bitte Logfile auf Platte als Referenz nehmen). Wenn das Skript auch nichts ausgibt wenn der Adapter pause macht ist schonmal klar das es nicht am Adapter liegt sondern bei dem Host die Daten nicht ankommen.

Jetzt (für den Fall Ihr habt einen zweiten Host mit nodejs im gleichen Netzwerk) könntet Ihr versuchen was der an paketen empfängt und auch hier vergleichen.

@Daniel110382
Copy link

Hi Apollon,
würde gerne das probieren wo du geschrieben hast. leider bin ich wie gesagt noch neuling auf diesem gebiet. trotz alledem möchte ich gerne helfen.
wenn dir die zeit mit mir wert ist könntest du es mir erklären was ich genau machen muss. gerne bin ich auch telefonisch erreichbar oder könnte dich auch anrufen.
ich versuche jetzt mal das zu irgendwie hin zu bekommen was du da geschrieben hast.
muss mich halt erst mal im forum schlau machen wie das alles geht.

@Apollon77
Copy link
Member

Hey, bin momentan leider unterwegs nur sporadisch erreichbar. :-(

Am besten auf dem Rechner vom iobroker einfach im deinem User Verzeichnis ein neues file filename.js anlegen mir dem Inhalt von oben. Und dann an der Shell „node filename.js“ und laufen lassen. Zweites ssh Fenster das tail -f auf das iobroker log. Das muss dann zusammenpassen. Und dann ist die frage was passiert wenn nichts mehr kommt obwohl es eine Aktion am Gerät gab. In beiden Fenstern keine neuen Ausgaben oder anders?

@Daniel110382
Copy link

bekomme jetzt diese fehlermeldung.
muss ich in dem skript noch etwas ändern?
unbenannt

@Apollon77
Copy link
Member

öääähmm ... ja mist geht doch nicht auf dem gleichen host wie der Adapter :-( könntest den Adapter stoppen und dann schauen ob Du das gleiche problem nachstellen kannst Wo auch hier keine Dsaen ankommen

@Daniel110382
Copy link

ok also habe jetzt den adapter beendet und den skript mal gute 10 min. laufen lassen und jetzt kommen keine daten mehr an. stillstand

@Apollon77
Copy link
Member

Dann sieht es mal so aus als ob die Daten weg bleiben. :-(
Dann ist was mal nicht der Adapter sondern Netzwerk oder shelly :-(

@Apollon77
Copy link
Member

Hast du noch einen zweiten Host wo du nodejs installieren kannst? Geht auch unter Windows oder so

@Daniel110382
Copy link

nein habe ich leider nicht.

@Daniel110382
Copy link

habe jetzt 3 mal den adapter neu gestartet und mir ist dabei aufgefallen das die daten immer für ca 6 min. gesendet werden.

  1. versuch 5:46 min.
  2. versuch 6:11 min.
  3. versuch 7:03 min.

Kann es vielleicht irgendwie sein das da ein speicher voll wird und er diesen nicht löscht weil er voll wird?
weil wenn ich den shelly adapter dann wieder neu starte geht es wieder so um die 6 min.

@Daniel110382
Copy link

also hab jetzt weiter getestet und immer das selbe. 6-7 min. geht es

@Apollon77
Copy link
Member

Such mit dem extra Skript anstelle Adapter?

@Apollon77
Copy link
Member

Auch ;-)

@Daniel110382
Copy link

ja auch bei dem skript

  1. 6:10 min.
  2. 7:38 min.

@schmupu
Copy link
Contributor

schmupu commented Dec 5, 2018

@Daniel110382 , sobald Du das Skript oder den Adapter neu startest funktioniert es wieder für ein paar Minuten? Ist der Raspberry über LAN oder WLAN mit der Fritzbox verbunden?

@Daniel110382
Copy link

ja genau sobald ich den adapter neu starte funtioniert er wieder für 6-7 min. der pi ist über lan am router verbunden

@schmupu
Copy link
Contributor

schmupu commented Dec 5, 2018

hast Du irgendwie eine Möglichkeit das Skript von @Apollon77 auf einem anderen Rechner (Macbook, PC, ....) zu starten? Würde mich interessieren ob sich die Verbindung dann auch verabschiedet? Wie viele Shellys hast Du und welche? Firmware? Standardeinstellungen in der Shelly App oder irgendetwas verändert?

@stefan-sylt
Copy link
Author

stefan-sylt commented Dec 6, 2018 via email

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018 •
edited

@Stefan, @daniel, könnt ihr sagen welchen raspi ihr nutzt und wie das Netzteil dimensioniert ist (grösser 2 Ampere)?
Welche nodejs Version Nutzt ihr?

@Daniel110382
Copy link

Raspberry Pi 3 b+
2.5A Netzteil
nodejs ist v8.14.0

@Daniel110382
Copy link

hab jetzt auch mal alle shellys im netzwerk auf werkseinstellungen zurück gestellt und alle neu angelernt. dann adapter und instanz gelöscht und wieder neu installiert leider ohne erfolg. gleicher fehler weiterhin

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

Wenn ich es richtig verstehe, ist der raspi über LAN direkt mit der Frizzbox verbunden . Welche Fritzbox habt ihr im Einsatz?

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

Und bitte unbedingt das Testprogramm einmal auf einem anderem Rechner als dem Raspi ausführen. Auch wir der Raspi mit direkter LaN Verbindung zur Fritzbox

@Daniel110382
Copy link

ich habe keine fritzbox. es ist ein router von a1 er heißt adb vv5522.
download

@Daniel110382
Copy link

mein Raspi steckt direkt über lan am router

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018 •
edited

ich glaube der Router verwirft die Multcast Pakete nach einer Weile. Das Problem gibt es anscheinend häufiger.

https://stackoverflow.com/questions/53250192/multicast-udp-stop-receiving-after-a-while-on-a-raspberry

Kannst du am Router irgendwelche IGMP Einstellungen vornehmen?

@Daniel110382
Copy link

habe nichts mit igmp einstellungen gefunden. bin alle reiter im router durchgegangen

@Daniel110382
Copy link

unbenannt

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

okay, das sieht nicht so, als ob man da etwas einstellen kann. Hast Du beim Raspberry ipv6 enabled? Bei Google schreiben einige, dass sie das Problem beheben konnten indem sie ipv6 disabled haben.

Ihr könnt einmal folgendes versuchen.

sudo  sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo  sysctl -w net.ipv6.conf.default.disable_ipv6=1

wenn Ihr jetzt ip a oder ifconfig solltet ihr nichts mehr mit inet6 findet! Jetzt bitte nochmals das Script von @Apollon77 starten. Ich bin gespannt.

ipv6 könnt ihr so enablen

sudo  sysctl -w net.ipv6.conf.all.disable_ipv6=0
sudo  sysctl -w net.ipv6.conf.default.disable_ipv6=0

@Daniel110382
Copy link

hilfe was hat er denn jetzt der adapter. alle paar sekunden neustart

2018-12-06 20:54:15.059 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"default_state":"off","btn_type":"edge","btn_reverse":1,"auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.064 - �[34mdebug�[39m: shelly.0 Initialize device SHSW-21#32B122#1 (7 now known)
2018-12-06 20:54:15.067 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"default_state":"off","btn_type":"edge","btn_reverse":1,"auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.069 - �[34mdebug�[39m: shelly.0 Initialize device SHSW-1#32C7A6#1 (7 now known)
2018-12-06 20:54:15.073 - �[34mdebug�[39m: shelly.0 Initialize device SHSW-1#059928#1 (7 now known)
2018-12-06 20:54:15.077 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.079 - �[34mdebug�[39m: shelly.0 Initialize device SHSW-1#5B2FBB#1 (7 now known)
2018-12-06 20:54:15.080 - �[34mdebug�[39m: shelly.0 stateChange shelly.0.SHSW-21#5B2971#1.Relay1.Switch {"val":false,"ack":true,"ts":1544126055068,"q":0,"from":"system.adapter.shelly.0","lc":1544125808160}
2018-12-06 20:54:15.080 - �[34mdebug�[39m: shelly.0 stateChange shelly.0.SHSW-21#5B2971#1.Power {"val":0,"ack":true,"ts":1544126055076,"q":0,"from":"system.adapter.shelly.0","lc":1544125808209}
2018-12-06 20:54:15.083 - �[34mdebug�[39m: shelly.0 Initialize device SHSW-21#5B2971#1 (7 now known)
2018-12-06 20:54:15.086 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.087 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.089 - �[34mdebug�[39m: shelly.0 Initialize device SHSW-1#0589E4#1 (7 now known)
2018-12-06 20:54:15.089 - �[34mdebug�[39m: shelly.0 stateChange shelly.0.SHSW-21#5B2971#1.hostname {"val":"shellyswitch-5B2971","ack":true,"ts":1544126055083,"q":0,"from":"system.adapter.shelly.0","lc":1544125808220}
2018-12-06 20:54:15.339 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"default_state":"off","btn_type":"edge","btn_reverse":1,"auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.410 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.411 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.414 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.715 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:15.946 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:16.131 - �[34mdebug�[39m: shelly.0 REST Response {"name":null,"ison":false,"has_timer":false,"overpower":false,"default_state":"off","btn_type":"edge","auto_on":0,"auto_off":0,"schedule":false,"schedule_rules":[],"sun":false,"sun_on_times":"0000000000000000000000000000","sun_off_times":"0000000000000000000000000000"}
2018-12-06 20:54:16.799 - �[34mdebug�[39m: shelly.0 CoAP data ignored: {"3332":"SHSW-21#32BEFC#1","3412":38400,"3420":9728,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,111,0]]}
2018-12-06 20:54:17.184 - �[34mdebug�[39m: shelly.0 CoAP data ignored: {"3332":"SHSW-1#059928#1","3412":38400,"3420":9472,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]}
2018-12-06 20:54:21.799 - �[34mdebug�[39m: shelly.0 CoAP status package received: {"3332":"SHSW-1#05878C#1","3412":38400,"3420":6400,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]}
2018-12-06 20:54:21.800 - �[34mdebug�[39m: shelly.0 Status update received for SHSW-1#05878C#1: {"G":[[0,112,0]]}
2018-12-06 20:54:21.800 - �[34mdebug�[39m: shelly.0 CoAP device description request for SHSW-1#05878C#1 to 10.0.0.4(0)
2018-12-06 20:54:21.802 - �[34mdebug�[39m: shelly.0 Connection update received for SHSW-1#05878C#1: true
2018-12-06 20:54:22.204 - �[34mdebug�[39m: shelly.0 CoAP data ignored: {"3332":"SHSW-1#32C7A6#1","3412":38400,"3420":10496,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]}
2018-12-06 20:54:23.118 - �[34mdebug�[39m: shelly.0 CoAP data ignored: {"3332":"SHSW-1#5B2FBB#1","3412":38400,"3420":12032,"Uri-Path":"cit/s"} / {"G":[[0,112,0]]}
2018-12-06 20:54:23.684 - �[34mdebug�[39m: shelly.0 CoAP data ignored: {"3332":"SHSW-21#5B2971#1","3412":38400,"3420":19712,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,111,0]]}
2018-12-06 20:54:23.802 - �[34mdebug�[39m: shelly.0 CoAP device description request for SHSW-1#05878C#1 to 10.0.0.4(1)
2018-12-06 20:54:25.804 - �[34mdebug�[39m: shelly.0 CoAP device description request for SHSW-1#05878C#1 to 10.0.0.4(2)
2018-12-06 20:54:27.536 - �[34mdebug�[39m: shelly.0 CoAP data ignored: {"3332":"SHSW-21#32B122#1","3412":38400,"3420":3073,"Uri-Path":"cit/s"} / {"G":[[0,112,0],[0,122,0],[0,111,0]]}
2018-12-06 20:54:27.807 - �[34mdebug�[39m: shelly.0 Create device object for undefined if not exist
2018-12-06 20:54:27.808 - �[34mdebug�[39m: shelly.0 Create state object for undefined.online if not exist
2018-12-06 20:54:27.824 - �[31merror�[39m: shelly.0 uncaught exception: "name" argument must be a string
2018-12-06 20:54:27.825 - �[31merror�[39m: shelly.0 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.getDeviceDescription (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:939:9)
at ShellyIot.getDeviceDescription (/opt/iobroker/node_modules/shelly-iot/index.js:198:32)
at Timeout.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/shelly-iot/index.js:218:22)
at ontimeout (timers.js:498:11)
at tryOnTimeout (timers.js:323:5)
at Timer.listOnTimeout (timers.js:290:5)
2018-12-06 20:54:27.840 - �[33mwarn�[39m: shelly.0 Exception: Error: "name" argument must be a string
2018-12-06 20:54:27.847 - �[34mdebug�[39m: shelly.0 connected set to false
2018-12-06 20:54:27.848 - �[34mdebug�[39m: shelly.0 stateChange shelly.0.info.connection {"val":false,"ack":true,"ts":1544126067829,"q":0,"from":"system.adapter.shelly.0","lc":1544126067829}
2018-12-06 20:54:27.889 - �[31merror�[39m: Caught by controller[0]: Error: "name" argument must be a string
2018-12-06 20:54:27.891 - �[31merror�[39m: Caught by controller[0]: at Resolver.getHostByAddr [as reverse] (dns.js:238:13)
2018-12-06 20:54:27.891 - �[31merror�[39m: Caught by controller[0]: at createDeviceStates (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:635:7)
2018-12-06 20:54:27.891 - �[31merror�[39m: Caught by controller[0]: at shelly.getDeviceDescription (/opt/iobroker/node_modules/iobroker.shelly/shelly.js:939:9)
2018-12-06 20:54:27.892 - �[31merror�[39m: Caught by controller[0]: at ShellyIot.getDeviceDescription (/opt/iobroker/node_modules/shelly-iot/index.js:198:32)
2018-12-06 20:54:27.892 - �[31merror�[39m: Caught by controller[0]: at Timeout.setTimeout [as _onTimeout] (/opt/iobroker/node_modules/shelly-iot/index.js:218:22)
2018-12-06 20:54:27.892 - �[31merror�[39m: Caught by controller[0]: at ontimeout (timers.js:498:11)
2018-12-06 20:54:27.893 - �[31merror�[39m: Caught by controller[0]: at tryOnTimeout (timers.js:323:5)
2018-12-06 20:54:27.893 - �[31merror�[39m: Caught by controller[0]: at Timer.listOnTimeout (timers.js:290:5)
2018-12-06 20:54:27.893 - �[31merror�[39m: host.raspberrypi instance system.adapter.shelly.0 terminated with code 0 (OK)
2018-12-06 20:54:27.894 - �[32minfo�[39m: host.raspberrypi Restart adapter system.adapter.shelly.0 because enabled

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

Fehler kommt, seit dem Du ipv6 deaktiviert hast? Was passiert wenn Du den Raspi komplett bootest?

@Daniel110382
Copy link

ne habe vorhin mal den adapter neu installiert seit dem habe ich es

@Daniel110382
Copy link

dieser fehler kommt jetzt wenn ich den adapter installiert habe und die instanz hinzufügen will.
was ist das für ein fehler?

ERR! Invalid response body while trying to fetch https://registry.npmjs.org/har-validator: Integrity verification failed for sha512-u80+ruKigcnvL6u/AoCX4VoySNRw/yaCULQ0FVtoaNxXo2kozbil7jI1D5wIQoPyUZwTSs7+t0lcDxrlrXBqnw== (/root/.npm/_cacache/content-v2/sha512/bb/cd/3eaee2a281c9ef2fabbf028097e15a3248d470ff268250b434155b6868dc57a36928cdb8a5ee32350f9c084283f2519c134acefeb7495c0f1ae5ad706a9f)
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2018-12-06T20_09_39_125Z-debug.log

Cannot install iobroker.shelly: 1
ERROR: process exited with code 25

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

Mist, das war nicht notwendig, da der Fehler nicht am Adapter liegt. Sonst würde das Testprogramm nicht gleich reagieren.

@Daniel110382
Copy link

macht nix hab jetzt das backup von gestern drauf gemacht.. jetzt läuft es wieder. so werde jetzt mal das mit dem ipv6 testen

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

Super, ich kann leider erst morgen weiter schauen. Muss morgen leider ausnahmsweise um 4 aufstehen und Lehre mich jetzt schlafen.

@Daniel110382
Copy link

hmm.. hat doch nicht geklappt.. er resetet alle paar sekunden neu immer noch gleicher fehler..
kein problem.. dann schlaf mal schön

@schmupu
Copy link
Contributor

schmupu commented Dec 6, 2018

Kannst ja den Shelly Adapter stoppen. Ipv6 deaktivieren und das Programm von @appollon77 starten. Mal sehen ob es nach ein paar Minuten weiterhin keine Daten liefert

@Daniel110382
Copy link

ok.. habe endlich meinen fehler gefunden.

ich hatte bei instanzen unter shelly einstellungen den benuternamen und das passwort von der shelly cloud eingegeben das war mein fehler. dort darf man nur unter benutzernamen: admin eingeben und beim passwort nichts eingeben.
seitdem läuft es ohne probleme.

@schmupu
Copy link
Contributor

schmupu commented Dec 10, 2018 •
edited

Danke für die Info. Dann schließe ich den Issue! Viel Spaß mit dem Adapter

Sent with GitHawk

@schmupu schmupu closed this as completed Dec 10, 2018
@tbenx99 tbenx99 mentioned this issue Jan 27, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@Apollon77 @stefan-sylt @schmupu @Daniel110382