Hallo zusammen,
ich habe ein Problem mit meiner Structure.
Um die Telegrammlast zu minimieren habe ich auf den Einsatz von FILTER zurückgegriffen, wenn ich die Rollläden beim sunset/sunrise + Offset schalte.
Doch leider wird dann das Attribut async_delay nicht mehr beachtet. Diese würde ich aber gerne verwenden um die Rollläden nicht alle gleichzeitig runter zu fahren.
Mache ich ggf. was falsch:
define EG_Jalousien structure room EG.JalousieWohnzimmer EG.JalousieKueche
attr EG_Jalousien async_delay 10
attr EG_Jalousien clientstate_behavior relativeKnown
Ein Workaround wäre direkt nach dem Schalten der structure ein dummy zu setzen und nach Time x wieder zurück zu setzen. Dann könnte man zumindest in meinem Fall auf den FILTER verzichten.
Vielen Dank für eure Hilfe.
Gruß
Wie wendest Du denn FILTER bei structure genau an?
Das funktioniert dort anders als sonst üblich.
Gruß
Dan
Bislang mach ich das in meinem DOIF so:
set EG_Jalousien [FILTER=state!=off] off
setstate EG_Jalousien off
Hmm, sollte richtig sein.
Das setstate sollte doch aber eigentlich unnötig sein.
Denke zwar nicht dass es daran liegt, aber hast Du es mal ohne probiert?
Gruß
Dan
ja, macht kein Unterschied. Man kann es ja auch ohne DOIF direkt über die Befehlszeile ausführen (nur den einzelnen Befehl)
Ich kenne DOIF nicht, ich gehe vom folgenden "normalen" FHEM Syntax aus: "set EG_Jalousien:FILTER=state!=off off"
Dieser Filter prueft den aktuellen state Reading der EG_Jalousien, und das ist vermutlich nicht mehr off, da es sich bei jeder Aenderung der Mitglieder aktualisiert.
setstate ist sinnlos, setzt den STATE Internal, und das ist was anderes.
set EG_Jalousien [FILTER=state!=off] offist auch 'normale' syntax. der FILTER wird hierbei an die einzelnen set der devices durchgereicht. nicht auf die structure selber. im gegensatz zu set EG_Jalousien:FILTER=state!=off off das den FILTER auf die structe selber anwendet.
allerdings wird aktuell bei gesetztem [FILTER...] async_delay tatsächlich nicht beachtet. siehe zeile 401 bzw. 418 folgende.
nach kurzem drüber schauen müsste es für normale devices reichen das CommandSet in structure_asyncQueue durch AnalyzeCommand zu ersetzen, in zeile 422 das set mit zu pushen: push @{$hash->{".asyncQueue"}}, "set ".join(" ", @list);und im if zweig des if( $filter) auch ein push @{$hash->{".asyncQueue"}}, "set $list[0]:$filter ".join(" ", @list[1..@list-1]);zu machen wenn async_delay gesetzt ist.
damit wäre dann nur der structure aus structre mit FILTER und async_delay fall noch offen.
@justme1968: Kannst du mir bitte einen Patch bauen: [FILTER...] in structure ist dein Kind, und ich habe es offensichtlich nie verinnerlicht.
@rudi: ich hatte gestern nur keinen rechner zum testen greifbar.
anbei ein patch der folgendes umsetzt:
- async_delay wird auch bei [FILTER=...] berücksichtigt
- dabei code für set aufgeräumt, vereinfacht und duplikate vermieden. deshalb schaut der patch größer aus als er ist
zusätzlich:
- bei gesetztem async_delay wird die queue sofort gestartet und nicht erst nach dem ersten zeitschritt.
d.h. das erste set passiert sofort und nicht verzögert.
- statt undef wird wieder $ret zurück gegeben wenn die set der devices etwas zurück geben
oder war das beabsichtigt? falls ja wäre aber das zusammen bauen von $ret mit \n unnötig.
was nicht eingebaut ist: Forum #70488 für den async_delay&[FILTER=...] fall. dann müsste man in structure_asyncQueue das kommando noch mal auseinander nehmen und prüfen oben es für eine structure ist und dann wie zeile 422ff. behandeln. kann man nachholen sobald ein problem gemeldet wird.
was mir aufgefallen ist: .cachedHelp wird nicht zurück gesetzt wenn an den beteiligten devices attr aufgerufen wird. d.h. wenn z.b. eine structure auf dummys angelegt wird und danach die dummys mit attr setList kommandos bekommen gibt es eine gute chance das set ? auf die structure etwas falsches zurück liefert.
Danke, habs kurz getestet und eingecheckt.
vielen Dank für eure Hilfe. Jetzt funktioniert es prima :)