NEWS
js-controller 4.0.x jetzt für alle User im STABLE!
js-controller 4.0.x jetzt für alle User im STABLE!
-
Das weiß ich auch nicht.
Aber ich weiß, dass man nicht npm in Verbindung mit sudo (ohne weitere Optionen) verwendet.
Da scheint mir auch schon was an den Rechten verbogen worden zu sein. Sonst dürfte da kein 'permission denied' erscheinen.
Wie sehen die Rechte an
/opt/iobroker/node_modules/iobroker.js-controller/lib/setup/../../tmp
denn jetzt aus?der server läuft ohne fehler meldungen und hat iob setup custom mit file !! und js-cont - 4x
-
Das weiß ich auch nicht.
Aber ich weiß, dass man nicht npm in Verbindung mit sudo (ohne weitere Optionen) verwendet.
Da scheint mir auch schon was an den Rechten verbogen worden zu sein. Sonst dürfte da kein 'permission denied' erscheinen.
Wie sehen die Rechte an
/opt/iobroker/node_modules/iobroker.js-controller/lib/setup/../../tmp
denn jetzt aus?ist dieser befehl richtig ?
sudo -H -u iobroker npm i iobroker.js-controller@3.3.22 --productionnach einem gelösten Thread wäre es sinnvoll dies in der Überschrift des ersten Posts einzutragen [gelöst]-... Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat. Forum-Tools: PicPick https://picpick.app/en/download/ und ScreenToGif https://www.screentogif.com/downloads.html
-
ist dieser befehl richtig ?
sudo -H -u iobroker npm i iobroker.js-controller@3.3.22 --production@liv-in-sky
Muss dann auch noch im richtigen Verzeichnis ausgeführt werden.cd /opt/iobroker -
@liv-in-sky
Muss dann auch noch im richtigen Verzeichnis ausgeführt werden.cd /opt/iobrokerdanke war der richtige befehl
haben restore gemacht - warten gerade darauf, dass er alles wieder installiert
-
würdest du das bitte noch richtigstellen - sonst viele fehler:
in
sudo -H -u iobroker npm i iobroker.js-controller@3.3.22 --production -
würdest du das bitte noch richtigstellen - sonst viele fehler:
in
sudo -H -u iobroker npm i iobroker.js-controller@3.3.22 --production@liv-in-sky Da muss eigentlich nichts angepasst werden. In einem korrekt installierten System, bei dem man nicht irgendetwas mittels sudo oder root-Login "verbogen" hat, und bei dem der angemeldete User der Gruppe iobroker angehört, funktioniert der Befehl exakt so ohne dass man den Befehl npm mittels sudo -u iobroker als user iobroker ausführen müsste.
Je weniger man irgendwo sudo verwendet, umso besser. Erst recht, wenn man nicht (genau) weiss, warum man es verwendet. Auf korrekten Installationen mit korrekten Usern und Gruppen lässt sich alles in und um iobroker ohne sudo bewerkstelligen.
Gruss, Jürgen -
@liv-in-sky Da muss eigentlich nichts angepasst werden. In einem korrekt installierten System, bei dem man nicht irgendetwas mittels sudo oder root-Login "verbogen" hat, und bei dem der angemeldete User der Gruppe iobroker angehört, funktioniert der Befehl exakt so ohne dass man den Befehl npm mittels sudo -u iobroker als user iobroker ausführen müsste.
Je weniger man irgendwo sudo verwendet, umso besser. Erst recht, wenn man nicht (genau) weiss, warum man es verwendet. Auf korrekten Installationen mit korrekten Usern und Gruppen lässt sich alles in und um iobroker ohne sudo bewerkstelligen.
Gruss, Jürgen@wildbill sagte in js-controller 4.0.x jetzt für alle User im STABLE!:
n einem korrekt installierten System
und vor allem, wenn man das gemacht hat was hinter dem Befehl in Klammern steht!
-
@liv-in-sky Da muss eigentlich nichts angepasst werden. In einem korrekt installierten System, bei dem man nicht irgendetwas mittels sudo oder root-Login "verbogen" hat, und bei dem der angemeldete User der Gruppe iobroker angehört, funktioniert der Befehl exakt so ohne dass man den Befehl npm mittels sudo -u iobroker als user iobroker ausführen müsste.
Je weniger man irgendwo sudo verwendet, umso besser. Erst recht, wenn man nicht (genau) weiss, warum man es verwendet. Auf korrekten Installationen mit korrekten Usern und Gruppen lässt sich alles in und um iobroker ohne sudo bewerkstelligen.
Gruss, Jürgenetwas seltsam - wir haben ein image von raspi debian bullseye installiert, dann die installation von iobroker aufgerufen - die ja alles mitinstalliert (nodejs14 )
da war nichts verbogen oder anderes gemacht worden
- dann wollte ich einen restore machen
- ging nicht , da backup file mit js-c 3.x war
- also wollte ich mit dem befehl ohne sudo den js-c downgraden
- ging nicht - weil jsonl
- dann müßten wir nochmal den js-c 4.x installieren, da iobroker nicht mehr startete
- dann mit iob setup custom auf file geändert
- dann versucht mit dem befehl (mit und ohne sudo) down zu graden
- bei beiden versuchen kamen rechte probleme
- dann wieder js-c4 installiert, da system wieder nicht startete
- dann wieder auf file umgestelt und mit dem befehl sudo -u iobroker ...... downgrade
- erst dann funktionierte es
definitiv war nichts am system vebogen - es war so installiert, wie es in der doku steht
vielleicht habe ich was anderes falsch gemacht - aber ungefähr so war das vorgehen - ab und an lief der "fixer"
-
@wildbill sagte in js-controller 4.0.x jetzt für alle User im STABLE!:
n einem korrekt installierten System
und vor allem, wenn man das gemacht hat was hinter dem Befehl in Klammern steht!
@homoran ich war immer im iobroker verzeichnis
-
etwas seltsam - wir haben ein image von raspi debian bullseye installiert, dann die installation von iobroker aufgerufen - die ja alles mitinstalliert (nodejs14 )
da war nichts verbogen oder anderes gemacht worden
- dann wollte ich einen restore machen
- ging nicht , da backup file mit js-c 3.x war
- also wollte ich mit dem befehl ohne sudo den js-c downgraden
- ging nicht - weil jsonl
- dann müßten wir nochmal den js-c 4.x installieren, da iobroker nicht mehr startete
- dann mit iob setup custom auf file geändert
- dann versucht mit dem befehl (mit und ohne sudo) down zu graden
- bei beiden versuchen kamen rechte probleme
- dann wieder js-c4 installiert, da system wieder nicht startete
- dann wieder auf file umgestelt und mit dem befehl sudo -u iobroker ...... downgrade
- erst dann funktionierte es
definitiv war nichts am system vebogen - es war so installiert, wie es in der doku steht
vielleicht habe ich was anderes falsch gemacht - aber ungefähr so war das vorgehen - ab und an lief der "fixer"
@liv-in-sky Was da bei Dir schief gelaufen ist und warum, kann ich natürlich nicht sagen. Aber ich kann sagen, dass bei korrekter Installation mit korrekt eingerichtetem User, der in der Gruppe iobroker ist, mit Ordnern unterhalb /opt/iobroker in denen noch kein root unterwegs war oder mit sudo hantiert wurde, definitiv der Befehl aus der Anleitung ohne sudo direkt als User funktioniert. Also muss bei Deiner Installation irgendwann irgendwo irgendwas anders gelaufen sein, als es im Standard tut. Spätestens nach einem einmaligen
Iobroker fixSollte es dann aber ohne sudo tun. Sonst ist irgendwo was faul.
Und wenn es mit sudo -u iobroker geht, mit dem normalaen User ohne sudo aber nicht, dann scheint entweder der User nicht der Gruppe iobroker anzugehören, oder die Datei- oder Ordnerrechte nicht (mehr) zu passen. Der Befehl sudo -u iobroker sorgt ja nur dafür, dass nachfolgender Befehl als User iobroker, und eben nicht als root odrer mit sonstwie erweiterten Rechten ausgeführt wird.Gruss, Jürgen
-
@liv-in-sky Was da bei Dir schief gelaufen ist und warum, kann ich natürlich nicht sagen. Aber ich kann sagen, dass bei korrekter Installation mit korrekt eingerichtetem User, der in der Gruppe iobroker ist, mit Ordnern unterhalb /opt/iobroker in denen noch kein root unterwegs war oder mit sudo hantiert wurde, definitiv der Befehl aus der Anleitung ohne sudo direkt als User funktioniert. Also muss bei Deiner Installation irgendwann irgendwo irgendwas anders gelaufen sein, als es im Standard tut. Spätestens nach einem einmaligen
Iobroker fixSollte es dann aber ohne sudo tun. Sonst ist irgendwo was faul.
Und wenn es mit sudo -u iobroker geht, mit dem normalaen User ohne sudo aber nicht, dann scheint entweder der User nicht der Gruppe iobroker anzugehören, oder die Datei- oder Ordnerrechte nicht (mehr) zu passen. Der Befehl sudo -u iobroker sorgt ja nur dafür, dass nachfolgender Befehl als User iobroker, und eben nicht als root odrer mit sonstwie erweiterten Rechten ausgeführt wird.Gruss, Jürgen
werden wir nicht mehr rausfinden - ich kann erst morgen wieder checken, wie es dem server geht.
danke für deine antwort - alles gut im moment
-
erstmal danke - bitte genau erklären - haben das ganze wieder auf js-c 4.x gebracht und mit jsonl
wie genau müssen wir vorgehen - wieder zuerst iob setup costum
und was dann
sudo -H -u iobroker npm i iobroker.js-controller@3.3.22 --production@liv-in-sky Warum willst du den controller wieder downgraden??
-
FAQ
Informationen zu pot. angezeigten Meldungen und Logs
(info) "Sets unsupported"
In MutliHost-Umgebungen wo noch nicht alle Hosts aktualisiert sind arbeitet eine Optimierung in einem Kompatibilitätsmodus. In diesem wird ggf vom js-controller und von Adaptern beim Start einmalig die Meldung "Sets unsupported" im Loglevel "info" geloggt. Diese verschwindet wenn alle Hosts auf js-controller 4.0+ sind.
(warn) Object XXX is invalid: obj.common.min/max has an invalid type!
Dies ist eine neue Prüfung, wie oben bereits erwähnt, welche prüft das der Minimum bzw Maximum Wert eines Objekts auch eine Zahl ist. Wenn diese Meldung kommt dann diese bitte per Issue an den Adapter-Entwickler weitergeben, das dies im Adapter behoben wird.
"Ignoring Directory "benchmark.files" because officially not created as meta ob ject. Please remove directory!"
Wenn bei der Inatallation des js-controller diese Meldung kommt:
The following notifications happened during sync: - Ignoring Directory "benchmark.files" because officially not created as meta ob ject. Please remove directory!Bitte ein
iob upload allausführen. Falls Einträge von Adaptern enthalten sein sollten die nicht mehr installiert sind, dann können diese Dateien manuell gelöscht werden.TypeError: Cannot read property 'warn' of undefined
Falls der iobroker nicht mehr startet und im /var/log/syslog die untenstehende Fehlermeldung enthalten ist dann ist die backup Konfigurtation fehlerhaft.
/opt/iobroker/node_modules/@iobroker/db-base/lib/inMemFileDB.js:187 this.log.warn( ^ TypeError: Cannot read property 'warn' of undefined at ObjectsInMemoryServer.initBackupDir (/opt/iobroker/node_modules/@iobroker/db-base/lib/inMemFileDB.js:187:22)Bitte in /opt/iobroker/iobroker-data/iobroker.json im Bereich backup beo objects und states schauen das der Wert "period" eine Zahl in Minuten ist. Standard ist 120. Falls hier ein Wert über 10.000 drin steht so ist dieser warum auch immer falsch eingetragen und muss bitte korrigiert werden. Danach tut alles wieder.
Warning: Accessing non-existent property '...' of module exports inside circular dependency
Wenn beim Ausführen von CLI Befehlen oder im ioBroker Log Meldungen wie die nachstehenden angezeigt werden so liegt dies an einer alten version der Library "mogodb" im System. Diese Meldungen kommen nicht vom js-controller Upgrade sondern von der Nutzung von Node.js 14+ und dieser Library. Diese wurde vom node-red Adapter ggf. installiert.
(node:2218) Warning: Accessing non-existent property 'count' of module exports inside circular dependency (Use `node --trace-warnings ...` to show where the warning was created) (node:2218) Warning: Accessing non-existent property 'findOne' of module exports inside circular dependency (node:2218) Warning: Accessing non-existent property 'remove' of module exports inside circular dependency (node:2218) Warning: Accessing non-existent property 'updateOne' of module exports inside circular dependencyWenn ein Update des node-red Adapters (bzw Uninstall falls nicht benötigt) nicht hilft dann bitte mit
npm list mongodb(im iobroker Verzeichnis/opt/iobroker) rausfinden wo es herkommt. Falls etwas von "extranous" steht dann einfach pernpm uninstall mongodb(im iobroker Verzeichnis/opt/iobroker) löschen.Eine Backitup Instanz wird automatisch erstellt
Dies passiert weil Backitup für Neuinstallationen ein Standardadapter ist. Der kleine Nebeneffekt ist, das, wenn noch keine Backitup Instanz existiert ABER der Adapter-Code auf einem Host installiert ist, dann dort eine Instanz angelegt wird. Wer das nicht will kann diese manuell wieder entfernen und dann aber am besten auch den Adapter deinstallieren. Dann passiert dies nicht noch einmal.
Infos zum Thema "Rebuilds bei Node.js Aktualisierungen"
Generell gilt das Node.js Updates wie unter https://forum.iobroker.net/topic/44566/how-to-node-js-für-iobroker-richtig-updaten-2021-edition beschrieben funktionieren. Der js-controller 4.0 führt nur die automatisierten Rebuilds etwas anders aus als die 3.3.
In der neuen Version versuchen wir zuerst generell alle Module neu zu erstellen. Das sollte alle Probleme auf einen Schlag lösen. Falls das (und ja da kann es Gründe geben) nicht funktioniert ist der zweite Versuch das wirklich betroffene NPM-Paket zu identifizieren (also z.B. direkt "serialport" o.ä.) und dieses neu zu kompilieren. Das hat deutlich weniger Nebeneffekte wie die bisherigen Versuche.
Aktuell sind zwei Module bekannt die leider eine manuelle Korrekt benötigen (wir haben es bei den Modulen gemeldet, sodass sich das in Zukunft löst). Dazu dann die Meldungen im Log befolgen.
FAQ zur DB Umstellung File -> JSONL
Ich nutze Redis. Betrifft mich das?
Wenn Du für beide Datenbanken einen Redis einsetzt dann nicht. Es ist nur relevant wenn eine oder beide DBs "File" sind.
Was ist denn so besser an der "JSONL"-Datenbank anstelle "File"?
Von der Funktionalität ist alles identisch! Die beiden Datenbanken unterscheiden sich nur darin wie die Daten gespeichert werden.
Die File-DB schreibt hier alles in einem großen JSON-File regelmäßig - bei Objekten sind dies schnell mal 20MB. Dies kann durchaus viel I/O verursachen und ist vor allem bei SD-Karten-Basierten Systemen nicht optimal, weil es die Karte sehr belastet. Aber auch für SSDs ist dies nicht optimal. Zusätzlich besteht das Problem das ein Absturz beim Schreiben dazu führt das das ganze File defekt ist. ioBroker greift in diesen Fällen auf ein Backup-File zurück.
JSONL arbeitet hier anders. Änderungen werden erst einmal nur an die Datei angehangen und - nur wenn nötig - wird dann das File "komprimiert" und so neu geschrieben. Dies erfolgt aber viel seltener als bei der File-DB.
Für JSONL hat es @AlCalzone mal folgendermaßen zusammengefasst:
JSONL ist resistenter. Ein kaputtes Byte in der DB macht nicht alles kaputt und ein Absturz beim Schreibvorgang sorgt nur dafür, dass die ausstehenden Änderungen verloren gehen, nicht alles.
JSONL schont die SD-Karte durch weniger und kleinere Schreibvorgänge (nur wenn nötig).
JSONL braucht zumindest phasenweise etwas mehr Platz (die DB ist bis auf Kompaktierungsvorgänge append-only)
JSONL braucht etwas länger, wenn viele Objekte in kurzer Zeit geschrieben werden sollen (wobei meine letzten Tests nur noch Unterschiede im Rahmen der Standardabweichung ergeben haben)Wir denken das das neue Datenbank-Handling mehr Vorteile hat - vor allem für SD-Karten- und SSD-basierte Systeme.
Was bedeutet es das die Datenbank jetzt jsonl ist?
Im Normalfall bedeutet hies für den täglichen Betrieb nichts. Auch die Umstellung erfolg vollautomatisch im Rahmen des js-controller Updates.
Einiob statuswird nach der Installation anstelle "file" jetzt "jsonl" anzeigen. Das wars auch schon. Backups über BackItUp oderiob backupund auch restores funktionieren weiterhin ohne Änderungen.WICHTIG: Durch die automatische Datenbankumstellung ist ein direkter Downgrade oder Backup Restore eines mit 4.0 erstellten Backups nur noch auf js-controller 3.3.x möglich! Für andere Downgrade Optionen bitte im nächsten Eintrag lesen. Ein Downgrade mit Redis als Datenbank ist problemlos weiterhin möglich!
Die Datenfiles im iobroker-data Verzeichnis haben jetzt .jsonl am Ende und nicht mehr .json. Die letzten "file DB .json"-Files werden umbenannt und liegen noch im Verzeichnis mit der Endung ".migrated".
Kann man die Einstellungen der JSONL ändern?
Ja, auch die JSONL Datenbank hat einige Einstellungen (wie das "writeFileInterval" der File-DB früher, welches bei jsonl nicht genutzt wird). Üblicherweise muss da niemand Hand anlegen, weil die Defaults von uns bereits optimiert wurden.
Wer dennoch schauen will finden unter https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/conf/iobroker-dist.json#L53-L71 (Objects) bzw https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/conf/iobroker-dist.json#L99-L117 die jeweiligen Default-Werte. Anpassungen können einfach in Eurer iobroker.json manuell gemacht werden.
Wie kann ich doch auf js-controller 3.2 oder kleiner downgraden wenn "jsonl" der DB Typ ist?
js-controller Versionen kleiner als 3.3.x hatten die nötigen Dateien für eine "jsonl" Datenbank nicht an Board. Daher ist ein direkter Downgrade nicht möglich weil dann die Daten nicht lesbar sind!
Daher muss ZUERST (!!) unter js-controller 4.0 die Datenbank manuell zurück auf "file" migriert werden. Dies erfolgt per
iob setup customund dort bei der Abfrage des DB Typsfileangeben. Alle weiteren Fragen beantworten und dann die Migration abwarten. Danach zeigtiob statuswieder "file" an. Dann kann ein Backup für den Restore in einer kleineren Version erstellt werden oder ein Downgrade vianpm i iobroker.js-controller@version(Vorher ins ioBroker Verzeichnis wechseln!) auf die gewünschte Version erfolgen.FAQ zu Redis "Sets" Optimierungen
Für Redis-basierte Systeme bringt der js-controller 4.0 einige Optimierungen mit. Eine davon nutzt spezielle interne Datenstrukturen, die konsistent initialisiert werden müssen. Aufgrund einiger Edge Cases wird diese Optimierung daher automatisch nur für Single-Host Redis-Systeme genutzt. Wer auch im Multi-Host-Umfeld mit Redis für Objekte von den Optimierungen profitieren möchte kann diese manuell aktivieren. VORAB müssen aber alle Hosts auf js-controller 4.0 sein und soweit alles gut sein das es keinen partiellen Downgrade mehr gibt.
Dann können die Optimierungen über
iob object activateSetsaktiviert werden, nachdem ALLE Hosts beendet wurden. So wird sichergestellt das die Datenstrukturen konsistent initialisiert werden können. Danach können alle Hosts wieder gestartet werden. Eine Deaktivierung der Optimierungen ist periob object deactivateSetsebenso möglich.@apollon77 sagte in js-controller 4.0.x jetzt für alle User im STABLE!:
Danach zeigt iob statuswieder "file" an. Dann kann ein Backup für den Restore in einer kleineren Version erstellt werden oder ein Downgrade via npm i iobroker.js-controller@version (Vorher ins ioBroker Verzeichnis wechseln!) auf die gewünschte Version erfolgen.
weil es da so steht
nach einem gelösten Thread wäre es sinnvoll dies in der Überschrift des ersten Posts einzutragen [gelöst]-... Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat. Forum-Tools: PicPick https://picpick.app/en/download/ und ScreenToGif https://www.screentogif.com/downloads.html
-
@apollon77 sagte in js-controller 4.0.x jetzt für alle User im STABLE!:
Danach zeigt iob statuswieder "file" an. Dann kann ein Backup für den Restore in einer kleineren Version erstellt werden oder ein Downgrade via npm i iobroker.js-controller@version (Vorher ins ioBroker Verzeichnis wechseln!) auf die gewünschte Version erfolgen.
weil es da so steht
@liv-in-sky Da steht Wenn man downgraden will tue es so und so Nichts anderes
Ich habs nochmal gelesen und wüsste nicht was ich ändern kann ... Mach gern nen vorschlag wenn für dich was unklar warBeitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@liv-in-sky Da steht Wenn man downgraden will tue es so und so Nichts anderes
Ich habs nochmal gelesen und wüsste nicht was ich ändern kann ... Mach gern nen vorschlag wenn für dich was unklar warich muss ehrlich gestehen, das ich den genauen ablauf vergessen habe - waren mehrere stunden um am server, um den fehler zu finden
letztlich wollte ich einen restore machen, der nicht ging, da wir das system ganz neu installiert hatten und jsonl bekamen, aber nur ein backup mit einem 3.x controller mit file hatten
ich bin mir leider nicht mehr sicher, ob wir das neue system auf "file" umstellten und dann gleich einen restore versuchten und das auch wieder schief ging
daher dachte ich wohl, es ist besser, die neue installation auf file umzustellen, dann einen downgrade auf js-c 3.x und dann den restore zu fahren - was ja letztlich zum erfolg führte
da ich beim letzten mal deine anleitung nicht richtig gelesen hatte und du mich darauf hinweien musstest, dass ich unter faq die lösung finde, dachte ich diesmal, lies die faqs und darin fand ich dann die anleitung, in der von backup und restore die rede war - und die wollte ich dann ausführen - ich habe deine faq so gelesen, dass ein restore nur geht, wenn ich den js-c downgrade - sorry - mein fehler - es handelt sich um ein fremdsystem - da wollte ich sicher sein, dass ich keinen "blödsinn" installiere
es kommt daher kein vorschlag von mir - lass es einfach so, wie es ist - mir reicht, dass es jetzt läuft
nach einem gelösten Thread wäre es sinnvoll dies in der Überschrift des ersten Posts einzutragen [gelöst]-... Bitte benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat. Forum-Tools: PicPick https://picpick.app/en/download/ und ScreenToGif https://www.screentogif.com/downloads.html
-
ich muss ehrlich gestehen, das ich den genauen ablauf vergessen habe - waren mehrere stunden um am server, um den fehler zu finden
letztlich wollte ich einen restore machen, der nicht ging, da wir das system ganz neu installiert hatten und jsonl bekamen, aber nur ein backup mit einem 3.x controller mit file hatten
ich bin mir leider nicht mehr sicher, ob wir das neue system auf "file" umstellten und dann gleich einen restore versuchten und das auch wieder schief ging
daher dachte ich wohl, es ist besser, die neue installation auf file umzustellen, dann einen downgrade auf js-c 3.x und dann den restore zu fahren - was ja letztlich zum erfolg führte
da ich beim letzten mal deine anleitung nicht richtig gelesen hatte und du mich darauf hinweien musstest, dass ich unter faq die lösung finde, dachte ich diesmal, lies die faqs und darin fand ich dann die anleitung, in der von backup und restore die rede war - und die wollte ich dann ausführen - ich habe deine faq so gelesen, dass ein restore nur geht, wenn ich den js-c downgrade - sorry - mein fehler - es handelt sich um ein fremdsystem - da wollte ich sicher sein, dass ich keinen "blödsinn" installiere
es kommt daher kein vorschlag von mir - lass es einfach so, wie es ist - mir reicht, dass es jetzt läuft
@liv-in-sky sagte in js-controller 4.0.x jetzt für alle User im STABLE!:
aber nur ein backup mit einem 3.x controller mit file hatten
Aber darum geht es gar nicht. Das ist egal. Beim backup restore gilt die DB die gerade eingestellt ist. Was vorher war als Backup erstellt wurde ist an der Stelle egal.
Deswegen steht da auch nichts von Restore, sondern nur von Downgrade des Controllers !!!
-
@apollon77
Seit js-controller Version 4.0.15 startet iobroker nach einem Restart nicht mehr, weil in der Datei "/opt/iobroker/iobroker-data/iobroker.json" der period Wert zu groß ist. Auch das heutige Update auf 4.0.18 bringt keine Änderung.In den Controller-Einstellungen sind 120 Minuten hinterlegt in der JSON Datei werden aber die Sekunden gespeichert, siehe Screenshot. Ändere ich die 7200000 in 120, startet iobroker wieder.
-
@apollon77
Seit js-controller Version 4.0.15 startet iobroker nach einem Restart nicht mehr, weil in der Datei "/opt/iobroker/iobroker-data/iobroker.json" der period Wert zu groß ist. Auch das heutige Update auf 4.0.18 bringt keine Änderung.In den Controller-Einstellungen sind 120 Minuten hinterlegt in der JSON Datei werden aber die Sekunden gespeichert, siehe Screenshot. Ändere ich die 7200000 in 120, startet iobroker wieder.
@blackeagle998 Jupp, bekannt und mit 4.0.18, welches gerade im Beta ist behoben. Ich habe keine Ahnung wo da bei dir so ein großer Wert überhaupt reingekommen ist
Der war schon immer "Minuten" und nicht Sekunden oder Millisekunden Aber am Ende egal weil der "backup" Part leider bei controller <4 ignoriert wurde 
-
@blackeagle998 Jupp, bekannt und mit 4.0.18, welches gerade im Beta ist behoben. Ich habe keine Ahnung wo da bei dir so ein großer Wert überhaupt reingekommen ist
Der war schon immer "Minuten" und nicht Sekunden oder Millisekunden Aber am Ende egal weil der "backup" Part leider bei controller <4 ignoriert wurde @apollon77
Meinst du eine andere 4.0.18 als ich installiert habe?
Mit der Version ist das jedenfalls gerade wieder passiert. -
@apollon77
Meinst du eine andere 4.0.18 als ich installiert habe?
Mit der Version ist das jedenfalls gerade wieder passiert.@blackeagle998 Was genau ist passiert? Also die 4.0.15 hatte den Bug das er gar nicht gestartet ist wenn der Wert zur gross war weil an der Code-Stelle wo eine Log Meldung ausgegeben werden sollte das der Wert falsch ist und runterkorrigiert wurde war ein Fehler.
Aber um nicht alle zu verwirren sollten wir Diskussionen zur BETA Version 4.0.18 bitte im beta Thread führen
608
Online32.4k
Users81.3k
Topics1.3m
Posts