| Author |
|
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 13:04 | IP Logged
|
|
|
So far no issues with red out in piggyback config (13 hours and counting now). I have never really known the time frame for this red out to occur, but usually every few days it happens - very similar to others experience on the forum. One question I have: how is COMM Reliability in the devices tab measured? All my Insteon devices are coming in at 97-99% with one or two in the low 90s range. All measure a specific percentile to the hundreths of a percent. My PLM is 50.00% exactly. This seems too precise at exactly one half, so I am wondering what exactly is being measured, and does 50.00% mean half is not being measured, or is something set up incorrectly? Is it a flaw in PH? Do all other have 100% for their PLM?
Edited by Handman - April 22 2009 at 13:06
|
| Back to Top |
|
| |
AllanMar
Groupie
Joined: April 02 2007
Online Status: Offline
Posts: 45
|
| Posted: April 22 2009 at 13:22 | IP Logged
|
|
|
My PLM has 1.11% reliability lol (Ive never had it come up as failed though). My PLM only has 150 Comm counts where as all my other devices have around 80-100k. So if your PLM has a high comm counts i suspect you have a weird link, or macro or something that is trying to contact the PLM in an improper way (powerhome sending out commands to try and control the PLM like a device? (guessing))
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 14:01 | IP Logged
|
|
|
The PLM comm count is only 210. The other 30 insteon devices are in the range between 70,000 and 170,000. I also have a 2414S PLC attached to an Elk M-1G that shows 600+ comm counts, but a 95% comm reliability. The PLC has been in place quite a bit longer than the PLM, though. Maybe when I parse through all the macros and triggers something will stand out.
Edited by Handman - April 22 2009 at 14:02
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 22 2009 at 14:21 | IP Logged
|
|
|
In theory PH should not be attempting any powerline communication with the PLM. I have a comm count of 84 which is just about the number of individual messages that were sent to the PLM as a result of my macro test. Each ph_insteon command results in PH issuing three Direct commands to the PLM as a responder, with all three attempts failing. After running the macro 5 times the PLM comm failed column is shaded red. With 5 macro runs times 3 individual command attempts, that makes 15 comm tries. I've run that test about 5 times which would take the comm count to 85. Not sure why 84 counted versus 85 expected. Just ran the macro test again, with PH trying the Direct command three more times, all failed. Now I have a PLM comm count of 87.
I don’t know what PH is using to develop the 50% number but it should not be making any attempts to communicate with the PLM over the powerline. The nature of the Insteon architecture is such that if the sending device (PLM in this case) gets its own message back, that is an error. It means the responder device that was suppose to react to the command and send an ACK failed to do so. There is no opportunity for the PLM to react to its own message because the very fact that the message appears back at the PLM is an error condition.
The piggy back of the Access Point may resolve or improve the problem you have controlling other Insteon devices but it should have no effect on PLM comm failed as there should be no communication directed to the PLM from the PLM to begin with.
Perhaps a picture will help.
SwithLinc A as a controller can send a message to the PLM as a responder and that is fine.
The PLM as a controller can send a message to SwitchLInc A as a responder and that is fine.
The PLM as a controller sending a message to the same PLM as a responder is invalid and will always fail.
The question is why is PH sending messages from the PLM as a controller to the same PLM as a responder. These will always fail. Does not explain why/how PH is calculating a 50% value, I would have expected it to be something like AllanMar is seeing.
I turned on Status Scan on my system to see if that would cause PH to attempt to query the PLM link database over the powerline. It did not but there could be some link found in another device that would prompt PH to attempt to scan the PLM via the powerline that I do not have on my system. By looking at the Event Log and Insteon Raw Log when the PLM comm failed turns red we should be able to determine what activity was in progress that prompted PH to attempt a communication with the PLM over the powerline rather than through the programmatic interface.
The activity to determine why PH is sending messages to the PLM as a responder, causing the PLM comm failed turning red is separate from determining why you have difficulty controlling the three devices from the macro.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 22 2009 at 14:36 | IP Logged
|
|
|
I wonder if there is some kind of communications going on between the PLC and the PLM. Controller to controller?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 14:57 | IP Logged
|
|
|
I agree with your assessment. The odd light operation is probably not related to the comm fails with the PLM. (It may be related to a fair number of extended insteon unmapped commands that appear in my event log.) I do have "status scan" on specifically to root out any issues.
OK, so my question is, once I get a comm failure (red shading) of the PLM, how do I know what time the 5th failed command was issued so I know WHERE to start looking in the event log? Also, I went to lower the maximum failures default from 5 to 2 to accelerate the discovery process. When I reinited I got a PH critical error: A critical error occurred at 2009-04-22 11:54:09.156.
PowerHome Version: 2.1b
Error Number: 35
Error Message: Error calling external object function <unknown> at line 5 in function f_initialize of object uo_plugin.
Window: uo_plugin
Object: uo_plugin
Event: f_initialize
Line: 5.
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 15:16 | IP Logged
|
|
|
Don't know why the critical error, but it seems fine now. I really don't understand how to search the event log using "filter" and "sort." These functions seem to me how I would look for communications between the PLC and PLM that might be causing the comm failure. Anyone use these before?
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 22 2009 at 15:17 | IP Logged
|
|
|
Handman, first let me say I owe you an apology for pointing the analysis in the wrong direction. A 50% comm reliability for a PLM in general indicates a powerline issue. I have several PLMs on my network and if any of them show a 50% reliability I have developed a powerline problem. However, what you clearly stated but I failed to pay attention to is that it is the PH Controller PLM being marked red. The rules for what is valid and what end results means is quite different between a PLM that is functioning as any other Insteon device on the powerline versus a PLM that is functioning as a PH Controller. It was not until other users posted in with similar Controller PLM symptoms that I realized we were analyzing a PH Controller PLM. Sorry for any confusion this has caused.
The net of all this is, PH cannot and should not be attempting to communicate with a PH Controller PLM as a responder device by any of the PH internal functions. Nothing stops a user from trying the same communication through an event or macro, as in the case of my test macro trying to turn On my Controller PLM as a responder. This could be a perfectly valid command to a PLM functioning as a normal Insteon device but it is totally invalid when directed to the PH Controller PLM. We will eventually determine why this type of communication is occurring but it is a separate question and different cause from the problem controlling the three devices.
Hope this explanation helps clarify what must have looked like a change in direction over night.
Changing the max failures to 2 has uncovered some bug in Powerhome. Go back to 5. What you are looking for in the Insteon Raw Log or the Event Log is ”any” Insteon message that has the Controller PLM as the To address in the Insteon message.
2009-04-22 15:09:10.468 TX &nbs p; 02 62 0F 44 DC 0F 11 00
2009-04-22 15:09:10.484 RX &nbs p; SENTINSTEON=0F 44 DC 0F 44 DC 0F 11 00 06
2009-04-22 15:09:10.687 RX &nbs p; RECEIVEINSTEONRAW=0F 44 DC 0F 44 DC 03 11 00
2009-04-22 15:09:14.484 RX &nbs p; INSTEON TIMEOUT=
The TX is the PH message resulting from my ph_insteon command. The To address of 0F.44.DC is my PH Controller PLM. This command can never work. The following RX SENTINSTON has both From and To Insteon address as that of my PLM. Cannot have from and to being the same address.
I assume you will find something that is directed to the Controller PLM and then back up in the Event Log or the Insteon Raw Log to see what was happening. Because the Insteon Raw Log can be written to a normal PC file, you can use Wordpad and search for your Controller PLM Insteon address. These entries are time stamped so you can then go to the Event Log to see what logically was going on in PH.
Edited by grif091 - April 22 2009 at 15:29
__________________
Lee G
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 16:02 | IP Logged
|
|
|
Apology totally unnecessary. Help is hugely appreciated. I feel like a dolt because I am not sure I was very clear (even though you say I was) that this PLM was the PH controller . . . that is because I have no idea how else it would be used! You say you have several PLMs on your network and it never occurred to me why anyone would have more than one! Of course I have a PLC on my Elk in addition to the PLM attached to the PH PC. The number of total comms to the PLM is holding steady at 210 so it's unlikely anything is in the raw log I started recording last night. After searching I have good and bad to report. My log file includes entries from two days in early March and since last night. There are several instances of the PLM trying to communicate with itself (oh behave!) in March, but not since it started recording last night. The bummer is that I have a macro to trim the event log every two days, so I can't look at what was happening there. Here is the raw log of several events in sequence:
2009-03-04 18:25:19.484 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-03-04 18:25:19.781 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 03 19 00
2009-03-04 18:25:23.484 RX &nbs p; INSTEON TIMEOUT=
2009-03-04 18:25:24.484 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-03-04 18:25:24.500 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-03-04 18:25:24.703 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 03 19 00
2009-03-04 18:25:28.500 RX &nbs p; INSTEON TIMEOUT=
2009-03-04 18:25:29.484 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-03-04 18:25:29.500 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-03-04 18:25:29.656 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 07 19 00
2009-03-04 18:25:33.500 RX &nbs p; INSTEON TIMEOUT=
2009-03-04 18:25:34.625 TX &nbs p; 02 62 0F 7A 5B 0F 19 00
2009-03-04 18:25:34.656 RX &nbs p; SENTINSTEON=0F 44 B1 0F 7A 5B 0F 19 00 06
2009-03-04 18:25:34.953 RX &nbs p; RECEIVEINSTEONRAW=0F 7A 5B 0F 44 B1 2B 0C FF
2009-03-04 18:25:35.000 TX &nbs p; 02 62 0F 7A 5B 05 28 00
There is nothing that I know of that is timed to happen at 6:25 pm, although it is kind of close to sunset maybe?
I'll continue to record the log and hope I can make a match with the event log.
Edited by Handman - April 22 2009 at 16:44
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 22 2009 at 17:25 | IP Logged
|
|
|
It would be helpful if we had both logs so we could match the time stamps. I still am wondering about PH trying to talk to Elk with a bad definition in a controller statement somewhere. I have multiple controllers for testing but the controllers don’t talk to each other although they share some devices.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 22 2009 at 17:42 | IP Logged
|
|
|
OK Lee, I got your search argument narrowed down. Just plug your own address in.
SELECT * FROM EVENTLOG WHERE (EVENT LIKE '%04.BB.8F%')
Edited by BeachBum - April 22 2009 at 17:43
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 22 2009 at 18:49 | IP Logged
|
|
|
That is the activity we are looking for. The command (cmd1) being issued is a 0x19 (dec 25) which is a status check command. Often issued against Insteon devices to determine if they are On and if so at what level. Also issued by PowerHome as part of the Status Scan process. Now the question is whether the sequence was initiated by PowerHome as part of a Status Scan operation which should not have included the Controller PLM or by some Event or Macro checking on the status of the PLM which also should not have been issued. When I turned on Status Scan last night on my PowerHome it did not queue up a request for a POLL STATUS: of the Controller PLM. I just started another Status Scan and again, there is no POLL STATUS; queued for my Controller PLM.
2009-03-04 18:25:24.484 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-03-04 18:25:24.500 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-03-04 18:25:24.703 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 03 19 00
2009-03-04 18:25:28.500 RX &nbs p; INSTEON TIMEOUT=
The TX is a Status Request 0x19 [dec 25] for 0F.44.B1 (was so close to my PLM address I thought I was looking at my trace). The RX SENTINSTEON has the To and From Insteon address of the Controller PLM which cannot work.
When looking at the cmd1 value in the Insteon Raw Log the value is show in hex as that is how it is sent and received on the powerline. When looking at the Event Log, Powerhome shows the cmd1 value in decimal. This is important as you may see many cmd1[19] entries but this is decimal 19 which is a 0x13 which is an Insteon Off command.
This may turn out to be a relatively harmless situation from the number of posts from other users seeing the same red shading of the Controller PLM. Once sufficient errors have been accumulated the entry is red shaded and no more status requests are done. Same as the RemoteLinc. Because the RemoteLinc is asleep most of the time when PowerHome does a Status Scan, the device query requests fail and the device entry is eventually shaded and no more queries are made of the RemoteLinc unless/until the column is checked to clear the failure. This is normal for a RemoteLinc and a Motion Sensor. Could be depending on the device options in effect, PowerHome does try to do a Status Check of the Controller PLM, eventually accumulating enough errors to shade it red and then stops checking the Controller PLM during a Status Check operation. As I mentioned before, this is unrelated to the three device control issue and may be harmless.
__________________
Lee G
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 22 2009 at 19:07 | IP Logged
|
|
|
I have several Inteon devices from SimpleHomeNet which use the PLM as the powerline interface (EZBridge, EZIO8SA, for example) which function as any other Insteon device would. These PLMs could function as PH Controller PLMs if the connection to the device was removed and the PLM connected to the PC.
You started out as saying you had replaced your PLC with the PLM. That is the flag waver that should have told me right off we were working with a Controller PLM and not where I went. I do some informal testing for SHN and most of my PLM interaction is with it as a device rather than a Controller.
You mentioned you have a PLC connected to an Elk. Any time you have multiple devices initiating powerline commands there is the possibility of conflicts. The more commands PowerHome and Elk put on the powerline async to each other the more possibility there will be commands from both products going on the powerline in an overlap situation. One stepping on the other so to speak. No difference than when a house full of people hit different switches at the same time.
EDIT: The Status Scan has made two full passes and no Status Query command 0x19 was issued against my Controller PLM. I'll collect up the Device and Type information and post that back later tonight. I may have defined my own Type entry way back when because this is an HL2 enabled PLM and I may have wanted to preserve the original PLM Type definition. That is not an absolute, just a maybe.
Edited by grif091 - April 22 2009 at 20:26
__________________
Lee G
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 21:36 | IP Logged
|
|
|
Lee, I am glad you and Pete are getting a better idea of what is going on because you are losing me. I don't know where you get your secret decoder rings, but I couldn't tell you what any of the hex or decimal means beyond the addresses. So far no red-shading, but as soon as I see it, I'll pass on the event log and raw log info and maybe you can nail this down. A lot more macro and triggers run on my system at night, so time will tell.
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 22 2009 at 22:07 | IP Logged
|
|
|
Wow, pretty busy thread  . Lots of good info. I'll try to fill in any missing pieces with an explanation of how it should work.
When the "Clear Failed" column gets a reddish background, that means that PowerHome (using whatever controller is the currently connected controller) has tried to communicate with the device (using "direct" communications..ie direct or group cleanup but not group broadcast) and the communications have failed. Standard procedure is for PowerHome to automatically retry direct commands 3 times. When this triple attempt fails (all 3 attempts must fail), PowerHome increments the Failed count by 1. When this Failed count meets or exceeds the "Max Failures", then this column is shaded red. Now if even a single direct command is successful, then PowerHome will zero out the Failed count column. Once the device is flagged as "Failed", then PH will no longer attempt any "background" direct communications with the device. What is meant by "background" are PH generated Status requests, link create, link modify, link delete, etc. commands. A direct command such as an On, Off, etc. command (including group cleanup commands) initiated by the user (a device status key, macro, trigger, formula, etc.) will still be sent. Only the commands that would normally show in the "Pending Operations" window will no longer be attempted until the Failed count is either cleared or is below the max failures value.
Now the "Reliability" column is nothing more than a calculated field. In the Insteon Explorer, Devices tab, scroll all the way towards the right and you'll see columns labeled ACK Count, NAK Count, Event 03 Count, and COMM Count. The current version of PowerHome (2.1b) has minor errors in these columns (which should be fixed in the upcoming beta...in any event the errors are small enough so as not to effect the usage of these columns and data) and some mis-labeling in the columns (also corrected). The COMM Count column is incremented anytime PH attempts a direct command (background or user generated). If the command is acknowledged successfully by the device, then the ACK count column is incremented. If the command "times out" (no response), then the NAK count column is incremented instead (this is part of the problem since an Insteon NAK is a different command altogether...a NAK is actually an acknowlegement but the command could not be carried out successfully). The Event 03 field is different depending upon if the controller is a PLM or a PLC (they will be the same in the next beta) but is essentially the amount of time it takes for a direct command to be sent from the PH controller to a device and the ACK (or NAK) to be received back. The longer this trip takes can mean that the device is further away from the controller than other devices (and thus needing to be repeated) OR can also be an indication of poor communications. This value is best evaluated alongside of the NAK count (soon to be the Timeout count). If the NAK count is very low but the Event 03 count is higher than other devices, then the device is probably just farther away than other devices and all is working normally. However, if the NAK count is higher than normal AND the Event 03 count is high, then it would tend to indicate a communication problem that should be looked at. With that explained, the "Reliability" column is just the ACK count divided by the sum of the ACK and NAK counts [ACK / (ACK + NAK) * 100.0]
Now, concerning the problem that some people are seeing with their PLM/PLC being flagged as COMM Failed (the reddish background). This has me stumped because it shouldnt be occurring. PowerHome should not be doing ANY background communications with its controller device. As has already been stated, a user operation may be initiated against the PLC/PLM and this will indeed increment the Failed Count (it will never get a successful return and so eventually the Failed count will meet or exceed the Max failures). Now, what keeps PowerHome from attempting background communications with the controller such as Status Request? The "PowerLinc" flag being checked in the Insteon Types table for the controller type. So, if your ID of your PowerHome controller is "PLM" with an Insteon Type of 2412S, then the "PowerLinc" flag in the Insteon Types table for the 2412S should be checked. If it is unchecked, then PH will attempt background Status Requests with the device so I would definately check this.
Now, if for some reason PH (or the user) is sending direct commands to the controller and the controller is being flagged as failed (reddish background) or has a low "Reliability", then this will have NO effect on the actual operation of PowerHome. The reddish background only means PH will not attempt background commands with the controller (which it shouldnt be doing anyways). The Reliability is simply a calculated field of the ratio of ACK's to the total of ACK's and NAK's so will also have no effect on normal operations. It would however be interesting to know what is causing the communication in the first place but it will have no effect on the overall operation.
I realize this doesnt help with the original question, but hope it helps to explain some of what is being seen.
Dave.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 22 2009 at 23:24 | IP Logged
|
|
|
Wow, did you take a deep breath in that explanation… VERY informative. I still go back to my original concern that the PLM is being flagged. Lee was able to duplicate it but I’m not sure he is duplicating the actual failure. My other concern is a PLM and PLC both being used if not possibly being incorrectly defined in PH.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 22 2009 at 23:39 | IP Logged
|
|
|
Right on, Dave. Thanks for the briefing. As soon as my PLM reds out, I will trace the logs and post it. So far it's behaving. Pete, for what it is worth, the PLC is attached to the M1XSP and is independent of the PH network because my PC is not connected to the M1 (and, unfortunately, PH cannot communicate with the M1 by way of the PLM to PLC). MY PC has been connected the the M1 before, but due to the location of the alarm panel and my PC, they are not connected normally. Therefore, there is only one active controller with PH and that is the PLM. The PLC turns on or off lights based on hard-wired door sensors, or it turns on certain lights if smoke alarms are triggered. There is some overlap of lighting groups with the PLC and PLM, but only if a smoke alarm is triggered (so far only once a year or so). Still, I have noticed communications between the PLC and PLM every once in a while when I am so bored that I read the event log. I can't recall what they "tell" each other, but I think it is basic "status" information. Wild, weird stuff.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 23 2009 at 00:42 | IP Logged
|
|
|
Dave, thanks a bunch. I think that fills in the missing piece regarding the usage of the Status command.
Handman, under the Devices tab, the PLM device entry, “Device Type” column, what device type was selected for your PLM?
For the Device Type that was selected, under the Types tab for that device type selection, is the PowerLinc column checked?
For my PLM device definition (under Devices tab), I selected “2412SH – PowerLinc Modem Serial HL2” in the Device Type column. Under the Types tab for that device type, the PowerLinc column is checked. Based on Dave’s explanation the PowerLinc column being checked is why my system does not issue Status commands against the PLM itself.
Based on the Insteon Raw Log that you posted the Status command is being issued for the PLM and that would suggest the “Device Type” that was selected for your PLM device definition does not have the PowerLinc column checked under the Types tab.
Pete, I was not recreating the actual condition causing the PLM entry to be shaded. From the Insteon Raw Log that Handman posted, the shading is being caused by Status commands being issued to the PLM which is presumed to be caused by a missing PowerLinc column check for whatever Device Type that was selected for the PLM device entry.
I think that covers everyone, I hope.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 23 2009 at 08:17 | IP Logged
|
|
|
Handman, thanks for clarifying the PLC in the gambit of things. That is similar to the approach I used a second controller for. The problem is the possibility of collisions in the network but that would not cause this problem. BTW how is the reliability coming?
Lee, I can also create the failure including the Critical Error. I would also be looking for the usage of PH_GETINSTEONLEVELRT(“PLM”) in some macro.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 23 2009 at 09:44 | IP Logged
|
|
|
Pete, that type of call would do it. We should be able to tell by finding the Status command in the Insteon Raw Log, using the time stamp of the command as an entry point into the Event Log to see what if any Timed Event, Macro, etc was in progress at the time. I had not paid any attention in the past but I found nothing in the Event Log regarding the PH background activity for Status Scan. So, if the Event Log shows nothing when the Status command is issued, it would be attributed to background activity which brings the PowerLinc column into question (which I hope we hear something from Handman or one of the other users with the red shading condition about which Device Type entry is being used). Or the Event Log will show some foreground activity in a Macro or something else that will identify where the command came from.
I looked at the various PLM Type definitions on my system, they all have the PowerLinc column checked and I do not have the Status command being issued against the PLM during a Status Scan. With more than one user posting the red shading symptom either that column is not checked on some PH systems, some other Type is being used for the PLM device entry, or PH is still doing Status checks against the PLM even with the PowerLinc column checked under some circumstance.
Since PH runs fine with the PLM entry red shaded this is really a "the machine is not smarter than I am" exercise.
__________________
Lee G
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PLM clear failed, and more
