NEWS
js-controller 3.2 jetzt im STABLE!
-
@marty56 Naja vor heute hast du den ioBroker ja die Tage auch neu gestartet. Und irgendwann danach ging das los. Frage ist wann das war und was da so im log Stand.
-
@apollon77 sagte in js-controller 3.2 jetzt im STABLE!:
(foxriver76) we warn if object not exists when setting a state via adapter.setState. Adjust your code that a state value is NOT set before the object is successfully created. If this deep check is NOT wanted for performance reasons the adapter needs to be initialized with strictObjectChecks = false!! (see DOCS LINK TODO)
Bei einem (vmtl. mehreren) User meines smartgarden Adapters kommt diese Warnung. Ich hab zwar eine Idee woran das liegen kann, aber ich würde es gerne prüfen. Also habe ich mein Testsystem auf js-controller 3.2.16 upgedated (ging problemlos - super, danke für die Arbeit), aber ich bekomme diese Warnung nicht angezeigt. Hmmm, wo kann der Unterschied zu meinem User sein ??? Ich möchte ausschließen, dass ich unabsichtlich das oben angebene
strictObjectChecks = false
gesetzt habe. Wo finde ich diese Einstellung?VG jpgorganizer
-
Habe bei Lets-Encrypt leider diesen Fehler:
2021-02-20 21:50:10.667 - error: admin.0 (1665) [LE] {"context":"cert_issue","subject":"mydomain.net","altnames":["mydomain.net"]} 2021-02-20 21:50:10.671 - error: admin.0 (1665) [LE] {"length":0}
Dazu irgendwelche Ideen?
Viele Grüße
-
@techmo Mehr Log gibts nicht? Bitte mal Admin in debug log starten und posten
-
@jpgorganizer Wenn es bei dir nicht passiert dann mach mal ne neuen Instanz, denke das passiert beim ersten Install vor allem - danach existieren die Objekte ja.
Und ja, genau code wie https://github.com/jpgorganizer/ioBroker.smartgarden/blob/master/main.js#L72-L83 verursacht das. setObjectNotExist legt das Objekt asynchron an, aber du feuerst das setState direkt hinterher, die laufen also quasi beide parallel und das setState wird schneller sein als das Objekt angelegt ist.
Entweder async/await nutzen oder setState im Callback von setObject machen. Mehr details am besten im Developer Forumbereich oder Discord oder Telegram.
-
@apollon77 sagte in js-controller 3.2 jetzt im STABLE!:
denke das passiert beim ersten Install vor allem - danach existieren die Objekte ja.
das ist auch meine Vermutung
@apollon77 sagte in js-controller 3.2 jetzt im STABLE!:
Und ja, genau code wie https://github.com/jpgorganizer/ioBroker.smartgarden/blob/master/main.js#L72-L83 verursacht das. setObjectNotExist legt das Objekt asynchron an, aber du feuerst das setState direkt hinterher, die laufen also quasi beide parallel und das setState wird schneller sein als das Objekt angelegt ist.
genau, das war mein Verdacht. Irgendwie war mir die callback bei
setObjectNotExist
entgangen :-).
Neue Instanz ist gute Idee. DankeVG jpgorganizer
-
@apollon77
Ist jetzt ein anderer Fehler:2021-02-21 21:21:06.123 - debug: admin.0 (31084) Adding to Greenlock: anstoots.ddns.net with alternative names anstoots.ddns.net 2021-02-21 21:21:06.380 - info: admin.0 (31084) Challenge server listening on port 80 2021-02-21 21:21:06.382 - info: admin.0 (31084) If something is not working and your adapter is not reachable anymore you can turn off HTTPS with executing "iobroker admin.0 set --secure false" in your shell. 2021-02-21 21:21:06.453 - info: admin.0 (31084) https server listening on port 8081 2021-02-21 21:21:06.454 - info: admin.0 (31084) Use link "https://localhost:8081" to configure. 2021-02-21 21:21:06.647 - debug: admin.0 (31084) Subscribe OBJECTS: * 2021-02-21 21:21:16.886 - debug: admin.0 (31084) [LE] certificate_order: {"account":{"key":{"kid":"https://acme-v02.api.letsencrypt.org/acme/acct/113314436"}},"subject":"mydomain.net","altnames":["mydomain.net"],"challengeTypes":["http-01"]} 2021-02-21 21:21:19.306 - debug: admin.0 (31084) [LE] challenge_select: {"altname":"mydomain.net","type":"http-01","keyAuthorization":"SZxIO3ip2CRhSFFNCsIKhbsJL5rNL-IuuKtQoRzsvCE.x5SIlyfhEmleea795fCKMguyqnZwCQZOs7-BVkyoLeQ"} 2021-02-21 21:21:25.662 - debug: admin.0 (31084) [LE] challenge_status: {"status":"pending","type":"http-01","altname":"mydomain.net"} 2021-02-21 21:21:28.068 - debug: admin.0 (31084) [LE] challenge_status: {"status":"valid","type":"http-01","altname":"mydomain.net"} 2021-02-21 21:21:28.072 - info: admin.0 (31084) Received new certificate for mydomain.net via http-01 2021-02-21 21:21:30.451 - debug: admin.0 (31084) [LE] certificate_status: {"subject":"mydomain.net","status":"valid"} 2021-02-21 21:21:31.478 - debug: admin.0 (31084) [LE] cert_issue: {"renewAt":1617822156264,"subject":"mydomain.net","altnames":["mydomain.net"]} 2021-02-21 21:21:31.479 - info: admin.0 (31084) Certificate for mydomain.net is valid till 2021-04-07T19:02:36.264Z 2021-02-21 21:21:38.021 - error: admin.0 (31084) [LE] {"errno":"ENOTFOUND","code":"ENOTFOUND","syscall":"getaddrinfo","hostname":"mydomain","context":"cert_issue","subject":"mydomain","altnames":["mydomain"]} 2021-02-21 21:21:38.025 - error: admin.0 (31084) [LE] {"length":0} 2021-02-21 21:21:38.026 - error: admin.0 (31084) [LE] {"length":0}
-
@techmo sagte in js-controller 3.2 jetzt im STABLE!:
really?? Ist das deine domain? Du scheinst Sie in der Konfig aber eingetragen zu haben ..
-
@apollon77
Nein ich habe die Domain im Log ersetzt.
Wo sie ohne .net steht ist sie auch im Original ohne net.
Bei den anderen eben mit. -
@techmo Also es sieht an sich gut aus. Das Zertifikat wurde geholt. starte admin mal neu ( hätte eigentlich gedacht der Startet sich automatisch neu ... aber ok). Und durufst es danach EXAKT MIT DEM Domainnamen auch auf für den Du das Zertifikat geholt hast?
-
@techmo Für mich scheint es, dass du Admin mit
https://mydomain/
aufrufst anstatt mithttps://mydomain.net/
. Da greenlock den Domainnamen überprüft und damit das Zertifikat auswählt, wird das nicht funktionieren. Du musst die Admin-Seite exakt mit demselben Domainnamen aufrufen. Wenn du das lokal nicht kannst oder willst, dann verwende lokal eine zweite Admin Instanz ohne HTTPS. -
Ja das habe ich bei dem Log auch gedacht, aber ich rufe immer genau die Domain auf, die auch als Domain eingetragen ist.
Deswegen frage ich mich was da los ist.Safari auf dem iPhone sagt auch noch:
Malformed HTTP Header: 'Host:mydomain.net:8081'
Ging bis zur Umstellung mit dem alten js-Controller immer ohne Probleme.
-
@techmo Na da haben wirs schon.
Das "Neue "Letsencrypt unterstützt aktuell nur "Standard https", also Port 443
-
@apollon77
Jap das ist es tatsächlich.Steht das irgendwo?
8081 ist ja der StandardPort für Admin.0, deswegen läuft es bei mir dort.
Habs jezt geändert und es läuft wieder.Vielen Dank.
-
Hallo,
ich bekomme seit dem Update auf js-controller 3.2.16 ab und zu folgende Fehlermeldungen2021-02-24 15:30:43.411 - error: host.iobroker-Server Cannot save backup file /opt/iobroker/iobroker-data/objects.json.bak: ENOENT: no such file or directory, stat '/opt/iobroker/iobroker-data/objects.json'
2021-02-24 16:00:36.149 - error: host.iobroker-Server Cannot save backup file /opt/iobroker/iobroker-data/objects.json.bak: ENOENT: no such file or directory, rename '/opt/iobroker/iobroker-data/objects.json' -> '/opt/iobroker/iobroker-data/objects.json.bak'
Backups der Datei werden aber gemacht
hatte das Update schon Freitag gemacht und auch diese Fehlermeldungen bekommen, hab es dann Gestern noch mal neu gemacht, ist aber immer noch das selbe mit denn Fehlermeldungen.
Aufgefallen ist mir das sich die Datei Attribute geändert haben vonobjects.json.bak, objects.json, states.json.bak, states.json
unter js-controller 3.1.6 wahren die noch
Datei Attribute 674
-rw-rwxr--und unter js-controller 3.2.16 sind die
Datei Attribute 664
-rw-rw-r--habe dann nochmal iobroker fix ausgefürt, Datei Attribute wurden auch geändert
Datei Attribute 674
-rw-rwxr--nach dem Start von iobroker haben sich die Datei Attribute aber wieder geändert
Datei Attribute 664
-rw-rw-r--das hab ich dann auch mal getestet
pi@iobroker:~ $ cd /opt/iobroker/iobroker-data pi@iobroker:/opt/iobroker/iobroker-data $ sudo chmod -v 674 objects.json der Modus von 'objects.json' wurde von 0664 (rw-rw-r--) in 0674 (rw-rwxr--) geändert pi@iobroker:/opt/iobroker/iobroker-data $ sudo chmod -v 674 objects.json.bak der Modus von 'objects.json.bak' wurde von 0664 (rw-rw-r--) in 0674 (rw-rwxr--) geändert pi@iobroker:/opt/iobroker/iobroker-data $ sudo chmod -v 674 states.json der Modus von 'states.json' wurde von 0664 (rw-rw-r--) in 0674 (rw-rwxr--) geändert pi@iobroker:/opt/iobroker/iobroker-data $ sudo chmod -v 674 states.json.bak der Modus von 'states.json.bak' wurde von 0664 (rw-rw-r--) in 0674 (rw-rwxr--) geändert pi@iobroker:/opt/iobroker/iobroker-data $
nur ändern sich die Datei Attribute wieder wenn die Dateien sich ändern
und unter /opt/iobroker/iobroker-data/backup-objects haben sich die Datei Attribute auch geändertRaspbeery 4
nodejs 12.20.2
node 12.20.2
npm 6.14.11
js-controller 3.2.16
admin 4.2.1
javascript 4.8.4Update habe ich wie folgt gemacht
cd /opt/iobroker
iobroker stop
ps auxww|grep io
iobroker update
iobroker upgrade self
iobroker fix
iobroker startalles ohne Fehler
und nu hab ich keine idee mehr
Gruß Michael
Edit: log angehangen
log0.txt -
@michi68 sagte in js-controller 3.2 jetzt im STABLE!:
.json
sind keine ausführbaren Dateien. Darüber hinaus sind die Dateien per ACL angelegt, dir fehlen also Informationen über die Attribute.
Jag da mal wieder den Fixer drüber.
iobroker fix
-
@thomas-braun
iobroker fix gemacht
nach dem start dann wieder
2021-02-24 22:44:49.947 - error: host.iobroker-Server Cannot save backup file /opt/iobroker/iobroker-data/objects.json.bak: ENOENT: no such file or directory, stat '/opt/iobroker/iobroker-data/objects.json'
-
pi@raspberrypi:~ $ getfacl /opt/iobroker/iobroker-data/iobroker.json getfacl: Entferne führende '/' von absoluten Pfadnamen # file: opt/iobroker/iobroker-data/iobroker.json # owner: iobroker # group: iobroker user::rw- group::r-- group:iobroker:rwx mask::rwx other::r--
Gut, bei der Gruppe iobroker ruder ich zurück, iobroker hat das x-bit.
-
@michi68 Ist das auf ner synology? Da gabs ja weiter oben ähnliche berichte ... ich weiss aber nicht was das issue sein soll ...
Das interessante ist auch das beim "nach dem Start"-Screenshot die objects.bak fehlt.
EDIT: Ok ich habs gefunden ... Der Fehler bedeutet (meeh unglücklich formuliert) erstmal nur das kein objects.json existiert und daher dieses auch nicht in "objects.json.bak" umbenannt werden kann. Es wird danach trotzdem das objects.json neu geschrieben . Beim nächsten Speichern sollte an sich dann wieder alles klappen und der Fehler nicht nochmals vorkommen.
Falls doch ist die Frage was da bei Dir passiert das das File verschwindet
-
@apollon77
jo fehlt hatte ich auch noch nicht bemerkt, ist aber wieder da
ist Raspbian buster