Active TopicsActive Topics  Display List of Forum MembersMemberlist  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin
PowerHome General
 PowerHome Messageboard : PowerHome General
Subject Topic: Insteon questions Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
jwshome
Newbie
Newbie


Joined: July 02 2006
Online Status: Offline
Posts: 17
Posted: December 29 2006 at 12:00 | IP Logged Quote jwshome

I have two questions that I hope someone can help to answer:

1. I don't understand the 'poll interval' and the 'status scan' items in the Insteon Exporer. Does Powerhome need to scan devices to know their status (or for some other purpose)? I thought Powerhome sits and listens for communications from devices, and updates their status accordingly.

The reason I'm asking is that the SDM log is constantly showing powerline communications, and I do't want this to slow the responsiveness of my devices when I turn them on and off via keypad controllers (see question below).

2. I have a simple macro (two lines) that turns on two devices that is triggered when one of the buttons on my KPL is turned on. The first device responds instantly, but the second device does not respond for abotu 20 seconds (the time varies). Any ideas what is causing this? Could it be caused by the insertion of a 'Wait' command into another macro? I inadvertently put this command into another macro and then later eliminated it, and restarted Powerhome.

Any help is appreciated, thanks ...

UPDATE: figured out the "macro delay" problem - I changed the Trigger from Immediate to Queued and the macro executes quickly. This is counterintuitive to me, but if it works ...


Edited by jwshome - December 30 2006 at 09:47
Back to Top View jwshome's Profile Search for other posts by jwshome
 
TonyNo
Moderator Group
Moderator Group
Avatar

Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
Posted: December 29 2006 at 13:44 | IP Logged Quote TonyNo

PH does pay attention to device comms, but it seems to me that the polling is a "belt and suspenders" approach. It can be disabled by clearing the Status Scan check box.
Back to Top View TonyNo's Profile Search for other posts by TonyNo Visit TonyNo's Homepage
 
jwshome
Newbie
Newbie


Joined: July 02 2006
Online Status: Offline
Posts: 17
Posted: December 29 2006 at 14:33 | IP Logged Quote jwshome

Thanks - I will disable the check box. But, will this reduce the reliability of my system?
Back to Top View jwshome's Profile Search for other posts by jwshome
 
TonyNo
Moderator Group
Moderator Group
Avatar

Joined: December 05 2001
Location: United States
Online Status: Offline
Posts: 2889
Posted: December 29 2006 at 17:55 | IP Logged Quote TonyNo

Dave would have to comment on that. I thought that there were some messages that devices sent that could be "trampled" by higher-priority ones, in which case polling could compensate for.
Back to Top View TonyNo's Profile Search for other posts by TonyNo Visit TonyNo's Homepage
 
dhoward
Admin Group
Admin Group
Avatar

Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
Posted: December 30 2006 at 19:54 | IP Logged Quote dhoward

The "Poll Interval" determines how often in seconds that PowerHome will do a background Insteon task. Device control commands or anything sent with the ph_insteon type functions are immediate and get priority over all else. The only time this may not happen right away is if PowerHome is in the middle of a background operation that takes a few seconds to complete such as creating a link. As soon as a "stopping point" is reached though, background operation will be paused and direct commands will then be executed.

A background operation is updating a link, deleting a link, scanning a link, creating a link, polling status, etc. The "Status Scan" does poll the status (on, off, dim level) of devices, but that is not it's primary purpose since as you said, PowerHome is listening to all communications and should keep status accurately by doing so. The main purpose of the "Status Scan" is that the same command also retrieves the "Database Delta" of a device. This is primarily what PowerHome is interested in and represents whether or not any changes have occurred in a devices internal link database. If PowerHome detects a change in the database, then it will rescan the device to make sure that it has all of the latest information.

If you are using "Only" PowerHome to manage and maintain links and are not creating links manually (tap-tap) or with other software, then it would be safe to turn "Status Scan" off. Since the same command gives database delta AND status information, the status is not wasted however and PowerHome WILL use the status info to make sure that it's internal status is up to date. This can be handy in case PowerHome was shutdown for a period of time (hence missing messages) or for the occasional "missed" message. While Insteon is much better than X10, it's not "perfect" and a message will occasionally be obliterated such that the PLC (and PowerHome) never sees it.

Usually, it's not a problem to leave this enabled however since it will rarely interfere or slow down direct commands (Choice, choices [:D]).

Concerning the "Queued" vs "Immediate" triggers. This causes people alot of problems. The default is "Queued", but people see "Immediate" and think that it's better. If anybody has suggestions for new terms for these two, Im all ears [:D].

Ive explained the differences before, but it's probably buried in the forums somewhere. Basically, when something causes a trigger to fire, it's possible to fire multiple triggers off of a single action. What happens is that PowerHome scans for all triggers that will be fired. If they are "Immediate", the are put into a temporary queue (first in, first out based upon alphabetical sorting of the Trigger ID). If they are "Queued", then they are added to the standard "Execution Queue" (where all keystroke triggered items normally go anyway). Once done with the current trigger evaluation, then PowerHome will process the temporary "Immediate" queue. If any of the "actions" of these immediate triggers attempt to send commands or "control" statements to a controller, then you will most likely hang the system or pick up wierd delays. This can especially be seen in Insteon. An incoming Insteon command is received, the Insteon controller module is paused, control transfers to trigger checking, an immediate trigger is fired that sends an Insteon command, the command goes to the Insteon controller, but the Insteon controller is currently paused in a state where it's still in the middle of the receiving routine. The internal memory of the controller is not ready for Insteon commands to be sent. With a queued trigger, the action is in the execution queue, the trigger routine finishes, control is returned to the Insteon controller, the receive routine completes, and control is transferred back to PowerHome where the execution queue is processed. The Insteon send command will then be sent to the Insteon controller and it will be in a state where it's ready to accept the command.

The ONLY time where an "Immediate" trigger should be used is when you need to update a variable, or check a variable instantly where further processing of the trigger routine may destroy a value (the incoming X10 queue used by multi-X) that needs to be maintained. As long as the action does not cause activity to be triggered on the same component that caused the trigger to fire in the first place (you could get a circular reference), then "Immediate" is safe.

It's difficult to explain adequately and Ive probably just confused more than I clarified, but the main thing is that the "action style" of "Immediate" vs "Queued" is not meant to imply that the action will happen quickly vs slowly, just how it's processed internally.

Hope this helps,

Dave.


Back to Top View dhoward's Profile Search for other posts by dhoward Visit dhoward's Homepage
 
jwshome
Newbie
Newbie


Joined: July 02 2006
Online Status: Offline
Posts: 17
Posted: December 31 2006 at 08:30 | IP Logged Quote jwshome

That's a great explanation, thanks. And I'm sorry that I did not find the answer elsewhere in the forum - it must be frustrating to have to answer the same question multiple times.

Regards.
Back to Top View jwshome's Profile Search for other posts by jwshome
 
dhoward
Admin Group
Admin Group
Avatar

Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
Posted: December 31 2006 at 12:24 | IP Logged Quote dhoward

No problem.

It helps to bring attention to the possibilities since I can attest to the fact that the "search" capabilities of the forum are rather lame [:D}.

Also, if anyone has any suggestions on possible terms that would be better than "Immediate" and "Queued", please let me know. After explaining the inner workings, they probably make sense but if you don't understand how it works (few people do, fewer care), it is counter-intuitive.

Dave.
Back to Top View dhoward's Profile Search for other posts by dhoward Visit dhoward's Homepage
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum