Weihnachtsangebot 2025! 🎄

[NetFritz]

@Skippy07

externalModules: {
         // autoInstall: false,   /** Whether the runtime will attempt to automatically install missing modules */
         // autoInstallRetry: 30, /** Interval, in seconds, between reinstall attempts */
         palette: {    /** Configuration for the Palette Manager */
              allowInstall: '%%palletmanagerEnabled%%' /** Enable the Palette Manager in the editor */
         //     allowUpdate: true,  /** Allow modules to be updated in the Palette Manager */
         //     allowUpload: true,  /** Allow module tgz files to be uploaded and installed */
         //     allowList: ['*'],
         //     denyList: [],
         //     allowUpdateList: ['*'],
         //     denyUpdateList: []
         // },

[Skippy07]

@netfritz So sieht es bei mir auch aus

[NetFritz]

@netfritz
Habe eben nochmal node Red aus der Adapter Übersicht installiert.
Dann steht in der Instanz Seite von Node Red eine Fehlermeldung.

Backups will not contain any projects or modules installed via the Palletmanager!

Der fällt mit ein ich hatte ja Gestern Debian und ioBroker neu Installiert.

Und gegen Abend ein Backup (ioBroker und Node Red) von einem anderen Rechner mit Ubuntu 20
aber mit den gleichen Versionen von den Adaptern auf den Debian Rechner eingespielt.
Vielleicht ist da schon etwas schief gelaufen.
Auf meinen Debian ioBroker und Node Red waren die Adapter und Fows vom Ubuntu Rechner nicht vorhanden.

Vielleicht sollte ich ioBroker und Node Red neu installieren.

[mickym]

@netfritz Diese Meldung ist völlig normal. Mach Dir keine Gedanken. Wenn Du NodeRed den extra Haken im BackitUp machst wird das auch mitgesichert und Du musst nachdem Restore nur noch eine npm install ausführen. Diese Warnung finde ich so überflüssig, weil der Palettenmanager wesentlich besser ist, als die Module manuell in die Adapterinstanz einzutragen. Ich weiß nicht, warum man diese dumme Warnung nicht längst rausgenommen hat und ggf. auf den extra Haken im Backitup verweist.

[haus-automatisierung]

@mickym Wo finde ich deinen Issue dazu?

[mickym]

@haus-automatisierung Ich gebe zu, dass ich dieses Mal kein Issue erstellt habe, ich will hier ja nicht immer der "Böse" sein.

Das Entfernen des Paletten-Managers wurde damals mit Node-Red Adapter 2.x eingeführt und ich habe mich damals schon aufgeregt: https://forum.iobroker.net/topic/34681/kein-paletten-verwalten-im-neuen-node-red-adapter?_=1703873162630

Das wurde so gemacht, weil man es halt im Javascript Adapter auch gemacht hat.

Da das normale Backup nicht nur zusätzliche Module (Nodes) nicht wiederhergestellt hatte, sondern auch, wenn man die Projektfunktion nicht ordnungsgemäß gesichert hat, gab es erst einen Disput, ob das nun ein Problem von backitup oder nodered Adapter ist. So habe ich damals ein Issue sowohl hier wie dort aufgemacht:

https://github.com/ioBroker/ioBroker.node-red/issues/321

https://github.com/simatec/ioBroker.backitup/issues/1005

Beide sind inzwischen wieder geschlossen. - Ich hab da ehrlich keine Lust mehr dieses Thema wieder aufzurollen, so wie das behandelt wurde. Man kann ja wieder einen dieser Issues aufmachen.

Fakt ist: Die zusätzlichen Nodes werden nicht im normalen Backup mitgesichert - insofern ist die Warnung korrekt.
Fakt ist auch: @simatec nun doch sehr viel Arbeit reingesteckt hat und nun auch die komplette Pallete mit der package.json mit gesichert werden, wenn man das Node-Red Backup extra ankreuzt.

Es fehlt lediglich das letzte npm install im Node-Red Datenverzeichnis der jeweiligen Instanz. Keine Ahnung, ob das inzwischen mit beim Restore ausgeführt wird oder nicht.

Jedenfalls ist das Verbieten des Paletten-Managers nicht akzeptabel - da folgende Einschränkungen:

1. Keine Volltextsuche nach neuen Node-Typen
2. Keine Überprüfung ob Updates vorliegen
3. Kein Überprüfung wenn Module aus der Adapterkonfig genommen wurden, ob die entsprechenden Nodes in den Flows verwendet werden.

Hier wurde halt mit der Adapterversion 2.x etwas eingeführt, was halt nicht unbedingt vorher mit "Community" abgestimmt wurde.

Wie gesagt - wurden hier mehrfach auf die Problematik hingewiesen. Aber mich stört die Meldung inzwischen genauso wenig, wie die Warnmeldung, dass keine Projekte aktiv sind (keine Ahnung was das soll - arbeitet eh keiner damit, speziell seit man mehrere NodeRed Instanzen im iobroker haben kann).

Keine Ahnung auch, warum man diese BackitUp Funktion der NodeRed Sicherung extra anhaken muss und nicht automatisch macht. Ich denke, dass das hier aber Designfragen am Gesamtkonzept sind. Ich glaube aber dass ich meinen Teil zu diesem Thema bereits beigetragen habe, auch wenn die Issues wieder zu sind.

Es sind ja im Übrigen auch nicht nur die Nodes futsch, wenn man nur die flows.json und die credentials sichert, es gehen ja auch Konfigurationen verloren (nicht wenn man node-red Backup extra ankreutzt), die bestimmte Nodes mit sich bringen (cron-plus etc. ..). Wie gesagt mit dem neuen Backup wird alles gesichert bis auf das nodes_modules verzeichnis, dass muss man halt derzeit (wie gesagt ich habe nicht den letzten Stand bei Backitup Adapter) manuell mit npm install wieder herstellen.

[haus-automatisierung]

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

ich will hier ja nicht immer der "Böse" sein.

Mh? Ist doch total normal dass Fehler gemeldet und Verbesserungen vorgeschlagen werden. Mache ich doch auch ständig bei allen möglichen Adaptern.

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

Das Entfernen des Paletten-Managers wurde damals mit Node-Red Adapter 2.x eingeführt

Kann doch aber über die Instanzkonfiguration wieder aktiviert werden? Mit 5.1.0 funktioniert das bei mir jedenfalls:

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

Fakt ist: Die zusätzlichen Nodes werden nicht im normalen Backup mitgesichert - insofern ist die Warnung korrekt.

Ja. Nur wäre ein zusätzlicher Hinweis auf den Backitup-Adapter trotzdem sinnvoll.

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

Keine Ahnung auch, warum man diese BackitUp Funktion der NodeRed Sicherung extra anhaken muss und nicht automatisch macht.

Das ist ja bei jedem Adapter so (History, SQL, ...). Zumindest wäre es nicht unbedingt "best practice" wenn eine Instanz die Einstellungen einer anderen ändert (habe ich so zumindest noch nirgendwo gesehen).

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

es gehen ja auch Konfigurationen verloren (nicht wenn man node-red Backup extra ankreutzt), die bestimmte Nodes mit sich bringen (cron-plus etc. ..)

Achso? Da muss ich mir mal anschauen, was da genau für Dateien angelegt werden.

[mickym]

@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:

Achso? Da muss ich mir mal anschauen, was da genau für Dateien angelegt werden.

Nein mit dem neuen Backup werden diese Verzeichnisse mitgesichert - in meinen Augen insofern kein Handlungsbedarf.

Das ist auch nicht festgelegt, da jede Node selbst ein Verzeichnis für Filekonext erstellen kann.

Hier nur mal ein Beispiel meiner NodeRed Instanz - wobei ich jetzt nicht jedes Verzeichnis sagen kann, ist auch auf keines verzichtbar.

lib - enthält die in der lokalen Bibliothek gespeicherten Flows
cronplusdata - enthält Konfigurationen der cronplus node
homekit-persist - enthält die yahka entsprechenden Nodes

aber wie gesagt - alles wird über die eigene NodeRed Sicherung mitgesichert und es sollten auch alle Verzeichnisse gesichert werden.

[mickym]

@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:

Kann doch aber über die Instanzkonfiguration wieder aktiviert werden? Mit 5.1.0 funktioniert das bei mir jedenfalls:

Ja ist doch auch gut - es geht ja nur über die Warnmeldung, die den Threadersteller verunsichert hat.

[mickym]

@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:

Das ist ja bei jedem Adapter so (History, SQL, ...). Zumindest wäre es nicht unbedingt "best practice" wenn eine Instanz die Einstellungen einer anderen ändert (habe ich so zumindest noch nirgendwo gesehen).

Müsste ja nicht sein, wenn die NodeRed Sicherung bei Installation des Adapters diese automatisch ausführt. Aber egal - wie gesagt, ich will mich da nicht einmischen.

[Marc Berg]

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:

Hier nur mal ein Beispiel meiner NodeRed Instanz

Interessant, auch wenn es jetzt noch weiter OT geht: Die erste NodeRed Instanz wird im Ordner

/opt/iobroker/iobroker-data/node-red/

, die zweite Instanz im Ordner

/opt/iobroker/iobroker-data/node-red.1

angelegt. Ein Restore der ersten Instanz wird wiederum in Ordner

/opt/iobroker/iobroker-data/node-red.0

erstellt. Auf einem frischen System hat die Wiederherstellung deshalb bei mir nicht funktioniert. Ich musste die Dateien erst umkopieren. Ich würde ein Issue aufmachen, aber wo liegt der Fehler? Node-Red oder Backitup?

[mickym]

@marc-berg Ja habe ich auch schon festgestellt - Umbennen der node-red.0 Verzeichnisses hätte auch funktioniert. ;)

Das Problem mit den Instanz Nummern kam erst mit der Adapter-Version 4 glaub dazu - da vorher waren nicht mehrere Instanzen möglich.

[haus-automatisierung]

@marc-berg sagte in ioBroker Node Red palettenmanager fehlt:

Ich würde ein Issue aufmachen, aber wo liegt der Fehler? Node-Red oder Backitup?

Aus irgend einem Grund wurde damals im Node-RED-Adapter bei der ersten Instanz die Nummer nicht angehangen. Das ist schon ewig so. Wahrscheinlich, weil mal nur eine erlaubt wurde (?).

https://github.com/ioBroker/ioBroker.node-red/blob/50de1a0443076f8b55e8728b86d49cf1b719fdad/main.js#L342-L347

Ob das eine schlaue Entscheidung war? Wahrscheinlich eher nicht. Dennoch sollte sich der Backitup-Adapter auch an diese Ausnahme halten.

[Marc Berg]

@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:

Dennoch sollte sich der Backitup-Adapter auch an diese Ausnahme halten.

Verstehe. Nicht schön, aber die Alternative wäre wahrscheinlich kaum umsetzbar.

[Marc Berg]

@mickym sagte in ioBroker Node Red palettenmanager fehlt:

Es fehlt lediglich das letzte npm install im Node-Red Datenverzeichnis der jeweiligen Instanz. Keine Ahnung, ob das inzwischen mit beim Restore ausgeführt wird oder nicht.

Nö, wird nicht. Es kommt aber ein Hinweis (der im Moment natürlich im falschen Pfad ins Leere läuft)

[DEBUG] [nodered] - Node-Red Restore completed successfully
[DEBUG] [nodered] - To complete the restore, please run an "npm install" in the path "/opt/iobroker/iobroker-data/node-red.0".

[haus-automatisierung]

@marc-berg sagte in ioBroker Node Red palettenmanager fehlt:

Nicht schön, aber die Alternative wäre wahrscheinlich kaum umsetzbar.

Die Alternative wäre ja noch komplizierter. Wenn man jetzt im Node-RED-Adapter ein Upgrade-Script baut, welches ab 5.2.0 oder so alles in node-red.0 speichert, dann müsste der Backitup-Adapter ja schauen, welche Adapter-Version das war und entweder das eine oder das andere Verzeichnis wiederherstellen.

Aktuell ist die Regel ja klar: Falls node-red.0, dann node-red.

[Marc Berg]

@haus-automatisierung sagte in ioBroker Node Red palettenmanager fehlt:

Die Alternative wäre ja noch komplizierter.

Äh, ja. Das meinte ich mit "kaum umsetzbar".

[mickym]

@marc-berg Aber immerhin geht das jetzt alles - vor einem halben Jahr hattest du, wenn Du den Paletten-Manager verwendet hast, gar keine Chance gehabt, Dein System wiederherzustellen - bzw. hättest Node-Typ für Node-Typ nachinstallieren müssen.

[simatec]

@marc-berg In v2.9.10 von Backitup habe ich die Instanz 0 gefixt und einen automatischen npm installeingebaut.
Aufgrund fehlender node-red Installation würde ich dich bitten, das mal zu testen.

Sollte heute Nacht ins latest kommen, oder halt über Github

[Marc Berg]

@simatec sagte in ioBroker Node Red palettenmanager fehlt:

Aufgrund fehlender node-red Installation würde ich dich bitten, das mal zu testen.

Die Wiederherstellung erfolgt jetzt im korrekten Verzeichnis und npm install wird ausgeführt. :+1:

Wenn ich allerdings von einem jungfräulichen ioB System ausgehe und nur die Node-Red Sicherung wiederherstelle, so können die Credentials nicht entschlüsselt werden. (Node-Red Adapter Version Quelle+Ziel jeweils 5.1.0)

Credentials

Die Frage ist, ob dies ein sinnvoller Use Case ist und betrachtet werden müsste?