Checkbox in Adaperkonfiguration deaktivieren

[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.