Test Adapter Admin 5.0.x: Alpha der neuen UI
-
@apollon77 ist das eigentlich nur bei mir so, daß in der react-ui keine button angezeigt werden?
-
@da_woody hab einen gefunden ^^
erscheint aber auch erst, wenn er einmal benutzt wurde/der State einmal geschaltet wurde. Fehlt bei anderen Geräten bei mir auch (null) -
@kueppert nö, bei kommt dann true oder false...
-
@da_woody Expertenmodus aktiviert?
-
@apollon77 ja
rabatzt! der wars...
-
Besteht denn schon ein Issue darüber, das man im RAW Modus das Context Menu nicht mehr öffnen kann, z. B. um zu kopieren etc? Der Bug ist inzwischen in beiden UI´s....
Das kopieren vermisse ich übrigens schon immer im Javascript Adapter im JS Modus.
-
@menne Was ist denn der RAW Modus?
-
-
@menne Ok, das ist die Alte UI - bitte mit der neuen React UI versuchen.
Auch hier in Admin4: Klicke einmalig in das Feld, dann kann man selektieren
-
Ok, wurde inzwischen wohl gelöst. Also erledigt.....habe nach dem letzen Upate noch nicht umgestellt.
-
@menne da wurde nix gelöst, das hat immer funktioniert...
-
@da_woody, wenn du das schreibst, wird es wohl stimmen.
-
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?
-
@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.
-
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 ...
-
@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 -
@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-
-
@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
-
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.
-
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 ...
