js-controller 4.0 jetzt im BETA/LATEST!

[JohGre]

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr

Kann ich so nicht bestätigen: Shelly-Adapter 5.2.0 läuft bei mir

[amg_666]

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr

bei mir läuft der shelly 5.2.0 ohne Probleme mit js 4.0.12

[Johannes Bauerstatter]

@amg_666 welche Firmware habt ihr in den Shellies? Letzte Frage weil falscher Threads.

[da_Woody]

@johannes-bauerstatter bin zwar erst auf 4.0.10, aber keine probleme mit shelly.
ich hab 1.11.8, bis auf die H&T, die haben wieder 1.11.7...

[Diginix]

@johgre sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

js-controller 4.0.12 funktioniert der Shelly Adapter nicht mehr

Kann ich so nicht bestätigen: Shelly-Adapter 5.2.0 läuft bei mir

Bei mir auch alles ok mit Shelly 5.2 und js-c 4.0.12
Firmware sollte keine Rolle spielen zumindest bei Gen.1 Shellys.

[amg_666]

@johannes-bauerstatter sagte in js-controller 4.0 jetzt im BETA/LATEST!:

welche Firmware habt ihr in den Shellies?

1.11.8 auf allen Shellys

[Johannes Bauerstatter]

Vielen Dank. Nach mehrmaliger Neuinstallation funktioniert der Adapter wieder. Da hat's irgendwo anscheinend gehakelt.

[da_Woody]

@amg_666 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

1.11.8 auf allen Shellys

bei den H&T dürfte das wieder zurückgezogen worden sein. mir wurde wieder die 1.11.7 angeboten. hatte auch bei 2 von 10 WLAN aussetzer. nach ca 10min keine verbindung mehr...
zurück auf 1.11.7 keine aussetzer mehr.

[wendy2702]

So,

gerade problemlos upgrade meiner drei Produktiv iob installeátionen von 4.0.8 --> 4.0.12 gemacht.

Master läuft auf Proxmox, CPU nur kurz beim starten etwas erhöht, RAM nahezu unverändert:

rote linie zeigt den neustart.

Lediglich bei einem Slave bin ich etwas verwundert über das verhalten. Hier gab es zwar den BackitUp Adapter allerdings ohne Instanz. Die wurde mir 4.0.12 von alleine wieder angelegt.... ist das so gewollt?

pi@pi-iobroker:~ $ iob update
Used repository: Beta (latest)
Adapter    "admin"        : 5.3.0    , installed 5.3.0
Adapter    "backitup"     : 2.3.3    , installed 2.3.0  [Updatable]
Adapter    "discovery"    : 2.7.5    , installed 2.7.5
Controller "js-controller": 4.0.12   , installed 4.0.8  [Updatable]
Adapter    "modbus"       : 3.4.17   , installed 3.4.17
Adapter    "net-tools"    : 0.1.7    , installed 0.1.7
Adapter    "rpi2"         : 1.3.2    , installed 1.3.1  [Updatable]
Adapter    "smartmeter"   : 3.2.1    , installed 3.2.1
Adapter    "tr-064"       : 4.2.15   , installed 4.2.15
pi@pi-iobroker:~ $ iob upgrade self
Update js-controller from @4.0.8 to @4.0.12
Stopped Objects DB
Stopped States DB
NPM version: 6.14.16
Installing iobroker.js-controller@4.0.12... (System call)

> iobroker.js-controller@4.0.12 preinstall /opt/iobroker/node_modules/iobroker.js-controller
> node lib/preinstallCheck.js

NPM version: 6.14.16

> iobroker.js-controller@4.0.12 install /opt/iobroker/node_modules/iobroker.js-controller
> node iobroker.js setup first

object _design/system updated
host.pi-iobroker create instance backitup
host.pi-iobroker object system.adapter.backitup.0.alive created
host.pi-iobroker object system.adapter.backitup.0.connected created
host.pi-iobroker object system.adapter.backitup.0.compactMode created
host.pi-iobroker object system.adapter.backitup.0.cpu created
host.pi-iobroker object system.adapter.backitup.0.cputime created
host.pi-iobroker object system.adapter.backitup.0.memHeapUsed created
host.pi-iobroker object system.adapter.backitup.0.memHeapTotal created
host.pi-iobroker object system.adapter.backitup.0.memRss created
host.pi-iobroker object system.adapter.backitup.0.uptime created
host.pi-iobroker object system.adapter.backitup.0.inputCount created
host.pi-iobroker object system.adapter.backitup.0.outputCount created
host.pi-iobroker object system.adapter.backitup.0.eventLoopLag created
host.pi-iobroker object system.adapter.backitup.0.sigKill created
host.pi-iobroker object system.adapter.backitup.0.logLevel created
host.pi-iobroker object backitup.0.info created
host.pi-iobroker object backitup.0.info.latestBackup created
host.pi-iobroker object backitup.0.info.ccuNextTime created
host.pi-iobroker object backitup.0.info.iobrokerNextTime created
host.pi-iobroker object backitup.0.history created
host.pi-iobroker object backitup.0.history.html created
host.pi-iobroker object backitup.0.history.json created
host.pi-iobroker object backitup.0.history.ccuLastTime created
host.pi-iobroker object backitup.0.history.iobrokerLastTime created
host.pi-iobroker object backitup.0.history.ccuSuccess created
host.pi-iobroker object backitup.0.history.iobrokerSuccess created
host.pi-iobroker object backitup.0.oneClick created
host.pi-iobroker object backitup.0.oneClick.ccu created
host.pi-iobroker object backitup.0.oneClick.iobroker created
host.pi-iobroker object backitup.0.output created
host.pi-iobroker object backitup.0.output.line created
host.pi-iobroker Set default value of backitup.0.info.ccuNextTime: none
host.pi-iobroker Set default value of backitup.0.info.iobrokerNextTime: none
host.pi-iobroker Set default value of backitup.0.history.html: No backups yet
host.pi-iobroker Set default value of backitup.0.history.json: []
host.pi-iobroker Set default value of backitup.0.history.ccuLastTime: No backups yet
host.pi-iobroker Set default value of backitup.0.history.iobrokerLastTime: No backups yet
host.pi-iobroker Set default value of backitup.0.history.ccuSuccess: false
host.pi-iobroker Set default value of backitup.0.history.iobrokerSuccess: false
host.pi-iobroker Set default value of backitup.0.oneClick.ccu: false
host.pi-iobroker Set default value of backitup.0.oneClick.iobroker: false
host.pi-iobroker Set default value of backitup.0.output.line:
host.pi-iobroker object system.adapter.backitup.0 created
{

[apollon77]

@wendy2702 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Lediglich bei einem Slave bin ich etwas verwundert über das verhalten. Hier gab es zwar den BackitUp Adapter allerdings ohne Instanz. Die wurde mir 4.0.12 von alleine wieder angelegt.... ist das so gewollt?

Ja, aber nur wenn dein System gar keine backitup Instanz hat. Wenn du kein Backitup willst bitte komplett deinstallieren

[Dolomiti]

@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@dolomiti Hm ... mach mal bitte im ioBroker dir ein npm list mongodb Was kommt da raus?

schlippe@ioBroker-Test:/opt/iobroker$ npm list mongodb
[sudo] password for schlippe:
iobroker.inst@1.1.2 /opt/iobroker
`-- mongodb@3.2.7  extraneous

npm ERR! extraneous: mongodb@3.2.7 /opt/iobroker/node_modules/mongodb

Habe Node-Red deinstalliert und der Fehler kommt immer noch.

schlippe@ioBroker-Test:/opt/iobroker$ iobroker status
(node:2218) Warning: Accessing non-existent property 'count' of module exports inside circular dependency
(Use `node --trace-warnings ...` to show where the warning was created)
(node:2218) Warning: Accessing non-existent property 'findOne' of module exports inside circular dependency
(node:2218) Warning: Accessing non-existent property 'remove' of module exports inside circular dependency
(node:2218) Warning: Accessing non-existent property 'updateOne' of module exports inside circular dependency
iobroker is running on this host.


Objects type: jsonl
States  type: jsonl
schlippe@ioBroker-Test:/opt/iobroker$

Vielleicht ist es langsam mal an der Zeit mein Testsystem sauber mit nem Backup neu aufzusetzten, in der Hoffnung, dass dann die mongodb-Fehler weg sind.

[crunchip]

@dolomiti dann lösche es, danach sollte es funktionieren

npm uninstall mongodb

[Dolomiti]

@crunchip
Hab es gerade deinstalliert. Fehler ist weg.

Danke

Dolomiti

[apollon77]

@dolomiti Jupp. Ich verstehe nur nicht warum er diese alte Version installiert. Im Adapter steht https://github.com/ioBroker/ioBroker.node-red/blob/master/package.json#L30

[Dolomiti]

@apollon77
Habe jetzt Node-Red nochmal neu installiert. Jetzt ist die Ausgabe wohl wie zu erwarten. Bei bei meinem 2. Testsystem, einem RasPi, sieht es auch so aus

schlippe@ioBroker-Test:/opt/iobroker$ npm list mongodb
[sudo] password for schlippe:
iobroker.inst@1.1.2 /opt/iobroker
`-- iobroker.node-red@2.4.2
  `-- mongodb@3.7.3

Da das Problem erst nach dem Update vom js-Controller aufgetreten ist, hatte ich das damit in Zusammenhang gebracht.

Danke für die Hilfe

Dolomiti

[Marc Berg]

Hallo, ich habe folgende Konfiguration:

• ioBroker als Docker Container (buanet), aktuelles Image
• NPM v6.14.16
• Node.js v14.19.0

Das Update auf den js-Controller 4 lief soweit (nach "iob fix") ohne Probleme durch und auch sonst läuft alles einwandfrei. Eine Sache ist mir aber aufgefallen: Während die "states.jsonl" regelmäßig komprimiert wird und eine Größe zwischen 1 und 10MB hat, wurde die Datei "objects.jsonl" immer größer und hatte mittlerweile (bei meinem recht kleinen System) 200 MB erreicht. Einige Experimente mit dem Parameter "auto-compress size factor" brachten keine Änderung. Erst nachdem ich eine "Fake-Umstellung" von json- auf Redis-DB mit "iob setup custom" durchgeführt hatte, wurde die "objects.jsonl" auf nun ca. 7 MB komprimiert.
Mit "Fake-Umstellung" meine ich das Starten der Migration auf Redis, die dann aber automatisch abgebrochen wird, da keine Redis-DB gefunden wird.

Das Log zeigt keine Auffälligkeiten, die ich mit dem "Problem" in Verbindung bringen könnte.

Meine Frage ist nun: Ist das Beschriebene überhaupt ein Problem oder das erwartete Verhalten und habe nur ich diesen Effekt?

Grüße, Marc

[AlCalzone]

@marc-berg sagte in js-controller 4.0 jetzt im BETA/LATEST!:

wurde die Datei "objects.jsonl" immer größer und hatte mittlerweile (bei meinem recht kleinen System) 200 MB erreicht

Kannst du mir noch ein paar Eckdaten geben? Wie viele States/ Objekte hast du? Kannst du mir einmal eine solche (große) Datei schicken (und die states.jsonl zum Vergleich)? Als zip sollte die sich gut komprimieren lassen - ich geb dir nen Upload-Link.

[JB_Sullivan]

Ist es eigentlich generell so, das nach der Migration die jsonl Dateien größer sind als die alten json Dateien?

Können eigentlich alle Dateien die *.migrated heißen weg?

Achso, ich habe 42 aktive Adapter mit 20.030 Datenpunkten.

[Marc Berg]

@alcalzone

ich habe: Objects: 2261, States: 1927

Gern kannst Du mir einen Upload-Link geben

[apollon77]

@jb_sullivan Naja "Files größer" ist relativ. Wenn Du oben in der FAQ liesst wie JSONL funktioniert sind sie ausser direkt nach der Komprimierung immer größer weil halt neue Daten wieder angehängt werden.

Ja die ".migrated" können weg, sind nur quasi ne Art "mini Backup" von dem zeitpunkt der jsonl umstellung