UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[apollon77]

Der Installation Fixer ist "gefixt" :-) Also bitte nochmal iobroker stoppen und "iobroker fix" ausführen, dann sollten die komischen Shell meldungen weg sein

[crunchip]

@apollon77 super und danke für den schnellen fix, läuft wieder:+1:
was mir grad aufgefallen ist, die zweite Zeile, die ist neu

tankerkoenig.0	2021-01-23 13:47:47.399	warn	(15196) State "tankerkoenig.0.stations.8.e10.combined" has no existing object, this might lead to an error in future versions
tankerkoenig.0	2021-01-23 13:47:46.387	warn	(15196) Please update js-controller to at least 1.2.0

[apollon77]

@crunchip Nee die ist Uralt und kommt dann wenn der zum anlegen der Objekte mal "Länger" als erwartet braucht ... ist ein mega hack und bullshit inzwischen :-) leg mal eher ein issue an das man das ausbaut ;-)

[crunchip]

@apollon77 ok, mach ich
seltsam, sonst wurde mir nur die erste Zeile angezeigt

edit:
@apollon77 Alexa2 (weil es ja dein Part ist:relaxed: und ich den passenden Thread grad nicht finde)
version 3.5.6 bei start von iobroker

2021-01-23 13:47:18.036 - error: alexa2.0 (14667) Error: Error while checking Authentication: Error: no JSON
2021-01-23 13:47:18.039 - info: alexa2.0 (14667) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason
2021-01-23 13:47:19.461 - error: alexa2.0 (14667) Cannot check object existence of "alexa2.0.info.connection": Error: Connection is closed.
2021-01-23 13:47:19.462 - warn: alexa2.0 (14667) Could not check object existence of state alexa2.0.info.connection: Error: Cannot check object existence of "alexa2.0.info.connection": Error: Connection is closed.
2021-01-23 13:47:19.463 - error: alexa2.0 (14667) 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().
2021-01-23 13:47:19.463 - error: alexa2.0 (14667) unhandled promise rejection: Cannot read property 'setState' of null
2021-01-23 13:47:19.492 - error: alexa2.0 (14667) TypeError: Cannot read property 'setState' of null
at Adapter.setState (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:6065:35)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
2021-01-23 13:47:19.493 - error: alexa2.0 (14667) Cannot read property 'setState' of null
2021-01-23 13:47:19.494 - info: alexa2.0 (14667) sendToHost not processed because States database not connected
2021-01-23 13:47:20.015 - info: alexa2.0 (14667) terminating

[foxriver76]

Wenn man nun den Fixer ausführt, sollte die iobroker CLI in Kombination mit "Grace" auch Auto-Completion unterstützen.

[apollon77]

@crunchip Die Alexa2 Fehler bitte mit der kommenden 3.2.9 vom controller nochmals checken

[UncleSam]

Hat jemand von euch den folgenden Fehler schon mal gesehen:

Something	2021-01-22 18:47:43.864	error	went wrong: sourceId=sonoff.0.WiFi-Plug11.POWER, sourceObj={"_id":"sonoff.0.WiFi-Plug11.POWER","common":{"type":"boolean","role":"switch","read":true,"write":true,"storeMap":true,"name":"WiFi-Plug11
Something	2021-01-22 18:47:43.863	error	went wrong: sourceId=mihome-vacuum.0.rooms.275001013648.roomClean, sourceObj={"type":"state","common":{"name":"clean Room","type":"boolean","role":"button","read":false,"write":true,"desc":"Start Roo

Er ist nicht von mir, aber er wurde in diesem Thema gemeldet.

[Rushmed]

@unclesam Ich beobachte noch, seit gestern ist das Phänmen noch nicht wieder aufgetaucht. Ich habe auch keine Ahnung was die Ursache war.

[Dr. Bakterius]

@apollon77 Ist es richtig, dass der js-controller unnötig oft (auch wenn sich nichts ändert) die objects.json und objects.json.bak schreibt?

[apollon77]

Hey all,

mit den letzten Dingen gibt es jetzt noch eine 3.2.10 (die 3.2.9 haben wir übersprungen, technische Gründe)

3.2.10 (2021-01-23)

• (Apollon77) prevent some errors shown and optimize database handling
• (Apollon77) prevent an endless loop when lua script initialization was not possible
• (Apollon77) catch semver errors in upgrade commands
• (foxriver76) ensure setAdapterInstanceEnabled can not hang

Bitte testen, einige Adapter sollten etwas ruhiger sein hoffe ich. @Diginix Bitte auch deine hängenden Prozesse beobachten

[apollon77]

@dr-bakterius Nein das ist nicht richtig. Wenn es neu geschrieben wird dann haben sich daten geändert. kannst ja die Files mal vergleichen

[apollon77]

@unclesam siehe anderer Thread: Da scheint irgendwas mit Aleas falsch eingestellt zu sein und Logging ist suboptimal. Logging wird verbessert

[JLeg]

@apollon77 sagte in js-controller 3.2 jetzt im Latest!:

@dr-bakterius Nein das ist nicht richtig. Wenn es neu geschrieben wird dann haben sich daten geändert. kannst ja die Files mal vergleichen

tu' ich gerade - alle 2-3 Minuten passiert genau das - objects.json u. objects.json.bak wurden neu geschrieben, Änderungen anzeigen lassen - keine vorhanden.

[apollon77]

@jleg Wie schaust Du denn nach Änderungen? Ich hoffe nicht nur über die Dateigrösse :-) Also bei meinem System ist aktuell (18:38) die objects.json von 18:32 als ich ihn neu gestartet habe.

Die states.json ist von 18:37

Was laufen denn so für Adapter?

[Dr. Bakterius]

@apollon77 sagte in js-controller 3.2 jetzt im Latest!:

kannst ja die Files mal vergleichen

Habe ich (und andere auch) und keine Unterschiede zwischen den Dateien gefunden.

Edit: Natürlich auf Dateiinhalt verglichen. Und auffällig ist es bei mir beim Netatmo- und DasWetter-Adapter. Regelmäßig in deren Zyklen werden die Dateien geschrieben.

[JLeg]

@apollon77 sagte in js-controller 3.2 jetzt im Latest!:

@jleg Wie schaust Du denn nach Änderungen? Ich hoffe nicht nur über die Dateigrösse :-) Also bei

naa :)
letztes Beispiel

-rwxrwxrwx+   1 iobroker iobroker 13789525 Jan 23 18:33 objects.json
-rwxrwxrwx+   1 iobroker iobroker 13789525 Jan 23 18:33 objects.json.bak

hier reicht ein

diff objects.json objects.json.bak

Im Fall dass es Unterschiede gibt, konvertiere ich vor'm diff natürlich nach "lesbar"...

meinem System ist aktuell (18:38) die objects.json von 18:32 als ich ihn neu gestartet habe.

Die states.json ist von 18:37

Was laufen denn so für Adapter?

diverse :) als "auffällig" identifiziert sind aber "WLED" und "DWD", die waren einfach zu finden, da die tatsächlich dauernd Objekte ändern (WLED: timestamps, DWD: da wechselt regelmässig mein Ortname und "")

[apollon77]

@dr-bakterius Naja da haben wirs ... DasWetter ist ein Cron Adapter, das heisst das der bei jedem Lauf die Objekte aktualisiert. Es gibt ein Issue im js-controller das ggf zu optimieren - hat es aber nicht in die aktuelle Version geschafft.
ABER das die Files keinen Unterschied haben kann an sich nicht sein weil sich mindestens Zeitstempel ändern in den Objekten.

Wir hier im Thread weiter oben besprochen kann die Schreibfreequenz über "writeFileInterval" in iobroker.json bei den File Db Konfigs geändert werden.
Es hat sich an der Thematik iom Vergleich zum 3.1.6er Adapter oder davor nichts geändert.

[apollon77]

@jleg Dann wären das Adapter-Issues

[JLeg]

@apollon77 sagte in js-controller 3.2 jetzt im Latest!:

@jleg Dann wären das Adapter-Issues

Ah, ok; hatte auch vergessen zu erwähnen - diese ganze "diskwrite"-SSD-wearout-Geschichte (im Nachbarthread) hat imo nichts mit "3.2 im Latest" zu tun, das sieht unter 3.1.x komplett genauso aus, ist also OT...

[Dr. Bakterius]

@apollon77 sagte in js-controller 3.2 jetzt im Latest!:

ABER das die Files keinen Unterschied haben kann an sich nicht sein weil sich mindestens Zeitstempel ändern in den Objekten.

Mea culpa - aber es ist nicht leicht die Unterschiede in einer großen Datei zu finden die nur eine Zeile hat. Es haben sich tatsächlich einige Timestamps geändert.

Das mit 'DasWetter' leuchtet mir ein. Warum aber beim 'Netatmo'? Allerdings frage ich mich, was die Timestamps in den objects zu suchen haben? Würden die nicht in die states gehören?