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
Explorans limites defectum
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
Explorans limites defectum
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
Explorans limites defectum
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 Server Error Bugman 4 1,047 06-05-2022, 08:54 AM
Last Post: Bugman
  Triggered Event w/ Elk AreaArm EST 18 6,695 12-04-2020, 05:37 PM
Last Post: gReatAutomation
  Triggered Event only works every second time znelbok 2 1,305 10-27-2020, 12:05 PM
Last Post: znelbok
  Global Variables in the Event Server context lleo 1 1,296 05-16-2020, 11:21 AM
Last Post: Dean Roddey
  Is there a Way to Export Multiple Templates Together? kblagron 1 857 04-23-2020, 08:01 AM
Last Post: Dean Roddey
  RadioRA2 Triggers gReatAutomation 3 1,260 03-25-2020, 05:11 PM
Last Post: Dean Roddey
  Reconfig of Driver Causes Built In Triggers to Fire gReatAutomation 2 1,492 03-25-2020, 04:09 PM
Last Post: gReatAutomation
  [FEATURE] Event Run Action simplextech 4 2,753 01-09-2020, 02:04 PM
Last Post: simplextech
  More than 4 triggers simplextech 4 2,026 01-09-2020, 10:02 AM
Last Post: simplextech
  Media playing from Event simplextech 11 4,485 01-07-2020, 06:09 PM
Last Post: simplextech

Forum Jump:


Users browsing this thread: 1 Guest(s)