[Aufruf] ioBroker für Windows, Version 1.5.11

[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?

[klassisch]

Also bei mir hat es ja mit dem Dash "-" funktionert. Alles out of the Box. Habe den normalen Installer-Mode verwendet.

[kevlar]

sprechen wir vom Instanz Namen?

[klassisch]

@kevlar Vermutlich haben wir uns mißverstanden. Du sagtest ursprünglich

Dann den Installer durchlaufen lassen, (den Hostnamen von bisher konnte ich wegen eines "-" nicht verwenden??)

Daraus schloß ich, daß Du einen Hostnamen mit "-" nicht verwenden konntest. Das funktioniert aber. Bei mir hat der Installer das alles selbst gemacht.
Vielleicht meintest Du aber, daß Du den Instanznamen nicht identisch zum Hostnamen wählen konntest.
Das würde dann wieder passen. Das ging bei mir auch nicht. Auf einem Host können ja mehrere Instanzen laufen. Das bringt wahrscheinlich bei der Migration oder zum Testen oder so Vorteile. Ich habe es bisher allerdings noch nicht genutzt und betreibe derzeit auf einem Rechner auch nur eine Instanz.

[SchuetzeSchulz]

Hallo zusammen,

klingt gut. Ich habe derzeit eine ioBroker Installation über den "alten" Windows-Installer (ist meine ich schon fast 2 Jahre her) auf einem Windows Server 2012 R2.
Bringt mir der neue Installer - ausser natürlich bei einer Neuinstallation - irgendwelche Vorteile?
Sollte ich den neuen Installer mal "drüber "installieren lassen?

[klassisch]

@SchuetzeSchulz Meine persönliche Meinung als Anwender:
Wenn Du die Funktionalität hast, die Du brauchst und alles stabil und hinreichend secure läuft, brauchst Du gar nichts tun.
Aber sobald Du einen neuen, aktuellen Adapter brauchst und updaten mußt, ist das eine Überlegung wert.
Das Updaten ist aus meiner Sicht etwas schwieriger geworden, weil ich die Kompatibilität der Versionen von NodeJS und npm nicht mehr überblicke.
Da hilft der Installer, weil Du dann wieder ein konsistentes Paket bekommst.
Schau mal dort https://forum.iobroker.net/topic/22867/how-to-node-js-für-iobroker-richtig-updaten .
Wenn Du Deine alte Installation auf Vordermann bringen willst, macht es wahrscheinlich am meisten Sinn, deine alte zu entfernen, wie in diesem Thread im Eingangspost beschrieben unter "Wie entferne man eine Testinstallation?". Vorher natürlich ein Backup machen, z.B.mit dem Backitup Adapter und bei angehaltenem ioBroker sicherheitshalber noch vom kompette Arbeitsverzeichnis des ioBroker.
Nach der Neuinstallation und restore das Log beobachten, ob alles richtig läuft.