Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Huebeni]

Hallo,

ich habe noch ein paar Dinge versucht, um den Fehler einzugrenzen:

• Der Anstieg des Speicherverbrauchs hängt ab vom Abfrageintervall. D.h. je öfter abgefragt wird, desto schneller steigt der Speicherbedarf. Bei 0 steigt er am schnellsten an.
• Ich habe auf smartmeter-obis auf 2.0.5 zurückgerollt ==> kein erkennbarer Unterschied

Ich denke ich werde vorerst das Abfrageintervall erhöhen und den Adapter automatisch neu starten lassen.

Ich finde es schon komisch, dass das Problem sonst keiner hat. Kann es irgendeine Dependency sein, die ich da erwischt habe?

Grüße,
Michael

[Huebeni]

Kurzes Update,

ich habe den Adapter als auch smartmeter-obis und serialport neu installiert. Leider keine Änderung.
Serialport ist Version 8.0.7.

Mit dem Debugger (Chrome-Dev-Tools) sind keine auffälligen Speicherlecks sichtbar. Das sieht man auch in meinem Flot-Chart: Der Heap wächst moderat.

Der Gesamtspeicherbedarf wächst aber immer massiv (memrss).

Leider habe ich noch keine weitere Idee.
Es gab mal vor einiger Zeit einen Bug in der Serialport-lIb: https://github.com/serialport/node-serialport/issues/1477 aber der sollte mittlerweile längst behoben sein.

Grüße,
Michael

[wendy2702]

Bei mir läuft 3.1.2 problemlos auf einem PI3.

[Huebeni]

@wendy2702 Hi, danke für die Info. Welche Node-Version verwendest Du? Wenn es keine Umstände macht, würden mich noch die Pakete interessieren, von denen smartmeter abhängt (Ausschnitt aus npm list).

[wendy2702]

Hi,

Node 10.20.1

Spoiler

iobroker.smartmeter@3.1.2
│ ├─┬ @iobroker/adapter-core@2.3.1
│ │ └─┬ @types/iobroker@3.0.4
│ │   └── @types/node@13.1.4 deduped
│ ├─┬ @sentry/integrations@5.15.4
│ │ ├── @sentry/types@5.15.4
│ │ ├─┬ @sentry/utils@5.15.4
│ │ │ ├── @sentry/types@5.15.4 deduped
│ │ │ └── tslib@1.10.0 deduped
│ │ └── tslib@1.10.0
│ ├─┬ @sentry/node@5.15.4
│ │ ├─┬ @sentry/apm@5.15.4
│ │ │ ├─┬ @sentry/browser@5.15.4
│ │ │ │ ├── @sentry/core@5.15.4 deduped
│ │ │ │ ├── @sentry/types@5.15.4 deduped
│ │ │ │ ├── @sentry/utils@5.15.4 deduped
│ │ │ │ └── tslib@1.10.0 deduped
│ │ │ ├── @sentry/hub@5.15.4 deduped
│ │ │ ├─┬ @sentry/minimal@5.15.4
│ │ │ │ ├── @sentry/hub@5.15.4 deduped
│ │ │ │ ├── @sentry/types@5.15.4 deduped
│ │ │ │ └── tslib@1.10.0 deduped
│ │ │ ├── @sentry/types@5.15.4 deduped
│ │ │ ├── @sentry/utils@5.15.4 deduped
│ │ │ └── tslib@1.10.0 deduped
│ │ ├─┬ @sentry/core@5.15.4
│ │ │ ├── @sentry/hub@5.15.4 deduped
│ │ │ ├── @sentry/minimal@5.15.4 deduped
│ │ │ ├── @sentry/types@5.15.4 deduped
│ │ │ ├── @sentry/utils@5.15.4 deduped
│ │ │ └── tslib@1.10.0 deduped
│ │ ├─┬ @sentry/hub@5.15.4
│ │ │ ├── @sentry/types@5.15.4 deduped
│ │ │ ├── @sentry/utils@5.15.4 deduped
│ │ │ └── tslib@1.10.0 deduped
│ │ ├── @sentry/types@5.15.4 deduped
│ │ ├── @sentry/utils@5.15.4 deduped
│ │ ├── cookie@0.3.1
│ │ ├─┬ https-proxy-agent@4.0.0
│ │ │ ├── agent-base@5.1.1
│ │ │ └─┬ debug@4.1.1
│ │ │   └── ms@2.1.2 deduped
│ │ ├── lru_map@0.3.3
│ │ └── tslib@1.10.0 deduped
│ ├─┬ serialport@8.0.7
│ │ ├─┬ @serialport/binding-mock@8.0.6
│ │ │ ├─┬ @serialport/binding-abstract@8.0.6
│ │ │ │ └─┬ debug@4.1.1
│ │ │ │   └── ms@2.1.2 deduped
│ │ │ └─┬ debug@4.1.1
│ │ │   └── ms@2.1.2 deduped
│ │ ├─┬ @serialport/bindings@8.0.7
│ │ │ ├── @serialport/binding-abstract@8.0.6 deduped
│ │ │ ├── @serialport/parser-readline@8.0.6 deduped
│ │ │ ├── bindings@1.5.0 deduped
│ │ │ ├─┬ debug@4.1.1
│ │ │ │ └── ms@2.1.2 deduped
│ │ │ ├── nan@2.14.0 deduped
│ │ │ └─┬ prebuild-install@5.3.3
│ │ │   ├── detect-libc@1.0.3 deduped
│ │ │   ├── expand-template@2.0.3
│ │ │   ├── github-from-package@0.0.0 deduped
│ │ │   ├── minimist@1.2.5
│ │ │   ├── mkdirp@0.5.1 deduped
│ │ │   ├── napi-build-utils@1.0.1 deduped
│ │ │   ├─┬ node-abi@2.15.0
│ │ │   │ └── semver@5.7.1
│ │ │   ├── noop-logger@0.1.1 deduped
│ │ │   ├── npmlog@4.1.2 deduped
│ │ │   ├─┬ pump@3.0.0
│ │ │   │ ├── end-of-stream@1.4.1 deduped
│ │ │   │ └── once@1.4.0 deduped
│ │ │   ├─┬ rc@1.2.8
│ │ │   │ ├── deep-extend@0.6.0
│ │ │   │ ├── ini@1.3.5 deduped
│ │ │   │ ├── minimist@1.2.5 deduped
│ │ │   │ └── strip-json-comments@2.0.1 deduped
│ │ │   ├─┬ simple-get@3.1.0
│ │ │   │ ├── decompress-response@4.2.1 deduped
│ │ │   │ ├── once@1.4.0 deduped
│ │ │   │ └── simple-concat@1.0.0 deduped
│ │ │   ├─┬ tar-fs@2.0.1
│ │ │   │ ├── chownr@1.1.3 deduped
│ │ │   │ ├── mkdirp-classic@0.5.2
│ │ │   │ ├── pump@3.0.0 deduped
│ │ │   │ └─┬ tar-stream@2.1.2
│ │ │   │   ├─┬ bl@4.0.2
│ │ │   │   │ ├─┬ buffer@5.6.0
│ │ │   │   │ │ ├── base64-js@1.3.1 deduped
│ │ │   │   │ │ └── ieee754@1.1.13 deduped
│ │ │   │   │ ├── inherits@2.0.4 deduped
│ │ │   │   │ └── readable-stream@3.6.0 deduped
│ │ │   │   ├── end-of-stream@1.4.1 deduped
│ │ │   │   ├── fs-constants@1.0.0 deduped
│ │ │   │   ├── inherits@2.0.4 deduped
│ │ │   │   └─┬ readable-stream@3.6.0
│ │ │   │     ├── inherits@2.0.4 deduped
│ │ │   │     ├── string_decoder@1.1.1 deduped
│ │ │   │     └── util-deprecate@1.0.2 deduped
│ │ │   ├── tunnel-agent@0.6.0 deduped
│ │ │   └── which-pm-runs@1.0.0 deduped
│ │ ├── @serialport/parser-byte-length@8.0.6
│ │ ├── @serialport/parser-cctalk@8.0.6
│ │ ├── @serialport/parser-delimiter@8.0.6
│ │ ├─┬ @serialport/parser-readline@8.0.6
│ │ │ └── @serialport/parser-delimiter@8.0.6 deduped
│ │ ├── @serialport/parser-ready@8.0.6
│ │ ├── @serialport/parser-regex@8.0.6
│ │ ├─┬ @serialport/stream@8.0.6
│ │ │ └─┬ debug@4.1.1
│ │ │   └── ms@2.1.2 deduped
│ │ └─┬ debug@4.1.1
│ │   └── ms@2.1.2 deduped
│ ├─┬ smartmeter-obis@2.1.2
│ │ ├─┬ open-sml@1.0.0
│ │ │ └── int64-buffer@0.99.1007
│ │ ├─┬ request@2.88.2
│ │ │ ├── aws-sign2@0.7.0 deduped
│ │ │ ├── aws4@1.9.1
│ │ │ ├── caseless@0.12.0 deduped
│ │ │ ├─┬ combined-stream@1.0.8
│ │ │ │ └── delayed-stream@1.0.0 deduped
│ │ │ ├── extend@3.0.2
│ │ │ ├── forever-agent@0.6.1 deduped
│ │ │ ├─┬ form-data@2.3.3
│ │ │ │ ├── asynckit@0.4.0 deduped
│ │ │ │ ├── combined-stream@1.0.8 deduped
│ │ │ │ └── mime-types@2.1.26 deduped
│ │ │ ├─┬ har-validator@5.1.3
│ │ │ │ ├─┬ ajv@6.12.2
│ │ │ │ │ ├── fast-deep-equal@3.1.1
│ │ │ │ │ ├── fast-json-stable-stringify@2.0.0 deduped
│ │ │ │ │ ├── json-schema-traverse@0.4.1
│ │ │ │ │ └── uri-js@4.2.2 deduped
│ │ │ │ └── har-schema@2.0.0 deduped
│ │ │ ├── http-signature@1.2.0 deduped
│ │ │ ├── is-typedarray@1.0.0 deduped
│ │ │ ├── isstream@0.1.2 deduped
│ │ │ ├── json-stringify-safe@5.0.1 deduped
│ │ │ ├─┬ mime-types@2.1.26
│ │ │ │ └── mime-db@1.43.0
│ │ │ ├── oauth-sign@0.9.0
│ │ │ ├── performance-now@2.1.0 deduped
│ │ │ ├── qs@6.5.2
│ │ │ ├── safe-buffer@5.2.0
│ │ │ ├─┬ tough-cookie@2.5.0
│ │ │ │ ├── psl@1.7.0 deduped
│ │ │ │ └── punycode@2.1.1
│ │ │ ├── tunnel-agent@0.6.0 deduped
│ │ │ └── uuid@3.4.0
│ │ └── serialport@8.0.7 deduped
│ └─┬ source-map-support@0.5.16
│   ├── buffer-from@1.1.1
│   └── source-map@0.6.1

[Huebeni]

So, kurzes Update:
Ich habe den Host mit dem Smartmeter Adapter kurzerhand von Node 12.16.2 auf Node 10.20.1 downgegraded.
Seitdem scheint der Speicher nicht mehr endlos zu wachsen.
Habe jetzt den automatischen Neustart für den Adapter entfernt und das Abfrageintervall auf 0s gestellt.
Morgen wird sich zeigen, ob es eventuell an Node 12 liegt.

[Huebeni]

Hi,

Es sieht so aus, als läuft das Setup mit NodeJS 10 stabil.
Anscheinend gibt es in Verbindung mit NodeJS 12 noch Probleme auf dem Raspi 3.

Umgebung:
Raspberry 3
Aktuelles Raspian "Buster"

Nicht ok:
smartmeter-Adapter: 3.0.10
smartmeter-obis: 2.1.2
NodeJS: v12.16.2
NPM: 6.14.4
js-controller 2.2.9
serialport: 8.0.7

OK:
Alles identisch bis auf
NodeJS: v10.20.1

In den Charts sieht man, dass sich der Speicherverbrauch nach dem Welchsel zu NodeJS 10 für den Adapter jetzt eingependelt hat. Davor sieht man den rasanten Anstieg, den ich durch die Adapter-Neustarts zurückgesetzt habe.

Bisher habe ich noch keine heiße Spur woran es liegt - vermute aber, dass es an der serialport-lib liegen könnte. Diese hatte in alten Versionen Speicherlecks auf der (offiziellen nicht unterstützten) Plattform arm und damit auf dem Raspi. Die Version 8.x hat große Umbauten, da kann schon mal etwas kaputt gehen.

Ich weiß nicht wie aktiv ich das Thema in der nächsten Zeit verfolgen werde, nachdem es jetzt erst mal läuft.

Gibt es denn jemanden, der den Adapter mit NodeJS 12 auf einem Raspi ohne Probleme betreibt?

Grüße,
Michael

[uschi08]

@Huebeni

Moin,

hast du den Adapter mit node 10 ans Laufen bekommen? Hier mit Node.js: v10.20.1 und Adapter v 3.0.10 geht es nicht, auch das Löschen und Neuinstallation auf 3.1.2 aus dem git hilft nicht.
Wie hast du denn neu kompiliert, nachdem du nods js upgedated hast?

ost.HWR	2020-05-20 10:16:15.166	error	instance system.adapter.smartmeter.0 terminated with code 1 (JS_CONTROLLER_STOPPED)
host.HWR	2020-05-20 10:16:15.166	error	Caught by controller[0]: at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
host.HWR	2020-05-20 10:16:15.165	error	Caught by controller[0]: at Module._compile (internal/modules/cjs/loader.js:778:30)
host.HWR	2020-05-20 10:16:15.165	error	Caught by controller[0]: at Object.<anonymous> (/opt/iobroker/node_modules/serialport/node_modules/@serialport/bindings/lib/linux.js:2:36)
host.HWR	2020-05-20 10:16:15.165	error	Caught by controller[0]: at bindings (/opt/iobroker/node_modules/bindings/bindings.js:112:48)
host.HWR	2020-05-20 10:16:15.164	error	Caught by controller[0]: at require (internal/modules/cjs/helpers.js:25:18)
host.HWR	2020-05-20 10:16:15.164	error	Caught by controller[0]: at Module.require (internal/modules/cjs/loader.js:692:17)
host.HWR	2020-05-20 10:16:15.164	error	Caught by controller[0]: at Function.Module._load (internal/modules/cjs/loader.js:585:3)
host.HWR	2020-05-20 10:16:15.163	error	Caught by controller[0]: at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
host.HWR	2020-05-20 10:16:15.163	error	Caught by controller[0]: at Module.load (internal/modules/cjs/loader.js:653:32)
host.HWR	2020-05-20 10:16:15.162	error	Caught by controller[0]: at Object.Module._extensions..node (internal/modules/cjs/loader.js:807:18)
host.HWR	2020-05-20 10:16:15.162	error	Caught by controller[0]: the module (for instance, using `npm rebuild` or `npm install`).
host.HWR	2020-05-20 10:16:15.162	error	Caught by controller[0]: NODE_MODULE_VERSION 64. Please try re-compiling or re-installing
host.HWR	2020-05-20 10:16:15.161	error	Caught by controller[0]: NODE_MODULE_VERSION 57. This version of Node.js requires
host.HWR	2020-05-20 10:16:15.161	error	Caught by controller[0]: was compiled against a different Node.js version using
host.HWR	2020-05-20 10:16:15.160	error	Caught by controller[0]: Error: The module '/opt/iobroker/node_modules/serialport/node_modules/@serialport/bindings/build/Release/bindings.node'
host.HWR	2020-05-20 10:16:15.160	error	Caught by controller[0]: ^
host.HWR	2020-05-20 10:16:15.153	error	Caught by controller[0]: throw e;
host.HWR	2020-05-20 10:16:15.152	error	Caught by controller[0]: /opt/iobroker/node_modules/bindings/bindings.js:121

MOD-Edit: Code in code-tags gesetzt!

[uschi08]

@uschi08

Nachtrag: steht ja auch im Log ;-), und mit "npm i serialport", sind wir schwupps wieder im Rennen..

[uschi08]

@uschi08
Schönen Dank für das Editieren.
Gibt es im Adapter noch ein erweitertes Log?
Der Adapter läuft jetzt zwar mit node 10 und in v 3.1.2 wieder an, dann passiert aber nichts mehr.

smartmeter.0	2020-05-20 12:03:53.997	warn	(1487) No or too long answer from Serial Device after last request.
smartmeter.0	2020-05-20 12:03:53.995	info	(1487) Error: No or too long answer from Serial Device after last request.
smartmeter.0	2020-05-20 12:01:33.966	warn	(1487) No or too long answer from Serial Device after last request.
smartmeter.0	2020-05-20 12:01:33.957	info	(1487) Error: No or too long answer from Serial Device after last request.
smartmeter.0	2020-05-20 11:59:33.451	info	(1487) starting. Version 3.1.2 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v10.20.1

und der Stick (Weidmann) lief jahrelang unter node 8 / v3.0.10. Nach dem Upgrade auf node 10 bleibt die Küche kalt..

[Homoran]

@uschi08 sagte in smartmeter Adapter 3.0.10 frisst Speicher (NodeJS 12):

Gibt es im Adapter noch ein erweitertes Log?

Instanzen -> Expertenmodus -> Logstufe -> debug

[uschi08]

@Homoran
ahh stimmt - Danke!
und jetzt kann man auch mehr sehen:

smartmeter.0	2020-05-20 12:13:55.532	debug	(24705) SET MESSAGE TIMEOUT TIMER: 120000
smartmeter.0	2020-05-20 12:13:55.524	debug	(24705) SERIALPORT OPEN
smartmeter.0	2020-05-20 12:13:55.520	debug	(24705) connected set to false
smartmeter.0	2020-05-20 12:13:55.510	debug	(24705) CREATE SERIALPORT: 9600 8 1 none
smartmeter.0	2020-05-20 12:13:55.504	debug	(24705) SmartmeterObis options: {"debug":2,"protocol":"SmlProtocol","transport":"SerialResponseTransport","requestInterval":"20","anotherQueryDelay":"1000","transportSerialPort":"/dev/serial/by-id/us
smartmeter.0	2020-05-20 12:13:55.064	info	(24705) starting. Version 3.1.2 in /opt/iobroker/node_modules/iobroker.smartmeter, node: v10.20.1
smartmeter.0	2020-05-20 12:13:53.971	debug	(24705) statesDB connected
smartmeter.0	2020-05-20 12:13:53.969	debug	(24705) States connected to redis: 192.168.178.45:9000
smartmeter.0	2020-05-20 12:13:53.952	debug	(24705) States create System PubSub Client
smartmeter.0	2020-05-20 12:13:53.947	debug	(24705) States create User PubSub Client
smartmeter.0	2020-05-20 12:13:53.934	debug	(24705) Redis States: Use Redis connection: 192.168.178.45:9000
smartmeter.0	2020-05-20 12:13:53.929	debug	(24705) objectDB connected
smartmeter.0	2020-05-20 12:13:53.916	debug	(24705) Objects connected to redis: 192.168.178.45:9001
smartmeter.0	2020-05-20 12:13:53.895	debug	(24705) Objects client initialize lua scripts
smartmeter.0	2020-05-20 12:13:53.894	debug	(24705) Objects create User PubSub Client
smartmeter.0	2020-05-20 12:13:53.891	debug	(24705) Objects create System PubSub Client
smartmeter.0	2020-05-20 12:13:53.882	debug	(24705) Objects client ready ... initialize now
smartmeter.0	2020-05-20 12:13:53.821	debug	(24705) Redis Objects: Use Redis connection: 192.168.178.45:9001
smartmeter.0	2020-05-20 12:13:49.036	info	(23708) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason
smartmeter.0	2020-05-20 12:13:49.032	info	(23708) terminating
smartmeter.0	2020-05-20 12:13:49.028	debug	(23708) SERIALPORT REMOVE LISTENERS
smartmeter.0	2020-05-20 12:13:49.026	debug	(23708) SERIALPORT CLOSE
smartmeter.0	2020-05-20 12:13:49.017	debug	(23708) CLEAR MESSAGE TIMEOUT TIMER
smartmeter.0	2020-05-20 12:13:49.015	debug	(23708) STOP
smartmeter.0	2020-05-20 12:13:49.010	info	(23708) Got terminate signal TERMINATE_YOURSELF
smartmeter.0	2020-05-20 12:13:43.517	debug	(23708) sendTo "listUart" to system.adapter.admin.0 from system.adapter.smartmeter.0
smartmeter.0	2020-05-20 12:13:43.513	info	(23708) List of port: [{"path":"/dev/ttyS0"},{"path":"/dev/ttyS1"},{"path":"/dev/ttyS2"},{"path":"/dev/ttyS3"},{"manufacturer":"dresden elektronik in

also immer noch der SERIALPORT?
Lösungsansätze in diesem Fall?

Danke,
Ole

[uschi08]

@uschi08

haut nicht mehr hin, ich hab nen issue aufgemacht.
https://github.com/Apollon77/ioBroker.smartmeter/issues/117

#edit:
und auch wieder geschossen.
Wen es integressiert: die Adaptereinstellungen, die bei mir mit dem Wiedmann funktionieren: