NEWS
Datenpunkt in der Objekt-Ansicht ändern
-
iob diag läuft, wird unten angehängt, erstmal habe ich einen alten Datenpunkt gefunden, der sich für einen weiteren Test ggfs eignet ...
{ "_id": "mqtt.0.Simulator_Receive.thermostat.desired.temperature", "common": { "name": "Simulator_Receive/thermostat/desired/temperature", "write": true, "read": true, "role": "variable", "desc": "mqtt server variable", "type": "string" }, "native": { "topic": "Simulator_Receive/thermostat/desired/temperature" }, "type": "state", "from": "system.adapter.mqtt.0", "user": "system.user.admin", "ts": 1678645965819, "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Schaut man da unter "Zustand"
! -
@mcm1957 Gibt es dafür nicht ein Erfassungsskript? ... ich mag keine Formulare ausfüllen, und dabei Fehler machen ...
iob prepare_err_report >> meinSystem.txt
EDIT, man sollte bis nach unten scrollen ...
Linux User bitte hier den Output von iob diag einfügen.
@martinp said in Datenpunkt in der Objekt-Ansicht ändern:
@mcm1957 Gibt es dafür nicht ein Erfassungsskript? ... ich mag keine Formulare ausfüllen, und dabei Fehler machen ...
Und ich mag keine halben Informationen.
Ok - wunder dich nicht, wenn ich auf solche Postings nicht reagiere. Und wahrscheinlich einige andere auch nicht :-(
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@martinp said in Datenpunkt in der Objekt-Ansicht ändern:
@mcm1957 Gibt es dafür nicht ein Erfassungsskript? ... ich mag keine Formulare ausfüllen, und dabei Fehler machen ...
Und ich mag keine halben Informationen.
Ok - wunder dich nicht, wenn ich auf solche Postings nicht reagiere. Und wahrscheinlich einige andere auch nicht :-(
@mcm1957 Ich habe ein paar Minuten vor Deinem Post gestern alle geforderten Informationen nachgeliefert ...
Ich bin der Sache auch weiter nachgegangen, und bin gar nicht sicher, ob ich mit jeder Variante des Bugfixes zufrieden wäre, da einige Wege, den Fehler zu beseitigen unangenehme Nebeneffekte hätten...
1 Voraussetzungen, dass man den Fehler überhaupt erzeugen kann
1.1 Admin-Modus aktivieren2 Erzeugen eines halbgaren Datenpunktes
2.1 In Abweichung zum Zufallsfund mit einem anderen Workflow:
MQTT-Explorer (gibt es für Linux, Windows und Mac) probeweise mit der MQTT Client/Server Instanz, die als Server konfiguriert ist verbinden.
2.2 Wenn das klappt, Verbindung wieder trennen, In den Subscriptions der Verbindungseinstellungen einen nicht vorhandenen Datenpunkt eintragen. (hier mit dem Mqtt5Explorer der Punkt "Mqtt5Explorer/TestSub1") "Save" am Schluss nicht vergessen
2.3 Verbinden, und warten bis der Datenpunkt im Explorer angezeigt wird.
3 Test im der Objekt-Ansicht des Iobroker
Dort müsste der Datenpunkt auch zu sehen sein
3.1 Klickt man da auf die "(null)" erscheint der erweiterte Dialog (wg. aktiviertem Admin)....
3.2) Ändert man "String" zu "Number", ohne vorher etwas an "Wert" zu ändern, kracht es
Ich bin jetzt nicht sicher, ob das ein Fehler des Admin-Adapter ist, oder ob der Mqtt-Adapter den Datenpunkt fehlerhaft anlegt, und deshalb die Probleme verursacht ...
Erzeuge gerade den issue auf github
-
Nur mal als Nachfrage:
du manipulierst einen Adapterdatenpunkt innerhalb des Namespaces eines Adapters?kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
Nur mal als Nachfrage:
du manipulierst einen Adapterdatenpunkt innerhalb des Namespaces eines Adapters?@homoran Das machen MQTT-Clients/Geräte ALLTÄGLICH, das ist ihr Lebenszweck...
Der MQTT-Explorer simuliert bei meinem Test, den Fehler zu reproduzieren einen Client, ein Gerät.
Geräte, die das erste Mal an einem Adapter auftauchen, subscriben NATÜRLICH Datenpunkte, auf denen sie z. B. Sollwerte oder ähnliches erwarten.
Es ist die Frage, was ein MQTT-Gerät machen soll, wenn es nach dem subscriben feststellt, dass der subscribte Wert leer ist: Selber korrigieren, oder muss man das per Blockly/Javascript von iobroker aus korrigieren?
Soweit ich das getestet habe, legen andere MQTT-Broker subscribte Datenpunkte, die es nicht gibt gar nicht an. Getestet habe ich das mit Mosquitto...
Da erscheint ein nicht subscribter Datenpunkt nicht im Tree des Mqtt-Explorer nach Aufbau der Verbindung.Das Verhalten des mqtt-Adapters ist da wohl etwas anders, finde das aber durchaus bequem..
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@homoran Das machen MQTT-Clients/Geräte ALLTÄGLICH, das ist ihr Lebenszweck...
Der MQTT-Explorer simuliert bei meinem Test, den Fehler zu reproduzieren einen Client, ein Gerät.
Geräte, die das erste Mal an einem Adapter auftauchen, subscriben NATÜRLICH Datenpunkte, auf denen sie z. B. Sollwerte oder ähnliches erwarten.
Es ist die Frage, was ein MQTT-Gerät machen soll, wenn es nach dem subscriben feststellt, dass der subscribte Wert leer ist: Selber korrigieren, oder muss man das per Blockly/Javascript von iobroker aus korrigieren?
Soweit ich das getestet habe, legen andere MQTT-Broker subscribte Datenpunkte, die es nicht gibt gar nicht an. Getestet habe ich das mit Mosquitto...
Da erscheint ein nicht subscribter Datenpunkt nicht im Tree des Mqtt-Explorer nach Aufbau der Verbindung.Das Verhalten des mqtt-Adapters ist da wohl etwas anders, finde das aber durchaus bequem..
@martinp Du hast meine Frage nicht beantwortet!
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
Hallo, habe hier gerade ein interessantes Verhalten im Object-Tree ausgelöst durch den MQTT-Adapter als Broker ...
Ein MQTT-Device hat durch Subscriben eines Topics das Anlegen eines Datenpunktes durch den Adapter verursacht. ./<Devicename>/Soll/Temperatur
Der DP hat den typ String und den Inhalt (null)
In diesem soll aber eine Soll-Temperatur als Zahl hinterlegt werden.
Wenn ich zuerst den Typ auf "Zahl" ändere, stürzt die Oberfläche ab.
Wenn ich erst das (null) durch eine Gleitkommazahl (egal ob mit Komma oder Punkt als Trennzeichen) ersetze, und danach den Typ auf "Number" ändere funktioniert es...
Um beim Fehlersuchen zu helfen, habe ich das Gleiche mit einem manuell erzeugten Datenpunkt in userdata versucht zu erreichen, aber habe es dort nicht nachstellen können ...
Ich weiß jetzt nicht, ob der Adapter, oder die Eingabemaske im Dialog der Schuldige ist - der Absturz erfolgt, wenn die Einstellung von String auf Number geändert wird ...
Wenn ich jetzt hier ZUERST den Typ auf Zahl ändere, kracht es...
Fehler
TypeError: can't access property "toString", this.state.targetValue is null render http://192.168.2.201:8081/assets/Objects-Dp71iotS.js:60 mu http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 ao http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 ya http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 va http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 kc http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 Qr http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 xu http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 wo http://192.168.2.201:8081/assets/index-DTGUg51P.js:24 dn http://192.168.2.201:8081/assets/index-DTGUg51P.js:22 fe http://192.168.2.201:8081/assets/index-DTGUg51P.js:24@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Hier:
schreibst du (was aus meiner Sicht korrekt ist):
"Es scheint so zu sein, dass das Subscribe auf den Datenpunkt im Mqtt Broker nicht dazu führt, dass der Datenpunkt automatisch angelegt wird..."
Nun behauptest du (was ich bezweifele)
Ein MQTT-Device hat durch Subscriben eines Topics das Anlegen eines Datenpunktes durch den Adapter verursacht. ./<Devicename>/Soll/Temperatur
Was stimmt denn nun?
EDIT: oder, um genauer zu sein, wie ist der Adapter in diesem Punkt konfiguriert?
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+EMQX+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Hier:
schreibst du (was aus meiner Sicht korrekt ist):
"Es scheint so zu sein, dass das Subscribe auf den Datenpunkt im Mqtt Broker nicht dazu führt, dass der Datenpunkt automatisch angelegt wird..."
Nun behauptest du (was ich bezweifele)
Ein MQTT-Device hat durch Subscriben eines Topics das Anlegen eines Datenpunktes durch den Adapter verursacht. ./<Devicename>/Soll/Temperatur
Was stimmt denn nun?
EDIT: oder, um genauer zu sein, wie ist der Adapter in diesem Punkt konfiguriert?
@marc-berg Ist ja leicht reproduziert ...
Die JETZIGE Version des MQTT-Adapters legt den Datenpunkt jedenfalls nach meinen Tests halbgar an ... im Mosquitto führt bei einem Gegentest das Subscriben nicht zu einer entsprechenden Erweiterung des Trees um den Subscribten Punkt
-
Ich habe den Datenpunkt nur indirekt ANGELEGT, (über den Weg MQTT-Explorer-> mqtt-Adapter als Broker -> iobroker Datenpunkt)
Die KORREKTUR des TYPS habe ich als Admin von Hand vorgenommen
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
Ich habe den Datenpunkt nur indirekt ANGELEGT, (über den Weg MQTT-Explorer-> mqtt-Adapter als Broker -> iobroker Datenpunkt)
Die KORREKTUR des TYPS habe ich als Admin von Hand vorgenommen
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Die KORREKTUR des TYPS habe ich als Admin von Hand vorgenommen
und damit hast du in einem Adapternamespace ein Objekt manipuliert.
Das ist für die Ursachenforschung entscheidend!
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Das machen MQTT-Clients/Geräte ALLTÄGLICH, das ist ihr Lebenszweck...
das stimmt so auch nicht wirklich!
Das mach der Adapter in seinem Namespace.
Und nur der darf das da.Und ich bin jetzt auch wieder weg
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Die KORREKTUR des TYPS habe ich als Admin von Hand vorgenommen
und damit hast du in einem Adapternamespace ein Objekt manipuliert.
Das ist für die Ursachenforschung entscheidend!
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
Das machen MQTT-Clients/Geräte ALLTÄGLICH, das ist ihr Lebenszweck...
das stimmt so auch nicht wirklich!
Das mach der Adapter in seinem Namespace.
Und nur der darf das da.Und ich bin jetzt auch wieder weg
@homoran Auf der anderen Seite wurde mir aber auch gesagt, dass das MQTT-Device auf "subscribed" Nodes nicht publishen darf, weil das eine Endlosschleife auslösen könne ...
Wahrscheinlich ist es sinnhafter, den Typ so zu lassen, wie er ist... Da wäre dann alles, was im Mqtt-Adapterbaum an Elementen liegt ein String, weil es so erzeugt wird.
Ist natürlich nicht besonders schön, einen Datenpunkt, der z. B. eine Temperatur enthält bei String als Datentyp zu belassen ...Erklärt vielleicht auch, warum viele MQTT-Devices mit JSON hantieren, statt mit einfachen Datentypen ...
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@homoran Auf der anderen Seite wurde mir aber auch gesagt, dass das MQTT-Device auf "subscribed" Nodes nicht publishen darf, weil das eine Endlosschleife auslösen könne ...
Wahrscheinlich ist es sinnhafter, den Typ so zu lassen, wie er ist... Da wäre dann alles, was im Mqtt-Adapterbaum an Elementen liegt ein String, weil es so erzeugt wird.
Ist natürlich nicht besonders schön, einen Datenpunkt, der z. B. eine Temperatur enthält bei String als Datentyp zu belassen ...Erklärt vielleicht auch, warum viele MQTT-Devices mit JSON hantieren, statt mit einfachen Datentypen ...
Habe jetzt eine vereinfachte und legitimere Form des Tests gemacht .. crasht auch
- Userdata Datenpunkt anlegen
- Name z. B. 0_userdata.0.LeererDP
- Typ String,
- Wert leer lassen
- (versucht man nun direkt (im "Expertenmodus") den Typ auf Zahl zu ändern klappt das.)
- Javascript Schnipsel programmiert, um den Fehler zu forcieren ...
setState("0_userdata.0.LeererDP", null, true);-
Script kurz ausgeführt ...
-
Versucht man nun in der Objekt Ansicht den Datentyp auf Zahl zu ändern, kracht das auch..
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
Habe jetzt eine vereinfachte und legitimere Form des Tests gemacht .. crasht auch
- Userdata Datenpunkt anlegen
- Name z. B. 0_userdata.0.LeererDP
- Typ String,
- Wert leer lassen
- (versucht man nun direkt (im "Expertenmodus") den Typ auf Zahl zu ändern klappt das.)
- Javascript Schnipsel programmiert, um den Fehler zu forcieren ...
setState("0_userdata.0.LeererDP", null, true);-
Script kurz ausgeführt ...
-
Versucht man nun in der Objekt Ansicht den Datentyp auf Zahl zu ändern, kracht das auch..
Hier noch der Link zum Issue
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
Hier noch der Link zum Issue
Der Issue scheint bearbeitet zu werden ... kriegte gerade eine Nachricht "Bitte mit der aktuellen Beta testen"...
Bin dann falsch abgeboben - was ist denn da mit dem Beta Repository los? Habe vom Stable auf Beta umgestell und kriege eine deutlich ältere Version angeboten?
Muss dann mal schauen wie ich das über github installiert bekomme.
Und da fangen die Probleme an ... auf dem üblichen Weg kann man den Adapter nicht aus Github installieren. Irgendwie wird mir das nach untenstehendem Screenshot gerade zu spooky, und ich bekomme Angst, mein System zu schrotten...
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@martinp sagte in Datenpunkt in der Objekt-Ansicht ändern:
was ist denn da mit dem Beta Repository los?
iob repo list
sagt?
-
martin@iobroker-test-sicher:/opt/iobroker/backups$ iob repo list ┌─────────┬──────────┬─────────────────────────────────────────────────────────┬──────────────┐ │ (index) │ name │ url │ auto upgrade │ ├─────────┼──────────┼─────────────────────────────────────────────────────────┼──────────────┤ │ 0 │ 'stable' │ 'http://download.iobroker.net/sources-dist.json' │ false │ │ 1 │ 'beta' │ 'http://download.iobroker.net/sources-dist-latest.json' │ false │ └─────────┴──────────┴─────────────────────────────────────────────────────────┴──────────────┘ Active repo(s): beta Upgrade policy: none martin@iobroker-test-sicher:/opt/iobroker/backups$Im CLI sieht aber allles ok aus. Versionsnummern aus dem Beta sind größer, als der aktuelle Stand aus Stable
martin@iobroker-test-sicher:/opt/iobroker/backups$ iob update |grep "Updatable" Adapter "admin" : 7.7.3 , installed 7.7.2 [Updatable] Adapter "backitup" : 3.3.9 , installed 3.3.5 [Updatable] Adapter "fb-checkpresence": 1.4.1 , installed 1.4.0 [Updatable] Adapter "jarvis" : 3.2.0-rc.5, installed 3.1.8 [Updatable] Adapter "javascript" : 9.0.11 , installed 8.9.2 [Updatable] Adapter "ping" : 1.7.9 , installed 1.6.2 [Updatable] Adapter "simple-api" : 3.0.7 , installed 2.8.0 [Updatable] Adapter "socketio" : 7.0.8 , installed 6.7.1 [Updatable] Adapter "sonoff" : 3.3.0 , installed 3.2.1 [Updatable] Adapter "vis-2" : 2.13.5 , installed 2.13.4 [Updatable] Adapter "vis-2-widgets-gauges": 2.0.2, installed 2.0.1 [Updatable] Adapter "web" : 7.0.9 , installed 7.0.8 [Updatable] Adapter "ws" : 3.0.19 , installed 2.6.2 [Updatable] martin@iobroker-test-sicher:/opt/iobroker/backups$Hilft aber nicht, beim das "letzte Beta" installieren. 7.7.3 ist vor 3 Wochen herausgekommen...
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
martin@iobroker-test-sicher:/opt/iobroker/backups$ iob repo list ┌─────────┬──────────┬─────────────────────────────────────────────────────────┬──────────────┐ │ (index) │ name │ url │ auto upgrade │ ├─────────┼──────────┼─────────────────────────────────────────────────────────┼──────────────┤ │ 0 │ 'stable' │ 'http://download.iobroker.net/sources-dist.json' │ false │ │ 1 │ 'beta' │ 'http://download.iobroker.net/sources-dist-latest.json' │ false │ └─────────┴──────────┴─────────────────────────────────────────────────────────┴──────────────┘ Active repo(s): beta Upgrade policy: none martin@iobroker-test-sicher:/opt/iobroker/backups$Im CLI sieht aber allles ok aus. Versionsnummern aus dem Beta sind größer, als der aktuelle Stand aus Stable
martin@iobroker-test-sicher:/opt/iobroker/backups$ iob update |grep "Updatable" Adapter "admin" : 7.7.3 , installed 7.7.2 [Updatable] Adapter "backitup" : 3.3.9 , installed 3.3.5 [Updatable] Adapter "fb-checkpresence": 1.4.1 , installed 1.4.0 [Updatable] Adapter "jarvis" : 3.2.0-rc.5, installed 3.1.8 [Updatable] Adapter "javascript" : 9.0.11 , installed 8.9.2 [Updatable] Adapter "ping" : 1.7.9 , installed 1.6.2 [Updatable] Adapter "simple-api" : 3.0.7 , installed 2.8.0 [Updatable] Adapter "socketio" : 7.0.8 , installed 6.7.1 [Updatable] Adapter "sonoff" : 3.3.0 , installed 3.2.1 [Updatable] Adapter "vis-2" : 2.13.5 , installed 2.13.4 [Updatable] Adapter "vis-2-widgets-gauges": 2.0.2, installed 2.0.1 [Updatable] Adapter "web" : 7.0.9 , installed 7.0.8 [Updatable] Adapter "ws" : 3.0.19 , installed 2.6.2 [Updatable] martin@iobroker-test-sicher:/opt/iobroker/backups$Hilft aber nicht, beim das "letzte Beta" installieren. 7.7.3 ist vor 3 Wochen herausgekommen...
Wo eine 7.4.4 herkommen soll kann ich mir aber dann nicht erklären.
Ich hatte sowas mal, als ich sowohl 'stable' wie auch 'beta' zeitgleich aktiv hatte.
Aber ist ja nicht bei dir.Edit: GUIs halt... Die neigen zu Lügen...
-
Wo eine 7.4.4 herkommen soll kann ich mir aber dann nicht erklären.
Ich hatte sowas mal, als ich sowohl 'stable' wie auch 'beta' zeitgleich aktiv hatte.
Aber ist ja nicht bei dir.Edit: GUIs halt... Die neigen zu Lügen...
@thomas-braun Den Update auf den Admin 7.7.3 habe ich über
npm install iobroker.adminAugeführt - danach hat der Neustart des Admin ewig gedauert ...
Als der Admin "wieder oben" war, den Test wiederholt - funktioniert mit der Version 7.7.3 ohne GUI-Crash
Intel(R) Celeron(R) CPU N3000 @ 1.04GHz 8G RAM 480G SSD
Virtualization : unprivileged lxc container (debian 12 on Proxmox 8.4.14)
Linux pve 6.8.12-16-pve
6 GByte RAM für den Container
Fritzbox 6591 FW 8.03 (Vodafone Leih-Box)
Remote-Access über Wireguard der Fritzbox -
@thomas-braun Den Update auf den Admin 7.7.3 habe ich über
npm install iobroker.adminAugeführt - danach hat der Neustart des Admin ewig gedauert ...
Als der Admin "wieder oben" war, den Test wiederholt - funktioniert mit der Version 7.7.3 ohne GUI-Crash
-
@thomas-braun Habe einfach mal ausprobiert, ob das "iob upgrade" auch für einen Downgrade auf die Stable Version nach dem Test taugt... und geht:
martin@iobroker-test-sicher:/opt/iobroker/backups$ iob upgrade admin@7.7.2 Would you like to downgrade admin from @7.7.3 to @7.7.2 now? [(y)es, (n)o]: y Update admin from @7.7.3 to @7.7.2 host.iobroker-test-sicher Adapter "system.adapter.admin.0" is stopped. NPM version: 10.9.3 Installing iobroker.admin@7.7.2... (System call)
Support us
515
Online32.6k
Benutzer82.1k
Themen1.3m
Beiträge