Bei einem Dummy welches seine Readings per 99_my* gesetzt bekommt,
schaffe ich es nicht ein Event getriggert zu bekommen, sodass DbLog anspringt.
list des Dummy:
Internals:
NAME VZ_Gesamt
NR 235
STATE updated
TYPE dummy
CHANGED:
maxValveSetting: 13
CHANGETIME:
Helper:
Dblog:
Desiredtemperature:
Logdb:
TIME 1448553169.65514
VALUE 19.0
Maxvalvesetting:
Logdb:
TIME 1448553169.65514
VALUE 0
Temperature:
Logdb:
TIME 1448553169.65514
VALUE 19.0
Readings:
2015-11-26 16:54:10 battery low
2015-11-26 16:54:10 desiredTemperature 19.0
2015-11-26 16:50:16 humidity 0
2015-11-26 16:54:10 maxValveSetting 13
2015-11-26 16:54:10 state updated
2015-11-26 16:54:10 temperature 19.0
2015-11-26 16:27:39 window 0
Attributes:
DbLogExclude battery,state
event-min-interval desiredTemperature:1800,maxValveSetting:1800,temperature:1800,window:1800
event-on-change-reading desiredTemperature,maxValveSetting,temperature:0.2,window
readingList battery,desiredTemperature,maxValveSetting,temperature,window
room Vorzimmer
Habe es in der Zwischenzeit in der 99_* per
readingsBulkUpdate()
set()
setreading()
setReadingsVal()
versucht, aber ich komm nicht zusammen.
Wenn ich via cmd dann ein set auf den dummy mache, wird DbLog richtig getriggert.
Im List sieht man auch im CHANGED eine ausstehende Änderung, welche noch nicht geloggt wurde.
Da ich vermute, dass es sich um die Loop-Unterbindung handelt, bleibt mir noch die Idee, mit einem "externen" - also eigenen - AT ein set auf den dummy auszuführen. Ist meine Vermutung richtig, oder habe ich einen anderen Fehler?
Danke & lG
Leider fehlt die Info wie das reading denn genau gesetzt wird. Wenn du z.B. setreading aus einem Notify heraus benutzt, dann musst du das über ein sleep leicht verzögern. Siehe commandref/setreading.
Ursächlich ist die Änderung eines Devices welches mittels userReadings eine Funktion in den 99_my* aufruft. In dieser wiederum, werden im dummy die Readings aus unterschiedlichen Quellen (nicht nur von jenem Device welches die Funktion via userReadings aufgerufen hat) gefüllt. Aktuell mittels "set ..." da alle Readings in der readingList des dummy enthalten sind. Und schlußendlich sollen die Readings des dummy in der DB landen.
Ist die Schilderung halbwegs verständlich?
Das Thema der notwendigen Verzögerung bei setreading denke ich kann ich ausschließen, da je nicht das dummy das set auslöst, sondern ein anderes Device.
Zitat von: juniormajor am 26 November 2015, 21:46:21
Ist die Schilderung halbwegs verständlich?
5 Zeilen Code sagen manchmal mehr als 1000 Worte ;)
Zitat von: juniormajor am 26 November 2015, 21:46:21
Das Thema der notwendigen Verzögerung bei setreading denke ich kann ich ausschließen, da je nicht das dummy das set auslöst, sondern ein anderes Device.
Welches Devices triggert ist völlig egal, wenn meine Vermutung zutrifft, dass es an der Schleifenerkennung liegt, die es nicht nur bei Notify, sondern auch bei watchdog, FileLog, etc. gibt. Das vorgeschlagene fhem sleep soll nicht zur Verzögerung dienen, sondern dazu um aus dem Mechanismus auszubrechen.
Danke.
Glücklicherweise waren es dann doch keine 1000... ;-)
Hab die Logik jetzt umgebaut, da ich auf keinen grünen Zweig gekommen bin (Habe deinen Vorschlag mit sleep probiert, aber das hat leider trotzdem nicht funktioniert - das setReading wurde ja nicht aus dem Notify heraus aufgerufen, sondern aus einer Funktion in 99_* welche aus dem Notify aufgerufen wurde).
Frage nun die Readings welche mich interessieren in einem at ab, und schreibe diese mittels BulkUpdate in meinen Dummy.
Nun wird auch das DbLog sauber getriggert.
Zitat von: juniormajor am 06 Dezember 2015, 23:28:00
das setReading wurde ja nicht aus dem Notify heraus aufgerufen, sondern aus einer Funktion in 99_* welche aus dem Notify aufgerufen wurde)
99_myUtils oder nicht ist egal, die Schleifenerkennung schläg auch dann zu. Ein sleep macht an der Stelle intern nichts anderes, als für Dich einen timer aufzurufen.