| Author |
|
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: December 05 2011 at 17:16 | IP Logged
|
|
|
Pete -
Just thinking (I know. That's dangerous at my age, but
what the heck).
The issue with direct switch linking is that when I tap Off
on the switch, I want all the room lights to go out, but
when I tap On I don't want any such actions.
Off hand, I can't think of a way to ONLY have the switch's
OFF tap trigger an action, while the On tap does nothing
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 05 2011 at 17:32 | IP Logged
|
|
|
I would think PH trigger would be sufficient for off since that is not usually a time related problem. In my option, I would think that the ON was more time related then OFF. In fact when I trigger OFFs usually I delay the action so people have a way to get out before it gets dark….
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: December 05 2011 at 17:34 | IP Logged
|
|
|
Dave -
In testing further on this "slowness" issue, I just captured the following scenario that demonstrates what I have been experiencing.
At 16:32:45 I selected "PLAY" for the "DR OFF" macro, but it never fired. Even after 5 minutes of waiting it never kicked off.
Looking at the Event Log (snapshot taken at ~16:34.10), my Play "DR Off" never even showed up. A log refresh several minutes later still showed no DR OFF execution.
The Execution Que kind of tells the story. It appears that my Garage Door state sensing macro was running, and running, and running. In fact after 5 minutes, it still was stuck in the queue until I executed a Clear Exec Que command.
Here is a listing of the Garage Door Sense macro . . .
Does this reveal anything to you?
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 05 2011 at 21:52 | IP Logged
|
|
|
You could be hung waiting for insteonwithret if it is encountering errors. But it should eventually clear. For those type of back to back commands I stick a short a wait in case someone wants to jump to the front.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 05 2011 at 22:58 | IP Logged
|
|
|
Pete's most likely right. I would think the ph_insteonwithret functions as the most likely suspect.
I'll trace the oode tomorrow to determine what happens if there are COMM problems while calling this function.
Dave.
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: December 06 2011 at 08:12 | IP Logged
|
|
|
dhoward wrote:
Pete's most likely right. I would think the ph_insteonwithret functions as the most likely suspect.
|
|
|
I think y'all have hit the nail on the head. Thinking back on my experiences, it seems like I have always noted that when PH performance seems very slow, I have seen that the Overhead door check macro was in the execution queue. Since it checks three doors every time it runs, there is a lot of potential for delays if the ph_insteonwithret function encounters issues.
I have noticed over the years that the EZIOxxx modules do not seem to have as good Insteon comm reliability as SmartHome units. Virtually all of my 70+ SmartHome Insteon devices have a COMM reliabily of 98-99% but my EZIO units seem to typically be in the 89% range (despite the fact that I have 2443 Access Point boosters within 10 feet of all my EZIO devices, otherwise there were almost unusable!) . . .
Per Pete's suggestion I put in 0.5 second Waits between the EZIO Read attempts, while that will help open the queue up to others during my back to back read attempts, I'm assuming that it won't really help if a particular read attempts gets hung up. The Wait doesn't get executed until after the ph_insteonwithret excution goes to completion, does it?
Dave does it make any sense to add a "timeout" parameter to the ph_insteonwithret function, so the read attempt aborts if unsuccessful for too long?
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 06 2011 at 08:23 | IP Logged
|
|
|
Here goes my 2 cents again. I think the way it is currently handled is sufficient without seeing the code. But I would have the (RET) return put into a wait queue instead of holding up other processes. If a timeout condition occurred or the return was satisfied it would then become active again. A similar problem occurs with the execution of X10 commands. I would like to see them put into a different queue while waiting to complete. But I may be in a minority on that one.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: December 06 2011 at 08:45 | IP Logged
|
|
|
Pete -
Excellent thoughts. It reflects your good Main Frame experience where Task Management included multiple prioritized execution queues. Obviously worked pretty well as I recall our big IBM 360/67 (requiring a whole floor of equipment in a very large building) which served hundreds of simultaneous time sharing users, yet had less performance that an iPad2 does today!
It is still hard to imagine, looking back, how we ever pulled it off.
Dave - thinking of your "prioritized" insteon command approach, I'm not sure you need to come up with a new methodology. Allowing all commands to be executed from the Boolean field really seems quite adequate to do everything I have desired. Perhaps if you can just focus on getting that to work, it gives a badly needed capability without having to come up with a whole new approach. 
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: December 06 2011 at 13:18 | IP Logged
|
|
|
Just wanted to post that I have been able to make a
SIGNIFICANT improvement in my overall performance this
morning.
I inserted 0.1 second Waits in every macro that polled
multiple devices or used a ph_insteonwithret function. I
had several macros that were quite long and ran often
(every ten minutes, for example) to poll device status,
or to update KPL button light states.
All of these now have WAITs interspersed.
I also enhanced (per BeachBums normal approach) my light
off macros (from a single switch tap) so that they do,
then test the results, and do again if needed. Using
judicious WAITs and limiting the tests to a max of 10.
The bottom line is things seem vastly improved. I still
vote for a "priorty" queue position function, however.
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Bug Reports
Topic: ph_macro does not execute immediately
