UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Ein ehemaliger Benutzer]

@apollon77 ,

Ok, wurde inzwischen wohl gelöst. Also erledigt.....habe nach dem letzen Upate noch nicht umgestellt.

[da_Woody]

@menne da wurde nix gelöst, das hat immer funktioniert...

[Ein ehemaliger Benutzer]

@da_woody, wenn du das schreibst, wird es wohl stimmen.

[JB_Sullivan]

Einen Guten Morgen - ich möchte nochmal kurz auf das Thema EBUSY Fehler unter ioB für Windows zu sprechen kommen.

Um ehrlich zu sein, weiß ich jetzt gar nicht mehr genau, ob das nun ein Admin 5.x oder ein js-controller 3.3.x Problem ist (war?) Jedenfalls habe ich bis dato nichts darüber gelesen, das es gefixt werden konnte.

Ich habe in diesem Zusammenhang festgestellt, das der EBUSY Fehler nicht auftritt, wenn man die Instanz vor dem Update händisch stoppt.

Alle Adapter Updates der letzten Zeit und das waren ja einige, wurden sauber ohne EBUSY Fehler bei gestoppter Instanz durchgeführt. Stoppt man die Instanz nicht, endet das Update mal mit EBUSY, mal wird es aber auch sauber durchgeführt.

Beim Admin Adapter sieht man als User ja ziemlich deutlich, das der Adapter angehalten wurde (drehender Kreis). Werden die anderen Adapter bei Updates nicht gestoppt, oder sieht man das nur nicht?

Wenn sie vom Update Prozess gestoppt werden, funktioniert dieses automatisch stoppen scheinbar nicht so sauber, als wenn ich die Instanz von Hand stoppe.

Für den Fall das dass EBUSY Problem nicht ohnehin schon gefixt wurde, wäre das ein möglicher Ansatz wo man suchen könnte?

[sigi234]

@jb_sullivan sagte in Test Adapter Admin 5.0.x: Alpha der neuen UI:

Einen Guten Morgen - ich möchte nochmal kurz auf das Thema EBUSY Fehler unter ioB für Windows zu sprechen kommen.
Um ehrlich zu sein, weiß ich jetzt gar nicht mehr genau, ob das nun ein Admin 5.x oder ein js-controller 3.3.x Problem ist (war?) Jedenfalls habe ich bis dato nichts darüber gelesen, das es gefixt werden konnte.
Ich habe in diesem Zusammenhang festgestellt, das der EBUSY Fehler nicht auftritt, wenn man die Instanz vor dem Update händisch stoppt.
Alle Adapter Updates der letzten Zeit und das waren ja einige, wurden sauber ohne EBUSY Fehler bei gestoppter Instanz durchgeführt. Stoppt man die Instanz nicht, endet das Update mal mit EBUSY, mal wird es aber auch sauber durchgeführt.

Das kann ich so bestätigen.

[apollon77]

Ich denke es hat weder mit controller nocht mit einem Adapter zu tun sondern ich kann mir vorstellen (also Achtung immer noch annahmen!) das es an Windows liegt und ggf daran das wenn ein Prozess läuft ggf bestimmte Dateien gelockt sind und daher von einem npm Update nicht angefasst bzw darauf zugegriffen werden dürfen. Das könnte speziell bei "nativen Modulteilen" der Fall sein (wie Serialport oder so).

EBUSY heisst das auf eine File bzw Systemresource nicht zugegriffen werden kann (so verstehe/deute ich es im weiteren Sinne). Das würde auch erklären warum es dann tut wenn man den Adapter stoppt.

Aber da bin ich weit weg davon ein Windows-Experte zu sein weil unter Linux und macOS passiert das nicht.

Wenn diese Annahmen und Herleitung stimmt dann kann weder ioBroker noch irgendein Entwickler von uns etwas daran tun und es ist mit irgendeiner Node.js Version oder Windows Update passiert.

Man könnte also jetzt mal wild Node.js downgraden und schauen wie es sich mit anderen nodejs Versionen verhält ...

[sigi234]

@apollon77 sagte in Test Adapter Admin 5.0.x: Alpha der neuen UI:

Ich denke es hat weder mit controller nocht mit einem Adapter zu tun

Ich denke schon, weil es ja vorher kein Problem damit gab.( Admin und/oder Controller)

Gerade auf meinen 2.Testsystem getestet:

Da haben alle Upgrades einwandfrei funktioniert

Admin: 4.2.1
JS controller: 3.2.16
Node.js: v12.20.0
NPM: 6.14.8

[apollon77]

@sigi234 Das ist es ja aber: Wir machen nichts anders und der der Fehler meldet ist npm ... der läuft als separater Prozess. Ich wüsste nicht wie wir das beeinflussen könnten - auch weil es ja nicht immer vorkommt sondern scheinbar nur wenn native Bestandteile dabei sind ...

Ich kann daher nur vermuten.

Um es genauer zu WIssen muss sich jemand mit Windows System bzw Know How des Themas annehmen und mal alle optionen testen ... alte Admin versionen oder alter controller und/oder nodejs Versionen und mal versuchen rauszufinden was nun der Auslöser ist. Sonst steht "Vermutung gegen Vermutung" :-)

Ich kann das leider nicht auch noch auf meine Kappe nehmen, hänge schon zuviele andere Dinge an meiner zu knappen Zeit. Also jegliche Unterstützung ist willkommen-

[sigi234]

@apollon77 sagte in Test Adapter Admin 5.0.x: Alpha der neuen UI:

Um es genauer zu WIssen muss sich jemand mit Windows System bzw Know How des Themas annehmen

was für @Stabilostick

[JB_Sullivan]

Wie ist das denn bei einem Adapter Update standard mäßig? Wird der Adapter vor der Update Routine gestoppt?

Wenn das bis jetzt nicht so sein sollte, wäre das doch etwas, was die ioB Entwickler einbauen könnten - oder? Der Admin wird ja auch vor dem Update gestoppt. Sofern es nicht sowieso passiert, wäre es unter Umständen vielleicht sogar für alle Adapter eine "sauberer" Lösung?

Wenn es unter LINUX nicht passiert, vielleicht könnte man im Rahmen des Update Prozess eine Prüfung auf das verwendete BS einbauen, sodaß nur bei Windows "Kunden" ein Zwangs Adapter Stop vor einem Update initiiert wird?!?!?

Sowohl Node.js als auch NPM waren vor dem Admin 5 /js-controller 3.3.x Update bei mir auf dem gleichen Stand wie sie es jetzt sind (bei mir NPM 6.14.11 // Node.js 14.16.0) - und unter den alten ioB Modulen hat es, so wie sigi auch schreibt, einwandfrei mit den Node/NPM Verionen funktioniert.

[arteck]

@jb_sullivan

du vergisst eine nicht ganz so unwichtige komponente "Windows"
ergo du hast nie den gleichen zustand wie "immer"... mach ein reboot installiere dann ..
und du wirst merken der Fehler kommt nicht ...

[apollon77]

@jb_sullivan es gibt ein flag in der io-Package ob der adapter vor dem Update gestoppt werden soll. Könnte der adapter setzen. Aber vllt ne bessere Idee das bei Windows einfach explizit zu machen weil auf Linux ist es ja nicht nötig so kann die Ausfallzeiten des Adapters dort minimiert bleiben. Wäre ein js-Controller request und dann was für die 4.0 des Controllers im herbst

[Megawaldi]

@apollon77
Mir ist aufgefallen, das ich unter Objekte eine Ordner "Script" habe, in dem genau ein Script meiner vielen Scripte ist.
Kannst du mir sagen was es mit dem Ordner auf sich hat oder für was der gedacht ist?
Und warum nur eines meiner Scripte darin ist?

[apollon77]

@megawaldSchalte mal den Expertenmodus ein ... sind dann mehr EInträge da? Wenn ja sit das eine Skrpt vllt "das erste" was angelegt wurde bevor die Skript-Objekte einen "experts Only" Flag bekommen haben :-)

[Feuersturm]

@apollon77 @Megawaldi
Ist bei mir auch so, wenn der Expertemodus nicht aktiv sehe ich eine Teilmenge von meinen Skripten

Bei aktiviertem Expertenmode sehe ich alle.

@apollon77 Was ist denn das gewünschte Sollverhalten und wozu dienen diese Skripte-Objekte? Inhalte werden nicht angezeigt (mit aktivietem Expertenmodus)

[Megawaldi]

@apollon77
Du hast natürlich recht. Im Expertenmodus sehe ich alle scripte. Wie kann man das denn beheben?
Was sich mir nicht erschließt ist, wozu dieser Script Ordner dient. Ich sehe ja alle scripte im Skripte reiter links?

[Dr. Bakterius]

@feuersturm Wenn du den Datenpunkt des "Skript" bearbeitest und auf Objektdaten gehst, befindet sich das Javascript unter "source". Aber wozu kann ich auch nicht sagen...

[SabineT]

Die Scripte werden ja auch in der Datenbank (objects.json) gespeichert, daher tauchen die auch unter Objekte auf (vermutlich wurde die bisher nur ausgeblendet).

[arteck]

@feuersturm damit kannst du ein Script ein oder auschalten... per script..

also mit einem Script ein anderes ausschalten oder neu starten

[apollon77]

@megawaldi sagte in Test Adapter Admin 5.0.x: Alpha der neuen UI:

Im Expertenmodus sehe ich alle scripte. Wie kann man das denn beheben?

Speichere mal das betroffene script neu? ggf wird da der "expersonly" flag hinzugefügt.