DbLog und ein Dummy für Dummies

Begonnen von juniormajor, 26 November 2015, 17:03:14

Vorheriges Thema - Nächstes Thema

juniormajor

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


dev0

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.

juniormajor

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.

dev0

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.

juniormajor

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.

dev0

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.