Triggered event w/ multiple triggers

[lleo]

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...

[Dean Roddey]

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

[lleo]

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?

[Dean Roddey]

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]

Oh, and you can also run it in the debugger and test out your code, which you can't really do with actions.

[lleo]

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.

[lleo]

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...