[Diskussion] js-controller 1.5.8 im Latest Repository

SBorg

Dann mal btt: 1.5.8 lüppt bisher problemlos

Stuebi

Hatte mit dem TR 064 und Find my iPhone Adapter.

2019-05-08 11:29:50.703 - error: Caught by controller[0]: /opt/iobroker/node_modules/soef/soef.js:1383
2019-05-08 11:29:50.703 - error: Caught by controller[0]: fns.adapter = fns.adapter(options);
2019-05-08 11:29:50.703 - error: Caught by controller[0]: ^
2019-05-08 11:29:50.704 - error: Caught by controller[0]: TypeError: fns.adapter is not a function
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at Object.exports.Adapter (/opt/iobroker/node_modules/soef/soef.js:1383:23)
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at Object. (/opt/iobroker/node_modules/iobroker.find-my-iphone/find-my-iphone.js:15:20)
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at Module._compile (module.js:653:30)
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at Object.Module._extensions..js (module.js:664:10)
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at Module.load (module.js:566:32)
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at tryModuleLoad (module.js:506:12)
2019-05-08 11:29:50.704 - error: Caught by controller[0]: at Function.Module._load (module.js:498:3)
2019-05-08 11:29:50.705 - error: Caught by controller[0]: at Function.Module.runMain (module.js:694:10)
2019-05-08 11:29:50.705 - error: Caught by controller[0]: at startup (bootstrap_node.js:204:16)
2019-05-08 11:29:50.705 - error: Caught by controller[0]: at bootstrap_node.js:625:3
2019-05-08 11:29:50.705 - error: host.iobroker instance system.adapter.find-my-iphone.0 terminated with code 1 ()

geholfen hat bei mir wie oben schon beschrieben

# TR 064
cd /opt/iobroker/node_modules/iobroker.tr-064
npm install soef

# Find my iPhone
cd /opt/iobroker/node_modules/iobroker.find-my-iphone/
npm install soef

VG
Stübi

apollon77

Wenn ein update der soef Lib hilft cool! Ich hatte mich in die Adapter schonmal reingearbeitet teilweise und dabei festgestellt das das ggf nicht immer hilft.

Ja wir sind gerade dabei die Adapter in die Adapter-Community zu übernehmen, alle wieder fit zu machen, zu testen und neu zu releasen. Leider wird das dann aber unter neuem Namen sein Aber das ist (auch wegen der Soef-Lib) alles nicht ganz so simpel und wird daher etwas dauern.

justr

Hallo Community,

nach Upgrade auf 1.5.8 kann ich nicht mehr über die externe URL (fgljpxxxxxxxxx.myfritz.net) auf Admin zugreifen.
D.h. es funktioniert:
https://localhost:port
https://interneIP:port
https://externeIP:port

Es funktioniert nicht:
https://externeURL:port

Da die externe IP funktioniert kann es nicht am Port-Forwarding liegen und da ich über die externe URL immer noch auf meine FritzBox komme, liegt es auch nicht am DNS.

Interessanterweise hilft auch ein Downgrade auf 1.5.7. nichts. Nach etwas Probieren bin ich nun auf Greenlock (Let's encrypt) als Ursache gestoßen. Die 1.5.7 kam mit greenlock@2.6.8, die 1.5.8 mit greenlock@2.7.18 und ein Downgrade auf 1.5.7 hat die greenlock-Version auf 2.7.18 belassen. Durch Testen habe ich nun die Version 2.7.1 als letzte funktionierende Version ermittelt.

Meine Lösung also:
cd <iobroker> (bei mir am Mac "cd /usr/local/iobroker")
cd node_modules/iobroker.js-controller
npm i greenlock@2.7.1

Hoffe das hilft dem ein oder anderen weiter und hilft bei der Korrektur.

Viele Grüße
justr

apollon77

@justr Legst DU bitte ein GitHub Issue dazu an. Und super Erkenntnisse!!

apollon77

Wir haben gerade eine 1.5.9 auf npm released, welche die greenlock 2.7.1 festpinnt. Bitte nochmal updaten und ansehen.

Das wäre dann die Version die wir gern zeitnah auch ins Stable schieben würden.

Vielen Dank an Euch schonmal und auch an @justr für das exakte rausfinden der funktionierenden greenlock Version!

Ingo

justr

Die 1.5.9 funktioniert bei mir wunderbar. Es wird ein Downgrade auf greenlock@2.7.1 durchgeführt und damit funktioniert auch wieder der Zugriff über die DynIP-Domain.

Ich verstehe lediglich nicht, warum greenlock immer (auch zuvor schon) doppelt installiert wird. Einmal in ".../iobroker/node_modules/iobroker.js-conroller/node_modules/greenlock" und einmal (extraneous) in "iobroker/node_modules/greenlock".

MacMini13:iobroker justr$ npm list greenlock
iobroker.inst@2.0.2 /usr/local/iobroker
├── greenlock@2.7.1  extraneous
└─┬ iobroker.js-controller@1.5.9
  └── greenlock@2.7.1 

npm ERR! extraneous: greenlock@2.7.1 /usr/local/iobroker/node_modules/greenlock

Das ändert aber erwartungsgemäß nichts an der Funktion.

Vielen Dank
justr

arteck

@justr einmal global und einmal im Adapter.. solltest den globalen entfernen iobroker/node_modules/greenlock

justr

Schon klar, aber beim nächsten Update des js-controllers wird er halt auch wieder global installiert.

e-i-k-e

Moin,

ich betreibe ein Master/Slave System (Master Rock64, Slave 5x Raspberry).

Die Slave laufen aktuell auf 1.5.7, den Master musste ich nach einem Crash (defekte SD-Karte anschließend Wechsel auf SSD) neu aufsetzen, somit läuft auf diesem die Version 1.4.2.

ioBroker war nach einem Update auf 1.5.7 und auch 1.5.8 nicht mehr über den Browser zu erreichen. Nach etlichen "Reparatur" versuchen und auch einem erfolglosen downgrade auf 1.4.2 hilft noch ein neu aufsetzen von oBroker.
Ich erhielt unter anderem öfter die Fehlermeldung.

root@ioBroker-Rock:~# cd /opt/iobroker
root@ioBroker-Rock:/opt/iobroker# node node_modules/iobroker.js-controller/contr            oller.js --logs
2019-05-08 00:04:50.074  - info: host.ioBroker-Rock iobroker.js-controller versi            on 1.5.7 js-controller starting
2019-05-08 00:04:50.083  - info: host.ioBroker-Rock Copyright (c) 2014-2018 blue            fox, 2014 hobbyquaker
2019-05-08 00:04:50.084  - info: host.ioBroker-Rock hostname: ioBroker-Rock, nod            e: v8.16.0
2019-05-08 00:04:50.091  - info: host.ioBroker-Rock ip addresses: 192.168.3.100             fe80::343d:a2d2:99a1:e291
2019-05-08 00:04:50.531  - info: host.ioBroker-Rock  inMem-states listening on p            ort 9000
2019-05-08 00:04:52.848  - info: host.ioBroker-Rock  inMem-objects listening on             port 9001
2019-05-08 00:04:52.880  - error: Another instance is running or some applicatio            n uses port!
2019-05-08 00:04:52.882  - error: uncaught exception: listen EADDRINUSE 0.0.0.0:            9000
2019-05-08 00:04:52.898  - info: host.ioBroker-Rock terminated
2019-05-08 00:04:52.954  - info: iobroker _restart
listen EADDRINUSE 0.0.0.0:9001
Error: listen EADDRINUSE 0.0.0.0:9001
    at Server.setupListenHandle [as _listen2] (net.js:1360:14)
    at listenInCluster (net.js:1401:12)
    at doListen (net.js:1510:7)
    at _combinedTickCallback (internal/process/next_tick.js:142:11)
    at process._tickCallback (internal/process/next_tick.js:181:9)
    at Function.Module.runMain (module.js:696:11)
    at startup (bootstrap_node.js:204:16)
    at bootstrap_node.js:625:3

@apollon77 said in [Diskussion] js-controller 1.5.8 im Latest Repository:

On Master/Slave systems please start updating master and the slaves afterwards
Required versions of adapters (only if used) for normal functionality: javascript >= 3.6.5, dasWetter >= 2.7.1, upnp >= 1.0.4
(bluefox) Breaking changes: "][*,;'"`<>?" are no more allowed in IDs

Kann es etwas damit zu tun haben, dass sich die Slave bereits auf Version 1.5.7 befinden und ich den Master erst auf diese Version bringen möchte?

apollon77

@justr npm magie :-)) Neuere npm Versionen versuchen an sich alles global zu packen, nur wenn es da Versionskonflikte gibt landen Dinge lokal.

Man kann "npm dedupe" (https://docs.npmjs.com/cli/dedupe.html) Versuchen, dann macht er genau das für "gewachsene Strukturen"

apollon77

@e-i-k-e Also 1.5.7 und 1.5.8 sind da kompatibel. auch in deinem Fall hast DU ja quasi die Slaves vorher aktuell gehabt als den Master. Also auch das ist ok.

Die Frage ist warum bei Dir Port 9000 belegt war. Das musst Du rausfinden. ggf lief da noch ein prozess oder ein anderes Programm hat den Port blockiert.

e-i-k-e

@apollon77 said in [Diskussion] js-controller 1.5.8 im Latest Repository:

@e-i-k-e Also 1.5.7 und 1.5.8 sind da kompatibel. auch in deinem Fall hast DU ja quasi die Slaves vorher aktuell gehabt als den Master. Also auch das ist ok.

Die Frage ist warum bei Dir Port 9000 belegt war. Das musst Du rausfinden. ggf lief da noch ein prozess oder ein anderes Programm hat den Port blockiert.

Ich habe das Problem nicht lösen können.
Zwei mal versucht (mit neuem ioBroker) und zwei mal den selben Fehler.
Darf ich dich über PN kontaktieren?

Stabilostick

@e-i-k-e

Wenn Du magst, schaue ich gerne mal nach. Habe Dir eine PN geschrieben. Wir hatten schon einmal Kontakt.

BBTown

@apollon77 sagte in [Diskussion] js-controller 1.5.8 im Latest Repository:

Wir haben gerade eine 1.5.9 auf npm released,

läuft auf anhieb sauber bei mir

eumats

Läuft bei mir auch stabil...

marcuskl

Bei mir seit dem update auf 1.5.9 hängt alles, es läuft alles sehr langsam und alles spinnt

sigi234

Läuft bei mir auch stabil...

apollon77

@marcuskl Hast Du ein paar Mehr Details? Mal gestoppt und alle Prozesse ggf gekillt oder reboot gemacht?

SBorg

Lüppt nun seit mehreren Stunden problemlos

NEWS

[Diskussion] js-controller 1.5.8 im Latest Repository

Support us

777
Online

31.7k
Users

79.9k
Topics

1.3m
Posts

NEWS

[Diskussion] js-controller 1.5.8 im Latest Repository

Support us

777Online

31.7kUsers

79.9kTopics

1.3mPosts

777
Online

31.7k
Users

79.9k
Topics

1.3m
Posts