Node.js 18.x und iobroker (ein Test)
-
Hi,
Node.js 18, welches jetzt seit gut 2 Monaten die aktuellste LTS Version ist, hatte bisher immer noch komische Probleme, vor allem mit dem Netzwerk. Weitere Probleme sind aber eher nicht bekannt.
Dementsprechend aber gibt es aktuell noch vergleichsweise wenige Erfahrungen mit der Version und ioBroker.
Wir haben die Ursache für die Netzwerk-Themen identifiziert und mit js-controller 4.0.24, der vor kurzem Released wurde, erst einmal einen Work-Around eingebaut.
Die Netzwerkprobleme entstehen vor allem wenn mal mit "Hostnamen" arbeitet und auch IPv6 im lokalen Netzwerk aktiviert ist. Wenn Node.js einen DNS Namen auflöst dann wird ab Version 18 bevorzugt die IPv6 Adresse zurückgegeben - Wenn der Server aber nur auf IPv4 lauscht ist das ein Problem. Man konnte die Themen umgehen wenn man die IP anstelle dem FDQN genutzt hat. In js-controller 4.0.24 haben wir das DNS-Auflöseverhalten erst einmal so geändert wie es bisher war und überlegen uns für js-controller 5.0 etwas besseres.
Aus dem Grund wäre jetzt eine gute Chance sich mal mit Node.js 18 auseinanderzusetzen ... Bitte versucht es und teilt Eure Erfahrungen - mit js-controller 4.0.24!!
Vielen Dank,
Ingo
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
Hi,
Node.js 18, welches jetzt seit gut 2 Monaten die aktuellste LTS Version ist, hatte bisher immer noch komische Probleme, vor allem mit dem Netzwerk. Weitere Probleme sind aber eher nicht bekannt.
Dementsprechend aber gibt es aktuell noch vergleichsweise wenige Erfahrungen mit der Version und ioBroker.
Wir haben die Ursache für die Netzwerk-Themen identifiziert und mit js-controller 4.0.24, der vor kurzem Released wurde, erst einmal einen Work-Around eingebaut.
Die Netzwerkprobleme entstehen vor allem wenn mal mit "Hostnamen" arbeitet und auch IPv6 im lokalen Netzwerk aktiviert ist. Wenn Node.js einen DNS Namen auflöst dann wird ab Version 18 bevorzugt die IPv6 Adresse zurückgegeben - Wenn der Server aber nur auf IPv4 lauscht ist das ein Problem. Man konnte die Themen umgehen wenn man die IP anstelle dem FDQN genutzt hat. In js-controller 4.0.24 haben wir das DNS-Auflöseverhalten erst einmal so geändert wie es bisher war und überlegen uns für js-controller 5.0 etwas besseres.
Aus dem Grund wäre jetzt eine gute Chance sich mal mit Node.js 18 auseinanderzusetzen ... Bitte versucht es und teilt Eure Erfahrungen - mit js-controller 4.0.24!!
Vielen Dank,
Ingo
Hier läuft mittlerweile soweit alles mit nodeJS@18:
pi@mysterium:~ $ nodejs -v v18.12.1 pi@mysterium:~ $ nodejs -v && iob list adapters v18.12.1 system.adapter.admin : admin - v6.3.5 system.adapter.alexa2 : alexa2 - v3.23.2 system.adapter.backitup : backitup - v2.5.9 system.adapter.ble : ble - v0.13.0 system.adapter.echarts : echarts - v1.0.12 system.adapter.followthesun : followthesun - v0.4.0 system.adapter.govee : govee - v0.0.5 system.adapter.history : history - v2.2.4 system.adapter.ical : ical - v1.13.2 system.adapter.info : info - v1.9.19 system.adapter.iot : iot - v1.11.9 system.adapter.javascript : javascript - v6.1.4 system.adapter.midea : midea - v0.0.7 system.adapter.mihome : mihome - v1.4.0 system.adapter.mihome-vacuum : mihome-vacuum - v3.8.6 system.adapter.miio : miio - v0.0.13 system.adapter.nina : nina - v0.0.25 system.adapter.nuki-extended : nuki-extended - v2.6.5 system.adapter.parcel : parcel - v0.0.23 system.adapter.pi-hole : pi-hole - v1.3.4 system.adapter.rpi2 : rpi2 - v1.3.2 system.adapter.sainlogic : sainlogic - v0.9.0 system.adapter.samsung : samsung - v0.5.11 system.adapter.simple-api : simple-api - v2.7.2 system.adapter.socketio : socketio - v6.1.8 system.adapter.switchbot-hub : switchbot-hub - v0.1.2 system.adapter.tado : tado - v0.4.3 system.adapter.tr-064 : tr-064 - v4.2.17 system.adapter.tradfri : tradfri - v3.1.3 system.adapter.trashschedule : trashschedule - v2.0.3 system.adapter.tuya : tuya - v3.11.1 system.adapter.web : web - v5.2.4 system.adapter.whatsapp-cmb : whatsapp-cmb - v0.2.3 system.adapter.ws : ws - v2.1.3 system.adapter.zigbee : zigbee - v1.7.6 pi@mysterium:~ $ cd /opt/iobroker/ pi@mysterium:/opt/iobroker $ npm ls iobroker.inst@3.0.0 /opt/iobroker ├── iobroker.admin@6.3.5 ├── iobroker.alexa2@3.23.2 ├── iobroker.backitup@2.5.9 ├── iobroker.ble@0.13.0 ├── iobroker.echarts@1.0.12 ├── iobroker.followthesun@0.4.0 ├── iobroker.govee@0.0.5 (git+ssh://git@github.com/nbuenger/ioBroker.govee.git#0d983c49135b87ac2f88f9d832a6d632c4889606) ├── iobroker.history@2.2.4 ├── iobroker.ical@1.13.2 ├── iobroker.info@1.9.19 ├── iobroker.iot@1.11.9 ├── iobroker.javascript@6.1.4 ├── iobroker.js-controller@4.0.23 ├── iobroker.midea@0.0.7 ├── iobroker.mihome-vacuum@3.8.6 ├── iobroker.mihome@1.4.0 ├── iobroker.miio@0.0.13 ├── iobroker.nina@0.0.25 ├── iobroker.nuki-extended@2.6.5 ├── iobroker.parcel@0.0.23 ├── iobroker.pi-hole@1.3.4 ├── iobroker.rpi2@1.3.2 ├── iobroker.sainlogic@0.9.0 ├── iobroker.samsung@0.5.11 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.samsung.git#70366ba038c0f5092731db63f09d16db8eb56e65) ├── iobroker.simple-api@2.7.2 ├── iobroker.socketio@6.1.8 ├── iobroker.switchbot-hub@0.1.2 (git+ssh://git@github.com/DrozmotiX/ioBroker.switchbot-hub.git#de8c1ad97edafedb16cbbb2c6dc14b032848df8e) ├── iobroker.tado@0.4.3 ├── iobroker.tr-064@4.2.17 ├── iobroker.tradfri@3.1.3 ├── iobroker.trashschedule@2.0.3 ├── iobroker.tuya@3.11.1 ├── iobroker.web@5.2.4 ├── iobroker.whatsapp-cmb@0.2.3 ├── iobroker.ws@2.1.3 └── iobroker.zigbee@1.7.6Auf dem 'bleeding-edge-System' mit nodejs@19 auch alles stabil:
echad@chet:~ $ nodejs -v v19.3.0 echad@chet:~ $ cd /opt/iobroker/ echad@chet:/opt/iobroker $ npm ls iobroker.inst@3.0.0 /opt/iobroker ├── iobroker.admin@6.3.5 ├── iobroker.alexa2@3.23.2 ├── iobroker.alias-manager@1.2.6 ├── iobroker.backitup@2.5.9 ├── iobroker.ble@0.13.1 ├── iobroker.cloud@4.3.0 ├── iobroker.echarts@1.0.12 ├── iobroker.firetv@1.0.0 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.firetv.git#93280a093a8d6518e4b980ecc589f6e3f566d030) ├── iobroker.followthesun@0.4.0 ├── iobroker.govee@0.0.6 (git+ssh://git@github.com/nbuenger/ioBroker.govee.git#73ec80b6350890015d95428dd3bbd3f72417a073) ├── iobroker.history@2.2.4 ├── iobroker.ical@1.13.2 ├── iobroker.iceroad@1.1.1 ├── iobroker.info@1.9.23 ├── iobroker.iot@1.14.0 ├── iobroker.javascript@6.1.4 ├── iobroker.js-controller@4.0.24 ├── iobroker.midea@0.1.0 (git+ssh://git@github.com/TA2k/ioBroker.midea.git#0d037c0c9a025b193546f881f747c8f998bfc724) ├── iobroker.mihome-cloud@0.0.1 (git+ssh://git@github.com/TA2k/ioBroker.mihome-cloud.git#41c5f2ff3774f2c9afca4e15eebbbec26ea20ddf) ├── iobroker.mihome-vacuum@3.8.8 ├── iobroker.mihome@1.4.0 ├── iobroker.miio@0.0.13 ├── iobroker.nina@0.0.25 ├── iobroker.nuki-extended@2.6.5 ├── iobroker.parcel@0.0.23 ├── iobroker.pi-hole@1.3.4 ├── iobroker.rpi2@1.3.2 ├── iobroker.sainlogic@0.9.0 ├── iobroker.samsung@0.5.11 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.samsung.git#59d70226dd038dec8e64eb6636c7604d3a6c8bba) ├── iobroker.simple-api@2.7.2 ├── iobroker.socketio@6.3.3 ├── iobroker.switchbot-ble@0.4.5 (git+ssh://git@github.com/mrbungle64/ioBroker.switchbot-ble.git#d42a950ef01f7edb1db5ef7301382477f2f01740) ├── iobroker.switchbot-hub@0.1.2 (git+ssh://git@github.com/DrozmotiX/ioBroker.switchbot-hub.git#de8c1ad97edafedb16cbbb2c6dc14b032848df8e) ├── iobroker.tado@0.4.3 ├── iobroker.tankerkoenig@3.1.0 ├── iobroker.tr-064@4.2.17 ├── iobroker.tradfri@3.1.3 ├── iobroker.trashschedule@2.1.0 ├── iobroker.tuya@3.11.2 ├── iobroker.web@5.3.1 ├── iobroker.whatsapp-cmb@0.2.3 ├── iobroker.ws@2.3.3 └── iobroker.zigbee@1.8.9 -
Hier läuft mittlerweile soweit alles mit nodeJS@18:
pi@mysterium:~ $ nodejs -v v18.12.1 pi@mysterium:~ $ nodejs -v && iob list adapters v18.12.1 system.adapter.admin : admin - v6.3.5 system.adapter.alexa2 : alexa2 - v3.23.2 system.adapter.backitup : backitup - v2.5.9 system.adapter.ble : ble - v0.13.0 system.adapter.echarts : echarts - v1.0.12 system.adapter.followthesun : followthesun - v0.4.0 system.adapter.govee : govee - v0.0.5 system.adapter.history : history - v2.2.4 system.adapter.ical : ical - v1.13.2 system.adapter.info : info - v1.9.19 system.adapter.iot : iot - v1.11.9 system.adapter.javascript : javascript - v6.1.4 system.adapter.midea : midea - v0.0.7 system.adapter.mihome : mihome - v1.4.0 system.adapter.mihome-vacuum : mihome-vacuum - v3.8.6 system.adapter.miio : miio - v0.0.13 system.adapter.nina : nina - v0.0.25 system.adapter.nuki-extended : nuki-extended - v2.6.5 system.adapter.parcel : parcel - v0.0.23 system.adapter.pi-hole : pi-hole - v1.3.4 system.adapter.rpi2 : rpi2 - v1.3.2 system.adapter.sainlogic : sainlogic - v0.9.0 system.adapter.samsung : samsung - v0.5.11 system.adapter.simple-api : simple-api - v2.7.2 system.adapter.socketio : socketio - v6.1.8 system.adapter.switchbot-hub : switchbot-hub - v0.1.2 system.adapter.tado : tado - v0.4.3 system.adapter.tr-064 : tr-064 - v4.2.17 system.adapter.tradfri : tradfri - v3.1.3 system.adapter.trashschedule : trashschedule - v2.0.3 system.adapter.tuya : tuya - v3.11.1 system.adapter.web : web - v5.2.4 system.adapter.whatsapp-cmb : whatsapp-cmb - v0.2.3 system.adapter.ws : ws - v2.1.3 system.adapter.zigbee : zigbee - v1.7.6 pi@mysterium:~ $ cd /opt/iobroker/ pi@mysterium:/opt/iobroker $ npm ls iobroker.inst@3.0.0 /opt/iobroker ├── iobroker.admin@6.3.5 ├── iobroker.alexa2@3.23.2 ├── iobroker.backitup@2.5.9 ├── iobroker.ble@0.13.0 ├── iobroker.echarts@1.0.12 ├── iobroker.followthesun@0.4.0 ├── iobroker.govee@0.0.5 (git+ssh://git@github.com/nbuenger/ioBroker.govee.git#0d983c49135b87ac2f88f9d832a6d632c4889606) ├── iobroker.history@2.2.4 ├── iobroker.ical@1.13.2 ├── iobroker.info@1.9.19 ├── iobroker.iot@1.11.9 ├── iobroker.javascript@6.1.4 ├── iobroker.js-controller@4.0.23 ├── iobroker.midea@0.0.7 ├── iobroker.mihome-vacuum@3.8.6 ├── iobroker.mihome@1.4.0 ├── iobroker.miio@0.0.13 ├── iobroker.nina@0.0.25 ├── iobroker.nuki-extended@2.6.5 ├── iobroker.parcel@0.0.23 ├── iobroker.pi-hole@1.3.4 ├── iobroker.rpi2@1.3.2 ├── iobroker.sainlogic@0.9.0 ├── iobroker.samsung@0.5.11 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.samsung.git#70366ba038c0f5092731db63f09d16db8eb56e65) ├── iobroker.simple-api@2.7.2 ├── iobroker.socketio@6.1.8 ├── iobroker.switchbot-hub@0.1.2 (git+ssh://git@github.com/DrozmotiX/ioBroker.switchbot-hub.git#de8c1ad97edafedb16cbbb2c6dc14b032848df8e) ├── iobroker.tado@0.4.3 ├── iobroker.tr-064@4.2.17 ├── iobroker.tradfri@3.1.3 ├── iobroker.trashschedule@2.0.3 ├── iobroker.tuya@3.11.1 ├── iobroker.web@5.2.4 ├── iobroker.whatsapp-cmb@0.2.3 ├── iobroker.ws@2.1.3 └── iobroker.zigbee@1.7.6Auf dem 'bleeding-edge-System' mit nodejs@19 auch alles stabil:
echad@chet:~ $ nodejs -v v19.3.0 echad@chet:~ $ cd /opt/iobroker/ echad@chet:/opt/iobroker $ npm ls iobroker.inst@3.0.0 /opt/iobroker ├── iobroker.admin@6.3.5 ├── iobroker.alexa2@3.23.2 ├── iobroker.alias-manager@1.2.6 ├── iobroker.backitup@2.5.9 ├── iobroker.ble@0.13.1 ├── iobroker.cloud@4.3.0 ├── iobroker.echarts@1.0.12 ├── iobroker.firetv@1.0.0 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.firetv.git#93280a093a8d6518e4b980ecc589f6e3f566d030) ├── iobroker.followthesun@0.4.0 ├── iobroker.govee@0.0.6 (git+ssh://git@github.com/nbuenger/ioBroker.govee.git#73ec80b6350890015d95428dd3bbd3f72417a073) ├── iobroker.history@2.2.4 ├── iobroker.ical@1.13.2 ├── iobroker.iceroad@1.1.1 ├── iobroker.info@1.9.23 ├── iobroker.iot@1.14.0 ├── iobroker.javascript@6.1.4 ├── iobroker.js-controller@4.0.24 ├── iobroker.midea@0.1.0 (git+ssh://git@github.com/TA2k/ioBroker.midea.git#0d037c0c9a025b193546f881f747c8f998bfc724) ├── iobroker.mihome-cloud@0.0.1 (git+ssh://git@github.com/TA2k/ioBroker.mihome-cloud.git#41c5f2ff3774f2c9afca4e15eebbbec26ea20ddf) ├── iobroker.mihome-vacuum@3.8.8 ├── iobroker.mihome@1.4.0 ├── iobroker.miio@0.0.13 ├── iobroker.nina@0.0.25 ├── iobroker.nuki-extended@2.6.5 ├── iobroker.parcel@0.0.23 ├── iobroker.pi-hole@1.3.4 ├── iobroker.rpi2@1.3.2 ├── iobroker.sainlogic@0.9.0 ├── iobroker.samsung@0.5.11 (git+ssh://git@github.com/iobroker-community-adapters/ioBroker.samsung.git#59d70226dd038dec8e64eb6636c7604d3a6c8bba) ├── iobroker.simple-api@2.7.2 ├── iobroker.socketio@6.3.3 ├── iobroker.switchbot-ble@0.4.5 (git+ssh://git@github.com/mrbungle64/ioBroker.switchbot-ble.git#d42a950ef01f7edb1db5ef7301382477f2f01740) ├── iobroker.switchbot-hub@0.1.2 (git+ssh://git@github.com/DrozmotiX/ioBroker.switchbot-hub.git#de8c1ad97edafedb16cbbb2c6dc14b032848df8e) ├── iobroker.tado@0.4.3 ├── iobroker.tankerkoenig@3.1.0 ├── iobroker.tr-064@4.2.17 ├── iobroker.tradfri@3.1.3 ├── iobroker.trashschedule@2.1.0 ├── iobroker.tuya@3.11.2 ├── iobroker.web@5.3.1 ├── iobroker.whatsapp-cmb@0.2.3 ├── iobroker.ws@2.3.3 └── iobroker.zigbee@1.8.9@thomas-braun sagte in Node.js 18.x und iobroker (ein Test):
Hier läuft mittlerweile soweit alles mit nodeJS@18:
Welche npm Version kommt mit nodejs18 ?
Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@thomas-braun sagte in Node.js 18.x und iobroker (ein Test):
Hier läuft mittlerweile soweit alles mit nodeJS@18:
Welche npm Version kommt mit nodejs18 ?
@segway
Im Moment noch npm@8, wird aber wohl im Januar auf npm@9 gedreht werden. nodeJS@19 kommt schon direkt mit npm@9 daher.echad@chet:/opt/iobroker $ node -v && npm -v v19.3.0 9.2.0 pi@mysterium:~ $ node -v && npm -v v18.12.1 8.19.2 -
@segway
Im Moment noch npm@8, wird aber wohl im Januar auf npm@9 gedreht werden. nodeJS@19 kommt schon direkt mit npm@9 daher.echad@chet:/opt/iobroker $ node -v && npm -v v19.3.0 9.2.0 pi@mysterium:~ $ node -v && npm -v v18.12.1 8.19.2@thomas-braun
Ich dachte ungerade Versionen sollte man nicht nehmen ? Oder gibt es diese Regel nicht mehr?Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@thomas-braun
Ich dachte ungerade Versionen sollte man nicht nehmen ? Oder gibt es diese Regel nicht mehr? -
Hi,
Node.js 18, welches jetzt seit gut 2 Monaten die aktuellste LTS Version ist, hatte bisher immer noch komische Probleme, vor allem mit dem Netzwerk. Weitere Probleme sind aber eher nicht bekannt.
Dementsprechend aber gibt es aktuell noch vergleichsweise wenige Erfahrungen mit der Version und ioBroker.
Wir haben die Ursache für die Netzwerk-Themen identifiziert und mit js-controller 4.0.24, der vor kurzem Released wurde, erst einmal einen Work-Around eingebaut.
Die Netzwerkprobleme entstehen vor allem wenn mal mit "Hostnamen" arbeitet und auch IPv6 im lokalen Netzwerk aktiviert ist. Wenn Node.js einen DNS Namen auflöst dann wird ab Version 18 bevorzugt die IPv6 Adresse zurückgegeben - Wenn der Server aber nur auf IPv4 lauscht ist das ein Problem. Man konnte die Themen umgehen wenn man die IP anstelle dem FDQN genutzt hat. In js-controller 4.0.24 haben wir das DNS-Auflöseverhalten erst einmal so geändert wie es bisher war und überlegen uns für js-controller 5.0 etwas besseres.
Aus dem Grund wäre jetzt eine gute Chance sich mal mit Node.js 18 auseinanderzusetzen ... Bitte versucht es und teilt Eure Erfahrungen - mit js-controller 4.0.24!!
Vielen Dank,
Ingo
@apollon77 weil ich gerade Zeit hab, lief ohne Auffälligkeiten durch, ble wurde mit dem ersten rebuild bereinigt.
bullseye auf Proxmox VM,
allerdings verwende ich kein IPv6
Adapter
-
@thomas-braun
Ich dachte ungerade Versionen sollte man nicht nehmen ? Oder gibt es diese Regel nicht mehr?@segway sagte in Node.js 18.x und iobroker (ein Test):
Ich dachte ungerade Versionen sollte man nicht nehmen ?
Nicht für ein stabiles/Produktiv-System. Die Kiste auf dem nodeJS@19 läuft ist die Frickel-Bude bei mir. Die drehe ich Versions-mäßig weit raus.
-
@apollon77 Hab mein Testsystem auch mal auf nodejs 18 aktualisiert. Bisher ohne Auffälligkeiten. Werde es mal weiter beobachten.
-
@thomas-braun sagte in Node.js 18.x und iobroker (ein Test):
@segway sagte in Node.js 18.x und iobroker (ein Test):
Ich dachte ungerade Versionen sollte man nicht nehmen ?
Nicht für ein stabiles/Produktiv-System. Die Kiste auf dem nodeJS@19 läuft ist die Frickel-Bude bei mir. Die drehe ich Versions-mäßig weit raus.
Wie macht ihr das eigentlich?
Spiegelt ihr euer Produktivsysten 1:1 als neue VM irgendwo ab? Sber dann braucht man ja auch neue Datenbank VM usw! Oder knallt ihr alles auf ein System?
Oder nur Minimal-Iob Install ?Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@thomas-braun sagte in Node.js 18.x und iobroker (ein Test):
@segway sagte in Node.js 18.x und iobroker (ein Test):
Ich dachte ungerade Versionen sollte man nicht nehmen ?
Nicht für ein stabiles/Produktiv-System. Die Kiste auf dem nodeJS@19 läuft ist die Frickel-Bude bei mir. Die drehe ich Versions-mäßig weit raus.
Wie macht ihr das eigentlich?
Spiegelt ihr euer Produktivsysten 1:1 als neue VM irgendwo ab? Sber dann braucht man ja auch neue Datenbank VM usw! Oder knallt ihr alles auf ein System?
Oder nur Minimal-Iob Install ?Ich habe zwei Systeme. Eins das mit den Versionen 'an vorderer Front' läuft und alle 24 Stunden gebackupt wird und ein 'Notsystem' (alles weitgehend auf 'stable', konservativ eingestellt), das auf einem zweiten System schlummert und nur im 'worst case' wachgeküsst wird und dann in die Bresche springt. Ist aber noch nie vorgekommen. Ich logge aber auch nix wirklich mit oder steuere Ommas Herzschrittmacher über den ioBroker. Insofern könnte ich auch mit ein paar Stunden downtime leben.
-
Ich habe zwei Systeme. Eins das mit den Versionen 'an vorderer Front' läuft und alle 24 Stunden gebackupt wird und ein 'Notsystem' (alles weitgehend auf 'stable', konservativ eingestellt), das auf einem zweiten System schlummert und nur im 'worst case' wachgeküsst wird und dann in die Bresche springt. Ist aber noch nie vorgekommen. Ich logge aber auch nix wirklich mit oder steuere Ommas Herzschrittmacher über den ioBroker. Insofern könnte ich auch mit ein paar Stunden downtime leben.
@thomas-braun
Mhhh, das beschreibt aber noch nicht dein System wo du jetzt mal eben die nodejs19 und npm9 drauf laufen hast.
Doch eher nicht auf deinem "Notsystem" - also musste ja noch was laufen haben.Ich möchte es nur mal wissen wie man sowas testet. Ich denke, ich komme nicht drumherum, die Adapter in einem Testsystem zu verankern und zu testen mit zB nodejs19 und npm9.
Dies impliziert aber überall zwei Testsysteme, also 1. IoB, 2. DB, 3. Vis ?, 4. ???Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
@thomas-braun sagte in Node.js 18.x und iobroker (ein Test):
@segway sagte in Node.js 18.x und iobroker (ein Test):
Ich dachte ungerade Versionen sollte man nicht nehmen ?
Nicht für ein stabiles/Produktiv-System. Die Kiste auf dem nodeJS@19 läuft ist die Frickel-Bude bei mir. Die drehe ich Versions-mäßig weit raus.
Wie macht ihr das eigentlich?
Spiegelt ihr euer Produktivsysten 1:1 als neue VM irgendwo ab? Sber dann braucht man ja auch neue Datenbank VM usw! Oder knallt ihr alles auf ein System?
Oder nur Minimal-Iob Install ?@segway Ich hab unter Proxmox verschiedene Container laufen. Einmal mein Produktivsytem und dann zwei separate Container als Master / Slave System. Ich hab vor längerer Zeit mal mein Produktivsystem geclonet und auf dem Testsystem spiele ich dann mit den neuesten Versionen rum. Mit den Backups / Snapshots von Proxmox kommt man auch schnell wieder zu einem lauffähigen Stand zurück, wenn es doch mal klemmt. Auf dem Testsystem sind die gleichen Adapter installiert wie auch auf dem Produktivsystem aber ich mach es abhängig davon was ich gerade brauche welche Instanzen ich auch aktiviere.
-
@thomas-braun
Mhhh, das beschreibt aber noch nicht dein System wo du jetzt mal eben die nodejs19 und npm9 drauf laufen hast.
Doch eher nicht auf deinem "Notsystem" - also musste ja noch was laufen haben.Ich möchte es nur mal wissen wie man sowas testet. Ich denke, ich komme nicht drumherum, die Adapter in einem Testsystem zu verankern und zu testen mit zB nodejs19 und npm9.
Dies impliziert aber überall zwei Testsysteme, also 1. IoB, 2. DB, 3. Vis ?, 4. ???@segway sagte in Node.js 18.x und iobroker (ein Test):
Mhhh, das beschreibt aber noch nicht dein System wo du jetzt mal eben die nodejs19 und npm9 drauf laufen hast.
@thomas-braun sagte in Node.js 18.x und iobroker (ein Test):
Die Kiste auf dem nodeJS@19 läuft ist die Frickel-Bude bei mir. Die drehe ich Versions-mäßig weit raus.
-
@thomas-braun
Mhhh, das beschreibt aber noch nicht dein System wo du jetzt mal eben die nodejs19 und npm9 drauf laufen hast.
Doch eher nicht auf deinem "Notsystem" - also musste ja noch was laufen haben.Ich möchte es nur mal wissen wie man sowas testet. Ich denke, ich komme nicht drumherum, die Adapter in einem Testsystem zu verankern und zu testen mit zB nodejs19 und npm9.
Dies impliziert aber überall zwei Testsysteme, also 1. IoB, 2. DB, 3. Vis ?, 4. ???@segway sagte in Node.js 18.x und iobroker (ein Test):
Doch eher nicht auf deinem "Notsystem" - also musste ja noch was laufen haben.
Die beiden Systeme hab ich oben gepostet.
chet ist der 'bleeding edge' Kandidat, mysterium ist der Notnagel.
(mysterium läuft mit nodeJS18, aber auch nur weil ich da mal vor geraumer Zeit ein Backup aus dem chet reingejubelt habe und der schon mit npm8 lief. Da wollte ich mich auf den Notnagel nicht mehr mit npm6 beschäftigen).Und nodeJS kannste ja total easy über den Paketmanager jonglieren.
-
@segway sagte in Node.js 18.x und iobroker (ein Test):
Doch eher nicht auf deinem "Notsystem" - also musste ja noch was laufen haben.
Die beiden Systeme hab ich oben gepostet.
chet ist der 'bleeding edge' Kandidat, mysterium ist der Notnagel.
(mysterium läuft mit nodeJS18, aber auch nur weil ich da mal vor geraumer Zeit ein Backup aus dem chet reingejubelt habe und der schon mit npm8 lief. Da wollte ich mich auf den Notnagel nicht mehr mit npm6 beschäftigen).Und nodeJS kannste ja total easy über den Paketmanager jonglieren.
Ja das ist mir schon klar.
Naja, muss jeder selber für sich definieren. ich kann mir jedenfalls nix unter einem Setup vorstellen, den man "Frickelbude" nennt.
Nichts für ungut ... wie gesagt definiert jeder selber für sich. Meine Definition steht fast und dazu baue ich nun die Hardware drumherum bzw. miete Sie mir :-) Schönen Abend noch !Gruß Dirk
Intel Proxmox Cluster (3x NUC) mit Debian & Proxmox / IoB als VM unter Debian / 60+ Adapter installiert -
Ja das ist mir schon klar.
Naja, muss jeder selber für sich definieren. ich kann mir jedenfalls nix unter einem Setup vorstellen, den man "Frickelbude" nennt.
Nichts für ungut ... wie gesagt definiert jeder selber für sich. Meine Definition steht fast und dazu baue ich nun die Hardware drumherum bzw. miete Sie mir :-) Schönen Abend noch !@segway sagte in Node.js 18.x und iobroker (ein Test):
ich kann mir jedenfalls nix unter einem Setup vorstellen, den man "Frickelbude" nennt.
Halt eine Kiste, bei der es nicht schlimm ist, wenn da mal was daneben läuft.
-
Ja das ist mir schon klar.
Naja, muss jeder selber für sich definieren. ich kann mir jedenfalls nix unter einem Setup vorstellen, den man "Frickelbude" nennt.
Nichts für ungut ... wie gesagt definiert jeder selber für sich. Meine Definition steht fast und dazu baue ich nun die Hardware drumherum bzw. miete Sie mir :-) Schönen Abend noch !@segway sagte in Node.js 18.x und iobroker (ein Test):
ich kann mir jedenfalls nix unter einem Setup vorstellen, den man "Frickelbude" nennt.
wäre Experimental-Installation verständlicher?
-
@segway Ich hab unter Proxmox verschiedene Container laufen. Einmal mein Produktivsytem und dann zwei separate Container als Master / Slave System. Ich hab vor längerer Zeit mal mein Produktivsystem geclonet und auf dem Testsystem spiele ich dann mit den neuesten Versionen rum. Mit den Backups / Snapshots von Proxmox kommt man auch schnell wieder zu einem lauffähigen Stand zurück, wenn es doch mal klemmt. Auf dem Testsystem sind die gleichen Adapter installiert wie auch auf dem Produktivsystem aber ich mach es abhängig davon was ich gerade brauche welche Instanzen ich auch aktiviere.
@feuersturm ich denke, das was @Segway eher meint, testen im vollen Umfang, jedoch ist das ja nur bedingt möglich, da gewisse Adapter/Geräte Netztechnisch auf unterschiedliche Ip Adressen agieren.
z.b. shelly, sonoff..(mqtt)
oder Daten in eine Datenbank schreibengenau aus solch Gründen hab ich auch kein Testsystem, ist mir zu umständlich
umgestiegen von Proxmox auf Unraid
-
@feuersturm ich denke, das was @Segway eher meint, testen im vollen Umfang, jedoch ist das ja nur bedingt möglich, da gewisse Adapter/Geräte Netztechnisch auf unterschiedliche Ip Adressen agieren.
z.b. shelly, sonoff..(mqtt)
oder Daten in eine Datenbank schreibengenau aus solch Gründen hab ich auch kein Testsystem, ist mir zu umständlich
@crunchip
Ja genau,
du hast es erfasst.
Mir geht es nicht um das "wording" wie ich ein solches System nenne sondern wie ich es aufsetze und da passt deine Beschreibung bestens.
Wie soll ich etwas testen, wenn nicht die Adapter, die ich nutze in meinem Testsystem vorhanden sind, wie Datenbank, Shelly, Modus, Solarlog, simple-Api usw.ABER alle werden auf die gleichen Geräte zugreifen sprich die Komponenten wie CCUx, Shelly, EnOcean usw. haben eine double load, was ich persönlich nicht so pralle finde zumal bei mir noch zB eine CCU2 werkelt.
Daher war die Frage, wie man so etwas aufbaut um es vernünftig zu testen. Danke @crunchip deine Beschreibung trifft es seht gut :-)
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden328
Online32.9k
Benutzer82.9k
Themen1.3m
Beiträge