Test js-controller v2.0.x (GitHub)
-
Zu meinem Backup Problem.
Umzug Rock64 Master auf Intel NUC (Debian) . (Js-controller 2.0.17)
Nach langem hin und her läuft das System jetzt einigermaßen.
Mein ioBroker hat Probleme einige "vis" npm Pakete zu installieren (ab ca. 20.30 Uhr) . Anbei der aktuelle log. iobroker.2019-10-01.log
-
@Stuebi Danke. Schaut gut aus kein Fehler und die History sachen rasen bei Debug sauber durch.
-
@ChrisXY , Klasse dann publishe ich das nachher auf npm
-
@apollon77 also Redis scheint zu klappen.
Habe den Redis im selben Docker. Ping ist möglich und auch root@iobroker:/opt/iobroker# redis-cli -h 192.168.2.203 ping
PONGSollte also nicht das problem sein ?
-
@lobomau Zwei Dinge dazu:
iobroker status liefert die Info ob das ipBroker-System läuft. Auf einem Slave gestartet mit einem laufenden Master wird immer die Meldung sein "iobroker running" weil der Master läuft.
Um das Update einzuspielen reicht es aber wenn der Slave beendet ist.
Zu deinem Fehler: Siehe oben erster Beitrag. Leider gibt es diesen Fehler aktuell wegen NPM-foo ... "sudo -u iobroker -H nom install ioBroker/ioBroker.js-controller" ausführen. Das tut wohl
-
@darkiop Also das darf an sich nicht passieren. Ja, nach dem Restore sind erstmal alle Adapter ausser Admin deaktiviert. Kann er bei änderungen das objects.json File (glaube bist ja nicht auf Redis) neu schreiben? Nicht das da was kaputt ist. Wenn Du den Adapter im Admin wieder aktivierst muss das persistiert werden ... Schau mal ob sich das File Date ändert.
-
@apollon77 top. Installation scheint zu laufen. Danke.
-
@darkiop Ok, das war alles super. Ich habe gefunden das "ioredis" (Die Redis Protokoll Lib) default "family" IPv4 hat ... mal schauen was ich da setzen kann ... Ich mache gleich eine neue Version, bitte damit neu testen, damit sollten an sich beide gehen (laut doku
) -
@e-i-k-e Da steht überall Version 1.2.1 ... das kann nicht passen. Am besten installiere einfach die "npm latest" version entweder per npm direkt oder per Admin neu.
-
-
Version 2.0.18 ist auf GitHub, und sollte jetzt IPv4 UND IPv6 machen ... please check
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
Lass doch mal in Debug Modus laufen und schau mal log an
-
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
Beides, also bei #257 auch
.bind(adapter), und in beiden Verzeichnissen.@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
Lass doch mal in Debug Modus laufen und schau mal log an
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
Zeigt er aber die URL n die er anfragt? Versuch doch mal diese im Browser oder mit "curl" abzurufen.Dann siehst Du ja ob er es generell nicht lädt oder so?!
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Beides, also bei #257 auch .bind(adapter), und in beiden Verzeichnissen.
Ok, ich habe Frank nochmals kontaktiert, ggf baue ich eine 2.0.1 für npm mit dem Fix dann ... Sehen wir mal
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
Zeigt er aber die URL n die er anfragt? Versuch doch mal diese im Browser oder mit "curl" abzurufen.Dann siehst Du ja ob er es generell nicht lädt oder so?!
Die API-URLs zeigt er an, ich kann sie auch aufrufen per Browser/Curl und es stehen Daten drin. Muss wohl morgen, ähh heute, mal paar Debugs einbauen wo er denn hängen bleibt. Eigentlich sind genügend try/catch drin, dass er wenigstens irgendwo mal meckern müsste...
-
@SBorg urig mal debug log bitte. Ich könnte mir auch vorstellen das irgendwo ein Callback nicht korrekt ist. Also am besten issue beim Adapter mit dem debug log.
-
Hier mal das Debug-Log, Issue mache ich dann heute früh dazu:
2019-10-01 19:26:02.883 - debug: daswetter.0 (23979) Redis Objects: Use Redis connection: 127.0.0.1:9001 2019-10-01 19:26:03.100 - debug: daswetter.0 (23979) objectDB connected 2019-10-01 19:26:03.108 - debug: daswetter.0 (23979) Redis States: Use Redis connection: 127.0.0.1:9000 2019-10-01 19:26:03.114 - debug: daswetter.0 (23979) Objects connected to redis: 127.0.0.1:9001 2019-10-01 19:26:03.129 - debug: daswetter.0 (23979) statesDB connected 2019-10-01 19:26:03.196 - debug: daswetter.0 (23979) States connected to redis: 127.0.0.1:9000 2019-10-01 19:26:04.073 - info: daswetter.0 (23979) starting. Version 2.8.1 in /opt/iobroker/node_modules/iobroker.daswetter, node: v8.16.1 2019-10-01 19:26:04.134 - debug: daswetter.0 (23979) set timeout to 60 sec 2019-10-01 19:26:04.135 - debug: daswetter.0 (23979) using new data structure 2019-10-01 19:26:04.138 - debug: daswetter.0 (23979) calling forecast 7 days: http://api.daswetter.com/index.php?api_lang=de&localidad=xxx&affiliate_id=xxx 2019-10-01 19:26:04.496 - debug: daswetter.0 (23979) 7 days forecast done, objects in list 107 2019-10-01 19:26:04.499 - debug: daswetter.0 (23979) calling forecast 5 days: http://api.daswetter.com/index.php?api_lang=de&localidad=xxx&affiliate_id=xxx&v=2.0 2019-10-01 19:26:04.892 - debug: daswetter.0 (23979) 5 days forecast done, objects in list 1059 2019-10-01 19:26:04.896 - debug: daswetter.0 (23979) calling forecast hourly: http://api.daswetter.com/index.php?api_lang=de&localidad=xxx&affiliate_id=xxx&v=2.0&h=1 2019-10-01 19:26:05.797 - debug: daswetter.0 (23979) hourly forecast done, objects in list 2699 2019-10-01 19:26:05.801 - debug: daswetter.0 (23979) objects in list: 2699 2019-10-01 19:27:04.135 - error: daswetter.0 (23979) force terminate, objects still in list: 1777 2019-10-01 19:27:04.184 - error: host.Ubuntu instance system.adapter.daswetter.0 terminated with code 15 (15)
