[gelöst] Zweite javascript Instanz

[Goersch]

Kann das evtl. mit meiner Multihost Einstellung zusammenhängen? Derzeit ist der Neben-Raspi so eingestellt (Haupt Raspi=192.168.20.3)

` > Type of objects DB [(f)ile, ouch, (r)edis], default [file]:

Host of objects DB(file), default[127.0.0.1]: 192.168.20.3

Port of objects DB(file), default[9001]:

Type of states DB [(f)file, (r)edis], default [file]: r

Host of states DB (redis), default[127.0.0.1]: 192.168.20.3

Port of states DB (redis), default[9000]: 6379

Host name of this machine [iobroker2]: `

Muss ich die Einstellungen der object db auch auf redis setzen? Wenn ja: auf welchen Port? Auch auf 6379?

Georg

[eric2905]

Moin,

Du arbeitest mit Redis - zumindest hast Du die Konfiguration so angegeben.
@Goersch:

Type of states DB [(f)file, (r)edis], default [file]: r

Host of states DB (redis), default[127.0.0.1]: 192.168.20.3 `

Hast Du auf dem Master den Redis-Zugriff auch freigegeben?

Ohne dem läuft da nix im Multihost-Betrieb.

Gruß,

Eric

[Goersch]

ja, das funktioniert - ein setState funktioniert und die Verbindung zwischen Haupt und Neben Raspi ist Ok. Es laufen bereits mehrere Instanzen (Cloud, ping, ical) Problemlos auf dem Neben-Raspi. Nur das getState des javascript adapters macht ärger

[Goersch]

ich hab die config des Neben-Raspi mal geändert:

` > Type of objects DB [(f)ile, ouch, (r)edis], default [file]: r

Host of objects DB(file), default[127.0.0.1]: 192.168.20.3

Port of objects DB(file), default[9001]: 6379

Type of states DB [(f)file, (r)edis], default [file]: r

Host of states DB (redis), default[127.0.0.1]: 192.168.20.3

Port of states DB (redis), default[9000]: 6379

Host name of this machine [iobroker2]: `

So leider keine Verbindung zwischen Haupt und Neben-Raspi.

[Homoran]

Nicht die objects ändern!

sondern die redis-config auf dem Master:

http://www.iobroker.net/?page_id=3068&l … _mit_redis

Gruß

Rainer

[Goersch]

ist geändert - die verbindung zu redis steht 8-)

siehe auch hier am Ende des Threads.

http://forum.iobroker.net/viewtopic.php?f=17&t=365

Ich stocher gerade im Nebel rum und find das Problem nicht.

[apollon77]

Also das Asynchrone sollte so gehen (aber siehe auch Anmerkungen im anderen Thread!)

getState(id, function(err, state) { 
  var status = state.val;
  ...
});

[Goersch]

damit läuft es - zumindestens komme ich an den State des Objects ran.

Nur hilft mir das leider auch nicht weiter, da der call async läuft. Bei der Abfrage eines States wäre das noch OK und man könnte den Rest der Logik in den asynchronen Callback legen - nur brauch ich natürlich mehrere getStates, womit es etwas schwierig wird

8-) mal abgesehen davon, dass es nicht schön ist, wenn man in der Instanz auf dem Neben-Raspi die Zugriffe anders Programmieren muss.

[apollon77]

Ich persönlcih gehe immer so vor das ich mir alle State-Werte quasi als Lokale Variablen hole. Damit entkoppelst Du das holen der Werte und die Skript-Logik.

Also quasi per "on(id…) jeden State dem man im Skript brauchst einer variable zuweisen bzw damit aktuell halten. Und dann das Skript in eine Funktion die dann von mehreren Stellen oder direkt in den "on" aufgerufen wird, was dann die lokalen Skript-Variablen benutzt

Dann entfällt das "getState" kram immer wieder zu machen

[paul53]

@apollon77:

Ich persönlcih gehe immer so vor das ich mir alle State-Werte quasi als Lokale Variablen hole. Damit entkoppelst Du das holen der Werte und die Skript-Logik. `
Genau so halte ich es auch. Damit vermeidet man auch unnötige Aufrufe der komplexen Funktion getState(id). Prinzip:

// ID als String eingeben oder mittels getIdByName('name') ermitteln.
var id1 = '...';
var id2 = '...';
...

// getState für den Skriptstart, falls erforderlich
var v1 = getState(id1).val;
var v2 = getState(id2).val;
...

function auswertung() {
    Hier werden v1, v2, ... ausgewertet;
}

auswertung();  // Skriptstart

on(id1, function(dp) {  // Änderung des Wertes von id1
    v1 = dp.state.val;
    auswertung();
});
on(id2, function(dp) {
    v2 = dp.state.val;
    auswertung();
});
...

[Goersch]

das geht sicherlich prinzipiell - funktioniert aber nicht, wenn man die ids zur Laufzeit erst zusammenbaut (bzw. wie in meinem Fall den Zugriff auf die Homematic Geräte via getIdByName macht und den Namen des Gerätes zur Laufzeit zusammenbaut).

Ich habe es häufig, dass ich einer Funktion z.B. den Raumnamen übergebe und die Funktion dann die ids selber zusammenbaut, um das setState/getState zu machen. Das ersparrt mir jede Menge gleichen Code, der sich nur durch die ids unterscheiden würde (bzw. wenn ich es so machen würde wie ihr, durch die unterschiedliche Verwendung von Variablen unterscheiden würde).

[apollon77]

Dann hast Du recht … und musst aber ggf mit dem asynchronen leben ... that's JavaScript ;-(

[Goersch]

8-) hab ich befürchtet

[Goersch]

mh, ich könnt mir ja auch ein array anlegen, in das die Werte geschrieben werden

var values = [];
on(....., function(obj) {values[obj.common.name] = obj.state.val;....

Dann könnte ich weitermachen wie bisher und müsste das getState nur durch ein value[name] ersetzen (und natürlich für jedes zu lesende Objekt ein on(…) programmieren).

Muss ich mal drüber nachdenken tun :geek:

[Goersch]

8-) mal ganz abgesehen davon, dass mir nicht wirklich klar ist, warum ein getState auf dem neben-Raspi nicht funktioniert oder nicht funktionieren könnte, ohne dass ich die callbacks nutzen muss.

Aber das kann an meinem wenig vorhandenen javascript wissen liegen….

[Bluefox]

@Goersch:

8-) mal ganz abgesehen davon, dass mir nicht wirklich klar ist, warum ein getState auf dem neben-Raspi nicht funktioniert oder nicht funktionieren könnte, ohne dass ich die callbacks nutzen muss.

Aber das kann an meinem wenig vorhandenen javascript wissen liegen…. `
Wie sieht es bei dir aus?

Nicht auf alle Zustände beim Start abonnieren: - AN oder AUS?

[Goersch]

mh, unterschiedlich

Haupt-Raspi AUS

Neben-Rasp EIN

Also bei der Instanz, wo das Problem besteht, ist die Option eingeschaltet

[apollon77]

Dann schalte das auf dem Neben-Raspi mal auch aus … gehts dann wieder ohne asynchron?

[Goersch]

wie nicht anders zu erwarten: das getState funzt jetzt ohne irgendwelche beschwerden

Danke, bluefox + apollon77