Author |
|
bhlonewolf Senior Member
Joined: March 29 2007
Online Status: Offline Posts: 198
|
Posted: June 28 2007 at 15:52 | IP Logged
|
|
|
I have a trigger that turns off a fan 10 minutes after the corresponding light is turned off. I think I'm seeing some changes in the new PH version regarding some behavior...
I have the trigger set up to listen for device changes from the light. I'm seeing the trigger get fired twice in some situations: initially when a button triggers the light to go off (either a linked button or virtually within PH) and again about 1 second later when the ACK is received.
Not sure if this is a bug or intentional change or user error -- what I'd like to do is trap any "off" signal from the device -- either issued locally or not, and fire the macro once for each hit. I have logic within the macro extend the timeout with each off, but like I said, it's getting fired twice now.
Anyone else notice this?
EDIT: The double trigger only seems to happen when the device change is triggered from within powerhome... locally it seems to work fine.
Thx!
Edited by bhlonewolf - June 28 2007 at 16:03
|
Back to Top |
|
|
dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: June 28 2007 at 18:12 | IP Logged
|
|
|
bhlonewolf,
I don't remember specifically changing the trigger functionality for the Insteon, but it's entirely possible that this was one of the early changes and if anything, was an additional trigger to also fire on Direct Insteon ACK messages (or what may be more likely is that the trigger was there and I fixed an error in the routine that prevented it from firing before).
In any event, there are a couple of ways to handle it. Im assuming that the trigger type you are working with is an "Insteon Device Chg" trigger. This trigger will fire on ANY command that could result in changing the device's status. In your situation, once for sending the Insteon command from PowerHome, and again on the ACK message (PowerHome doesnt necessarily distinguish between commands originating from within itself or from another device).
Now Im not sure what the desired functionality is...is the timer supposed to turn the fan off 10 minutes after the light is ACTUALLY turned off or 10 minutes after any Off signal (such as the light already being off and someone coming in and pressing the Off button again).
If the function is supposed to set the timer ONLY when the light actually turns off, then you could use the [LOCAL9] and [LOCAL10] variables to determine this. [LOCAL9] contains the previous status before the command was received and [LOCAL10] contains the status after the command was received. If the light was previously on and then turned off, then [LOCAL9] would be a value greater than 0 and [LOCAL10] would be 0. This would cause the trigger to only fire on the first command that was received by PowerHome that actually turned the light off. This is good because if PowerHome missed the initial command, it could still trigger on the ACK. You could easily implement this by placing this formula in the Boolean field of the trigger:
if([LOCAL9] > 0 and [LOCAL10] = 0,1,0)
Now, if you wanted to just ignore any changes as a result of a Direct ACK message, then the type of message that caused the Insteon Device Chg trigger to fire is stored in the [TEMP4] variable. In the case of a Direct ACK message, [TEMP4] would contain a 7. You could also setup a formula in the Boolean field to validate the value in [TEMP4].
Another favorite technique I use when I don't want triggers to multiple fire for whatever reason, is to use the ph_disabletrigger function. My favorite way to do this is to create a function called DISABLE_TRIGGER. This function looks like:
Code:
10 Formula Immediate ph_disabletrigger("[TEMP1]")
20 Wait [LOCAL1]
30 Formula Immediate ph_enabletrigger("[TEMP1]")
|
|
|
Thats it! I can now use this formula for any trigger that I want to temporarily disable for a short period of time.
All I have to do is set my Trigger action type to "Raw Formula" and prefix my normal trigger action with a call to the DISABLE_TRIGGER macro like this:
ph_macroparm("DISABLE_TRIGGER",5,0,0,0,0) + ph_macro("THE MACRO ID I REALLY WANT TO FIRE BASED UPON THE TRIGGER")
It works because when a trigger is fired, the ID of the trigger is stored in the [TEMP1] variable. I pass the number of seconds I want the trigger to be disabled as the first parameter of the ph_macroparm function (which ends up in the [LOCAL1] variable).
Simple and reuseable for any trigger you want to treat in this manner.
Hope this helps,
Dave.
|
Back to Top |
|
|
bhlonewolf Senior Member
Joined: March 29 2007
Online Status: Offline Posts: 198
|
Posted: June 28 2007 at 18:41 | IP Logged
|
|
|
Excellent, Dave, thanks!
Yeah, this definitely covers the bases here -- essentially I've got a bath fan that gets left on a lot because we need to air it out ... it's a small shower "room" with no windows.
The way I set it up is that if the light is turned off and the fan is still on, fire up the macro and wait 15 minutes. It does this, as you guessed, on the Insteon Device changed event.
Just to be clever I made it so any subsequent off presses extend the timeout, so if I wanted it on for 30 minutes, I could just hit off twice. (I suppose I could really be clever and just do fastoff and the like.)
Thanks a lot for the info -- I hadn't used the temp variables before so this is a good start...
|
Back to Top |
|
|
|
|