[Aufruf] ioBroker für Windows, Version 1.5.11

[klassisch]

Klasse und herzlichen Dank! Mein "neuer" Rechner steht bereit und wartet schon auf ioBroker.
Dann werde ich heute mal alles final vorbereiten und heute Nacht in der "Schwachlastzeit" migrieren.
Dazu ein paar Fragen:

• Ich möchte vom OPi auf ein Thinkpad X250 mit i5 5300u 8GB RAM umsteigen. Der OPi reagiert u.U. nicht mehr richtig, wenn ich meine FLOT-Sammlung mit ca. 40 Charts öffne. Ich möchte die IP Adresse vom OPi gerne übernehmen, um ansonsten nichts ändern zu müssen. Dazu sehe ich 2 Möglicheiten
  -- Opi Backuppen und stillegen. Dann dem Eth vom X250 aufsetzen die IP Adresse zuweisen, ioBroker aufsetzen, restoren und starten.
  -- ioBroker Grundinstallation auf dem X250 via WLAN aufsetzen und erst danach den OPI backuppen, stillsetzen und die IPAdresse dem Eth vom X250 zuweisen. So hat der ioBroker die kürzere Ausfallzeit.
  Welche Methode ist besser?

Nächste Frage: Ich möchte auf den X250 noch ein zweites Programm migrieren, welches allerdings auch den Port 8081 verwendet. Kann ich die Ports beim ioBroker irgendwo umstellen? Oder sollte man davon besser die Finger lassen?

[Stabilostick]

@klassisch

Beides ist möglich. Zuerst aber eine Frage: Kannst Du dem X250 vor dem Restore den gleichen Rechnernamen geben wie dem OPI?

Nächste Frage: Ich möchte auf den X250 noch ein zweites Programm migrieren, welches allerdings auch den Port 8081 verwendet. Kann ich die Ports beim ioBroker irgendwo umstellen?

Wenn Du das Setup im Expertenmodus durchführst, geht das aktuell für eine Neuinstallation. Nach dem Restore vom OPI hast Du aber dessen Admin-Port-Einstellung übernommen. Wenn alles läuft, dann mit den folgenden Kommandozeilenbefehlen (aufgerufen über das Startmenü) dem Admin einen neuen Port zuweisen:

iobroker set admin.0 --port <beliebiger_freier_port>
iobroker restart admin.0
iobroker list instances

Die letzte Anweisung zeigt Dir neben den Adapterinstanzen auch ggf. deren Ports mit an.

[klassisch]

@Stabilostick Vielen Dank für Deine Antwort! Da triffst Du bei mir einige blinde Flecken. Da ich die Geräte immer mit IP anspreche, habe ich mich nie um die Namen gekümmert. Zumal es damit mal Verwirrung gab, weil die Rechner in der Fritte anders benannt wurden als im Windows. Mir ist dann auch nicht klar, ob der Name dann für Eth oder WLAN gilt.
Aber mein X250 ist noch nicht produktiv, also sollte ich den Namen ändern können, wenn es so geht https://www.windowspower.de/windows-10-computername-aendern/
Nur welchen Namen muß ich eintragen? ioBroker Admin zeigt

Host opi2e_ioBroker

Fritte sagt

opi2e-ioBroker

Opi's Konsole sagt

root@opi2e_ioBroker:~#
root@opi2e_ioBroker:~# hostname
opi2e_ioBroker

Also 2:1.
Und übernimmt die Fritte dann den Namen nach der Änderung, oder behält die den jetzigen bei?

Ich nehme an, daß ich die Portbelegung des X250 mit

NETSTAT -an

herausbekomme, wie in http://www.winfaq.de/faq_html/Content/tip1000/onlinefaq.php?h=tip1143.htm beschrieben. Ich würde einfach eine 1 davor setzen und damit 18081 wählen falls nichts dagegen spricht, z.B. wenn das eine anderweitig beliebte Standardadresse wäre.

[Stabilostick]

@klassisch

Schnelle Idee zum Ablauf:

• Lass dem Windows seinen Namen.
• Installiere den ioBroker mit dem Windows-Setup. Der einfache Modus reicht.
• Stoppe den ioBroker-Dienst der installierten Instanz und setze die Startart des Dienstes auf „manuell“.
• Benenne den Ordner iobroker-data im Instanzverzeichnis um.
• Kopiere vom opi den Ordner iobroker-data komplett in den Instanzordner auf Windows. (WinSCP, USB-Stick, o.ä.)
• Ändere die IP des Windows-Rechners auf die des opi. (Weil Du Das so magst)
• Schalte den opi aus.
• Starte den Windows Rechner. Weil der Dienst auf manuell steht, starte der ioBroker nicht. Das ist gut.
• Rufe die Kommandozeile der installierten Instanz über das Startmenü auf.
• iobroker host this ausführen, um den Hostnamen im ioBroker auf den des Windows-Rechners zu ändern.
• iobroker set admin.0 --port <dein_port_für_admin> um den Admin-Port anzupassen.
• iobroker list instances für eine Instanzübersicht.
• Dann den ioBroker-Dienst der Instanz auf automatisch stellen und starten.
• Logs prüfen. Wenn der Dienst nicht startet, auch die Logs im Ordner daemon.
• Die fehlenden Adapter werden vom ioBroker beim Start erkannt und automatisch nachinstalliert. Das kann etwas dauern, auf langsamen Systemen auch gerne länger. Der Fortschritt ist im Log erkennbar.
• Wenn alles läuft, kannst der umbenannte iobroker-data-Ordner gelöscht werden.

Fallback: Der opi ist nicht verändert und kann einfach wieder eingeschaltet werden. Natürlich muss der Windows-Rechner dann aus sein, wegen der gleichen IP-Adresse.

Wir können das auch zusammen machen, wenn Du Dich da sicherer fühlst. Gerne kannst Du mir eine PN im Chat schreiben.

[klassisch]

@Stabilostick sagte in [Aufruf] ioBroker für Windows, Version 1.5.x:

Wir können das auch zusammen machen, wenn Du Dich da sicherer fühlst. Gerne kannst Du mir eine PN im Chat schreiben.

Vielen Dank für dieses sehr freundliche Angebot, welches ich sehr zu schätzen weiß! Noch mehr schätze ich allerdings Deine Zeit als Entwickler. So eine Migration beinhaltet erfahrungsgemäß viele langwierige Kopiervorgänge und Wartezeiten. Die möchte ich Dir nicht antun, dazu ist Deine Zeit zu wertvoll und Du kannst Deine Zeit sicher sinnvoller nutzen.

Vielen Dank für die Schritt für Schritt-Anleitung. Ich versuche die heute Nacht bzw. morgen früh in der Schwachlastzeit, wenn wenige Daten anfallen bzw. verloren gehen umzusetzen. Werde mir Notizen machen und anschließend auch eine Anleitung verfassen.
Wenn ich auf unüberwindliche Hindernisse stoßen sollte, nehme ich den X250 wieder vom Eth und gehe auf den OPi zurück Außer ein paar Stunden Datenaufzeichnung wäre dann nichts verloren. Und ich habe auch die Jahrzehnte vor ioBroker ohne Datenaufzeichnung überlebt
Und dann würde es halt nächstes WE weiter gehen. Komfortable Situation.

Noch eine Frage: Werden bei diesem Verfahren die Adapter in der gleichen Version wie beim OPi genommen, oder wird automatisch upgedatet.

[klassisch]

Vielen Dank, die Migrationsanweisung hat gepasst.
Die Windows Integration macht einen sehr erwachsenen Eindruck. Es gibt sogar einen Eintrag im Startmenue zum Aufrufen der ioBroker Konsole.
Das Mitlesen des logs ist schon respekteinflößend! Was da alles unter der Haube abgeht, wirklich allen Respekt!
Einmal ist der ioBroker dabei abgeschmiert.
Dann war der web-Adapter störrisch und history kann einige Daten nicht schreiben, wahrscheinlich seltsame Dateinamen oder so.
Das process-List JS Script erzeugt Fehler; klar ist für Linux geschrieben und läßt ps aufs OS los.
Beim Updaten von vis gabs eine lange Fehlerliste. Meine recht einfach gehaltenen Seiten gehen dennoch.
Der info-Adapter lief mal amok und brachte jede Sekunde eine Fehlermeldung "TypeError: Cannot read property 'push' of undefined ". Nach Adapter restart wieder iO.
Werde das Ganze mal noch etwas beobachten.

[Stabilostick]

@klassisch

Super, dass Du es geschafft hast!

Werden bei diesem Verfahren die Adapter in der gleichen Version wie beim OPi genommen, oder wird automatisch upgedatet.

Je nachdem, auf welchem Repository der Quell-ioBroker stand (Stable oder Latest), werden die Adapter in den jeweils aktuellen Versionen nachinstalliert.

history kann einige Daten nicht schreiben

Bitte ändere einen Eintrag in der Datei ...\iobroker-data\iobroker.json und mache aus dem /-Zeichen eine Klammer wie folgt:

{
  "system": {
    "memoryLimitMB": 0,
    "hostname": "<Dein_Rechnername>(<Dein_Instanzname>)",   <---- hier ändern
    "statisticsInterval": 15000,

[...]

Dann führe sicherheitshalber noch einmal

iobroker stop
iobroker host this
iobroker start

aus.

Das mit der Namensänderung integriere ich dann auch so in die nächste Version des Setups.

Danke für die ausfürliche Beschreibung. Ich habe das Gefühl, dass es einen js-controller 1.5.12 geben wird.

[klassisch]

@Stabilostick Das ist seltsam mit den History-Fehlern.
Denn jetzt sind sie weg. Hatte zwischenzeitlich mal den X250 rebootet.
Und in der iobroker.json gibt es kein Kapitel "system".
Jetzt ist gerade alles ruhig.
Die History-Fehler waren etwa solche:

2019-06-02 05:17:01.154  - error: history.0 Cannot store file d:/History/20190602/history.hm-rpc.0.*IEQ0509xxx.1.INSTALL_TEST.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.hm-rpc.0.*IEQ0509xxx.1.INSTALL_TEST.json'
2019-06-02 05:17:01.155  - error: history.0 Cannot store file d:/History/20190602/history.hm-rpc.0.*IEQ0509xxx.1.STATE.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.hm-rpc.0.*IEQ0509xxx.1.STATE.json'
2019-06-02 05:17:01.156  - error: history.0 Cannot store file d:/History/20190602/history.hm-rpc.0.*LEQ0035xxx.1.INSTALL_TEST.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.hm-rpc.0.*LEQ0035xxx.1.INSTALL_TEST.json'
2019-06-02 05:17:01.156  - error: history.0 Cannot store file d:/History/20190602/history.hm-rpc.0.*LEQ0035xxx.1.STATE.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.hm-rpc.0.*LEQ003xxxx.1.STATE.json'
2019-06-02 05:17:01.157  - error: history.0 Cannot store file d:/History/20190602/history.hm-rpc.0.*LEQ012xxxx.1.INSTALL_TEST.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.hm-rpc.0.*LEQ012xxxx.1.INSTALL_TEST.json'
2019-06-02 05:17:01.157  - error: history.0 Cannot store file d:/History/20190602/history.hm-rpc.0.*LEQ012xxxx.1.STATE.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.hm-rpc.0.*LEQ0122987.1.STATE.json'
2019-06-02 05:17:20.965  - error: history.0 Cannot store file d:/History/20190602/history.system.adapter.simple_2~_2~_2~_2~_2~api.upload.json: Error: ENOENT: no such file or directory, open 'd:/History/20190602/history.system.adapter.simple_2~_2~_2~_2~_2~api.upload.json'

Ich habe im History Adapter die Pfadangabe nach Win Schreibweise, als mit Backslash

D:\History

eingegeben. Vielleicht ist das falsch und ich hätte besser die Linux-Form

d:/History

verwenden sollen.
Aber so wie aussieht wrd das Gros der Daten geschrieben, allerdings auch einige mit präfix "_" oder "%2A".

Und auch zu den beanstandeten Namen gibt es Daten. Beispiel

history.hm-rpc.0.LEQ0035264.1.STATE.json
history.hm-rpc.0.LEQ0035264.0.UPDATE_PENDING.json
history.hm-rpc.0.LEQ0035264.0.UNREACH.json
history.hm-rpc.0.LEQ0035264.0.STICKY_UNREACH.json
history.hm-rpc.0.LEQ0035264.0.LOWBAT.json
history.hm-rpc.0.LEQ0035264.0.CONFIG_PENDING.json
history.hm-rpc.0.LEQ0035264.0.DEVICE_IN_BOOTLOADER.json
history.hm-rpc.0.LEQ0035264.0.DUTYCYCLE.json
history.hm-rpc.0.LEQ0035264.0.LOWBAT_ALARM.json
history.hm-rpc.0.LEQ0035264.0.STICKY_UNREACH_ALARM.json
history.hm-rpc.0.LEQ0035264.0.UNREACH_ALARM.json
history.hm-rpc.0.LEQ0035264.0.CONFIG_PENDING_ALARM.json
history.hm-rpc.0.LEQ0035264.0.DUTYCYCLE_ALARM.json
history.hm-rpc.0._LEQ0035264.1.INSTALL_TEST.json
history.hm-rpc.0._LEQ0035264.1.STATE.json
history.hm-rpc.0.LEQ0035264.1.INSTALL_TEST.json
history.hm-rpc.0.LEQ0035264.0.RSSI_PEER.json
history.hm-rpc.0.LEQ0035264.0.RSSI_DEVICE.json
history.hm-rpc.0.%2ALEQ0035264.1.INSTALL_TEST.json
history.hm-rpc.0.%2ALEQ0035264.1.STATE.json

Wobei es sich bei dem LEQ0035264 um einen alten Rauchmelder handelt, der als Team (Gruppe) geschaltet ist.
Die zugrundeliegende HM-Installation ist im Grunde uralt mit einer langen Migrationsgeschichte (CCU1 -> CCU2 -> piVCCU -> piVCCU3) und kann schon einige Macken haben.
Wenn Du magst, kann ich Dir das heute Log per chat zukommen lassen, wenn das die Forums-SW noch hergibt.

[Stabilostick]

@klassisch

Habe mir inzwischen den history-Adapter kurz angesehen. Er verwendet die vollständigen Objektnamen zum Speichern der Werte der States. Ich hatte nach Deiner ersten Schilderung vermutet, dass das /-Zeichen im Hostanzeigenamen Probleme macht, da es als Dateinamensbestandteil unter Windows und Linux verboten ist.

Der History-Adapter hat aber glücklicherweise dafür bereits eine Ausnahmeregelung eingebaut. Er ersetzt die Zeichen : und / sowie das 0-Byte einfach durch ~. Die Richtung der Slashes (/ oder \) im Pfad ist egal. Mach Dir deswegen keine Sorgen.

Problematischer sind die *-Zeichen. Die sind ebenfalls (inzwischen) verboten. Und zwar in Dateinamen und im ioBroker.

Leider bin ich mit Homematic nicht so firm. Ein alter hm-rpc-Adapter hat wohl früher Objekte mit * im Namen angelegt. Wenn diese States noch im Objektbaum vorhanden sind und die Historisierung darauf aktiv ist, dann ergibt das die bei Dir aufgetretenen Probleme. Die jetzt im ioBroker eingebaute Sperrliste mit verbotenen Zeichen (aktuell sind das die Zeichen []*,;'"`<>\?) wirkt u.a. nur beim Anlegen usw.

Kann es sein, dass Du inzwischen für jedes Objekt mit * im Namen (z.B. hm-rpc.0.*IEQ0509xxx) jetzt ein zweites mit _ hast (z.B. hm-rpc.0._IEQ0509xxx)? Das sind dann die aktuellen. ioBroker ersetzt diese Sperrzeichen jetzt mit einem _. Die alten Objekte mit verbotenen Zeichen können weg.

Tipp: Teste das, indem Du zuerst ein Objekt mit * löscht und dann die Daten von der Homematic neu synchronisierst. Wenn das klappt, lösche alles mit *. Und dann natürlich die Historisierung wieder auf die aktuellen Objekte einrichten.

[paul53]

@Stabilostick sagte:

ein zweites mit _ hast (z.B. hm-rpc.0._IEQ0509xxx)?

Die IDs des hm-rpc-Adapters lauten hm-rpc.0.IEQ0509xxx.N.IRGENDWAS (N = Ziffer)

[Homoran]

@paul53
Gruppen haben bei HM einen *

[paul53]

@Homoran sagte:

Gruppen haben bei HM einen *

Danke für die Info. Da ich keine Rega verwende, kenne ich keine Gruppen.

[klassisch]

@Stabilostick Danke für die Hinweise! Hatte den Artikel mit den verbotenen Zeichen damals gelesen und das Reinigungsskript angewendet. Habe heute nicht nur den Rechner neu gestartet, sondern auch die HM-Adapter auf Vordermann gebracht. Seither ist Ruhe mit diesen Fehlermeldungen. Wahrscheinlich haben die neuen Adapter das Thema gelöst. Auf dem OPi hatte ich auch schon mal die neueren HM-Adapter installiert. Das hatte sich aber leider nicht bewährt; die Anzahl der DB reconnects stieg deutlich an, weshalb ich wieder auf alte Versionen zurück bin. Einer der Hauptgründe für die Migration auf einen stärkeren Rechner.
Die Gruppen habe ich nur bei den Rauchmeldern, weil die sich gegenseitig alarmieren. Ansonsten habe ich solche Sache vermieden, KISS.

[kevlar]

ich hab gerade folgendes Setup:

• Windows 10 mit iobroker (damals manuell installiert) als Hauptserver
• Raspberry PI 3 als 2. Host

Nun möchte ich bei Windows 10 die alte iobroker instanz begraben und mit dem Installer neustarten. (Unter anderem aufgrund von NPM/Node Update problemen und nerviger manueller Wartung).
Bei den Instanzen hab ich nun im Admin Backend alle zum Raspberry geändert. IP für Vis, Admin Backend usw ist jetzt der Raspberry, das klappt soweit.
Wenn ich nun den iobroker Dienst bei Windows beende ist aber auch das Backend nichtmehr aufrufbar. macht das Sinn?

[klassisch]

Denke, das ist eher eine Frage für die Rubrik Multihost System als für Windows Installer. Das Systemverhalten wird ja im eigentlichen ioBroker Code festgelegt und sollte somit plattformunabhängig sein. But I stay to be corrected.
Ich persönlich hätte grob folgende Schritte zur Erneuerung des Systems durchgeführt:

• Backup auf dem Win System durchführen
  • Mit Backitup Adapter das normale Backup durchführen
  • Alle History Daten etc. sichern
• Alle ioBroker Instanzen anhalten. Auch auf den anderen Hosts
• Die bisherige Windows-ioBroker Instanz entfernen wie im Eingangspost unter "Wie entferne man eine Testinstallation?" beschrieben. Laut ToDo-List wird dieser Schritt von einer zukünftigen Version des Installers ebenfalls angebiten werden
• Mit dem Installer die neue Version installieren lassen
• Backup restoren
• alle Instanzen starten, auch auf dem Raspi etc.
  Das Verschieben der Instanten auf den Raspi würde ich mich nicht trauen, da ich befürchte, daß dann die Daten unter einem anderen Namen nochmals angelegt werden. Aber ich weiß nicht, ob diese Befürchtung richtig ist. Jedenfalls wäre mir das auch zu kompliziert

Meine generelle Updatestrategie bzw. -Hoffnung ist:

• Teilupdates von Adaptern etc. nur innerhalb von Hauptreleases
• Update auf neue Hauptreleases nur über diesen Installer von @Stabilostick so daß ich dann ein konsistentes Paket bekomme.

[kevlar]

@klassisch ich dachte immer "verschieben" sprich Server bei den Instanzen ändern funktioniert problemlos. Alle Instanzen sind auf jeden Fall nach dem verschieben auf den Raspi noch einsatzbereit. Komisch ist dass es keine Statusanzeige vom verschieben gibt. das müsste ja ein bisschen dauern und könnte der Grund sein warum ich ioBroker bei Windows noch nicht beenden kann. multihost hab ich bei beiden testweise deaktiviert, Windows beenden killt aber immer noch alles.
Mysteriös das ganze.
Ich wollte halt mit dem Installer wirklich ganz frisch starten und nicht wieder per Backup altlasten draufspielen.

[klassisch]

@kevlar sagte in [Aufruf] ioBroker für Windows, Version 1.5.x:

Ich wollte halt mit dem Installer wirklich ganz frisch starten und nicht wieder per Backup altlasten draufspielen.

Ich verwende noch kein Multihost. Insofern kann ich nicht genau sagen was da passiert. Aber ich stelle mir das kompliziert vor, weil ja die meisten Adapter ihre Objekte lokal auf dem host halten.
Das System komplett neu aufsetzen ist natürlich so eine Sache. Wenn Du wirklich die "Platte putzt", dann sind natürlich auch Deine Objekte weg und die Verbindung zu deren History. Das kannst Du wahrscheinlich zwar alles wieder aufbauen, aber das kann sehr mühselig sein. Und das nimmt Dir das Backup ab.
Deshalb würde ich eher die den Verwahrungsort (Adapteransicht, Schraubenschlüssel oben links) auf "default" stellen. Dann werden nur stabile Versionen geholt.
Wie man eine Altinstallation löscht steht im Eingangspost.
Und dann eben mit dem Installer ioBroker und die stabilen Adapter holen. Und Backup gibt den Daten wieder die alten Namen und erledigt den Rest.

[kevlar]

so, folgendes hab ich bisher herausgefunden:

Multihost Master/Slave
Die Instanz Daten liegen beim Master im "iobroker-data" Verzeichnis.
Meine Windows Installation ist Master, daher funktioniert auch wenn ich alle Instanzen auf dem Raspi Slave laufen lasse nichts wenn ich Windows beende.

Migration von manueller Installation auf die Installer Version
Im Grunde hab ich einfach den ioBroker Dienst beendet und auf deaktiviert geschaltet.
Dann den Installer durchlaufen lassen, (den Hostnamen von bisher konnte ich wegen eines "-" nicht verwenden??), "iobroker-data" Verzeichnis durch das der alten Windows Version ersetzt.

iobroker multihost enable

und das gleiche Secret wie bei der alten Installation Vergeben.
Danach hat wie von Geisterhand alles wieder funktioniert, der Raspi hat die neue Windows Installation direkt gefunden und trotz anderem Hostnamen anerkannt.

Bug?
beim Update des jscontroller über die Konsole kam folgender Error:

C:\Program Files\iobroker\mainserver>iobroker upgrade self
Update js-controller from @1.5.11 to @1.5.12
NPM version: 6.9.0
npm install iobroker.js-controller@1.5.12 --unsafe-perm --production --save --prefix "C:/Program Files/iobroker/AiRServer" (System call)
npm WARN deprecated json3@3.3.2: Please use the native JSON object instead of JSON 3
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\iobroker\AiRServer\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Windows_NT 10.0.18362
gyp ERR! command "C:\\Program Files\\iobroker\\mainserver\\nodejs\\node.exe" "C:\\Program Files\\iobroker\mainserver\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Program Files\iobroker\mainserver\node_modules\iobroker.js-controller\node_modules\unix-dgram
gyp ERR! node -v v10.16.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: unix-dgram@0.2.3 (node_modules\iobroker.js-controller\node_modules\unix-dgram):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: unix-dgram@0.2.3 install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

Host "main-server" (win32) updated
Starting node restart.js

Es funktioniert aber trotzdem alles.

[klassisch]

Vielen Dank für die Rückmeldung und klasse, daß es jetzt funktioniert!
gyp-Errors hatte ich bei meinem Orange Pi Plus 2e praktisch immer weil für den OPi sehr häufig neu übersetzt werden mußte. Das wurde dann aber erkannt und neu übersetzt.
Interessanterweise hat meine Widows Installation einen dash "-" im Namen, weil der Installer den Namen des Windows Rechner nach dem Schema "DESKTOP-1234567" automatisch übernommen hat.

[Stabilostick]

Für Windows Hostnamen sind die Zeichen „a-Z“, „0-9“ und das „-“-Zeichen zulässig. Habe ich etwas beim Installer übersehen?