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

[sushbone]

> Umstellen des Typs is tricky und manchmal zickig.
Wohl wahr… :lol:

Wenn ready aufgerufen werden müsste sollte der Teil in der main.js zumindest schonmal korrekt sein. Ggf. geben die Logs aber den richtigen Hinweis, irgendwie scheint der Adapter nicht richtig zu terminieren nachdem er gelaufen ist (oder besser: "initialisiert wurde") , folgendes habe ich heute früh in den Logs gefunden. Korrekterweise jede Minute, darauf habe ich den scheduler testweise eingestellt.

` > …

host.raspberrypi 2018-05-28 05:00:01.413 error instance system.adapter.syncthing.0 terminated with code 7 (Adapter already running)

host.raspberrypi 2018-05-28 05:00:00.054 info instance system.adapter.syncthing.0 started with pid 10059

host.raspberrypi 2018-05-28 04:00:01.375 error instance system.adapter.syncthing.0 terminated with code 7 (Adapter already running)

host.raspberrypi 2018-05-28 04:00:00.054 info instance system.adapter.syncthing.0 started with pid 9192

... `

Spannende Frage ist jetzt, woran liegts? Ich wüsste nicht was in meiner main() Methode den Adapter "am Leben" erhält. Wobei die Objekte noch keine Werte aus der main-Methode erhalten haben, main() scheint also zuvor noch nicht aufgerufen worden zu sein, es wurde lediglich die Objekt-Struktur angelegt.

Seltsam… Muss man den ganz gezielt irgendwo in den JavaScript klassen den Adapter terminieren am Ende?

[apollon77]

Es sollte alles korrekt klappen wenn man

Adapter.stop()

nutzt. Einige schedule Adapter haben aber auch ein „nach x weiteren Sekunden process.exit() Hard kill“ drin ;-)

Muss halt so lange sein das ggf. Letzte Werte noch verarbeitet/gespeichert werden konnten… also 30/60s+

[sushbone]

Danke Dir, die letzten Hinweise von Dir bzgl. Terminierung des Adapters war die Lösung.

Ich habe am Ende jetzt analog Weatherunderground Adapter ein setTimeout gesetzt weil der http-Request noch einen Moment braucht und ein adapter.stop() zu schnell terminiert. Aber gut zu wissen dass es beides gibt.

Den SetTimeout Wert werde ich dann noch per Admin-Oberfläche konfigurierbar machen mit einem default von 30 Sekunden. Und ggf. noch eine Anpassung machen dass der Adapter nach Speichern der Konfiguration bereits einmal initial ausgeführt wird vor dem ersten schedule, das fänd ich irgendwie schöner.

Aber ansonsten wars das, jetzt klappt alles, der Cron-Job wird schön jede Minute ausgeführt und alle Werte aus Syncthing geholt und die Object-Werte aktualisiert! TOP!! Jetzt kann ich den Adapter diese Woche fertig machen, d.h. die Readme finalisieren und den Code noch ein klein wenig polishen (z.B. die Log-Ausgaben). Mal sehen vielleicht schafft er's ja irgendwann in das Default Verzeichnis der Adapter. Aber am wichtigsten war mir jetzt erstmal dass er fertig wird.Daher danke nochmal für die tolle Hilfe!

[apollon77]

Äääähm … das adapter stop musst du machen wenn der http request beendet wurde ... also in dem callback. Dann sollte doch nichts mehr offen sein ...

Ich schaue mir das die Tage mal an.

[sushbone]

Das wäre lieb von Dir, stehe mit dem Callback Konzept etwas aufs Kriegsfuß.

Habe den Stop-Befehl nach dem letzten Befehl innerhalb der Main Methode aufgerufen, bin gespannt was das richtige Vorgehen an der Stelle ist.

THX vorab für die Hilfe an dem Adapter bzw. dem Tipp was verändert werden muss!

[apollon77]

Ok, dann hier mal einige gedanken/Feedback:

• Verzeichnisse www und widget weg wenn nicht gebraucht

• Adapter brauchen für das Repo ab sofort Admin v3 Support. Also ein admin/index_m.html … Sieht etwas anders aus als die index.html

• io-package.json: restartAdapter raus wenn kein Widget dabei ist

• io-package.json: Adaptertyp "common adapters" gints nicht. WÜrde das ggf eher unter "utility" sehen ... ?!

• Mit deinem Github Account bei Travis-CI/Appveyor anmelden, Projekt aktivieren und commit machen, Dann sollten die Adaptertests bei jedem Commit automatisch laufen

• Verzeichnis tasks und das "gruntfile.js" weg. Dafür gulp aus dem Template-Adapter bitte rein

• Auch travis/appveyor Files bitte mit Template abgleichen und so aktualisieren

• Auch lib/utils.js aus dem Template-Adapter nehmen und dann in der main.js eine Änderung: utils.adapter -> utils.Adapter

• Wenn du on (objectchange/statechange/message)" nicht brauchst dann am besten auch auskommentieren

• Anstelle setObject immer setObjectNotExists nutzen. Wenn States in instanceObjects im io-package.json schon angelegt wurden kann das aus dem Code raus

• adapter.subscribeStates('*'); brauchst Du nur wenn Du auch willst das User etwas ändern können. Brauchst Du aber nicht.

Nun noch zur Frage vom letzten Beitrag:

Also parallel zum Start des HTTP-Requests schon den Timer für den Prozess-Kill zu starten ist keine gute Idee bzw da einen längeren Timeout nehmen.

Am besten du baust eine eigene "stop" Methode die den Prozess beendet (bzw den 30s Timer macht oder adapter.stop und callback) und diese rufst Du nach den ganzen setState-Calls (im Request-Erfolgs/Fehlerfall) auf. Dann laufen die 30s wenigstens erst los wenn die Antwort da ist.

Eigentlich sollte https://github.com/dschaedl/ioBroker.we ... und.js#L79 reichen ...

Ingo

[sushbone]

Hallo Ingo,

wow vielen Dank für das ausführliche Feedback und dass Du Dir die Zeit für den Adapter genommen hast. Ich habe gestern und heute Deine Liste abgearbeitet. Danke Dir für die Mühe und das genaue Hinsehen. TOP! Gute Hinweise dabei bei denen ich wieder was gelernt habe,

und mit dem korrekten Stop-Handling arbeitet der Adapter jetzt genau wie er soll.

Auch der Test über Appveyer und Travis-CI ist eine feine Sache! :)

Ich habe mich eben noch die Readme angepasst und den Adapter auf Version 0.1.1 angehoben. So wie es aussieht ist er jetzt erstmal fertig.

:D :D

• Verzeichnisse www und widget weg wenn nicht gebraucht

-> erledigt (beides rausgenommen)

• Adapter brauchen für das Repo ab sofort Admin v3 Support. Also ein admin/index_m.html … Sieht etwas anders aus als die index.html

-> erledigt. Sah zumindest in der Preview des HTML Editor OK aus (unter ioBroker hab ich die Seite noch nicht sehen können.

• io-package.json: restartAdapter raus wenn kein Widget dabei ist

-> erledigt

• io-package.json: Adaptertyp "common adapters" gints nicht. WÜrde das ggf eher unter "utility" sehen … ?!

-> "common adapters" war mal in einem alten template enthalten. Habs in utility geändert, denke das passt auch.

• Mit deinem Github Account bei Travis-CI/Appveyor anmelden, Projekt aktivieren und commit machen, Dann sollten die Adaptertests bei jedem Commit automatisch laufen

-> erledigt. Bei beiden angemeldet. Sowohl Appveyer als auch Travis-CI haben einen erfolgreichen Lauf per Email bestätigt.

• Verzeichnis tasks und das "gruntfile.js" weg. Dafür gulp aus dem Template-Adapter bitte rein

-> erledigt

• Auch travis/appveyor Files bitte mit Template abgleichen und so aktualisieren

-> erledigt

• Auch lib/utils.js aus dem Template-Adapter nehmen und dann in der main.js eine Änderung: utils.adapter -> utils.Adapter

-> erledigt

• Wenn du on (objectchange/statechange/message)" nicht brauchst dann am besten auch auskommentieren

-> erledigt (auskommentiert)

• Anstelle setObject immer setObjectNotExists nutzen. Wenn States in instanceObjects im io-package.json schon angelegt wurden kann das aus dem Code raus

-> erledigt (in setObjectNotExists geändert)

• adapter.subscribeStates('*'); brauchst Du nur wenn Du auch willst das User etwas ändern können. Brauchst Du aber nicht.

-> erledigt (auskommentiert)

Nun noch zur Frage vom letzten Beitrag:

Also parallel zum Start des HTTP-Requests schon den Timer für den Prozess-Kill zu starten ist keine gute Idee bzw da einen längeren Timeout nehmen.

Am besten du baust eine eigene "stop" Methode die den Prozess beendet (bzw den 30s Timer macht oder adapter.stop und callback) und diese rufst Du nach den ganzen setState-Calls (im Request-Erfolgs/Fehlerfall) auf. Dann laufen die 30s wenigstens erst los wenn die Antwort da ist.

Eigentlich sollte https://github.com/dschaedl/ioBroker.we … und.js#L79 reichen ...

-> Hatte bei der alten Lösung den Timer parallel loslaufen zu lassen auch kein gutes Gefühl. Jetzt wird er wie Du empfiehlst in dem Request Erfolgs-/Fehlerteil aufgerufen. Klappt perfekt.

[apollon77]

Nach Änderungen an en Admin files in deinem ioBroker brauchst du ein „ioBroker upload asaptername“ das du die im Admin siehst

[sushbone]

Ah okay probiere ich aus. Ich hatte gehofft / vermutet dass ein einfaches Entfernen und neu hinzufügen aus Github in der ioBroker Admin-Oberfläche reichen würde. Teste ich später mal.

[Homoran]

@sushbone:

ein einfaches Entfernen und neu hinzufügen aus Github in der ioBroker Admin-Oberfläche reichen würde `
du musst nach der Änderung der Datei ein upload (siehe Apollon) machen

Evtl. auch noch die Instanz löschen und neu anlegen - aber das weiß apollon besser wann das sein muss.

Gruß

Rainer

[sushbone]

OK passt Update auf Admin V3 wäre erledigt, index_m.html wird jetzt gezogen. Ich musste mich in einem anderen Thread nochmal durch den Migrationspfad auf die V3 durcharbeiten, u.a. bzgl. der Sprachfiles und der notwendigen Anpassung in io-package.json etc..

Aber jetzt funktioniert die Konfig des Syncthing Adapters auch in der ioBroker Admin V3. :D

https://abload.de/img/unbenannt-1insle.jpg" />

[sushbone]

Erweitert auf Version 0.1.2.

Es werden jetzt alle Informationen eines Folders des entsprechenden Syncthing Endpunktes abgefragt.

~~https://abload.de/img/unbenannt-22p4utd.jpg" />

Ich denke das ist erstmal meine finale Version falls ich nicht noch über irgendwelche Bugs stolpere.

Für eine spätere Version wären eventuell noch die Resourcen-Auslastung (CPU etc) des Syncthing Servers abfragbar, aber das kann erstmal warten.

Jetzt wäre es natürlich cool irgendwann mit dem Adapter unter ioBroker in die Übersicht oder Auswahlliste (Adapter aus eigener URL installieren -> Von Github -> Auswahlliste) zu kommen. Ist irgendwo dokumentiert welche Voraussetzungen dazu erfüllt sein müssen?

In den FAQs habe ich dazu nichts gefunden.~~