Checkbox in Adaperkonfiguration deaktivieren

[AlCalzone]

@SchuetzeSchulz:

Ich vermute er erstellt/ändert im Hintergrund wohl noch States während durch das Setzen der Flags der Neustart des Adapters ausgelöst wird.

Allerdings ist mir bisher noch nichts eingefallen, das zu umgehen. `
Beim Überfliegen blicke ich nicht ganz durch, wie der Programmablauf mit Neustarts sein soll. Aber Ändern des Adapter-Objekts führt in der Regel zu sofortigem Neustart. D.h. du solltest das erst machen, wenn deine Initialisierung abgeschlossen ist, also alle Objekte und States befüllt sind.

Die setState und setObject-Methoden haben allesamt einen Callback, der dich darüber informiert, dass der Vorgang abgeschlossen ist. Du könntest vor dem Erstellen der Objekte ermitteln, wie viele angelegt werden sollen und in diesem Callback eine Variable runterzählen. Wenn diese dann Null erreicht, bist du fertig und kannst den Adapter neustarten durch Setzen der Flags.

In meinem TypeScript-Adapter-Template sind die meisten Adapter-Methoden "dokumentiert", z.B. adapter.setObject hier:

https://github.com/AlCalzone/ioBroker.t … d.ts#L1009

und der Callback hier:

https://github.com/AlCalzone/ioBroker.t ... d.ts#L1268

[SchuetzeSchulz]

Das mit dem Callback klingt logisch und würde sicherlich bei meinem Problem helfen.

Allerdings muss ich dazu sagen dass ich leider noch absoluter JavaScript newbie bin und nicht so ganz verstehe wie ich das implementieren kann.

Der Callback müsste ja quasi über alle setObjects etc. gehen.

Auch Google hatte mir jetzt nichts brauchbares ausgespuckt, was ich verstehe…

Hättest Du evtl. ein kurzes Codebeispiel für mich?

[AlCalzone]

@SchuetzeSchulz:

Hättest Du evtl. ein kurzes Codebeispiel für mich? `
So ähnlich wie hier http://forum.iobroker.net/viewtopic.php … 66#p112166

Nur mit setObject statt createState und entsprechend angepassten Definitionen. Und die Funktion main() ersetzt durch deinen Adapter-Neustart.

[SchuetzeSchulz]

Das setzt aber voraus, dass ich vorab schon weiß welche/wieviele States ich habe, oder?

Bei liest der Adapter diese ja erstmal aus dem Gateway aus (setupDevices()) und erzeugt diese dann dynamisch.

[AlCalzone]

Wie gesagt, ich weiß nicht wie dein Gateway bzw. die Kommunikation funktioniert und wann du weißt welche States erzeugt werden. Anhand der Gateway-Antwort müsstest du aber ermitteln können wie viele States es werden, oder?

Im Prinzip kannst du auch deiner Funktion setupDevices() einen Callback übergeben und den dann in setupDevices aufrufen, wenn alle States fertig sind. In diesem Callback gehts dann weiter bzw. startest du den Adapter neu.

[SchuetzeSchulz]

Hmm, mir scheint ich habe da ein größeres Problem im Adapter.

Ich bekomme auch Fehler im Log, wenn ich "nur" den Adapter manuell über den Admin stoppe.

Und das nicht nur wenn der Adapter nur kurz läuft (dann hätte man ja vermuten können er ist mit den setObject's noch beschäftigt), sondern auch nach längerer Laufzeit

[AlCalzone]

@SchuetzeSchulz:

Ich bekomme auch Fehler im Log `
Wenn du sie postest, kann man eventuell helfen

[SchuetzeSchulz]

Sind die gleichen wie oben.

Quasi keine wirklich Fehler aber halt rot

[Bluefox]

Eigentlich so ein Parameter sollte nicht als Object, sondern als State existieren.

Einfach in ip-package.json

ein State definieren (z.B. "info.initialized", wie hier https://github.com/ioBroker/ioBroker.mi … e.json#L99 )

Und im Adapter dann nach der Initialization auf true setzen.

Beim Start dann prüfen ob "info.initialized" true ist.

{
            "_id": "info.initialized",
            "type": "state",
            "common": {
                "role": "indicator.initialized",
                "name": "If all information was read from Gateway",
                "type": "boolean",
                "read": true,
                "write": true,
                "def": false
            },
            "native": {}
        }

Man muss nur dann den Adapter uploaden und neue Instanz anlegen, dann wird die Variable "info.initialized" automatisch erzeugt.

[apollon77]

Dann geht es aber nicht per Admin zu setzen. Er will den gleichen Mechanismus wir „one time sync“ im hm-Rpc

[SchuetzeSchulz]

@apollon77:

Dann geht es aber nicht per Admin zu setzen. Er will den gleichen Mechanismus wir „one time sync“ im hm-Rpc `

Genau und das geht meines Wissens mit Bluefox' gepostetem Lösungsvorschlag nicht, oder?

[AlCalzone]

@apollon77:

Dann geht es aber nicht per Admin zu setzen. `
Ich bin mir nicht 100% sicher, was der Socket im Admin-Interface alles zulässt, aber eventuell per

socket.emit("setState", stateID, value, callback);

[Bluefox]

@AlCalzone:

@apollon77:

Dann geht es aber nicht per Admin zu setzen. `
Ich bin mir nicht 100% sicher, was der Socket im Admin-Interface alles zulässt, aber eventuell per

socket.emit("setState", stateID, value, callback);

```` `  

Das geht

[SchuetzeSchulz]

Darf ich fragen, was das socket.emit bewirkt?

Soll ich das statt setForeignObject nutzen?

[apollon77]

@Bluefox: Warum kann er es nicht so machen wie auch hm-rpc … bzw warum tut es nicht?

[AlCalzone]

@SchuetzeSchulz:

Darf ich fragen, was das socket.emit bewirkt?

Soll ich das statt setForeignObject nutzen? `
Das ist eine Möglichkeit, aus der Admin-Oberfläche bestimmte Adapterfunktionen aufzurufen - mit leicht anderer Syntax.

Ich glaube aber dass bei dem was du vor hast (1x Sync aus Admin anstoßen?) die ursprüngliche Lösung einfacher ist - wenn du denn das Timing des Adapter-Neustarts auf die Reihe bekommst.