Triggered event to turn stuff off

[Dean Roddey]

Dean,

Does the event server have access to global variables? Can i test for values in the action area of the event server?

The event server has it's own global variable space, shared by the triggered and scheduled events. So actions set by one action will be seen by another. You do have to be careful not to make assumptions though because multiple actions can be running at once.

[zra]

Thanks,

That was what i was doing wrong last week. I was trying to call up the value of a global variable from within the event server and it wasnt liking it.

Made some local variables within the event server and initialized them from my variables driver and wallah.

[Dean Roddey]

Thanks,

That was what i was doing wrong last week. I was trying to call up the value of a global variable from within the event server and it wasnt liking it.

Made some local variables within the event server and initialized them from my variables driver and wallah.

I think you may have a terminology issue. The variables driver isn't providing 'global variables'. They are just fields that one can use as variables (i.e. the only hold whatever you write to them.) If anything, they are 'system variables' in that they are available system wide.

Variables are either global (to whatever program the variable is created by) or local (limited to the action that created it.)

So the event server has a global variables scope that any scheduled or triggered actions can see. Any fields are also available to any action, anywhere, so any variable driver fields are definitely available, but they are fields, not variables, so you have to access them as fields, i.e.:

$(moniker.field)

not:

%(moniker.field)

$() is for getting the values of fields, and %() is for getting the values of variables, and other standard tokens like runtime values or action parameters, which are really just sort of special variables created for you automatically.

So you can certainly access variable fields within your triggered or scheduled events if you want. If you are going to access a field value multiple times in the same action, and you aren't worried about it changing in between accesses (or what to make sure you only see the initial value), then you can grab the value of the field and put it into a local variable and use that for the rest of the action. That will be more efficient since you aren't going to back over the network multiple times to get the same field within the scope of a single action.

[zra]

Followup question.

Per your suggestion I created a countdown timer that sends an event when its value = 0. Since that value is, presumably zero, at all times except for when i start it counting down is it constantly sending events to the event server? Should I be concerned with that? If so, can you suggest a better way to handle it?

On a second, perhaps, related note, I had a few executions of the code when i wasnt expecting it, so I created an override switch, using a variables driver field. Now the code in the triggered event server only executes based on the value of that override.

[znelbok]

Events are only triggered on change to, and not while equal. So you will only get one event trigger on your timer.

Are you sure it was the TE that ran and not something else somewhere?

Mick

[zra]

im pretty sure Mick. By the way, I have it set to send when isequal to 0.

[znelbok]

yeah isequal is still only a single triggered event

i.e.

value changes from 1 to 0 - trigger sent (value now equals 0)

while the value is at 0 there are no triggers sent. This has been a bug bear to some of us becase we want to trigger to be sent (eg you want a triggered action when you change to CD, but CD is already selected) but no trigger is sent.

Hence the question, you wont get re-triggers unless the value is changing and going back to 0.

Similarly, if you have say isLsThanEq, and a value of 5, it would only trigger 6 times (assuming 1 second resolution), 5, 4, 3, 2, 1 & 0 on a countdown, and only when the value changes, not while it was constant.

Mick