| Author |
|
patc
Groupie
Joined: December 02 2002
Location: United States
Online Status: Offline
Posts: 48
|
| Posted: March 25 2004 at 19:13 | IP Logged
|
|
|
Dave,
I'm looking forward to the Beta. In the meantime I got in trouble while testing some routines using the flags. I forgot to set a flag "complete" and now I've got a macro cycling forever waiting for the flag to change. How do I kill a running macro? I tried reinitializing, no luck. I tried exiting PH and restarting that didn't work either. I also tried executing a macro to reset the flag since its a global var but that didn't work. I'm hoping I don't have to back to my last backup. That was a days work ago.
__________________
PatC
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: March 25 2004 at 22:02 | IP Logged
|
|
|
Pat,
When you say the macro is recycling, is it because its being called from a timed event or is it a waiting macro that respawns. Either way, it'll be easy enough to fix.
If its a timed event, you can just press "Alt-F5" to toggle between timed events being on and off. Once timed events are off, you can open the Explorer and clean up the timed events table.
If its a waiting macro, there are a couple of functions that can be called kill waiting macros. They are ph_killmacrowait and ph_killallmacrowait. You can also go into the Explorer under Preferences and clear the "Resume Waiting Macros" field and restart PowerHome. Any waiting macros will be cleared from the macro wait table. You could then change this field back.
If its a case where PowerHome starts and you have absolutely no control to run ph_killmacrowait or turn off timed events, just exit PowerHome and edit the pwrhome.ini file. You'll find the TIMEDEVENTAUTOSTART and RESUMEMACROWAIT parameters under the [System] area. You could one or both of these to NO as your situation requires and restart PowerHome.
Hope this helps and let me know how it turns out.
Dave.
|
| Back to Top |
|
| |
patc
Groupie
Joined: December 02 2002
Location: United States
Online Status: Offline
Posts: 48
|
| Posted: March 25 2004 at 22:25 | IP Logged
|
|
|
Dave,
the macro was recycling a wait loop. I tried the ph_killallmacrowait because I was testing a called macro sequence three deep and didn't know which one was looping. ph_killallmacrowait solved the problem. Thanks,
<SCRIPT language=javascript>postamble();
__________________
PatC
|
| Back to Top |
|
| |
patc
Groupie
Joined: December 02 2002
Location: United States
Online Status: Offline
Posts: 48
|
| Posted: March 25 2004 at 22:34 | IP Logged
|
|
|
Dave,
I just remembered the PowerHome Stat window in this version so I ran the test again knowing it would cycle and sure enough there was my macro listed in the "Waiting Macros" window. That will allow me to be more specific via the ph_killmacrowait function. Is everything in this Stat updated in real time?
<SCRIPT language=javascript>postamble();
__________________
PatC
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: March 26 2004 at 09:16 | IP Logged
|
|
|
Pat,
Yep, the PowerHome Status window has helped me quite a bit as well. Yes, everything is updated in real time. You'll have to watch carefully though to see anything in the Execution Queue and Incoming Communications Queue since these are cleaned out very quickly. I tend to find the realtime eventlog to be one of the most useful troubleshooting tools.
Glad that the ph_killallmacrowait command fixed you up...it would have been a bummer to have to go back to a previously saved database  .
Dave.
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: November 27 2011 at 11:43 | IP Logged
|
|
|
This is a new input to an old thread, but it seems appropriate to continue on with this theme.
I have been plagued by the same problem for years, now.
I have a number of Insteon paddle switches that when tapped on or off trigger PH action sequences to control a number of lights in the room. When I leave my office room, I tap the ceiling light switch and via a PH Trigger this switch is supposed to turn out all of the lights in the room.
The problem is that it almost never responds quickly, but takes 20-60 seconds before actions are triggered! This means I have to stand by the door for up to a minute to make sure everything really happens. (It would be quicker to just walk around the room and manually turn things off! )
The Trigger simply calls a macro . . .
and the macro executes several Immediate actions and Posts less critical actions . . .
However, the "Immediate" actions are anything but that!
The only slowing influence I can determine, is that I have several Timed Event macros that check on light states and synchronize my KPL Pad lamps to track. I also have a timed event that checks the state of three garage doors to synchronize several KPL Pad lights with status updates. These KPL sync macros are all Posted actions yet I have notice by looking at my PH screen, that when these syncing macros are running the "DR On" macro that is supposed to control the down room office lights is at the end of the Execution Que and seems to have to wait for the sync checkers to finish before getting executed itself.
This seems to be contrary to the intent of the "Immediate" mode so I am . .
a) Puzzled at this behavior, and
b) Even more puzzled on how to solve it.
Any ideas gratefully accepted! 
Edited by GadgetGuy - November 27 2011 at 11:44
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: November 28 2011 at 15:45 | IP Logged
|
|
|
Ken,
If you can, also post a screenshot of the eventlog (assuming you're logging the relevant events) around the time the trigger occurs. This would help in determining what may be keeping the events from happening quick enough.
What I suspect is happening is background Insteon processing bogging things down. The way PH works is that all actions go into the execution queue. Its a first in, first out type of thing. When you trigger the Insteon Off command, the Insteon controller (PH control module) will receive this command and fire a trigger check (this does not go through the execution queue and triggers are fired as they occur). If a matching trigger is found and the Boolean field is true, then the "Action" of the trigger is added to the end of the execution queue (in this case, your DR OFF macro). If other items are ahead of it in the queue, then your macro may be waiting for awhile before it even runs. Once the DR OFF macro gets its turn in the queue, then the first 3 immediate commands will be executed right away...pending any the completion of any background Insteon processing. The Insteon controller (PH module) has several queues of its own. One of them is the direct command queue (what these commands would hit)...it has top prority. The second one is the group cleanup command queue...not group cleanups that you specifically issue (those are treated as direct commands) but group cleanups initiated via the built in PH processing as the result of sending a group command (which is also a direct command). Last is the background Insteon process queue. What could be happening to also slow down your processing is that if you've got background comms happening quite often and you've got alot of database scanning not using extended commands (8 Insteon reads per record) and perhaps not the greatest communications, then any direct commands will wait for the current background operation to complete. If you've got "Enable Pending" checked, then the background queue will always have something in it (unless all your devices have failed comms). An item from this queue will be processed once every poll interval. If this operation happens to be a link scan, that is 8 individual Insteon read operations. If the comms are a little iffy, you'll also have up to 3 retries per read. This could take several seconds before a background operation is completed. If a direct command is placed in the queue while one of these background operations are mid process, then the direct command will wait until the current background operation completes. After the background op completes, the direct queue will be checked and ALL pending direct commands will be executed. After the direct queue is empty, the group cleanup queue will then be processed. If a direct command arrives before the cleanup queue is empty, it will be processed as soon as the "current" cleanup command completes. Only after the direct and cleanup queues are empty will PH go back to processing the background queue. But the key here is that the direct (or cleanup) queue is only checked "after" the current operation is complete.
The rest of your lines in the DR OFF macro are "Post" commands. What this does is add the formulas to the end of the execution queue. So they wont run until the current macro is completed. If the DR OFF macro was the only thing running, then they will execute in order just as if they were immediate in the DR OFF macro.
So to sum up, the immediate commands will be executed immediately, they don't go to the execution queue but they don't even get a chance to run until the DR OFF macro is actually executed on its turn in the execution queue (other macros/formulas may be ahead of it). Posted commands go to the end of the execution queue. When the immediate commands are executed, they will wait in the Insteon direct command queue until the current Insteon operation being performed is completed. If a currently running background operation is taking a long time or there are other Insteon direct commands already in the direct command queue, the new commands must wait their turn.
Hope this helps to explain the inner workings a little better. A paste of the eventlog should help in determining where the slowdown is as well as a paste of your Insteon Explorer settings to see what may be going on in the background since background Insteon operations are not logged .
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: November 28 2011 at 16:07 | IP Logged
|
|
|
What would nice if there was a way to have an item go to the top of the execution queue. Right now the only way I seem to be able to control it is to place short waits in long macros.
Ken, the weather is nice down here… Time to come…
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: November 29 2011 at 17:55 | IP Logged
|
|
|
Dave -
(As always) Thanks for the comprenhensive response. Very informative!
Here is a screen capture of an attempt to turn off the room lights this morning. I lucked out and tapped the controlling switch just before a Timed Event occured . . .
It took a lot of image size reduction and compression to meet the 150K upload requirement, so these are a bit hard to read. [Sorry about that.]
Note that the light switch off tap was seen at 07:57:58 (red circle) and 6 seconds later (07:58:040 (orange circle)there was a Insteon Out commmand that turned on (actually dimmed back from off to a 20% on level)the light attached to the switch.
That command was fired from my macro but there was also a Group Off command issued by the macros that didn't happen. So I tapped the On (top) of the paddle switch at also the same 6 second point (purple circle), not realizing that some response to my initial tap was happening.
The Group Off command apparently was never seen by the room lights as nothing seemed to happen in that respect, although the KPL sync macro seemed to be turning the KPL buttons off.
What I captured is almost a best case scenario!
Usually I have to wait up to a minute before I get a response to my switch tap! 
__________________
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: November 29 2011 at 17:58 | IP Logged
|
|
|
BeachBum wrote:
What would nice if there was a way to have an item go to the top of the execution queue. Right now the only way I seem to be able to control it is to place short waits in long macros.
Ken, the weather is nice down here… Time to come…
|
|
|
Wish I was there Pete. The weather is awful here. Cold and big time rainy. The yard was underwater yesterday and it is snowing now.
Will be heading to Naples at the end of Feb, and then back up to your digs at the end of March, before heading back to MI at the end of April.
See you soon (hopefully) at the next PH user meeting.
Edited by GadgetGuy - November 30 2011 at 15:20
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: November 29 2011 at 18:59 | IP Logged
|
|
|
Ken,
Appreciate the screenshot but its too difficult for me to make out with any certainty. Feel free to email it to me and I'll be able to make a better determination.
The one thing that I can see and you mentioned in your message is that you're basically firing two triggers off of the one Insteon in message and what looks like DSS-OFFTAP (the second trigger) is what I believe is calling your DR OFF macro. When you have the case where multiple triggers can fire off a single condition, you can control the order of which fires first by the ID of the trigger. Triggers are fired alphabetically by ID when multiple triggers are fired. Since the second trigger is just a cleanup of keypad buttons, I would prefix the ID with a Z to make sure it always fires last since its just cleanup routines. This may help make the response time a little quicker for other things like your DR OFF macro.
The other things that Ive been thinking about for this type of thing is creating a special high-priority execution queue. This would be a queue that would always take priority over the normal execution queue. The only problem there is that everyone would probably just end up using that queue all the time and it would lose its purpose.
Another thing I may be able to work on is coming up with better interrupt routines for the background insteon processing. This would take a little work and I would need to be careful not to send commands mid background processing. Can you also post a screenshot of your Insteon Explorer so I can see what kind of background operations that may be taking place.
One other trick that I try not mention too often because it can potentially cause problems is that there is a way to bypass the execution queue on a trigger. You have to use care because it can cause unexpected results but it may help. Recall from my earlier flow of PH processing that when incoming insteon is received, triggers are checked immediately (they don't get added to the execution queue). Matching triggers then have their Boolean field evaluated. If the evaluation is non zero or logical true, then the action is added to the execution queue. The trick is that you get a formula evalution in the Boolean field. You could fast track your macro ahead of anything in the queue by making your Boolean field look something like:
ph_macro("DR OFF") + 1
The macro will be executed immediately and still add whatever action you'd like to the end of the execution queue. If you don't want to have an action added to the execution queue because you're doing the action in the boolean field you could do this:
ph_macro("DR OFF") * 0
A handy little trick when necessary but potentially dangerous.
Good luck
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: November 29 2011 at 21:44 | IP Logged
|
|
|
Thanks for the input Dave. Started using that tip earlier but it is a bit tricky. I still think it would be nice if we could prioritize it and let the chips fall where they may. I have some routines I don’t care when they complete and I have others that need to go right now and they get caught waiting to execute. In the “main frame” days we utilized that concept.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: November 30 2011 at 15:14 | IP Logged
|
|
|
Dave -
Sent you requested screen caps by email. For the bebefit of the forum I post here what happened with the "dangerous" ExecQueue trick.
I created a Boolean formula like this (switch on/off taps circled in red) See Boolean formulas in right field. . . .
It didn't seem to fire quickly after I tapped the switch at 14:57:06. After about 5-6 seconds the DR Off macro seemed to execute. But when I looked at the Event Log I discovered that there seemed to be a Comm Problem with the PLM (See System Message). . .
This is repeatable. I tried several times and always get the same Comm Error. Perhaps when the Queue is bypassed, some needed .dll is skipped over?
Also I note that although I renamed the Triggers so that the low priority actions started with a "Z" that the ZCC-D-STAIR seems to have fired first in the Event Log!?
Edited by GadgetGuy - November 30 2011 at 15:24
__________________
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: November 30 2011 at 15:37 | IP Logged
|
|
|
Same here… This in the Boolean field causes the same intermittent problem but the PLM keeps ticking.
IF ("{DARK_DAY_GATE}"="OFF",ph_setglobal_a("DARK_DAY_GATE","ON" )+ph_setglobal_a("DARK_DAY_TRIGGER","OFF")+ph_macro("DARK_DA Y_TRIGGER")+1,0)
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: November 30 2011 at 16:03 | IP Logged
|
|
|
OK - Solving a bit of the mystery, but sure at a loss as to why!
My macro to turn the Down Room lights off consisted of Insteon commands to turn the light switch I just tapped off, back on to a dim level for night lighting, and a Group command to turn the lights off . . .
ph_insteongroup ( "DR-LTS", ioff, 0 )
where the "DR-LTS" have been defined in the PH PLC/PLM Groups tab of IE as the room lights.
Even with the "dangerous" Boolean formula trick it was still taking 20 seconds to turn the (group) room lights off, although the light just tapped off does come back on almost instantly.
So. My curiosity aroused, I started debugging.
I found that if I make a single line macro with "ph_insteongroup ( "DR-LTS", ioff, 0 )" as the entry, and then "Play" it. It takes about 20 seconds before the lights go out.
I thought a Group command was supposed to be quick, but clearly it is NOT. 
So what is happening?
Edited by GadgetGuy - November 30 2011 at 16:05
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: December 04 2011 at 23:13 | IP Logged
|
|
|
Ken,
Concerning the ZCC-D-STAIR trigger firing first...is it an Insteon Group In trigger like DSS OFFTAP or is it a different type of trigger? I checked the source and an Insteon Device Change trigger will fire before an Insteon Group In trigger does. I should have clarified that triggers of the same type will fire in the alphabetical order of their ID but different type triggers fire in a particular order. In this case, you could create a virtual Insteon device as a responder of the controller that you're firing for Insteon group in and then create an Insteon Device Change trigger for the virtual device with a lower ID.
Performing an action in the boolean field does have its risks. I wasnt sure if the recent changes I had made to the Insteon controller would resolve the issue but it looks like it hasnt. Performing an Insteon send while an Insteon receive trigger is firing is still apparently a no no. You should be safe performing an innocuous formula such as updating a variable or similar but nothing that would result in an Insteon send being performed while in the midst of an Insteon receive. My bad  .
The Insteon group command should be quick. It doesnt require an ack and all devices that respond to the group should do so very quickly. We would need to see the event log to see how long between launching the macro and sending the group command. If the time is negligible but the devices didnt respond for some time, then it may be a communication issue and its possible that the light didnt respond until the group cleanup was sent (which could take a little time). Would need to see the eventlog to be sure.
I'll also try to work on some functionality to with a priority queue.
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: December 05 2011 at 07:57 | IP Logged
|
|
|
Ken, food for thought. Any actions taken by a touch of the physical paddle I want to send a group cmd from immediately I physically link them at the paddle and not in PH. The broadcast goes instantaneous. My reason for doing it that way is for backup purposes if the system goes down. Dumb me stupid logic as I have 4 backup systems running. Groups commands I initiate from PH go instantaneous when I issue them but using a trigger for an instantaneous response I find very unreliable. It is only instantaneous if there isn’t any other things going on. I have found different factors contribute to it such as to where it is placed on the execution queue and especially if there is any X10 activity as X10 I/O drags for a long time compared to Insteon. Hence my reasons for asking Dave a way to bump to the head of the queue. The controller failure msg, which is not a true failure, will show if you issue a macro from the Boolean that has I/O or that calls a macro that does I/O. Glad Dave explained how the ordering of the firing went. That explains a lot of whys???
__________________
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 15:24 | IP Logged
|
|
|
dhoward wrote:
Ken,
Concerning the ZCC-D-STAIR trigger firing first...is it
an Insteon Group In trigger like DSS OFFTAP or is it a
different type of trigger?
|
|
|
Dave my triggered action is a ph_insteongroupcu function
that sets KPL buttons to the new current state of a
trigger switch's change.
It is a very low priority task, so fast execution is not
an issue for me here. I was just surprised that based on
the trigger ID names that the "Z" executed before a "D"
named event! BUT. Your explanation cleared that mystery
all up!
Quote:
Performing an action in the boolean field does have its
risks ... You should be safe performing an innocuous
formula such as updating a variable or similar but
nothing that would result in an Insteon send being
performed while in the midst of an Insteon receive. My
bad .
|
|
|
OK. I seem to be getting away with it and it does do
what I wanted, that is, when you leave a room and tap the
designated switch OFF, all of the room lights quickly go
out! Have I just been lucky so far? And what is my risk
here? Will I bomb PH, or will my "quick task" just get
aborted. If the later then if the Boolean "Quicky"
works, I'm OK and if I append "+1" to my quicky, then at
least the trigger's normal Macro field will get executed
in the normal (albeit slower)fashion. Right?
Quote:
I'll also try to work on some functionality to with a
priority queue.
Dave.
|
|
|
PLEASE DO!!!!!!!!!!!
I really need a "quicky." 
__________________
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 05 2011 at 15:30 | IP Logged
|
|
|
BeachBum wrote:
Any actions taken by a touch of the
physical paddle, that I want to send a group cmd from
immediately, I physically link them at the paddle and not
in PH. The broadcast goes instantaneous. |
|
|
Pete - very interesting idea! In all these years, and
with almost 80 Insteon devices in my home, I have never
thought of doing this. It solves the "quicky" need for
some key locations.
But. That said, I am clueless at the moment as to how to
create a Group Broadcast command and link it to a switch.
Can you give me a kick start?
__________________
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 16:19 | IP Logged
|
|
|
Lee correct me if I’m wrong, but if you link each device one at a time they will end up in a group when you hit the paddle. Just hold the set button on the switch until it goes into linking mode and go to the light you want to link and press it’s set button until it stops blinking.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Bug Reports
Topic: ph_macro does not execute immediately
