UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[haus-automatisierung]

@ben1983 Wenn Du den Support übernimmst, mache ich das gleich 😉

[Ben1983]

@haus-automatisierung :-D is klar ;-)

[haus-automatisierung]

@ben1983 sagte in [gelöst] Javascript-adapter ruft on ereignis doppelt auf:

@haus-automatisierung wann wird die Version im stable sein?

Heute freigegeben.

[Ben1983]

@haus-automatisierung Habe nun folgendes szenario:

shelly 2.5:
switch wird beschrieben mit true;
ich frage mit folgendem code ab, ob der shelly bestätigt hat:

on({id:IdFrischwasserstellmotor, ack:true},(dp) =>{
    if(dp.state.val)
    {...}
}

wird nun allerdings der wert des shelly.switch wieder auf true gesetzt,
so wird die Bestätigung (ACK) erst nach der in der Konfig eingestellten Abfragezeit gemeldet.
Ist das wirklich so gewollt?
Warum meldet der Adapter nicht direkt mit ack = true zurück?

Ich hoffe es war verständlich.

[haus-automatisierung]

@ben1983 sagte in [gelöst] Javascript-adapter ruft on ereignis doppelt auf:

Warum meldet der Adapter nicht direkt mit ack = true zurück?

Weil Du als Fehler gemeldet hattest, dass Du das nicht möchtest. Ich hatte alles sofort bestätigt, wenn ein Wert geändert wurde. Jetzt wird der erst bestätigt, wenn er vom Gerät kommt.

Ich würde Dich (erneut) bitten komplette Scripts zu zeigen und nicht nur Ausschnitte. Also inklusive Ansteuerung und was in IdFrischwasserstellmotor steht.

Generell meldet der Shelly eigentlich die meisten Werte über MQTT und CoAP sofort zurück. Nur wenn etwas über HTTP abgerufen werden muss (weil es nicht per Event gesendet wird), kommt es zu der Verzögerung. Aber ohne Infos zu den genauen Datenpunkten usw. kann ich das natürlich nur raten.

Antwort: Es kommt drauf an.

[Ben1983]

@haus-automatisierung Nein, ichhatte gemeldet, dass er bei einmal wert setzen diesen 2 mal mit ack=true zurück gemeldet hat.
Er soll es ja direkt setzen, aber eben nur einmal mit true und nicht doppelt.

Das ist das komplette script:

// Auswahl der Wasserquelle
function chooseWaterSource()
{
    // Check states for logging
    if((frischwasseranforderungZeit.val || frischwasseranforderungManuell.val || schwimmerschalter.val) && !_bypassZisterne.val)
    {
        SendTelegramMessage("Frischwasserbezug aktivieren",usernamePrivat);
        clearStateDelayed(IdZisternenstellmotor);
        clearStateDelayed(IdFrischwasserstellmotor);
        setState(IdZisternenstellmotor,true);
    }
    else
    {
        SendTelegramMessage("Zisternenwasserbezug aktivieren",usernamePrivat);
        clearStateDelayed(IdZisternenstellmotor)
        clearStateDelayed(IdFrischwasserstellmotor);
        setState(IdFrischwasserstellmotor,false);
    }
}

on({id:IdZisternenstellmotor, ack:true}, (dp) =>{
    if(dp.state.val)
    {
        // Ausgabe des aktuellen States
        SendTelegramMessage("Zisternenstellmotor schließen",usernamePrivat);

        // Nachfolgend Frischwasserstellmotor öffnen
        setStateDelayed(IdFrischwasserstellmotor,true,verfahrzeitZisternenstellmotor.val * 1000);
    }
    else
    {
        SendTelegramMessage("Zisternenstellmotor öffnen",usernamePrivat);
    }
});

on({id:IdFrischwasserstellmotor, ack:true},(dp) =>{
    if(dp.state.val)
    {
        SendTelegramMessage("Frischwasserstellmotor öffnen",usernamePrivat);
    }
    else
    {
        // Ausgabe des aktuellen States
        SendTelegramMessage("Frischwasserstellmotor schließen",usernamePrivat);

        // Nachfolgend den Zisternenstellmotor öffnen
        setStateDelayed(IdZisternenstellmotor,false,verfahrzeitFrischwasserstellmotor.val * 1000);
    }
});

Zur erklärung, frischwasseranforderung Zeit wird durch eine shedule gesetzt.
Man kann es aber auch per Hand setzen. (FrischwasseranforderungManuell).
Wenn dies nun kurz hintereinander kommt, dann kommt es zu diesen überschneidungen.

Ich habe nie behauptet, dass die Werte nicht direkt geschrieben werden sollen, das sollen sie ja sehrwohl,
aber sie wurden ja wie gesagt bei Änderung doppelt geschrieben und die beide male mit ack=true
Das war das eigentliche Problem.
So finde ich es aktuell etwas unvorteilhaft, da man die änderung erst nach x sekunden mit bekommt.

Ps. In IdFrischwasserstellmotor / IdZisternenstellmotor stehen die Ids zu den shelly.switch states drin.

Also weißt Du was mein erstes Problem war?

EDIT:
Ich schalte quasi einen switch state eines shellys und reagiere dann darauf, wenn der shelly dies zurück meldet.
Wenn währenddessen etwas anderes angestoßend wird und dann der shelly erstverspätet zurückmeldet, dann gibt es durcheinander

[Ben1983]

@haus-automatisierung sagte in [gelöst] Javascript-adapter ruft on ereignis doppelt auf:

@ben1983 sagte in Javascript-adapter ruft on ereignis doppelt auf:

Alle auf der neuesten Firmware: Datenpunkt "Relais0.switch" "Relais1".switch (Wobei ich andere jetzt nicht abfrage)

Fehler gefunden. Problem war, dass die Änderung einmal bestätigt wurde, wenn der Wert geändert wurde und zum Gerät geschickt wird. Zusätzlich antwortet das Gerät dann aber direkt über CoAP oder MQTT direkt mit dem neuen Wert. Was wiederum zu einem Event mit ack geführt hat.

Ist in 5.3.1 behoben.

Hier hast Du es doch selbst geschrieben.
Dachte Du bestätigst es jetzt wenigstens einmal.
Jetzt wird es ja gar nicht bestätigt, sondern nur nach der Zeit x... denke aber ein Schreiben des switchs (Ob Änderung oder nicht), sollte direkt bestätigt werden, aber eben nur einmal

Edit: Bei Änderung von true auf false,oder false auf true, bestätigt der shelly adapter dies sofort.
Nur wenn der Wert schon passend steht, dann bestätigt er erst nach einer Zeit x.
Das wäre doch schön, wenn das auch direkt passieren würde. dann wäre es einheitlich

[Ben1983]

@haus-automatisierung Habe es jetzt geändert und so gelöst.
Da wird halt nicht auf die Rückmeldung des shellys geachtet.

// Auswahl der Wasserquelle
function chooseWaterSource()
{
    // Check states for logging
    if((frischwasseranforderungZeit.val || frischwasseranforderungManuell.val || schwimmerschalter.val) && !_bypassZisterne.val)
    {
        SendTelegramMessage("Frischwasserbezug aktivieren",usernamePrivat);
        clearStateDelayed(IdZisternenstellmotor);
        clearStateDelayed(IdFrischwasserstellmotor);
        // Zisternenstellmotor schließen
        setState(IdZisternenstellmotor,true);
        // Nachfolgend Frischwasserstellmotor öffnen
        setStateDelayed(IdFrischwasserstellmotor,true,verfahrzeitZisternenstellmotor.val * 1000);
    }
    else
    {
        SendTelegramMessage("Zisternenwasserbezug aktivieren",usernamePrivat);
        clearStateDelayed(IdZisternenstellmotor)
        clearStateDelayed(IdFrischwasserstellmotor);
        // Frischeasserstellmotor schließen
        setState(IdFrischwasserstellmotor,false);
        // Nachfolgend den Zisternenstellmotor öffnen
        setStateDelayed(IdZisternenstellmotor,false,verfahrzeitFrischwasserstellmotor.val * 1000);        
    }
}

/*****************************************************************************************
 * ****************************************States*****************************************
 * ************************************************************************************ */

on(IdZisternenstellmotor, (dp) =>{
    // Ausgabe des aktuellen States
    if(dp.state.val)
    {
        SendTelegramMessage("Zisternenstellmotor schließen",usernamePrivat);
    }
    else
    {
        SendTelegramMessage("Zisternenstellmotor öffnen",usernamePrivat);
    }
});

on(IdFrischwasserstellmotor,(dp) =>{
    // Ausgabe des aktuellen States
    if(dp.state.val)
    {
        SendTelegramMessage("Frischwasserstellmotor öffnen",usernamePrivat);
    }
    else
    {
        SendTelegramMessage("Frischwasserstellmotor schließen",usernamePrivat);
    }
});

Aber ich denke es sollte schon direkt zurück gemeldet werden mit ack= true, wenn der Wert geschrieben wird.
Nur dann eben nicht mehr durch CoAP oder MQTT ein zweites mal.

Was denkst Du?

[AlCalzone]

@ben1983 sagte in [gelöst] Javascript-adapter ruft on ereignis doppelt auf:

Aber ich denke es sollte schon direkt zurück gemeldet werden mit ack= true, wenn der Wert geschrieben wird.

Hängt natürlich von den Geräten ab, aber bei Z-Wave mach ich das z.B. nicht. ack=true gibts da erst wenn vom Gerät die Änderung bestätigt wurde. Ansonsten kann man anhand des States ja gar nicht sehen ob es geklappt hat oder nicht.

[Ben1983]

@alcalzone Ja klar, aber das gerät (shelly relais) meldet ja auch nicht 15s später erst zurück, dass es das relais angeschaltet hat. Es soll mir einfach zurückmelden, wenn es geklappt hat und nicht irgendwie zeitlich gesteuert.
Das ist aber aktuell nicht der fall. (Nur bei änderung des zustands. (ist dieser schon so aktiv, dann kommt die Meldung zeit gesteuert und ich denke das ist nicht ok, oder?

[AlCalzone]

Da würde ich dir zustimmen.

[Ben1983]

@alcalzone Danke.
@haus-automatisierung Was sagst Du dazu?

[haus-automatisierung]

@ben1983 sagte in [gelöst] Javascript-adapter ruft on ereignis doppelt auf:

Das ist aber aktuell nicht der fall. (Nur bei änderung des zustands. (ist dieser schon so aktiv, dann kommt die Meldung zeit gesteuert und ich denke das ist nicht ok, oder?

Was hast Du denn in den Instanz-Einstellungen konfiguriert? Dort kann man festlegen, ob gleiche Werte auch eine Aktualisierung triggern sollen. Siehe

https://github.com/iobroker-community-adapters/ioBroker.shelly/blob/v5.3.2/docs/de/state-changes.md

[Ben1983]

@haus-automatisierung aktuell ist es so eingestellt:

Setze ich den Haken ganz unten, dann bekomme ich alle 15s ein Ereignis, obwohl nichts passiert ist.

Der Gedanke war ja so, dass wenn auf den Switch geschrieben wird, dieser auf jeden Fall zurück gemeldet wird mit ack =true, wenn das Gerät dies übernommen hat, aber nicht generell alle x Sekunden.

Es war ja vorher schon alles soweit ok, nur wurde ja wie gesagt eine Änderung immer doppelt mit ack=true bestätigt.

[haus-automatisierung]

@ben1983 sagte in [gelöst] Javascript-adapter ruft on ereignis doppelt auf:

Es war ja vorher schon alles soweit ok, nur wurde ja wie gesagt eine Änderung immer doppelt mit ack=true bestätigt.

Bei welchem Datenpunkt passiert das denn genau? Nach deinem Script oben weiß ich ja immernoch nicht was in IdFrischwasserstellmotor für eine ID steht.

Nur einige Informationen werden alle x Sekunden per HTTP abgefragt. Die kritischen Sachen werden eigentlich sofort per CoAP oder MQTT vom Gerät zurückgemeldet (wie schon geschrieben).

Bitte mach mal einen GitHub Issue auf mit einer genauen Beschreibung zum Gerät und einem kleinen Beispiel-Script, welches das Problem mit Logs darstellt.

[paul53]

@haus-automatisierung sagte: Beispiel-Script, welches das Problem mit Logs darstellt.

@Ben1983 Ersetze bitte in diesem Skript die Variable IdFrischwasserstellmotor durch die echte ID.

[Ben1983]

@paul53 @haus-automatisierung ich mache ein issu.
Nur soviel:

das hier:

on({id:"shelly.0.SHSW-25#C45BBE612F7A#1.Relay0.Switch", ack:true}, (dp) =>{
    log("shelly.switch.val = " + dp.state.val);
    log("shelly.switch.ack = " + dp.state.ack);
});

und die einstellung:

führen zu dem Log:

16:59:41.594	info	javascript.0 (6947) script.js.common.Zisterne: shelly.switch.val = true
16:59:41.594	info	javascript.0 (6947) script.js.common.Zisterne: shelly.switch.ack = true
16:59:56.595	info	javascript.0 (6947) script.js.common.Zisterne: shelly.switch.val = true
16:59:56.595	info	javascript.0 (6947) script.js.common.Zisterne: shelly.switch.ack = true
17:00:07.615	info	javascript.0 (6947) script.js.common.Zisterne: shelly.switch.val = true
17:00:07.616	info	javascript.0 (6947) script.js.common.Zisterne: shelly.switch.ack = true

Konnte ich bei shelly 2 & 2.5 nachstellen,
beim 1er nicht

[Ben1983]

@haus-automatisierung
Hier:

on({id:"shelly.0.SHSW-25#C45BBE612F7A#1.Relay0.Switch", ack:true}, (dp) =>{
    log("shelly.switch.val = " + dp.state.val);
    log("shelly.switch.ack = " + dp.state.ack);
});

würde ich also bei jedem Beschreiben des States EINE Bestätigung direkt danach erwarten.

Und hier

on("shelly.0.SHSW-25#C45BBE612F7A#1.Relay0.Switch", (dp) =>{
    log("shelly.switch.val = " + dp.state.val);
    log("shelly.switch.ack = " + dp.state.ack);
});

Würde ich nur eine Bestätigung erwarten, wenn wirklich eine Wertänderung des switch.val vorliegt.

[Ben1983]

@haus-automatisierung Ist der issue soweit ok und verständlich?

[Ben1983]

@alcalzone ist es generell so, dass:

on(„insstanz.0.xyz“,dosomething);

Nur bei Änderung des val den callback aufruft und:

on({id:“Instanz.0.xyz“},dosomething);

Bei jeder Änderung aufgerufen wird?
Also auch bei ack Änderung ohne dass sich der val ändert?
Ich meine das hätte ich mal so beobachtet.