Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Ben1983]

@ticaki OK, gibts dazu schon ein issue?

[ticaki]

@ben1983
Hab nicht nachgesehen.

[Asgothian]

@ben1983 sagte in Wann ist ein nach der Erzeugung dp verfügbar?:

Hallo, ich habe folgende Logik:

on(TrigerId,async(dp)=>{
    await extendObject(DestinationId, {type:'state', common:{name:'Gerät ist zu Hause', type:'boolean', def: false}});
    // Aktuellen Zustand auslesen
    const actState= getState(DestinationId).val;
}

nun verursacht dies aber ein actState = null

Erzeuge ich den state mit extendObject beim Scriptstart (nur zum Testen), so funktioniert es.
Ich dachte, dass das await dafür sorgt, dass entsprechend lange gewartet wird.

Natürlich tut es das. Du hast zwar den State angelegt, aber der Wert des State wurde nicht gesetzt. Den holst Du dir aber. Zusätzlich rufst du die 'callback' Variante der Funktion extendObject auf, ohne eine callback Funktion beizulegen. Die dafür vorgesehene Funktion ist (meines Wissens nach) aber extendObjectAsync.

Prüfe mal bitte den folgenden Code:

on(TrigerId,async(dp)=>{
     await extendObjectAsync(DestinationId, {type:'state', common:{name:'Gerät ist zu Hause', type:'boolean', def: false}});
     // Aktuellen Zustand auslesen
     const actState= getState(DestinationId);
 }

[ticaki]

@asgothian sagte in Wann ist ein nach der Erzeugung dp verfügbar?:

await extendObjectAsync(DestinationId, {type:'state', common:{name:'Gerät ist zu Hause', type:'boolean', def: false}});
// Aktuellen Zustand auslesen
const actState= getState(DestinationId);

Ändert nix, der state existiert noch nicht im Javascript-Adapter, wenn getState() ausgeführt wird. Aber das async fehlt natürlich trotzdem.

Mit const actState= await getStateAsync(DestinationId);geht auch die abfrage auf den State.

[Asgothian]

@ticaki sagte in Wann ist ein nach der Erzeugung dp verfügbar?:

@asgothian sagte in Wann ist ein nach der Erzeugung dp verfügbar?:

await extendObjectAsync(DestinationId, {type:'state', common:{name:'Gerät ist zu Hause', type:'boolean', def: false}});
// Aktuellen Zustand auslesen
const actState= getState(DestinationId);

Ändert nix, der state existiert noch nicht im Javascript-Adapter, wenn getState() ausgeführt wird. Aber das async fehlt natürlich trotzdem.

Mit const actState= await getStateAsync(DestinationId);geht auch die abfrage auf den State.

Interessant. Mein System scheint da schneller zu sein - der Code den ich gepostet hab geht bei mir direkt durch - ohne Probleme :)

[ticaki]

@asgothian
Eh ich habe gerade geupgraded.. also nix da :D

Kann halt nur schreiben was passiert ist. Aber ein sleep hinter einem extend macht das ganze eh viel entspannter.

[Ben1983]

@ticaki bei mir geht es auch damit nicht (Hatte ich schon vor erstellen dieses Threads gecheckt.)
Und extendObjectAsync sollte soweit mit bekannt in extendObject drin sein, wenn dies nicht als Callback benutzt wird.

[mcm1957]

@ben1983 said in Wann ist ein nach der Erzeugung dp verfügbar?:

@ticaki bei mir geht es auch damit nicht (Hatte ich schon vor erstellen dieses Threads gecheckt.)
Und extendObjectAsync sollte soweit mit bekannt in extendObject drin sein, wenn dies nicht als Callback benutzt wird.

Nur wenn du aktuellen js-controlelr einsetzt.
https://github.com/ioBroker/ioBroker.js-controller/blob/master/CHANGELOG.md#704-2024-12-04---lucy
Kann gut sein, dass setObject zu extendObject durchschlägt

[OliverIO]

@ben1983
Und wo wird der State geschrieben oder der default Wert des Objekts gesetzt?
Welcher Wert würde erwartet werden?

Bin mir zwar nicht sicher, aber ein Objekt muss nicht zwangsläufig auch gleich einen State haben

[Ben1983]

@mcm1957 setze 7.0.6 ein ;-)

[mcm1957]

@ben1983
Hoffe deine User auch :-)
Ansonsten solltest du ggF die dependencies des js-controllers checken / anpassen.

[ticaki]

@ben1983
@mcm1957

Ich glaube das ist leichter zu begründen, will jetzt aber nicht den Eindruck erwecken als wenn ich den Javascript-Adapter-Code durchschaut hätte. :)

create/set/extendWasauchimmerAsyncerzeugt im js-controller einen State/Object und wartet bis er angelegt ist. Jedoch hat der Javascript-Adapter einen Cache. Ein darauf folgenden getState() wird aus dem Cache gezogen und wenn der subscriber noch nicht durch ist, gibts ihn halt noch nicht.

Dazu kommt dann noch das die ...Async sich anders verhält als im Adapter - ohne Async wird nicht gewartet. https://github.com/ioBroker/ioBroker.javascript/blob/7778007eb9304658aed10f4a975de91864ad26bc/lib/sandbox.js#L4403

[Ben1983]

@mcm1957 Das hier ist ein eigenes Skript im Javascript Adapter, kein Eigener Adapter

[mcm1957]

@ben1983

OK - Für Javascript im Javascript Adapter gelten tw. andere Regeln.

Wenn Unetrscheide allerdings eher verwirrend sind und aufwärtskompatibel anpassbar scheinen dann macht es ev. durchaus Sinn ein Issue zu erstellen. Bluefox migriert den Javascritp adapter meines Wissens nach z,Z zu Typescript. Da kann man ggF kompatible (!) Anpassungen durchaus vornehmen.

Aber das müssen die Maintainer entscheiden.