| Author |
|
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 23 2009 at 09:56 | IP Logged
|
|
|
Your assumption is correct but I haven’t seen an event log timed to the raw log. Also on my system one cannot change the checked mark for PowerLinc. I seriously doubt PH is causing the problem and so far I have not been able to duplicate the problem except by using Insteon commands. I use PH_GETINSTEONLEVELRT all the time in my error recovery routines. There might be some macro or trigger doing the same thing but with the PLM id instead.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 23 2009 at 13:10 | IP Logged
|
|
|
<<Handman, under the Devices tab, the PLM device entry, “Device Type” column, what device type was selected for your PLM?>>
2412S - Powerlinc Modem Serial (I have not selected HL2 because the Houselinc 2 version is different from what I purchased from Smarthome, although I don't know how the PLM differs)
<<For the Device Type that was selected, under the Types tab for that device type selection, is the PowerLinc column checked? >>
The PowerLinc column is checked for the PLM (and for the PLC). For what it is worth, I tried to uncheck it since Pete said he couldn't uncheck his, and I got a PH critical error message and it did not uncheck.
A critical error occurred at 2009-04-23 10:09:34.906.
PowerHome Version: 2.1b
Error Number: 6
Error Message: Invalid DataWindow row/column specified at line 509 in itemchanged event of object dw_detail of w_explorer.
Window: w_explorer
Object: dw_detail
Event: itemchanged
Line: 509
My PLM is still working fine with no red outs. Reliability is still at exactly 50.00%, but none of the counts has changed since the original posting (acks, Naks, Event 03, etc.) I have lowered the failure count to 2, so as soon as I see something, I'll post it, but after a normal night of macros, nada.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 23 2009 at 13:36 | IP Logged
|
|
|
Thanks, that is what the definitions should look like. I use the HL2 definition because I am running with one of those special PLMs enabled for HouseLinc2 (which no one seems to know or is willing to document what the difference is). PowerHome does not doing anything different when using an HL2 enabled PLM. The error when the PowerLinc column is unchecked will be fixed in the next PH release (per Dave post on another thread). You want the PowerLinc column checked anyway.
The counts are not changing as whatever was trying to talk to the PLM as a responder is not happening right now.
Do you run with the "Status Scan" option checked or unchecked? Maybe run it sometimes and not others? The Status Scan function queries the defined devices with the 0x19 Status command. The Status Scan function should not be querying the PLM when the PowerLinc column is checked.
Even if/when the PLM device entry becomes red shaded, PH should continue to run correctly. That would only stop PH from running a background activity against the PLM on the powerline side which it should not be doing anyway (per Daves post above).
Edited by grif091 - April 23 2009 at 14:13
__________________
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 14:09 | IP Logged
|
|
|
Lee, I have found the scan will run in the background even if you have Status Scan uncheck. If Enable Pending is check and Status Scan is not sometimes background scan will occur. BTW I was able to create the same problem with Insteon - PLM - Fast On in a macro. So there are many ways the PLM will become shaded red. Still would like to see the failure with Event Log plus Raw.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 23 2009 at 14:18 | IP Logged
|
|
|
Yeah, I have figured out that the red shading is more of a nuisance alert than anything else. I thought it might have had something to do with my original issue that I posted at the start of this thread (once upon a time ago now). I can live with the shading whatever the cause, but I will be certain to post what I can find if/when it happens again (assuming my wife hasn't left me by then  .
I run with status scan on most of the time, but once everything is really working (haha) I will plan to turn it off. I have one device that does consistently red out. It also generally needs to be reset (air gap pulled on switchlinc dimmer). I tried to use the insteon raw log compare to the event log method of troubleshooting, but alas, there is nothing in the event log to compare time stamps, so at least this issue is the result of a normal status scan or something else that isn't logged. (I currently log everything in the event log). There is something about the location of that switch that causes problems. I have tried three switches and all lock up after the switch is on, in combination with other switches, for a period of time. Oddly enough, the Insteon reports show decent communications with the switch, even though it physically locks up and is red shaded! I am not sure whether the electronic ballasts in the individual low-voltage halogens on that circuit are to blame or the nearby outdoor CFCs on the other side of the wall, or something entirely different. The really strange thing is that this switch is one of three on the same light circuit and the other two don't lock up and they are closer to the potential source of noise/interference (electronic ballasts). Anyway, I digress.
In looking at the raw insteon logs I realize that I understand very little of what is in this logs. Is there a file/document that list all the insteon commands somewhere so I could interpret what some of the devices are transmitting?
Finally, I am not sure, but I think the problem with my light turning on (original issue on day 1) might be because the switch has somehow associated an X-10 code with it. That is, a wireless X10 motion sensor might be triggering the switch directly and not as a result of a trigger/macro. PH does not show any associated x-10 housecode for the dimmer, but I am not sure PH would do this without my manual input of the code anyway. More troubleshooting . . .
Anyway, thanks again for you interest and help.
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 23 2009 at 14:26 | IP Logged
|
|
|
Pete, that is interesting. Does it scan all the devices and do you know why PH decides to do the scan?
I don't think any command sent to the PLM through the PLM will work. All for the same reason. If the command gets back to the PLM on the powerline side, by definition it failed because the PLM is expecting an ACK or NAK from the responder. When it sees the orignal command come back it looks like the responder did not pick it up so it is interpreted as an error. The command itself was not evalutated.
__________________
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 15:05 | IP Logged
|
|
|
Lee, I don’t know what the criteria is for putting scans in the Pending Operations. I know if you do any linking it will. But now I have one sitting that reads Scan Link Record 43 and if I check Enable Pending it will take off. This may be normal but I don’t like to scan because it flickers on my X10 tracks.
Handman, I have acuminated years of experience fighting noise with X10. Your “electronic ballasts in the individual low-voltage halogens” is a major cause of noise.  On mine I use dimmers also. I tried Insteon but they don’t work worth a hoot in a noisy environment. I have found over the years the Leviton HCM06-1D works flawlessly. The only way I have found to fight the noise from those circuits is to surround them with Access Points and then the Insteon seems to work. But I have been able to get away with some low voltage tracs with Insteon but they are limited in wattage. I have also experienced problematic situations where I trigger a Insteon device with an X10 H/C and at the same time PH is also talking to the same device in Insteon. Solution, don’t do it.
Edited by BeachBum - April 23 2009 at 15:06
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 26 2009 at 00:14 | IP Logged
|
|
|
Well, it finally happened again. The PLM tried to communicate with itself and redded out. The event log shows that an insteon device (an icon dimmer switch)sent out a broadcast to "Stop Man Chg." Then the PLM tried to send itself three status requests. Here is the event log and raw log.
2009-04-25 18:49:28.531 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:49:29.156 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:49:31.359 RX &nbs p; RECEIVEINSTEONRAW=0B 23 41 00 00 01 C7 18 00
2009-04-25 18:49:31.609 TX &nbs p; 02 62 0B 23 41 0F 19 00
2009-04-25 18:49:31.625 RX &nbs p; SENTINSTEON=0F 44 B1 0B 23 41 0F 19 00 06
2009-04-25 18:49:31.984 RX &nbs p; RECEIVEINSTEONRAW=0B 23 41 0F 44 B1 27 00 85
2009-04-25 18:49:32.156 TX &nbs p; 02 62 03 B6 01 0F 19 00
2009-04-25 18:49:32.171 RX &nbs p; SENTINSTEON=0F 44 B1 03 B6 01 0F 19 00 06
2009-04-25 18:49:32.531 RX &nbs p; RECEIVEINSTEONRAW=03 B6 01 0F 44 B1 27 00 84
2009-04-25 18:49:32.703 TX &nbs p; 02 62 0D 4E 66 0F 19 00
2009-04-25 18:49:32.718 RX &nbs p; SENTINSTEON=0F 44 B1 0D 4E 66 0F 19 00 06
2009-04-25 18:49:33.015 RX &nbs p; RECEIVEINSTEONRAW=0D 4E 66 0F 44 B1 2B 19 00
2009-04-25 18:49:33.156 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-04-25 18:49:33.171 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-04-25 18:49:33.390 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 03 19 00
2009-04-25 18:49:37.187 RX &nbs p; INSTEON TIMEOUT=
2009-04-25 18:49:38.156 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-04-25 18:49:38.171 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-04-25 18:49:38.328 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 07 19 00
2009-04-25 18:49:42.171 RX &nbs p; INSTEON TIMEOUT=
2009-04-25 18:49:43.156 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-04-25 18:49:43.171 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-04-25 18:49:43.328 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 07 19 00
2009-04-25 18:49:47.171 RX &nbs p; INSTEON TIMEOUT=
2009-04-25 18:49:49.765 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:49:50.406 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:50:03.062 TX &nbs p; 02 62 03 5D 09 0F 19 00
I doubt it has anything to do with the trigger (TV ROOM LT ON2) because it fires all the time and is set to turn off a light in a room late at night using X10.
The device "B5" is suspect. I noticed recently that the little amber led flashes whenever there is insteon traffic on the powerline, the same way the led on a PLC or PLM would flash. The device is linked with one other icon dimmer and they control five LV halogen can lights. The switch's operation has been practically flawless for three years, other than the flashing LED which is a pretty recent development. I have had other switches that have had their LEDs flash in response to network traffic. Usually rebuilding the links has taken care of it, although I can't say I have been aggressive about it since I considered it odd, but not a problem. Thoughts?
Oh, I almost forgot. PH was polling at the time. I rebooted and forgot to uncheck status scan.
Edited by Handman - April 26 2009 at 00:17
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 26 2009 at 02:58 | IP Logged
|
|
|
There was an X10 L10 ON received at 18:49:29 which looks like it caused trigger TV ROOM LT ON2 to fire.
That was followed at 18:49:31 by a Group Broadcast from 0B.23.41 (B5) Group 1 Stop Dim/Bright which was in the Raw Log and the Event Log. Someone was doing a manual Dim or Bright and released the switch which results in the Stop Dim/Bright command 0x18 (dec 24).
There three Status Requests, to 0B.23.41, 03.B6.01, 0D.4E.66 which are not in the Event Log which should indicate they are part of the background Status Scan operation.
Then there is a Status Request at 18:49:33 checking the status of the PLM. This is a bad command and since it is in the Event Log Powerhome thinks this came from a foreground activity, not the background Status Scan. The last trigger to fire was TV ROOM LT ON2 which suggests the PLM Status request came from something this trigger did. Can you post this trigger? Since there were three Status checks that also ran in the background perhaps something the trigger relies on to determine what device(s) it will communicate with was affected by the background Status Scan operation.
I am looking at only a snip it of the Raw Log and the Event Log so there could be something earlier that actually generated the PLM Status request that I cannot see. The fact that the activity is in the Event Log suggests it came from something you implemented rather than being part of the background Status Scan.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 09:44 | IP Logged
|
|
|
Lee, what does “stop Man Chg” do and since it’s incoming who did it?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 26 2009 at 10:45 | IP Logged
|
|
|
Pete, a light is Off, you press the On paddle/button and hold it. Because the paddle/button is held On a command 0x17 Start Man Chg is issued that starts the ramping up of the responder. When the desired Bright level is reached, the paddle/button is released and the 0x18 Stop Man Chg command is issued. Same sequence of commands is issued if the light is On except the responder starts to Dim, stopping when the paddle/button is released.
In this case the command came from 0B.23.41 which the Event Log identified as device ID "B5" Group 1. This could be an ICON switch or button 1 of a KeypadLinc.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 10:54 | IP Logged
|
|
|
Thanks Lee… I wondering if the module has dual addressing in it?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: April 26 2009 at 11:06 | IP Logged
|
|
|
Handman, most of my switches are ICON, dimmer or relay, and the orange LED does not blink. These are old devices so later versions might do something different. A KeypadLinc button LED will flash rapidly if a responder device does not answer. It is a visual indication that something is wrong. The KPL button flashing can be the result of responder that no longer has power, has been unplugged, or the link database in the KPL has been corrupted such that the responder device address is not valid. Perhaps your ICONs are a later version where the orange LED flashes if a responder does not answer.
Pete, no way to tell from the traces but since the device id is “B5”, could be.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 11:15 | IP Logged
|
|
|
The reason why I asked is I have experienced a lot of problems with dual addressing. Mainly when something like a ControLinc and a module have the same X10 address and PH has a Insteon address to the same device and a Trigger is triggered. The results are unpredictable except the process ends in a disaster especially with the speed of the PLM.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 26 2009 at 13:45 | IP Logged
|
|
|
The Insteon device "B5" is an icon dimmer ver 1.6. Ver 1.2 was the one where Smarthome had a lot of paddle issues. I have many of the ver 1.6 icons and none of the LEDs flash with Insteon communications except this one (and there is nothing in the manuals explaining that it should flash). I do have one Switchlinc V2 dimmer that has also had this behavior in the past. The switch (B5) is paired/linked with one other switch and they communicate perfectly (i.e., the links are verified and they operate normally). Also, the flashing is happening with ANY network communications, not just the comms to/from that device.
I specifically recall setting the dim setting on that icon switch because it was at our kitchen table for dinner. So, yes, Lee, you are spot on.
As for the trigger "TV ROOM LT ON2" is very basic: if motion is detected by L10 (a wireless X10 motion sensor -MS14 I believe) and an L10 ON signal is picked up by PH, then the trigger sends out an X10 command (C9 ON) to an RR501 receiver which turns on a living room light. The trigger fires every time motion is detected in the living room, but only sends the ON command (C9) between 11:30 pm and DUSK.
I don't understand what you guys mean by "dual addressing." Nothing I have set up has the same X10 address. I have 30 insteon devices and 2 RR501 transceivers (for activating table lamps addressed at C1 and C9) and 8 wireless X10 motion sensors (addresses of L2/L4/L6/L8/L10/L12/L14). I also have 2 DS10A X-10 wireless magnetic contact sensors (addresses of D1 and D2). I hope this helps. Here is the rest of the raw log, preceding the three PLM self-requests:
2009-04-25 18:46:26.062 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:46:26.140 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:46:47.171 RX &nbs p; RECEIVEX10RAW=BB 00
2009-04-25 18:46:47.734 RX &nbs p; RECEIVEX10RAW=B3 80
2009-04-25 18:46:58.343 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:46:58.921 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:47:05.968 RX &nbs p; RECEIVEX10RAW=B8 00
2009-04-25 18:47:06.546 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:47:26.078 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:47:26.656 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:48:14.093 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:48:14.875 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:48:38.578 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:48:39.171 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:48:58.296 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:48:58.890 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:49:17.593 RX &nbs p; RECEIVEX10RAW=BA 00
2009-04-25 18:49:18.218 RX &nbs p; RECEIVEX10RAW=B3 80
2009-04-25 18:49:18.468 TX &nbs p; 02 62 03 BA 9A 0F 13 00
2009-04-25 18:49:18.484 RX &nbs p; SENTINSTEON=0F 44 B1 03 BA 9A 0F 13 00 06
2009-04-25 18:49:18.796 RX &nbs p; RECEIVEINSTEONRAW=03 BA 9A 0F 44 B1 2B 13 00
2009-04-25 18:49:19.000 TX &nbs p; 02 62 03 D1 A8 0F 13 00
2009-04-25 18:49:19.015 RX &nbs p; SENTINSTEON=0F 44 B1 03 D1 A8 0F 13 00 06
2009-04-25 18:49:19.328 RX &nbs p; RECEIVEINSTEONRAW=03 D1 A8 0F 44 B1 2B 13 00
2009-04-25 18:49:28.531 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:49:29.156 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:49:31.359 RX &nbs p; RECEIVEINSTEONRAW=0B 23 41 00 00 01 C7 18 00
2009-04-25 18:49:31.609 TX &nbs p; 02 62 0B 23 41 0F 19 00
2009-04-25 18:49:31.625 RX &nbs p; SENTINSTEON=0F 44 B1 0B 23 41 0F 19 00 06
2009-04-25 18:49:31.984 RX &nbs p; RECEIVEINSTEONRAW=0B 23 41 0F 44 B1 27 00 85
2009-04-25 18:49:32.156 TX &nbs p; 02 62 03 B6 01 0F 19 00
2009-04-25 18:49:32.171 RX &nbs p; SENTINSTEON=0F 44 B1 03 B6 01 0F 19 00 06
2009-04-25 18:49:32.531 RX &nbs p; RECEIVEINSTEONRAW=03 B6 01 0F 44 B1 27 00 84
2009-04-25 18:49:32.703 TX &nbs p; 02 62 0D 4E 66 0F 19 00
2009-04-25 18:49:32.718 RX &nbs p; SENTINSTEON=0F 44 B1 0D 4E 66 0F 19 00 06
2009-04-25 18:49:33.015 RX &nbs p; RECEIVEINSTEONRAW=0D 4E 66 0F 44 B1 2B 19 00
2009-04-25 18:49:33.156 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-04-25 18:49:33.171 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-04-25 18:49:33.390 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 03 19 00
2009-04-25 18:49:37.187 RX &nbs p; INSTEON TIMEOUT=
2009-04-25 18:49:38.156 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-04-25 18:49:38.171 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-04-25 18:49:38.328 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 07 19 00
2009-04-25 18:49:42.171 RX &nbs p; INSTEON TIMEOUT=
2009-04-25 18:49:43.156 TX &nbs p; 02 62 0F 44 B1 0F 19 00
2009-04-25 18:49:43.171 RX &nbs p; SENTINSTEON=0F 44 B1 0F 44 B1 0F 19 00 06
2009-04-25 18:49:43.328 RX &nbs p; RECEIVEINSTEONRAW=0F 44 B1 0F 44 B1 07 19 00
2009-04-25 18:49:47.171 RX &nbs p; INSTEON TIMEOUT=
2009-04-25 18:49:49.765 RX &nbs p; RECEIVEX10RAW=BF 00
2009-04-25 18:49:50.406 RX &nbs p; RECEIVEX10RAW=B2 80
2009-04-25 18:50:03.062 TX &nbs p; 02 62 03 5D 09 0F 19 00
2009-04-25 18:50:03.078 RX &nbs p; SENTINSTEON=0F 44 B1 03 5D 09 0F 19 00 06
2009-04-25 18:50:03.390 RX &nbs p; RECEIVEINSTEONRAW=03 5D 09 0F 44 B1 2B 00 00
2009-04-25 18:50:03.531 TX &nbs p; 02 62 03 5D 09 05 28 00
2009-04-25 18:50:03.546 RX &nbs p; SENTINSTEON=0F 44 B1 03 5D 09 05 28 00 06
2009-04-25 18:50:03.750 RX &nbs p; RECEIVEINSTEONRAW=03 5D 09 0F 44 B1 21 28 00
2009-04-25 18:50:03.875 TX &nbs p; 02 62 03 5D 09 05 2B 22
2009-04-25 18:50:03.890 RX &nbs p; SENTINSTEON=0F 44 B1 03 5D 09 05 2B 22 06
2009-04-25 18:50:04.093 RX &nbs p; RECEIVEINSTEONRAW=03 5D 09 0F 44 B1 21 2B 21
2009-04-25 18:50:04.218 TX &nbs p; 02 62 03 5D 09 05 2B 32
2009-04-25 18:50:04.250 RX &nbs p; SENTINSTEON=0F 44 B1 03 5D 09 05 2B 32 06
2009-04-25 18:50:04.718 RX &nbs p; RECEIVEINSTEONRAW=03 5D 09 0F 44 B1 26 2B FE
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 26 2009 at 13:56 | IP Logged
|
|
|
BTW, this is a tad unrelated, but is there an easy way to rename my devices and have all the triggers and macros update? I originally named my devices on the X10 codes that the ELK M1 uses. Oh my, that may explain the dual addressing . . . Elk identifies all insteon based on X10 addresses. That is why the kitchen table light switch is called B5. If Elk wanted to turn that light on, it would send a command to turn B5 on and then the PLC connected to Elk would issue the command to the insteon address. Still, if a command was issued by the Elk and PLC, I am assuming that the PLM would pick up this signal and not just the insteon device. There really are almost no commands that come from the Elk to control lighting, and unfortunately, there is no event logger for the Elk.
EDIT: this is not correct, after rereading the manuals, Elk uses it's own naming/numbering convention. It uses the numbers 1-192 for lighting devices and 193-254 for groups. X10 house codes are referenced with these Elk numbers, but not relevant to the Elk's operation. Therefore, house code A1 is Elk lighting device 1, A2 is 2, but the X10 code is not necessary to the Elk's operation. Since I did my Insteon lights in sequence, each new Elk light received an X10 house/unit code and that is why I named them by X10 codes. Years later after looking at event logs, I have decided that this "coding" makes it a lot harder to try and figure out which lights are operating. 
Is there an easy way to replace my old device names with new ones, or do I have to go in each macro/trigger if I want to change it?
Edited by Handman - April 26 2009 at 14:29
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 14:15 | IP Logged
|
|
|
Lee, I don’t know if we had the conversation with Handman BUT how was the PLM loaded? Was it Min or Full? Just a long shot but trying to eliminate problems we’ve seen in the past.
Dual addressing I was referring to is an Insteon device with both an X10 address and an Insteon address. I’m assuming from a previous post there is no links defined between the PLC Elk and PH PLM.
The trace looks like a flood of X10 devices that are not defined by PH. Is that true without me having to pullout by conversion charts?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Handman
Senior Member
Joined: February 02 2009
Location: United States
Online Status: Offline
Posts: 229
|
| Posted: April 26 2009 at 14:36 | IP Logged
|
|
|
Pete, reread my edited post above.
The PLM was loaded with a FULL load because of posts I had read earlier.
The PLC and PLM are not linked in any way, although they do share lights, albeit in different groups. If one of my smoke detector triggers at night, the ELK (PLC) will sound an alarm AND turn on a group of lights (group "193"). When there is no motion in the house at night, the PLM will also turn off a group of light (group "194"). That should be the only connection. Maybe I should do a full reload of the DB into the PLC to be sure.
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: April 26 2009 at 14:55 | IP Logged
|
|
|
I get this eerie feeling Lee is acting like a mad scientist and about to come up with a possible answer that indicates he found a bug in PH unless he’s out on the lake. I don’t see the obvious yet but I’m about to tackle your last trace.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
dhoward
Admin Group
Joined: June 29 2001
Location: United States
Online Status: Offline
Posts: 4447
|
| Posted: April 26 2009 at 16:39 | IP Logged
|
|
|
Yayyy!! A bug was found  . When the device issued a Stop Manual Change command, PH searched through the link database for every device linked as a responder to the device (in this case, Im assuming the PLM was linked as a responder as most people would) and would have issued a Status request to every device to now determine its new level based upon the manual change. This is what is causing the PLM to get redded out and I will add a change to the code to keep the status requests from going to the controller PLC/PLM. Nice detective work and a good catch.
Concerning the changing of your ID's...unfortunately no. PowerHome will automatically update dependant children (the links, etc.) but Macros and triggers are not in this hierarchy and will not be updated. There is a tool in PH to help make it easier to update though. Under the "Reports" menu is a report called "Database where used". Launching this report will open a window allowing you to type a search string to determine everywhere in the database that the string is used. You'll definately want to use wildcard characters to catch ALL occurences. So if you wanted to find every occurrence of "E5" in the database, just type:
%E5%
in the search window and you'll get a report showing all locations.
Dave.
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PLM clear failed, and more
