Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Triggered event w/ multiple triggers
#11
thanks, it seems not the writes but the flood of triggers trip my device driver. I am considering to write a separate driver which would do some kind of polling at a comfortable pace and than do an update from time to time.
Can you also point me to the right docs for the event monitor to look into. Always happy to learn new things...
Reply
#12
You are probably getting into a circular feedback loop, where one changes the other which changes the first which changes the other, and it just keeps going. The docs for event monitors is in the base class that all of them derive from:

http://www.charmedquark.com/Web2/CQCDocs.../EvMonBase
Dean Roddey
Software Geek Extraordinaire
Reply
#13
So I set up a simple event monitor that detects when my chosen volume field changes. From a Min. to a Max. continuous button press it registers about 5-6 events, evidenced by the messages logged into the logs when field change is detected.

I am lost though on how is this different compared triggered event, am I correct that the event monitor is different only that is based on CML, thus could build an elaborate system to detect which field changed, and time spent since last write/update, thus avoiding the race condition?
Reply
#14
Well, the event trigger is always running, so it's a lot easier to maintain context over time, and yeh, a lot simpler to do the calculations you want and compare previous values to new values and that sort of thing. It also won't ever get run more than once, which can happen in a triggered event, and that can complicate things a lot. If you get multiple field changes in a row, you can get multiple instances of the triggered event running.

You can also set the idle seconds to 5 seconds (currently the lowest allowed) and do things not just in response to field changes. If it the sync can be up to 5 seconds later (worst case, 2.5 seconds on average) you can just save the values and, if nothing has happened for some number of seconds, then use the Idle() callback to then do something. That gets you around the issue of a cascade of changes causing too much activity.

For that matter, you aren't just being called every time the value changes, the server is polling the fields so you don't get called for every change, you just get called periodiclaly when something has changed (though that is a fairly short period.) So that also limits the possibility of runaway changes, because you won't see another change until you return from the current field change callback and a small amount of time has passed. So even just using the field change callback to do the work is fairly safe.
Dean Roddey
Software Geek Extraordinaire
Reply
#15
Oh, and you can also run it in the debugger and test out your code, which you can't really do with actions.
Dean Roddey
Software Geek Extraordinaire
Reply
#16
(06-06-2018, 06:02 PM)Dean Roddey Wrote: Well, the event trigger is always running, so it's a lot easier to maintain context over time, and yeh, a lot simpler to do the calculations you want and compare previous values to new values and that sort of thing. It also won't ever get run more than once, which can happen in a triggered event, and that can complicate things a lot. If you get multiple field changes in a row, you can get multiple instances of the triggered event running.

You can also set the idle seconds to 5 seconds (currently the lowest allowed) and do things not just in response to field changes. If it the sync can be up to 5 seconds later (worst case, 2.5 seconds on average) you can just save the values and, if nothing has happened for some number of seconds, then use the Idle() callback to then do something. That gets you around the issue of a cascade of changes causing too much activity.

For that matter, you aren't just being called every time the value changes, the server is polling the fields so you don't get called for every change, you just get called periodiclaly when something has changed (though that is a fairly short period.) So that also limits the possibility of runaway changes, because you won't see another change until you return from the current field change callback and a small amount of time has passed. So even just using the field change callback to do the work is fairly safe.
thanks, this is very helpful.
Reply
#17
(06-06-2018, 06:06 PM)Dean Roddey Wrote: Oh, and you can also run it in the debugger and test out your code, which you can't really do with actions.

I usually test my action code by setting up a trigger for the motion detector in the room I am, and than wave my arms violently and a few moments of still...   Smile
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Event entry not responding! Deane Johnson 4 498 12-11-2017, 02:10 PM
Last Post: Dean Roddey
  Writing to an external file from trigger event Ira 21 2,749 11-13-2017, 02:08 PM
Last Post: znelbok
  High Level Triggers and Action rules admin screen kfly 1 401 11-01-2017, 05:21 PM
Last Post: Dean Roddey
  Motion Event Running Twice? zra 2 786 07-31-2017, 08:15 PM
Last Post: zra
  are triggers reliable? indygreg 4 1,030 06-29-2017, 11:52 AM
Last Post: Dean Roddey
  COuld not update triggers znelbok 11 1,950 06-08-2017, 03:55 PM
Last Post: znelbok
  EVent Server Monitor znelbok 1 687 06-07-2017, 12:36 PM
Last Post: Dean Roddey
  Problem with Triggers pjgregory 11 2,627 05-11-2017, 11:36 PM
Last Post: pjgregory
  I have an event that I want to happen 5 hours after sunset. ghurty 8 1,838 03-24-2017, 08:40 AM
Last Post: Dean Roddey
  Scheduled Event - Yearly Basis Bugman 2 812 11-07-2016, 04:44 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)