| Author |
|
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: November 10 2008 at 16:30 | IP Logged
|
|
|
The problem as I see it is the motion detector is rapidly sending X10 signals to the PLM. I don’t think the PLM does a good job at listening for traffic before it sends and the Insteon signal is walked on. As Lee suggested try Waits of 1 to 2 seconds as that has helped me in the past. The other solution is to stop the motion detector from sending multiple signal if it doing that. I think the reason your seeing the problem more with the PLM is the PLM is extremely fast compared to the PLC and the Insteon return from the trigger is happening before the motion detector settles down.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 10 2008 at 19:26 | IP Logged
|
|
|
Lee and Pete, I don't run with scans on because I don't like all the blinking and the collisions that they cause.
Here is the Raw Log:
2008-11-10 17:27:07.359 RX &nbs p; RECEIVEX10RAW=68 00
2008-11-10 17:27:07.765 RX &nbs p; RECEIVEX10RAW=62 80
2008-11-10 17:27:08.046 TX &nbs p; 02 62 05 D3 E8 0F 11 FF
2008-11-10 17:27:08.062 TX &nbs p; 02 62 08 1B D0 0F 19 00
2008-11-10 17:27:08.109 RX &nbs p; SENTINSTEON=0D D9 F8 05 D3 E8 0F 11 FF 06
2008-11-10 17:27:08.171 RX &nbs p; SENTINSTEON=0D D9 F8 08 1B D0 0F 19 00 06
2008-11-10 17:27:08.390 RX &nbs p; RECEIVEINSTEONRAW=08 1B D0 0D D9 F8 2B 0E 00
In the event log, I see (in oldest first order):
X10 in
Trigger Check
Macro Shop Motion
Insteon Out SHOP LIGHTS ON
The SHOP MOTION macro is:
10 JUMP if ({SHOP MOTION ENABLED = 1, 1, 9999)
20 JUMP if (ph_getinsteonlevel("BASEMENT LIGHTS") > 0, 2, 1)
30 JUMP if (ph_getinsteonlevelrt("BASEMENT LIGHTS") > 0, 1, 2)
40 Insteon SHOP LIGHTS On 255
50 Jump if (ph_getinsteonlevelrt("DUST COLLECTOR") > 0, 1, 9999)
60 Insteon SHOP WARNING LIGHT Fast On
Adding a WAIT 2 to the start of the macro produces nearly the same results:
2008-11-10 17:54:58.343 RX &nbs p; RECEIVEX10RAW=68 00
2008-11-10 17:54:58.765 RX &nbs p; RECEIVEX10RAW=62 80
2008-11-10 17:55:01.078 TX &nbs p; 02 62 05 D3 E8 0F 11 FF
2008-11-10 17:55:01.093 TX &nbs p; 02 62 08 1B D0 0F 19 00
2008-11-10 17:55:01.109 RX &nbs p; SENTINSTEON=0D D9 F8 05 D3 E8 0F 11 FF 06
2008-11-10 17:55:01.171 RX &nbs p; SENTINSTEON=0D D9 F8 08 1B D0 0F 19 00 06
2008-11-10 17:55:01.421 RX &nbs p; RECEIVEINSTEONRAW=08 1B D0 0D D9 F8 2B 0E 00
Adding a WAIT 10 to the start of the macro again gives nearly identical results:
2008-11-10 17:58:38.640 RX &nbs p; RECEIVEX10RAW=68 00
2008-11-10 17:58:39.078 RX &nbs p; RECEIVEX10RAW=62 80
2008-11-10 17:58:49.375 TX &nbs p; 02 62 05 D3 E8 0F 11 FF
2008-11-10 17:58:49.390 TX &nbs p; 02 62 08 1B D0 0F 19 00
2008-11-10 17:58:49.406 RX &nbs p; SENTINSTEON=0D D9 F8 05 D3 E8 0F 11 FF 06
2008-11-10 17:58:49.468 RX &nbs p; SENTINSTEON=0D D9 F8 08 1B D0 0F 19 00 06
2008-11-10 17:58:49.765 RX &nbs p; RECEIVEINSTEONRAW=08 1B D0 0D D9 F8 27 0E 00
Changing the macro to:
10 Jump if ({SHOP MOTION ENABLED} = 1, 1, 9999)
20 Jump if (ph_getinsteonlevel("BASEMENT LIGHTS") > 0, 2, 1)
30 Jump if (ph_getinsteonlevelrt("BASEMENT LIGHTS") > 0, 1, 5)
40 Set System [LOCAL1] 5
50 Insteon SHOP LIGHTS On 255
60 Set System [LOCAL1] [LOCAL1] - 1
70 Jump if (([LOCAL1] > 0) and (ph_getinsteonlevel("SHOP LIGHTS") > 0), 1, -2)
80 Jump if (ph_getinsteonlevelrt("DUST COLLECTOR") > 0, 1, 9999)
90 Set System [LOCAL1] 5
100 Insteon SHOP WARNING LIGHT Fast On
110 Set System [LOCAL1] [LOCAL1] - 1
120 Jump if (([LOCAL1] > 0) and (ph_getinsteonlevel("SHOP WARNING LIGHT") > 0), 1, -2)
Produces:
2008-11-10 18:06:18.453 RX &nbs p; RECEIVEX10RAW=68 00
2008-11-10 18:06:18.875 RX &nbs p; RECEIVEX10RAW=62 80
2008-11-10 18:06:19.140 TX &nbs p; 02 62 05 D3 E8 0F 11 FF
2008-11-10 18:06:19.187 RX &nbs p; SENTINSTEON=0D D9 F8 05 D3 E8 0F 11 FF 06
2008-11-10 18:06:19.468 RX &nbs p; RECEIVEINSTEONRAW=05 D3 E8 0D D9 F8 2B 11 FF
2008-11-10 18:06:19.640 TX &nbs p; 02 62 05 D3 E8 0F 11 FF
2008-11-10 18:06:19.656 TX &nbs p; 02 62 08 1B D0 0F 19 00
2008-11-10 18:06:19.671 RX &nbs p; SENTINSTEON=0D D9 F8 05 D3 E8 0F 11 FF 06
2008-11-10 18:06:19.734 RX &nbs p; SENTINSTEON=0D D9 F8 08 1B D0 0F 19 00 06
2008-11-10 18:06:20.046 RX &nbs p; RECEIVEINSTEONRAW=08 1B D0 0D D9 F8 27 0E 00
2008-11-10 18:06:22.328 RX &nbs p; RECEIVEX10RAW=64 00
2008-11-10 18:06:22.734 RX &nbs p; RECEIVEX10RAW=63 80
And in the event log (in newest first order):
Incoming X-10 received on Insteon DM controller PLM. Byte Values: 63 80 Decode: A{Off}
Incoming X-10 received on Insteon DM controller PLM. Byte Values: 64 00 Decode: A15
Insteon DM Controller PLM transmission of Address:[05.D3.E8] Flags:[15] Cmd1:[17] Cmd2:[255]. Decode: Direct. ID: SHOP LIGHTS, On
Incoming Insteon received on Insteon DM controller PLM. From Address:[05.D3.E8] To Address:[0D.D9.F8] Flags:[43] Cmd1:[17] Cmd2:[255]. Decode: Direct ACK. From: SHOP LIGHTS To: POWERLINC MODEM, On
Insteon DM Controller PLM transmission of Address:[05.D3.E8] Flags:[15] Cmd1:[17] Cmd2:[255]. Decode: Direct. ID: SHOP LIGHTS, On
Macro SHOP MOTION executed.
Trigger check of SHOP MOTION performed.
Incoming X-10 received on Insteon DM controller PLM. Byte Values: 62 80 Decode: A{On}
Incoming X-10 received on Insteon DM controller PLM. Byte Values: 68 00 Decode: A14
If I simply turn the device on from the device status window (which works 100% of the time) I get:
2008-11-10 18:18:45.328 TX &nbs p; 02 62 05 D3 E8 0F 11 FF
2008-11-10 18:18:45.343 RX &nbs p; SENTINSTEON=0D D9 F8 05 D3 E8 0F 11 FF 06
2008-11-10 18:18:45.718 RX &nbs p; RECEIVEINSTEONRAW=05 D3 E8 0D D9 F8 27 11 FF
2008-11-10 18:18:47.171 RX &nbs p; RECEIVEX10RAW=64 00
2008-11-10 18:18:47.578 RX &nbs p; RECEIVEX10RAW=63 80
And in the event log (newest first):
Incoming X-10 received on Insteon DM controller PLM. Byte Values: 63 80 Decode: A{Off}
Incoming X-10 received on Insteon DM controller PLM. Byte Values: 64 00 Decode: A15
Incoming Insteon received on Insteon DM controller PLM. From Address:[05.D3.E8] To Address:[0D.D9.F8] Flags:[39] Cmd1:[17] Cmd2:[255]. Decode: Direct ACK. From: SHOP LIGHTS To: POWERLINC MODEM, On
Incoming Insteon received on Insteon DM controller PLM. From Address:[05.D3.E8] To Address:[0D.D9.F8] Flags:[39] Cmd1:[17] Cmd2:[255]. Decode: Direct ACK. From: SHOP LIGHTS To: POWERLINC MODEM, On
All this is leading me to believe that perhaps the X10 events are not clobbering the Insteon commands and instead, something somewhat odd is being sent when the macro is executing.
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 10 2008 at 19:51 | IP Logged
|
|
|
Well, the previous debugging and examination of the data gave me a clue. I changed the initial macro to not check the status of DUST COLLECTOR if it was trying to turn on the SHOP LIGHTS. This stopped sending a "STATUS REQUEST" immediately after an "ON" request. The shop lights now come on reliably.
Tom
Oh, clicking on help, and then exiting help leaves PH2 hung.
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 10 2008 at 20:52 | IP Logged
|
|
|
Dave,
I use PLC/PLM Groups a lot. I have a group for SUNSET that has 5 devices. When I do an Insteon Group SUNSET On, I see the Group Broadcast On go out, then the cleanup On's, but every one of the cleanups gets NAK'd. If I do direct On's, every one gets ACK'd. This is the macro:
10 Insteon Group SUNSET On
20 Set Global Daylight 0
One more thing that needs to be done when converting from PLC to PLM, change the controller in the PLC/PLM Groups tab of Insteon Explorer.
Tom
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 10 2008 at 21:02 | IP Logged
|
|
|
Is that a CNTLR NAK when the message is given to the PLM or a device NAK coming back on the powerline?
Nice job on that earlier diagnosis of the closely clustered Insteon messages.
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: November 10 2008 at 23:12 | IP Logged
|
|
|
I just took a quick glance since I was tied up. Is the motion detector programmed for both Insteon and X10?
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 10 2008 at 23:24 | IP Logged
|
|
|
Pete,
Viper found the problem. The macro was querying the status of another device immediately after sending the SHOP LIGHT ON. The status message was getting to the PLM 15 milliseconds after the SHOP LIGHT ON. That timing sound familiar. Same as TonyNo Timed Event lost message, although not the exact trace sequence. The status query was deleted/moved (?) and now the SHOP LIGHT ON from the X10 motion signal trigger is reliable.
__________________
Lee G
|
| Back to Top |
|
| |
bmwragtop
Newbie
Joined: March 30 2008
Location: United States
Online Status: Offline
Posts: 27
|
| Posted: November 11 2008 at 06:03 | IP Logged
|
|
|
I took the plunge and installed the new serial PLM last night. So far, so good. I am seeing a few more NAKs than I did with the PLC, but it could still be random variability.
Tom G.
Edited by bmwragtop - November 11 2008 at 06:04
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 11 2008 at 07:50 | IP Logged
|
|
|
Lee,
Concerning the change to the SHOP MOTION macro: If the SHOP LIGHTS are on, I don't try to turn them on again and go check the DUST COLLECTOR. If the SHOP LIGHTS are off, I only attempt to turn on the SHOP LIGHTS. I figured the lights coming on would get my attention, and I don't need to turn on lights that are already on. At one time, I was concerned about getting the SHOP LIGHTS on as fast as possible, hence the jumps instead of GOTO's and LABELS and minimal logic before turning on the lights. You can walk a long ways into a dark room in 1 to 2 seconds.
The Motion Sensor is an EagleEye (I think) X10 only device mounted in the floor joists of the floor above the shop to limit its view to just the door area.
Concerning the Broadcast and NAKs:
The macro:
10 Insteon Group SUNSET On (SUNSET is Group 11)
20 Set Global DAYLIGHT 0
The Event log (newest first):
Global variable DAYLIGHT changed from 0 to 0
Insteon DM Controller PLM transmission of Address:[06.D6.2B] Flags:[69] Cmd1:[17] Cmd2:[11]. Decode: Group Cleanup. ID: KITCHEN FLOOR LIGHTS Group: 11, On
Insteon DM Controller PLM transmission of Address:[0D.3C.90] Flags:[69] Cmd1:[17] Cmd2:[11]. Decode: Group Cleanup. ID: CURIO CABINET Group: 11, On
Insteon DM Controller PLM transmission of Address:[04.97.89] Flags:[69] Cmd1:[17] Cmd2:[11]. Decode: Group Cleanup. ID: VICTORIAN LAMP Group: 11, On
Insteon DM Controller PLM transmission of Address:[08.1C.EE] Flags:[69] Cmd1:[17] Cmd2:[11]. Decode: Group Cleanup. ID: SECURITY LIGHT Group: 11, On
Insteon DM Controller PLM transmission of Address:[04.8D.E9] Flags:[69] Cmd1:[17] Cmd2:[11]. Decode: Group Cleanup. ID: MASTER BEDROOM LAMP Group: 11, On
Insteon DM Controller PLM transmission of Address:[00.00.0B] Flags:[207] Cmd1:[17] Cmd2:[0]. Decode: Group Broadcast. Group: 11, On
Macro SUNSET executed.
The Raw Insteon Log:
2008-11-11 06:25:39.718 TX &nbs p; 02 62 00 00 0B CF 11 00
2008-11-11 06:25:39.796 RX &nbs p; SENTINSTEON=0D D9 F8 00 00 0B CF 11 00 06
2008-11-11 06:25:40.546 TX &nbs p; 02 62 04 8D E9 45 11 0B
2008-11-11 06:25:40.593 RX &nbs p; SENTINSTEON=0D D9 F8 04 8D E9 45 11 0B 06
2008-11-11 06:25:40.843 RX &nbs p; RECEIVEINSTEONRAW=04 8D E9 0D D9 F8 61 11 0B
2008-11-11 06:25:44.640 RX &nbs p; INSTEON NAK=04 8D E9
2008-11-11 06:25:44.671 TX &nbs p; 02 62 08 1C EE 45 11 0B
2008-11-11 06:25:44.718 RX &nbs p; SENTINSTEON=0D D9 F8 08 1C EE 45 11 0B 06
2008-11-11 06:25:44.921 RX &nbs p; RECEIVEINSTEONRAW=08 1C EE 0D D9 F8 61 11 0B
2008-11-11 06:25:48.843 RX &nbs p; INSTEON NAK=08 1C EE
2008-11-11 06:25:48.875 TX &nbs p; 02 62 04 97 89 45 11 0B
2008-11-11 06:25:48.921 RX &nbs p; SENTINSTEON=0D D9 F8 04 97 89 45 11 0B 06
2008-11-11 06:25:49.187 RX &nbs p; RECEIVEINSTEONRAW=04 97 89 0D D9 F8 61 11 0B
2008-11-11 06:25:52.953 RX &nbs p; INSTEON NAK=04 97 89
2008-11-11 06:25:52.984 TX &nbs p; 02 62 0D 3C 90 45 11 0B
2008-11-11 06:25:53.031 RX &nbs p; SENTINSTEON=0D D9 F8 0D 3C 90 45 11 0B 06
2008-11-11 06:25:53.234 RX &nbs p; RECEIVEINSTEONRAW=0D 3C 90 0D D9 F8 61 11 0B
2008-11-11 06:25:57.093 RX &nbs p; INSTEON NAK=0D 3C 90
2008-11-11 06:25:57.125 TX &nbs p; 02 62 06 D6 2B 45 11 0B
2008-11-11 06:25:57.171 RX &nbs p; SENTINSTEON=0D D9 F8 06 D6 2B 45 11 0B 06
2008-11-11 06:25:57.406 RX &nbs p; RECEIVEINSTEONRAW=06 D6 2B 0D D9 F8 61 11 0B
2008-11-11 06:26:01.203 RX &nbs p; INSTEON NAK=06 D6 2B
So, to me it looks like they are NAK's from the devices, but I don't know enough about the raw data to be sure.
Tom
Edited by Viper - November 11 2008 at 07:54
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 11 2008 at 08:32 | IP Logged
|
|
|
You are right on. They are NAK's from the powerline side (maybe not the individual devices because of so many) but definitely not from the PLM rejecting the Group Cleanup message. In another thread the TX trace entry (PH sending data to the PLM) was immediately followed by a CNTLR NAK message which was the PLM rejecting the preceding TX command. In this case the Group Cleanup Direct messages were sent out but not ACKed by each device. Since all those devices would not fail at the same time I suspect the responder link in each of those devices have not have been changed to the new PLM address. The link records would still be there but with the address of the PLC so the devices would not respond to a Group command coming from the PLM. Would explain why the Direct messages work but not the Group messages. If I am correct you will have to establish new links for all the PLC/PLM Groups. Another item to add to the PLC to PLM conversion activities. After changing the controller in the PLC/PLM Groups tab, create new links with the responder devices.
EDIT: just reviewed the steps you did in converting to the PLM. Sounds like you already recreated the PLC/PLM Group links. I still think the links in the responders are the problem, but could be something like the Group number does not match rather than the address does not match.
Edited by grif091 - November 11 2008 at 08:42
__________________
Lee G
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: November 11 2008 at 08:46 | IP Logged
|
|
|
Lee, point well made on the linking. Seems like the 15 millisecond timing is getting notorious. As far as a few more NAKs with the PLM. The PLM has a lower transmit level, unless they have corrected it at your firmware, and this could cause a problem for some locations. If that being so a work around is to plug an Access Point into the PLM ( piggy back).
EDIT: Viper, is the motion detector set up with A14 ON and A15 OFF?
Edited by BeachBum - November 11 2008 at 09:14
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 11 2008 at 09:52 | IP Logged
|
|
|
Viper, disregard what I said about missing or incorrect responder links. I set up a PLC/PLM Group on my system and get the same NAK result. The problem is the message coming back from the device is an ACK (flag byte 0x6x) not a NAK (flag byte would be 0xEx). Don't know if the INSTEON NAK= message is PHs interpretation of the device response which is inaccurate or if that is a message from the PLM. Hoping this is just PHs analysis of the device response which has a glitch rather than a PLM error. Something for Dave to look into.
EDIT: In my case the device actually responded to the Group command correctly. That is what got me looking more closely at the actual response message coming back from the device. Viper, are you devices actually turning On in response to the the PLC/PLM Group On request, hope so to make this consistent with my results.
Edited by grif091 - November 11 2008 at 10:10
__________________
Lee G
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 11 2008 at 09:53 | IP Logged
|
|
|
Pete, The motion sensor is set up so MOTION = A14 ON, 1 min delay, A14 OFF, It is also a light sensor, so LIGHT = A15 ON, DARK = A15 OFF.
Lee, I just went through a whole series of experiments:
- Rebuilt a device - NAK
- Rebuilt the PLM - NAK
- Deleted the link, Created the link - NAK
- Deleted the link, deleted the device, created the device, created the link - NAK
- Cleared the PLM, Add Full, Reinit - NAK
Other than starting completely from scratch (OMG), I'm out of options that I'm aware of.
EDIT: I should state that the devices are responding to the broadcasts by turning on and off appropriately, The problem is the NAK's coming back on the cleanups. In a perfect world, we wouldn't need cleanups, but it isn't a perfect world and occasionally a device doesn't see a broadcast due to noise.
Tom
Edited by Viper - November 11 2008 at 10:05
|
| Back to Top |
|
| |
BeachBum
Super User
Joined: April 11 2007
Location: United States
Online Status: Offline
Posts: 1880
|
| Posted: November 11 2008 at 10:04 | IP Logged
|
|
|
Viper, the reason I asked is I don’t see the A15 OFF all the time and I’m wondering if it’s trampling on the Insteon signals. As I have discovered before unsolicited X10 signals have made my PLM do strange things. Did not have that problem with the PLC.
On the NAKs maybe you might want to reset the devices.
__________________
Pete - X10 Oldie
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 11 2008 at 10:08 | IP Logged
|
|
|
Viper, our posts have crossed paths. See my earlier post about the NAK being a false message. The messages you posted and the message from my device is actually an ACK. My device actually responded correctly to the PLC/PLM Group command even thought the trace said NAK which is what got me looking more closely at the actual device response message. Hope your devices are also responding correctly and it is only the NAK message itself that is wrong.
EDIT: Just read that your devices are responding correctly. I think this is just a glitch in the way PH interpreted the flag byte. The 0x20 bit can be a NAK indication but not from a Group Cleanup Direct response of 0x6x.
Edited by grif091 - November 11 2008 at 10:14
__________________
Lee G
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 11 2008 at 10:18 | IP Logged
|
|
|
If you have any interest in the various flag byte settings there is an Insteon Details document on the SmartLabs web site (page 18) that has a good description of flag byte bit combinations.
__________________
Lee G
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 11 2008 at 10:21 | IP Logged
|
|
|
Pete,
I don't think it is the A15 OFFs or the A14 OFFs. Simply removing that stat to another device immediately after the on has things working perfectly now.
You are right, I hadn't tried a hard reset. I just did a hard reset and the result is, you guess it, NAK...
EDIT: Thanks Lee for testing and looking at the flows. I must say that both you and Pete have been very helpful. I'll ignore the NAKs and hope they go away with PH 2.0.1... :-)
I'm close to commiting and moving control back to my server in the hole...
Tom
Edited by Viper - November 11 2008 at 10:28
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 11 2008 at 10:28 | IP Logged
|
|
|
Viper, we are both being so proactive on this problem that our posts are crossing paths. The INSTEON NAK= is wrong. The device command responses are correct and the responses to the Group Cleanup Direct are ACKs, not the NAK the trace is showing. I do believe this is glitch in how PH interpreted the Group Cleanup Direct message response. Everything is working as it should, just the trace message itself is wrong. I'll take a few minute break and let everyone catch up on the posts.
EDIT: I apologize for getting you going down the wrong path about link problems. I took the INSTEON NAK= on face value without cross checking that the response message was actually a NAK. If I had done that to begin with I would have seen the actual device response was an ACK. Very sorry about that.
Edited by grif091 - November 11 2008 at 10:34
__________________
Lee G
|
| Back to Top |
|
| |
Viper
Groupie
Joined: January 14 2007
Location: United States
Online Status: Offline
Posts: 88
|
| Posted: November 11 2008 at 10:36 | IP Logged
|
|
|
Lee, No problem! I appreciate the responsiveness and helpfulness of both you and Pete. We did have the messages flying pretty fast there.... 
Tom
|
| Back to Top |
|
| |
grif091
Super User
Joined: March 26 2008
Location: United States
Online Status: Offline
Posts: 1357
|
| Posted: November 11 2008 at 10:57 | IP Logged
|
|
|
Pete is a good guy, for someone with gray hair and sand in his shoes! He has helped me on many occasions. That is what I like about PowerHome and this forum. So many folks willing to help and Dave's responses could not be better.
__________________
Lee G
|
| Back to Top |
|
| |
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome General
Topic: PLC to USB PLM Upgrade Offer
