High Level Triggers and Action rules admin screen

[kfly]

Dean,
Now that V2 has brought some organization to drivers and fields any chance to get a higher level more easy to use global action screen in the Admin Interface?
Using Triggers and Edit Actions gets messy quickly and easy to leave triggers on if you want a bunch of just simple rules.

I only need to evaluate every second or two the status of a device(light,security field,etc) when they transition.
Rules could be very simple like:

if  elk.SEC#Zone_FrontEntryDoor_Status Equals  Not Ready
    Zwave.LGHT#Sw_FrontPorch = ON
End

If Zwave.LGHT#Sw_livingRoomLight Equals False
     Zwave.LGHT#Sw_Hallway = OFF
     Pause(10)
     Denon2112.PWR#Main~Power = False
 End
    
Also:
Right now I have a  scheduled events to check for Denon power is off  every 60 minutes and then turn off all the other hardware.
Would be great to have it all in one place(events-triggers,etc)

If Denon2112.PWR#Main~Power = False
    Russound.PWR#Z01 = Off
    Russound.PWR#Z04 = Off
End

Would be even better if you could turn on or off  for X seconds. (again without having to write a complicated  Schedule item)
Zwave.LGHT#Sw_FrontPorch = ON  for 10 seconds


elk does a pretty good job at letting you write rules all on one screen so something like that would be excellent.


Thanks
Kevin

[Dean Roddey]

The for X seconds is already there. Use a timed field change for that.

The other thing is really something different from triggered events. Triggered events are very efficient because they are triggered. I.e. they don't have to constantly monitor the value of a field (which has a cost in a network distributed system like CQC.) They get told when the field changes. That also means that they aren't subject to race conditions, i.e. a field changes quickly before you ever get a chance to see it (because polling across the network can only be done so fast.) You always get the trigger no matter how quickly the field changes because the driver itself sends the trigger upon storing the field change. And of course it can work with predefined triggers which makes them much more portable across devices.

What you are talking about is sort of a different scheme, which has to monitor fields constantly. So it's more like Rules, not Events. So it would have to be implemented differently and be a whole other area of the browser tree.

In one sense, Event Monitors are designed for what you want to do, but they are currently CML only, so that makes them not so useful for most folks, and they are badly under-utilized these days given how powerful they could be.