Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[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 :D

Danke, bluefox + apollon77 :)