NEWS
Test js-controller v2.0.x (GitHub)
-
Muss man auch den Master beenden um das Update auf den slave zu spielen? Habe ich noch nicht ausprobiert.
Bisheriger Versuch auf Pi3-Slave zu installieren schlug fehl.
Probleme: iobroker status sagt immer iobroker running obwohl vorher beendet. Fix habe ich auch schon vorher durchlaufen lassen.
Version:
npm: 6.9.0
nodejs: 10.6.3pi@Pi3:/opt/iobroker $ sudo iobroker status iobroker is running Objects type: file States type: file pi@Pi3:/opt/iobroker $ sudo iobroker stop pi@Pi3:/opt/iobroker $ sudo npm install ioBroker/ioBroker.js-controller npm ERR! code 128 npm ERR! Command failed: git clone --mirror -q git://github.com/ioBroker/ioBroker.js-controller.git /root/.npm/_cacache/tmp/git-clone-ca0fa90a/.git npm ERR! fatal: could not create leading directories of '/root/.npm/_cacache/tmp/git-clone-ca0fa90a/.git' npm ERR! npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2019-09-30T19_54_21_045Z-debug.log pi@Pi3:/opt/iobroker $ sudo iobroker status iobroker is running Objects type: file States type: file@lobomau Zwei Dinge dazu:
iobroker status liefert die Info ob das ipBroker-System läuft. Auf einem Slave gestartet mit einem laufenden Master wird immer die Meldung sein "iobroker running" weil der Master läuft.
Um das Update einzuspielen reicht es aber wenn der Slave beendet ist.
Zu deinem Fehler: Siehe oben erster Beitrag. Leider gibt es diesen Fehler aktuell wegen NPM-foo ... "sudo -u iobroker -H nom install ioBroker/ioBroker.js-controller" ausführen. Das tut wohl
Beitrag 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
-
@apollon77 Das habe ich, siehe ein paar Beiträge weiter oben. Mit nem sleep 10 bzw. zur Sicherheit sleep 15 läuft es erstmal Quick n Dirty.
Aktuell habe ich das Probelm, das sich ioBroker nicht merkt welche Adapter gestartet sind. Nach einen Reboot sind alle bis auf admin.0 und backitup.0 deaktiviert. Das war der Ausgangszustand nach dem Restore aus dem minimal Backup. Fixer hab ich bereits laufen lassen.
Wo wird denn gespeichert welcher Adapter aktiv sein soll?
@darkiop Also das darf an sich nicht passieren. Ja, nach dem Restore sind erstmal alle Adapter ausser Admin deaktiviert. Kann er bei änderungen das objects.json File (glaube bist ja nicht auf Redis) neu schreiben? Nicht das da was kaputt ist. Wenn Du den Adapter im Admin wieder aktivierst muss das persistiert werden ... Schau mal ob sich das File Date ändert.
-
@lobomau Zwei Dinge dazu:
iobroker status liefert die Info ob das ipBroker-System läuft. Auf einem Slave gestartet mit einem laufenden Master wird immer die Meldung sein "iobroker running" weil der Master läuft.
Um das Update einzuspielen reicht es aber wenn der Slave beendet ist.
Zu deinem Fehler: Siehe oben erster Beitrag. Leider gibt es diesen Fehler aktuell wegen NPM-foo ... "sudo -u iobroker -H nom install ioBroker/ioBroker.js-controller" ausführen. Das tut wohl
@apollon77 top. Installation scheint zu laufen. Danke.
-
was hast Du denn gemacht? War die IPv4 dann da und es ging trotzdem nicht?
Den Workaround mii-tool -r eth0ausprobiert, dann den Sleep im Startkskript rausgenommen und durchgebootet.
Ist bei 1.5.14 immer eine IPv4 beim Start des js-Controllers im Log an der Stelle vorhanden?
Wir kommen der Sache näher! Nein unter 1.5.14 war auch keine IPv4 zu diesem Zeitpunkt vergeben, was aber keine Auswirkung auf den js-controller hatte - der wurde trotzdem gestartet. Mach ich das selbe mit 2.0.x crasht der js-controller.
Log / Erklärung:
20:08 --> sleep im Start Skript deaktiviert und reboot
20:11 --> sleep im Stark Skript aktiviert und reboot┬─[darkiop@iobroker-hwr:/opt/iobroker/log]─[20:12:12] ╰─>$ cat iobroker.2019-10-01.log | grep "host.iobroker-hwr ip addresses" 2019-10-01 20:08:49.178 - info: host.iobroker-hwr ip addresses: 2019-10-01 20:11:10.254 - info: host.iobroker-hwr ip addresses: 10.3.1.22 fe80::dea6:32ff:fe17:78f5js-controller crash mit 2.0.x ohne IP beim Start des Prozesses:
2019-10-01 19:02:15.589 - info: host.iobroker-hwr ip addresses: 2019-10-01 19:02:15.610 - error: host.iobroker-hwr uncaught exception: connect ENETUNREACH 192.168.1.82:9001 - Local (0.0.0.0:0) 2019-10-01 19:02:15.611 - error: host.iobroker-hwr Error: connect ENETUNREACH 192.168.1.82:9001 - Local (0.0.0.0:0) at internalConnect (net.js:881:16) at defaultTriggerAsyncIdScope (internal/async_hooks.js:294:19) at defaultTriggerAsyncIdScope (net.js:971:9) at process._tickCallback (internal/process/next_tick.js:61:11)@darkiop Ok, das war alles super. Ich habe gefunden das "ioredis" (Die Redis Protokoll Lib) default "family" IPv4 hat ... mal schauen was ich da setzen kann ... Ich mache gleich eine neue Version, bitte damit neu testen, damit sollten an sich beide gehen (laut doku ;-) )
-
Zu meinem Backup Problem.
Umzug Rock64 Master auf Intel NUC (Debian) . (Js-controller 2.0.17)
Nach langem hin und her läuft das System jetzt einigermaßen.
Mein ioBroker hat Probleme einige "vis" npm Pakete zu installieren (ab ca. 20.30 Uhr) . Anbei der aktuelle log. iobroker.2019-10-01.log
-
@apollon77 also Redis scheint zu klappen.
Habe den Redis im selben Docker. Ping ist möglich und auch root@iobroker:/opt/iobroker# redis-cli -h 192.168.2.203 ping
PONGSollte also nicht das problem sein ?
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Schau mal ob es ggf in node_modules/iobroker.broadlink2/node_modules nochmal so ein @frankjoke verzeichnis mit dem File gibt. Also ich hab im Code geschaut und ja auch dort wird die betroffene Methode genutzt ...
UND: häng mal hier https://github.com/frankjoke/myAdapter/blob/master/myAdapter.js#L257 am Ed enoch ein ".bind(adapter);" an wie bei den anderen auch ...
Bingo Ingo :grinning:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
https://github.com/frankjoke/ioBroker.broadlink2/issues/66@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Der Fehler kommt wenn der Adapter 60s läuft und nicht in der Zeit fertig wird, dann wird er hart gekillt. Ich kann mir nicht vorstellen das das neue soooo viel langsamer ist ... komisch
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
Beitrag 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
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Schau mal ob es ggf in node_modules/iobroker.broadlink2/node_modules nochmal so ein @frankjoke verzeichnis mit dem File gibt. Also ich hab im Code geschaut und ja auch dort wird die betroffene Methode genutzt ...
UND: häng mal hier https://github.com/frankjoke/myAdapter/blob/master/myAdapter.js#L257 am Ed enoch ein ".bind(adapter);" an wie bei den anderen auch ...
Bingo Ingo :grinning:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
https://github.com/frankjoke/ioBroker.broadlink2/issues/66@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg Der Fehler kommt wenn der Adapter 60s läuft und nicht in der Zeit fertig wird, dann wird er hart gekillt. Ich kann mir nicht vorstellen das das neue soooo viel langsamer ist ... komisch
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
Lass doch mal in Debug Modus laufen und schau mal log an
-
@apollon77 Unsere Vermutung war Richtig, mit nem sleep 10 passts ...
Grundsätzlich sollte der iobroker aber ja erst starten nach dem das Netzwerk oben ist ... :D
#!/bin/bash ### BEGIN INIT INFO # Provides: iobroker.sh # Required-Start: $network $local_fs $remote_fs # Required-Stop: $network $local_fs $remote_fs # Should-Start: redis-server # Should-Stop: redis-server # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: starts ioBroker # Description: starts ioBroker ### END INIT INFO PIDF=/opt/iobroker/node_modules/iobroker.js-controller/lib/iobroker.pid NODECMD=$(which node) RETVAL=0 start() { echo -n "Starting ioBroker" sleep 10 su - iobroker -s "/bin/bash" -c "$NODECMD /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js start" RETVAL=$? } stop() { echo -n "Stopping ioBroker" su - iobroker -s "/bin/bash" -c "$NODECMD /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js stop" RETVAL=$? } if [ "$1" = "start" ]; then start elif [ "$1" = "stop" ]; then stop elif [ "$1" = "restart" ]; then stop start else echo "Usage: iobroker \{start\|stop\|restart\}" exit 1 fi exit $RETVAL -
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
Beides, also bei #257 auch
.bind(adapter), und in beiden Verzeichnissen.@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
Lass doch mal in Debug Modus laufen und schau mal log an
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
Beides, also bei #257 auch
.bind(adapter), und in beiden Verzeichnissen.@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
Lass doch mal in Debug Modus laufen und schau mal log an
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
Zeigt er aber die URL n die er anfragt? Versuch doch mal diese im Browser oder mit "curl" abzurufen.Dann siehst Du ja ob er es generell nicht lädt oder so?!
Beitrag 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
-
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Es gibt noch ein zweites Verzeichnis und nach patchen dessen lüppt auch der Broadlink nu.
Was hast Du gepatcht? Nur das zuerstgesagte oder auch das zweite was ich noch dazu geschrieben hatte mit dem "bind"?
Beides, also bei #257 auch
.bind(adapter), und in beiden Verzeichnissen.@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Ich polle alle ~30 Minuten und jeder Request funktioniert nicht bei daswetter. Scheint als bekäme er nie etwas an Daten und bricht dann ab. Wohl eher ein prinzipielles Problem, als denn ein zeitliches durch den JS-Controller.
Lass doch mal in Debug Modus laufen und schau mal log an
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Beides, also bei #257 auch .bind(adapter), und in beiden Verzeichnissen.
Ok, ich habe Frank nochmals kontaktiert, ggf baue ich eine 2.0.1 für npm mit dem Fix dann ... Sehen wir mal
-
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
Zeigt er aber die URL n die er anfragt? Versuch doch mal diese im Browser oder mit "curl" abzurufen.Dann siehst Du ja ob er es generell nicht lädt oder so?!
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
Zeigt er aber die URL n die er anfragt? Versuch doch mal diese im Browser oder mit "curl" abzurufen.Dann siehst Du ja ob er es generell nicht lädt oder so?!
Die API-URLs zeigt er an, ich kann sie auch aufrufen per Browser/Curl und es stehen Daten drin. Muss wohl morgen, ähh heute, mal paar Debugs einbauen wo er denn hängen bleibt. Eigentlich sind genügend try/catch drin, dass er wenigstens irgendwo mal meckern müsste...
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@apollon77 sagte in [Aufruf] js-controller 2.0 Beta Test:
@SBorg sagte in [Aufruf] js-controller 2.0 Beta Test:
Hab ich schon, nix. Er wartet einfach den eingestellten TimeOut beim parsen der Daten ab, wirft aber keinerlei Fehler. Erhöhe ich ihn, wartet er halt nur länger. Sieht also nicht nach einem Zeitproblem aus.
Zeigt er aber die URL n die er anfragt? Versuch doch mal diese im Browser oder mit "curl" abzurufen.Dann siehst Du ja ob er es generell nicht lädt oder so?!
Die API-URLs zeigt er an, ich kann sie auch aufrufen per Browser/Curl und es stehen Daten drin. Muss wohl morgen, ähh heute, mal paar Debugs einbauen wo er denn hängen bleibt. Eigentlich sind genügend try/catch drin, dass er wenigstens irgendwo mal meckern müsste...
-
Hier mal das Debug-Log, Issue mache ich dann heute früh dazu:
2019-10-01 19:26:02.883 - debug: daswetter.0 (23979) Redis Objects: Use Redis connection: 127.0.0.1:9001 2019-10-01 19:26:03.100 - debug: daswetter.0 (23979) objectDB connected 2019-10-01 19:26:03.108 - debug: daswetter.0 (23979) Redis States: Use Redis connection: 127.0.0.1:9000 2019-10-01 19:26:03.114 - debug: daswetter.0 (23979) Objects connected to redis: 127.0.0.1:9001 2019-10-01 19:26:03.129 - debug: daswetter.0 (23979) statesDB connected 2019-10-01 19:26:03.196 - debug: daswetter.0 (23979) States connected to redis: 127.0.0.1:9000 2019-10-01 19:26:04.073 - info: daswetter.0 (23979) starting. Version 2.8.1 in /opt/iobroker/node_modules/iobroker.daswetter, node: v8.16.1 2019-10-01 19:26:04.134 - debug: daswetter.0 (23979) set timeout to 60 sec 2019-10-01 19:26:04.135 - debug: daswetter.0 (23979) using new data structure 2019-10-01 19:26:04.138 - debug: daswetter.0 (23979) calling forecast 7 days: http://api.daswetter.com/index.php?api_lang=de&localidad=xxx&affiliate_id=xxx 2019-10-01 19:26:04.496 - debug: daswetter.0 (23979) 7 days forecast done, objects in list 107 2019-10-01 19:26:04.499 - debug: daswetter.0 (23979) calling forecast 5 days: http://api.daswetter.com/index.php?api_lang=de&localidad=xxx&affiliate_id=xxx&v=2.0 2019-10-01 19:26:04.892 - debug: daswetter.0 (23979) 5 days forecast done, objects in list 1059 2019-10-01 19:26:04.896 - debug: daswetter.0 (23979) calling forecast hourly: http://api.daswetter.com/index.php?api_lang=de&localidad=xxx&affiliate_id=xxx&v=2.0&h=1 2019-10-01 19:26:05.797 - debug: daswetter.0 (23979) hourly forecast done, objects in list 2699 2019-10-01 19:26:05.801 - debug: daswetter.0 (23979) objects in list: 2699 2019-10-01 19:27:04.135 - error: daswetter.0 (23979) force terminate, objects still in list: 1777 2019-10-01 19:27:04.184 - error: host.Ubuntu instance system.adapter.daswetter.0 terminated with code 15 (15)LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@Stabilostick Die Firmware des RPI4 ist aktuell.
-
@darkiop Also das darf an sich nicht passieren. Ja, nach dem Restore sind erstmal alle Adapter ausser Admin deaktiviert. Kann er bei änderungen das objects.json File (glaube bist ja nicht auf Redis) neu schreiben? Nicht das da was kaputt ist. Wenn Du den Adapter im Admin wieder aktivierst muss das persistiert werden ... Schau mal ob sich das File Date ändert.
@apollon77 said in [Aufruf] js-controller 2.0 Beta Test:
Also das darf an sich nicht passieren. Ja, nach dem Restore sind erstmal alle Adapter ausser Admin deaktiviert. Kann er bei änderungen das objects.json File (glaube bist ja nicht auf Redis) neu schreiben? Nicht das da was kaputt ist. Wenn Du den Adapter im Admin wieder aktivierst muss das persistiert werden ... Schau mal ob sich das File Date ändert.
Unter 2.0.18 ändert sich die objects.json definitiv nicht. Hab Testweise den info.0 beendet, die objects.json blieb unverändert. Dann wieder zurück zur 1.5.14 und hier wird sie nach ein Änderung immer neu angelegt.
Genau, Ich bin noch auf file/file - bin mir nicht sicher ob es Sinn macht im aktuellen Zustand auf redis/redis zu gehen. Grundsätzlich fühlt sich das ganze System gerade nicht mehr gut an, heute Morgen war auch unter 1.5.14 das System zusammengebrochen. Ich hatte irgendwann mal einen nächtlichen Restart für den javascript.0 eingeplant und der hat folgendes geworfen. Danach war dann wohl admin.0/web.0 nicht mehr zu erreichen obwohl die Prozesse noch liefen. Bei einem manuellen Restart des javascript.0 ist der Fehler reproduzierbar.
2019-10-02 07:28:24.595 - error: Caught by controller[0]: (node:20475) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'enabled' of undefined 2019-10-02 07:28:24.595 - error: Caught by controller[1]: (node:20475) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) 2019-10-02 07:28:24.596 - error: Caught by controller[1]: (node:20475) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.Die 2.0.18 hat auch leider nicht geholfen bzgl. des IPv4 Themas. Und dazu kommt jetzt noch, das nach der Installation der 2.0.18 (danach lasse ich auch immer noch schnell den fixer laufen) der iobroker-hwr nicht mehr mit init.d sondern mit systemd gestartet wird, d.h. mein sleep-fix ist weg :)
Proxmox-ioBroker-Redis-HA Doku: https://forum.iobroker.net/topic/47478/dokumentation-einer-proxmox-iobroker-redis-ha-umgebung
-
@apollon77 hm ich denke nicht der redis client kann sich ja auch verbinden ..
Neuste Version von gerade hat auch nicht geklappt:
Connecting to previous DB "file"... Creating backup ... This can take some time ... please be patient! host.iobroker 16727 states saved host.iobroker 19327 objects saved Backup created: /opt/iobroker/backups/2019_10_02-07_55_13_backupiobroker-migration.tar.gz Connecting to new DB "redis" ... States NOT connected Objects NOT connected New Database could not be connected. Please check your settings. No settings have been changed. -
@e-i-k-e Da steht überall Version 1.2.1 ... das kann nicht passen. Am besten installiere einfach die "npm latest" version entweder per npm direkt oder per Admin neu.
@apollon77
Okay ich bin mal auf die Suche genagen. habe NPM 6.9.0 und NPM x.x.x (aktuelle Version) auf meinem System gehabt. Das konnte ich beheben. Allerdings wird mir immer noch der selbe Fehler angezeigt. Könnte ich noch eine eine dritte Version auf meinem System haben? Wenn ja, wie finde ich die?
Support us
332
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge