ioBroker.fritzdect
ioBroker.fritzdect copied to clipboard
foxthefox
Werte bei Aktualisieren überschrieben
Wenn man die Aktualisierung aus 2s stehen hat und man eine dect Steckdose ein schaltet, so bekommt man folgende Änderungen: Ein, Aus, Ein
ich denke durch die Aktualisierungsrate wird hier wiedererwachen überschrieben. Ist hier etwas bekannt? Heute Morgen hattet er bei einer Steckdose sogar nur Ein Aus Geschaltet, also den Wert dann nicht korrekt übernommen.
ist bei Steckdosen überhaupt die Aktualisierungsrate notwenig, oder wenden hier Zustand und Leistung / Energy sowieso bei Änderung aktualisiert?
Edit: Habe die Aktualisierungsrate auch schon hoch gesetzt, leider macht er das immer noch. Schreibt immer den aktuellen Wert, dann kurz den alten und dann wieder den aktualisierten.
mit so kurzen Aktualisierungszyklen hat wahrscheinlich noch keiner experimentiert. Was der Adapter macht:
- er schickt den Befehl an die FB
- das Versenden ist erfolgreich und es wird dann dann noch mal mit Bestätigung der Wert gesetzt
- ob das ganze dann schon an die Steckdose weitergeschickt wurde ist damit nicht sichergestellt, da dies ein unabhängiger asynchroner Prozeß der FB mit DECT ist
Somit kann es sein, daß man genau nach einem Befehl noch die nicht relaisierte Weitergabe ausliest
Ok, was würdet ihr als Aktualisierungsrate empfehlen? Ich habe lediglich Fritz Steckdosen? Hat die Aktualisierungsrate Einfluss auf die Leistungswerte? Also werden die bei einer 60s Aktualisierungsrate auch bei Änderung nur alle 60s abgeholt?
ps. Warum bekomme i h denn aber trotzdem immer den alten Status zurück und danach den aktualisierten? Könnte man das nicht irgendwie abfangen, dass sich Fernfahrer merkt, fassen gerade true gesendet hat und somit den nächste. Zyklus genau dieses states ignoriert?
Wie sieht es hier aus? Ich habe eine schedule: `schedule({hour: 9, minute: 30,},aktiviereStart);
// Aufruf erfolgt direkt aus der schedule
function aktiviereStart()
{
if(getState(idWaermepumpeAutomatik).val && !getState(idFreigabeWaermepumpe).val)
{
setState(idFreigabeWaermepumpe,true);
sendTelegramMessage("Freigabe Wärmepumpe wurde aufgrund der maximalen Einschaltzeit eingeschaltet.",usernamePrivat.val);
}
}`
dann gibt es diese on funktion: `on(idFreigabeWaermepumpe,()=>{ waermepumpenfreigabeZuModbus(); });
// Dient zur Modbus Meldung und dem Logging, wenn geschaltet wurde (auch extern)
function waermepumpenfreigabeZuModbus()
{
if(getState(idFreigabeWaermepumpe).val)
{
setState(idFreigabeWaermepumpeModbus,1);
sendTelegramMessage("Freigabe Wärmepumpe ein.",addActiveTelegramUsername(usernamePrivat.val));
setTelegramUserToPrivate();
}
else
{
setState(idFreigabeWaermepumpeModbus,0);
sendTelegramMessage("Freigabe Wärmepumpe aus.",addActiveTelegramUsername(usernamePrivat.val));
setTelegramUserToPrivate();
}
}`
Wenn die Schedule nun den Wert setzt, dann wurde heute Morgen die on funktion wieder zwei mal aufgerufen, das erste mal mit true, was aus der schedule heraus gesetzt wurde und dann nochmals mit false. (Die Steckdose blieb also aus..... WARUM?
nur noch mal als Tipp, in iobroker wird zwischen Kommandos und Rückmeldungen unterschieden. ACK=false ist ein Kommando ACK=true ist eine Rückmeldung
Ok, was würdet ihr als Aktualisierungsrate empfehlen? Ich habe lediglich Fritz Steckdosen? Hat die Aktualisierungsrate Einfluss auf die Leistungswerte? Also werden die bei einer 60s Aktualisierungsrate auch bei Änderung nur alle 60s abgeholt?
Die Aktualisierungsrate hat keinen EInfluß auf die Leistungswerte. Es wird nachgefragt, was die FB an Werten hat und das kommt per Telegramm zu iob. Wie lang es her ist, daß der Wert an die FB übermittelt wurde, kann man nicht ermitteln. Ebenso lässt sich der interne DECT Übertragungsalgorithmus nicht beeinflussen. Beim Thermostat gibt es bis zu 15min Totzeiten, je nachdem wann der letzte Zyklus stattfand.
Also ich habe das jetzt nochmal analysiert.
Setze eine ausgeschaltete Steckdose auf true.
Die Rückmeldung fange ich dann so ab:
on(idDerSteckdose,(dp)=>{ log("freigabe: val: " + dp.state.val + " ; ack: " + dp.state.ack); });
Es kommt dass folgender Log heraus:
10:26:30.528 | info | javascript.0 (141) script.js.Garten.Pool.Filterpumpe: freigabe: val: true ; ack: false
10:26:31.184` | info | javascript.0 (141) script.js.Garten.Pool.Filterpumpe: freigabe: val: false ; ack: true
10:26:32.929 | info | javascript.0 (141) script.js.Garten.Pool.Filterpumpe: freigabe: val: true ; ack: true
Er bestätigt also nochmal mit dem alten Wert, bevor der neue Wert mit ack = true bestätigt wird.
EDIT: Dies konnte ich nun mit hoch setzen der Aktualisierungsrate umgehen, was allerdings dazu führt, dass die Leistung auch sehr verzögert ankommt. Geht also nicht, kann ja nicht sein, dass die Steckdose ausschaltet und noch 300s oder so die Leistung genau so anstehen bleibt.
Wie hoch ist derzeitig das Abfrageintervall? Ich schau es mir nochmal im Adapter an.
Edit: Wenn 10:26:30.528 der Befehl abgesetzt wurde, dann ist es mit 2,4s recht lang mit der Rückmeldung. Bei mir ist zwischen Befehl erkennen und erfolgreich FB verschicken ca. 250ms bis 400ms. Also die Rückmeldung aus dem Adapter, nach erfolgreichen Verschicken des Befehls, müsste wesentlich früher da sein.
Eventuell hilft auch mal den Adapter in debug modus zu versetzen, dann hat jeder Befehl folgende Zeilen:
- state fritzdect."ID" changed: "Wert" (ack = false)
- ack is not set! -> command
- Turned switch "ID" "Wert" -> erfolgreiches Verschicken des Befehls
- state fritzdect."ID" changed: "Wert" (ack = true) -> Wert nach erfolgreichen Befehl verschicken, setzen
2022-06-19 15:29:19.346 - debug: fritzdect.1 (6316) state fritzdect.1.DECT_087610006102.state changed: true (ack = false)
--
2022-06-19 15:29:19.347 - debug: fritzdect.1 (6316) ack is not set! -> command
2022-06-19 15:29:19.347 - info: fritzdect.1 (6316) DECT ID: 087610006102 identified for command (state) : true
2022-06-19 15:29:19.720 - debug: fritzdect.1 (6316) Turned switch 087610006102 on
2022-06-19 15:29:19.722 - debug: fritzdect.1 (6316) state fritzdect.1.DECT_087610006102.state changed: true (ack = true)
diesen Test hatte ich mit der Einstellung 2s gemacht. habe die Zeit nun auf 15s hoch gesetzt. ich logge gleich nochmal das ergebnis mit und ohne ack.
Vom Adapter her werden Datenpunkte auch nicht mit ack=false geschrieben. in der gleichen ms kann die Bestätigung des Befehls nicht kommen. Welche Differenz zwischen debug des fritzdect und des javascript gibt es denn?
Sorry, hatte oben den Falschen Datenpunkt geloggt. (Der war vom Schalter) Versuche es gleich nochmal.
Hier der Code:
Habe einmal ein und einmal aus geschaltet.
on(idFreigabeFilterpumpe,(dp)=>{
log(`change -- val: ${dp.state.val} -- ack: false`);
});
on({id:idFreigabeFilterpumpe, ack:false},(dp)=>{
log(`val: ${dp.state.val} -- ack: false`);
});
on({id:idFreigabeFilterpumpe, ack:true},(dp)=>{
log(`val: ${dp.state.val} -- ack: true`);
});
Hier der Ergebnis log:
16:58:44.807 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: change -- val: true -- ack: false
16:58:44.807 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: val: true -- ack: false
16:58:45.082 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: val: true -- ack: true
16:58:49.207 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: val: true -- ack: true
16:58:49.211 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: val: true -- ack: true
16:58:51.423 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: change -- val: false -- ack: false
16:58:51.424 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: val: false -- ack: false
16:58:51.699 | info | javascript.0 (141) script.js.XXX_Testskripte.AAAA: val: false -- ack: true
Stelle ich nun von 15s auf 2s dann kommt der change pro schaltvorgang 3 mal. Bspw. kommt er jetzt bei 15s eben nur einmal bei an => val = true bei 2s kommt er true, false, true
Ich hab im Adapter noch nichts gefunden, was ein erneutes (wiederholtes) Setzen des Status auslöst.
16:58:44.807 Kommando und setzen des Zustands um 16:58:45.082 ist plausibel und passt für mein Verständnis. das nachgetriggern 16:58:49.207 ist ca. 4s später als der Befehl, da hätte ich schon noch einen Zwischenstatus erwartet, wenn die Aktualisierung bei 2s steht und 16:58:49.211 ist mit 4ms nach dem, der wahrscheinlich aus der Aktualisierung kommt, aber ich wüsste nicht was im Adapter die Ursache wäre.
Im obigen Beispiel kam dann auch kein true,false, true bei den 3
ich würde gern mal die sequenz von 3 rückmeldungen und das davorige Schalten als debug-Meldungen aus dem fritzdect Adapter sehen.
Hier ist ein log.
Ich setze den Wert von
fritzdect.0.DECT_116300263665.state
auf true und dann wird er mit false und ack = true zurück gemeldet und dann mit true und ack = true
iobroker.2022-06-20.log
habe mal die relevanten Dinge herauskopiert
das false ist aus dem zyklischen Update. Mitten im zyklischen Update ist der Befehl abgesetzt. Befehlsausführung dauert 1,2s, was mir recht hoch erscheint.
-> zyklisches update
2022-06-20 14:52:02.132 - [34mdebug[39m: fritzdect.0 (9807) polling! fritzdect is alive
2022-06-20 14:52:02.133 - [34mdebug[39m: fritzdect.0 (9807) __________________________
2022-06-20 14:52:02.133 - [34mdebug[39m: fritzdect.0 (9807) updating Devices / Groups
-> Kommando
2022-06-20 14:52:02.141 - [34mdebug[39m: fritzdect.0 (9807) state fritzdect.0.DECT_116300263665.state changed: true (ack = false)
-> Verarbeitung des zyklischen Updates
2022-06-20 14:52:02.142 - [34mdebug[39m: fritzdect.0 (9807) ack is not set! -> command
2022-06-20 14:52:02.142 - [32minfo[39m: fritzdect.0 (9807) DECT ID: 116300263665 identified for command (state) : true
2022-06-20 14:52:02.145 - [32minfo[39m: javascript.0 (21899) script.js.Garten.Pool.Filterpumpe: Freigabe Pumpe an.
2022-06-20 14:52:02.412 - [34mdebug[39m: fritzdect.0 (9807) devices
2022-06-20 14:52:02.413 - [34mdebug[39m: fritzdect.0 (9807) update Devices 3
2022-06-20 14:52:02.544 - [34mdebug[39m: fritzdect.0 (9807) object transfer state 0 116300263665
2022-06-20 14:52:02.544 - [34mdebug[39m: fritzdect.0 (9807) updating data DECT_116300263665 : state : 0
2022-06-20 14:52:02.642 - [34mdebug[39m: fritzdect.0 (9807) state fritzdect.0.DECT_116300263665.state changed: false (ack = true)
-> Rückmeldung des erfolgreich ausgeführten Befehls
2022-06-20 14:52:03.555 - [34mdebug[39m: fritzdect.0 (9807) Turned switch 116300263665 on
2022-06-20 14:52:03.558 - [32minfo[39m: javascript.0 (21899) script.js.Garten.Pool.Filterpumpe: Freigabe Pumpe an.
2022-06-20 14:52:03.559 - [34mdebug[39m: fritzdect.0 (9807) state fritzdect.0.DECT_116300263665.state changed: true (ack = true)
-> nächstes zyklisches update
2022-06-20 14:52:04.133 - [34mdebug[39m: fritzdect.0 (9807) polling! fritzdect is alive
2022-06-20 14:52:04.133 - [34mdebug[39m: fritzdect.0 (9807) __________________________
2022-06-20 14:52:04.133 - [34mdebug[39m: fritzdect.0 (9807) updating Devices / Groups
2022-06-20 14:52:04.410 - [34mdebug[39m: fritzdect.0 (9807) devices
Ja und wie gesagt, wenn man es auf 15s stellt, dann kommt die Bestätigung ja direkt nach paar ms.
in der Version 2.3.0 habe ich einen neuen Konfigurationsschalter, dieser bewirkt nur ein Schreiben von Werten, wenn diese einen anderen Wert haben als der im Datenpunkt gespeicherten, evtl. bringt das ja Verbesserung. Bitte einmal testen
@foxthefox . Sorry, habe es gerade erst gelesen. nehme an, die 2.3.0 ist noch Beta?
@foxthefox Ich habe es heute einmal mit der 2.3.1 getestet. Es liefe heute automatisch ab und die Schaltungen sahen ganz gut aus. Ich setze die Zeit mal wieder etwas herunter und dann beobachte ich es nochmal.
Bei 2s schaltet er wieder hin und her: Hier ein Grafana Auszug (ich habe lediglich ausgeschaltet:
Stelle ich auf 15s, dann sieht es so aus:
Ich habe den Fall heute morgen auch bei 15s Intervall gehabt. Wahrscheinlich dann, wenn es sich knapp überschneidet. die Rückmeldung war: true, false, true