get/set im Sekundentakt

[crispyduck]

Danke! Sage ja es ist nicht schön, aber funktioniert. 

Nein, werde das nochmal überdenken, vielleicht finde ich doch einen anderen Lösungsweg, eventuell mach ich ein eigenes device das mir nur den einen Wert im Sekundentakt abfragt und eben in der Nacht disabled wird.

Aber 1000 Dank für die Info mit dem neuen Attribut, bin dadurch erst auf uiTable aufmerksam geworden.
Wollte jetzt über Weihnachten mit Tablet UI anfangen, glaube das lasse ich jetzt und mach es mit deinem Modul!

Das schaut ja spitze aus! Nochmal 1000 Dank für das Modul! 

@DOIF_Readings, ist zwar auch nicht wirklich sinnvoll was ich da probiere, aber hätte mir bei folgendem erwartet das es hoch zählt:

Code Auswählen Erweitern

define di_test DOIF ([+2]) (set test [$SELF:add])

attr di_test DOIF_Readings add:[test:state]+1
attr di_test do always

Tut es aber nicht, sondern "add" wird nur neu berechnet wenn "test" von außerhalb des DOIFs geändert wird.

Oder darf man soetwas einfach gar nicht machen da je

Änderungen dieser Readings triggern allerdings das eigene DOIF-Modul, wenn sich deren Inhalt ändert.

Danke,
crispyduck

[Damian]

Wozu so kompliziert. Ursache und Wirkung sollte nicht im gleichen Modul stattfinden - Rekursionsgefahr. Was geht: externes Reading->DOIF_Reading->DOIF_Reading in der Bedingung

Code Auswählen Erweitern

define di_test DOIF ([+2]) (set test {([test]+1)})

attr di_test do always


[crispyduck]

Danke, das ist eh klar. Hab mich jetzt nur bisschen mit dem neuen attribut gespielt, und da ist mir aufgefallen das eben die Berechnung im DOIF_Readings nicht upgedated wird wenn eines der Readings der Berechnung vom DOIF selbst geändert wurde.

Das add:[test:state]+1 war jetzt nur ein einfaches beispiel.

Heißt also man sollte im Ausführungsteil des DOIFs keine Readings ändern die im selben DOIF zur Berechnung eines DOIF_Readings genutzt werden.
Dachte bei Rekursionsgefahr also bei Ursache und Wirkung nur an Bedingung und Ausführungsteil.

Das DOIF_Readings wird also nur berechnet wenn der trigger/die Reading Änderung von ausserhalb des DOIFs kommt und nicht durch das DOIF selbst.

Idee war das attribut DOIF_Readings für ein DOIF zu verwenden welches zu einer definierten Zeit eine mehrfach verwendete Berechnung nutzt in welche auch das Ergebnis des letzten DOIF aufrufes mit einfließen soll.
Das DOIF_Readings würde dabei nicht upgedated werden wenn sich nur das Reading geändert hat welches durch die letzte DOIF ausführung gesetzt wurde.

Vereinfacht dargestellt dachte ich das man mit dem neuen attr aus:

Code Auswählen Erweitern

define di_test DOIF ([+2]) (set test {([test:state]+[test1:state])})
attr di_test do always

das nachen könnte:

Code Auswählen Erweitern

define di_test DOIF ([+2]) (set test [$SELF:add])
attr di_test DOIF_Readings add:[test:state]+[test1:state]
attr di_test do always

Das klappt so dann aber nicht, wenn sich [test1:state] nicht verändert hat.

Lg
crispyduck

[Damian]

Code Auswählen Erweitern

define di_test DOIF ([+2]) (set test [$SELF:add])
attr di_test DOIF_Readings add:[test:state]+[test1:state]
attr di_test do always

Das klappt so dann aber nicht, wenn sich [test1:state] nicht verändert hat.

Lg
crispyduck

Wie schon geschrieben, sind DOIF_Readings dazu gedacht Berechnungen durchzuführen, um deren Ergebnis in der DOIF-Bedingung bzw. in uiTable und sogar im state-Attribut zu nutzen und nicht umgekehrt. Deswegen reagieren sie nicht auf Veränderungen im Ausführungsteil, das braucht man auch nicht, da man im Ausführungsteil per setreading seine eigenen Readings berechnen und setzen kann, hier in deinem Beispiel:

Code Auswählen Erweitern

define di_test DOIF ([+2]) (setreading $SELF add {([test:state]+[test1:state])})
attr di_test do always

[crispyduck]

Danke, alles klar. Einfach nur gut wenn man weiß was man machen kann und was man nicht machen sollte. 

Beispiel:

Code Auswählen Erweitern

define di_test DOIF ([+2]) (setreading $SELF add {([test:state]+[test1:state])})
attr di_test do always

Wenn man die selbe Berechnung aber auch schon in der Bedingung braucht muss sie zumindest zwei mal berechnet werden, oder kann man das auch schon irgendwie in der Bedingung in eine Variable schreiben?
Folgendes z.B., immer wieder die gleiche (vereinfachte) Berechnung [test:state]+[test1:state]

Code Auswählen Erweitern

define di_test DOIF ([+2] and ([test:state]+[test1:state]) > 5) (set test {([test:state]+[test1:state])}) DOELSEIF (([test:state]+[test1:state]) < 0) (set test {([test:state]+[test1:state])-5)})......
attr di_test do always

[Damian]

Die Berechnung werden in Perl und im Speicher ausgeführt, daher von der Performance unkritisch. Gleiche Variablen zwischen Bedingung und Ausführungsteil gibt es nicht.

Wenn test und test1 extern sind (keine eignen Readings wären), dann wäre DOIF_Readings dafür prädestiniert, ansonsten gibt es auch UserReadings, die erzeugen allerdings Events und das kostet mehr Performance als die gleichen Readings im DOIF mehrfach anzugeben.

[crispyduck]

Herzlichen Dank für deine Antwort. Sorry für die späte Antwort, aber habe leider keine Benachrichtigung erhalten.

Dank deinen Antworten habe ich mich jetzt erst mehr mit den events meines systems auseinander gesetzt und auch einige eingespart.

Lg
Andi