| Author |
|
mike0999
Groupie
Joined: June 14 2009
Location: United States
Online Status: Offline
Posts: 56
|
| Posted: March 04 2010 at 00:26 | IP Logged
|
|
|
Hi everyone,
I am experiencing what seems to me to be some really odd behavior when trying to use triggers and my USB UIRT to control some insteon devices. I wonder if this is a bug in the software or maybe I am doing something wrong.
In particular, I have defined some triggers to execute a macro when I press a key on my IR remote. I have defined, for example, a macro to "toggle" a light on and off when pressing the same button on the IR remote - "toggle" meaning if the light is off, pressing the button on my remote turns it on, and if the light is on, pressing the same button on my remote turns it off.
The odd behavior is that when my light is off, for example, and I press the button on my remote, the light comes on and almost immediately goes off. If I look at the event log, what is happening is that the trigger is "triggered," but the software is issuing an "on" command PRIOR TO executing the macro. The macro runs right after the"on" command is issued, and because it is designed to toggle the light, it turns it immediately back off. I have no idea why the trigger is causing an on command to be issued prior to executing the macro.
If I put a delay as the first command in my macro, I can cause the behavior to go away. I.e. no "on" command is issued prior to execution of the macro, and the behavior is exactly what I would expect.
Thoughts? Thanks in advance for any help. If anyone is aware of a relevant post, feel free to point me to it. I can provide logs, macro details, trigger details, etc. if that is helpful.
Regards,
Mike
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: March 04 2010 at 01:31 | IP Logged
|
|
|
Are you doing any Insteon commands within the Trigger itself (Boolean field for example). With the macro being a toggle you must have logic to either issue an ON or OFF command. With the wait at the beginning of the macro stopping the macro processing and that stopping the On command, sounds like the macro is issuing both commands but no idea why the order of the log entries. Post the trigger content and macro.
__________________
Lee G
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: March 04 2010 at 15:24 | IP Logged
|
|
|
May need to know what the linking looks like as well. If the Light is linked to the UIRT and to PowerHome, you will get that kind of behaviour. Removing the link to the light will let Powerhome do all the control (if a link exists).
Tom
|
| Back to Top |
|
| |
mike0999
Groupie
Joined: June 14 2009
Location: United States
Online Status: Offline
Posts: 56
|
| Posted: March 06 2010 at 00:25 | IP Logged
|
|
|
Thanks guys. The following is the trigger definition. I've included the fields vertically, and omitted the description. I'll include the macro in a subsequent post. No logic in the trigger.
ID LVGDNG LIGHTS
Action Type Macro
Action TOGGLE LVGDNG LIGHTS
Trigger Type IR in
Trigger URC 8820
ID Trigger ID Number Lvgnrm Dngrm Lights
Trigger Value Received
Boolean 1
The Action Field contains the name of the Macro that contains all of the logic. The Trigger Field, URC 8820, is the name of the IR device that I defined. The Trigger ID number is the "description" within the IR device under which I stored the incoming code (part of my definition of the IR device when using powerhome explorer). After defining this name under the IR Device, I was able to simply select this name from the pull down menu that appears after I select URC 8820 for the "Trigger" field when defining the trigger.
In order to define the URC 8820, basically I went into the Devices section of Powerhome explorer. I selected IR; added the device called URC 8820; and defined UIRT as the controller.
Tom, I wasn't sure what you meant when you said the light being linked to the UIRT, given that the UIRT isn't an insteon device. But, maybe this is what you mean. Maybe I need to define my PLM as the controller here. Maybe this is why I am getting the duplicate commands. I'll try changing that now.
Thanks again for the help.
Edited by mike0999 - March 06 2010 at 00:45
|
| Back to Top |
|
| |
mike0999
Groupie
Joined: June 14 2009
Location: United States
Online Status: Offline
Posts: 56
|
| Posted: March 06 2010 at 02:35 | IP Logged
|
|
|
Well, changing the controller didn't work. So, I guess I probably don't understand what you mean Tom. Any chance you could explain a little more?
The following is the macro. I have tried a number of variations on this macro. Among them, instead of using ph_getinsteonlevelrt I have used ph_getinsteonstat and I ph_getinsteonlevel. Same result.
Goto Label if(ph_getinsteonlevelrt("LVGRM- DNGRM")=0,"","TURNOFF")
Formula ph_devicebtn(INSTEON,"L VGRM-DNGRM",ion,"255")
Jump 999
Label T URNOFF
Formula ph_devicebtn(INSTEON,"LVGRM-DNGRM",ioff,"0")
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: March 06 2010 at 07:36 | IP Logged
|
|
|
Can you post the Event Log showing the unexpected sequence.
Have you tried a macro that is using normal ph_insteon() funcion calls rather than using the device button call.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: March 06 2010 at 08:00 | IP Logged
|
|
|
I believe where Tom was going is a direct link to the light itself from the UIRT. But as you explained that can’t be done from the UIRT. I suspect your problem may be from a double firing of the trigger. You might try putting TRIGDISABLE in the Boolean field of the trigger and see what happens. Trigdisable can be found here on the 1st page.
http://www.myx10.com/forum/forum_posts.asp?TID=2132&KW=trigd isable&TPN=1
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: March 06 2010 at 08:27 | IP Logged
|
|
|
Pete understood me correctly and I would have to say that Pete is probably right. If a device is double firing, that has to be handled (typically with a ph_disabletrigger()/ph_enabletrigger()) or odd behaviour can occur.
|
| Back to Top |
|
| |
mike0999
Groupie
Joined: June 14 2009
Location: United States
Online Status: Offline
Posts: 56
|
| Posted: March 08 2010 at 20:57 | IP Logged
|
|
|
Thanks guys. I studied the Event Log a bit more, and looks like that is exactly what is happening.
I am using a wireless RF device to transmit the IR command from my IR remote to my computer in another room. The RF device near my computer receives the command at my computer in RF form, converts to IR, and issues the IR command to the computer. But, for some reason it is issuing two RF commands in very quick succession. So fast, apparently, that the trigger was activated the "second time" so quickly that it was happening prior to the macro issuing the insteon on or off command from the first time the macro was triggered. So, it actually appeared in the Event Log as if an insteon command was issuing after a trigger, but before execution of the macro. In reality, the first insteon command was from the prior trigger.
Hope that that explanation is sufficiently clear, but net is that it appears that everything is working fine in the software. Apologize I didn't notice that earlier. Now I'll have to figure out why I am getting the double command from my RF/IR device.
Maybe I can mask the effect, at least for this purpose, by disabling the trigger briefly, as you suggest. For some reason I hadn't really noticed an issue when controlling my htpc.
Thanks again!
Regards,
Mike
Edited by mike0999 - March 08 2010 at 21:02
|
| Back to Top |
|
| |
mike0999
Groupie
Joined: June 14 2009
Location: United States
Online Status: Offline
Posts: 56
|
| Posted: March 08 2010 at 23:32 | IP Logged
|
|
|
Well, that seems to be working like a charm. At minimum, makes it usable until I have time to investigate the IR/RF device further.
Thanks again!
Regards,
Mike
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: Odd Trigger Behavior
