Author |
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 15 2008 at 19:22 | IP Logged
|
|
|
A trigger of mine does not work (not Alpha related ;) ).
Here is the log entry of the device changing...
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[01.7A.9F] To Address:[00.00.01] Flags:[235] Cmd1:[19] Cmd2:[0]. Decode: NAK of Group Cleanup. From: BATHROOM LIGHT To: Group: 0, Off
The trigger is a Device Change, Any, Off.
I think the "to address" should be my PLC, so I rebuilt the link, but nothing changed.
Edited by TonyNo - April 15 2008 at 19:22
|
Back to Top |
|
|
BeachBum Super User
Joined: April 11 2007 Location: United States
Online Status: Offline Posts: 1880
|
Posted: April 16 2008 at 10:12 | IP Logged
|
|
|
Tony, I could be wrong but I don’t believe a NAK will fire a trigger. In my tracing of group related problems the TO address looking like yours is a Broadcast Group command and this may be normal. Others with the correct documentation can verify this. I would think the log should show 1 Group command and a Cleanup to each device in the group. The trigger should fire for each Cleanup but not the Broadcast if you’re using Any, Any, Off. If you’re using Any, BATHROOM LIGHT, Off then the trigger should fire for the Cleanup with the ID from BATHROOM.
__________________ Pete - X10 Oldie
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 16 2008 at 12:05 | IP Logged
|
|
|
Hmm. Maybe it left the group, somehow. I'll check that, thanks.
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 17 2008 at 07:41 | IP Logged
|
|
|
Rebuilt the links, even deleted and reset controller/responder, with no change.
|
Back to Top |
|
|
BeachBum Super User
Joined: April 11 2007 Location: United States
Online Status: Offline Posts: 1880
|
Posted: April 17 2008 at 08:50 | IP Logged
|
|
|
Am I assuming correctly that you are trying to trigger from the press of the SwitchLinc to OFF? If so can you clear the DM and capture the log at that moment and I’ll see if I can duplicate it.
__________________ Pete - X10 Oldie
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 17 2008 at 14:20 | IP Logged
|
|
|
Yes. I can get the SDM line tonight.
I have two triggers that just stopped working. In addition to the Device Change, there was a Group Off trigger.
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 18 2008 at 07:54 | IP Logged
|
|
|
Didn't get a chance to trap the SDM data, but there is a theme here. All of the switches I've tried are sending NAK's for manual changes...
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[01.7A.9F] To Address:[00.00.01] Flags:[235] Cmd1:[17] Cmd2:[0]. Decode: NAK of Group Cleanup. From: BATHROOM LIGHT To: Group: 0, On
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[03.66.0C] To Address:[00.00.01] Flags:[235] Cmd1:[19] Cmd2:[0]. Decode: NAK of Group Cleanup. From: MBR LIGHT To: Group: 0, Off
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[03.6F.97] To Address:[00.00.01] Flags:[239] Cmd1:[19] Cmd2:[0]. Decode: NAK of Group Cleanup. From: FOYER LIGHT To: Group: 0, Off
|
Back to Top |
|
|
BeachBum Super User
Joined: April 11 2007 Location: United States
Online Status: Offline Posts: 1880
|
Posted: April 18 2008 at 08:40 | IP Logged
|
|
|
Sometimes when I get weird NAK problems I reset the PLC and it goes away. I’ve seen this occur when retrieving Insteon level from the devices but everything else keeps working just slower.
__________________ Pete - X10 Oldie
|
Back to Top |
|
|
dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: April 18 2008 at 09:04 | IP Logged
|
|
|
Tony,
Your messages are very wierd. You are correct in that the "To Address" should be the PLC or whatever other devices are linked to the switch. 00.00.01 is typically the address for group 1. Your CMD2 is showing 0 which is the place where a group cleanup places the *group* command...in this case 0 which is not valid. The flags are correct in showing a NAK of a group cleanup message.
The first thing I would do is completely reset the PLC. Download the Core App, Clear the PLC database, and Add Min ID's to the PLC. This will usually take care of most wierdness.
Give that a try and we'll see where it gets us.
Dave.
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 18 2008 at 09:51 | IP Logged
|
|
|
Ah, weirdness. ;) I'll try that tonight!
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 18 2008 at 23:27 | IP Logged
|
|
|
Hmm. A change, but no fix...
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[03.6F.97] To Address:[00.80.01] Flags:[235] Cmd1:[19] Cmd2:[0]. Decode: NAK of Group Cleanup. From: FOYER LIGHT To: Group: 0, Off
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[01.7A.9F] To Address:[00.80.01] Flags:[235] Cmd1:[17] Cmd2:[0]. Decode: NAK of Group Cleanup. From: BATHROOM LIGHT To: Group: 0, On
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[01.7A.9F] To Address:[00.80.01] Flags:[235] Cmd1:[19] Cmd2:[0]. Decode: NAK of Group Cleanup. From: BATHROOM LIGHT To: Group: 0, Off
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 26 2008 at 17:11 | IP Logged
|
|
|
Here are some lines from the SDM for switch presses. The first group is a switch I have no triggers for. The second one is the one with issues.
PLC:eventraw=03
PLC:eventraw=02
PLC:receiveinsteonraw=02 03 6F 97 00 00 01 EF 13 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 03 6F 97 00 D4 2C 65 13 01
PLC:eventraw=03
PLC:eventraw=02
PLC:receiveinsteonraw=02 03 6F 97 00 00 01 EF 13 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 03 6F 97 00 D4 2C 65 13 01
PLC:eventraw=02
PLC:receiveinsteonraw=02 01 7A 9F 00 00 01 EF 11 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 01 7A 9F 00 D4 2C 65 11 01
PLC:eventraw=03
PLC:eventraw=02
PLC:receiveinsteonraw=02 01 7A 9F 00 00 01 EF 13 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 01 7A 9F 00 D4 2C 65 13 01
PLC:eventraw=03
|
Back to Top |
|
|
dhoward Admin Group
Joined: June 29 2001 Location: United States
Online Status: Offline Posts: 4447
|
Posted: April 27 2008 at 16:45 | IP Logged
|
|
|
Tony,
Well, after typing nearly a complete message, I went back and actually looked up all of the flag values for the PLC log and had to start from scratch ...what you've posted makes no sense.
At first glance, the first line of the PLC log looks like a normal group broadcast from 03.6F.97 (FOYER LIGHT), ie. it looks like someone manaully turned the foyer light off. However, the flags "EF" make absolutely no sense. The first nybble, "E" tells us what kind of message this is. In this case, it's a NAK of an All-Link cleanup message. This would mean that the FOYER LIGHT is sending a command to a device ID of 00.00.01 (Ive never seen device ID's like this...this looks like a group ID). The CMD2 (00) would normally be the group ID, in this case 0, which we would never normally see.
The second message at least makes more sense. The flags tells us it's an ACK of a group cleanup message to device 00.D4.2C for group 1. What's troubling is that I don't see the group cleanup message from 00.D4.2C or even the original group broadcast command.
The first thing I would do is open Insteon Explorer and go to the "Devices" tab. Check to make sure that you don't have any devices with an address of 00.00.01. If everything looks normal in the Devices tab, next go to the "Links" tab. Look at the links for the FOYER LIGHT. Do you have any [ID NOT FOUND] type links. Also, find out what device is 00.D4.2C. It should be a real device since the FOYER LIGHT is sending ACKs to it. If necessary, flag the FOYER LIGHT to rescan it's database. Next, do a factory reset on the FOYER LIGHT and then follow that with a "Rebuild" from the links tab. When done, see if the foyer light is acting normal or not. If it isnt, then I would start to suspect something flaky with the PLC. Perhaps doing a factory reset on it followed by the standard download core app, clear PLC database, add min ID's.
Let me know how this goes.
Dave.
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 27 2008 at 19:11 | IP Logged
|
|
|
Quote:
Check to make sure that you don't have any devices with an address of 00.00.01. |
|
|
Check.
Quote:
Look at the links for the FOYER LIGHT. Do you have any [ID NOT FOUND] type links. |
|
|
Nope.
Quote:
find out what device is 00.D4.2C. It should be a real device since the FOYER LIGHT is sending ACKs to it. |
|
|
00.D4.2C is my PLC.
Quote:
I would start to suspect something flaky with the PLC. Perhaps doing a factory reset on it followed by the standard download core app, clear PLC database, add min ID's. |
|
|
Already done last time.
Here is the switch after all of that...
PLC:receiveinsteonraw=02 03 6F 97 00 80 01 EF 11 00
PLC:receiveinsteonraw=01 03 6F 97 00 D4 2C 65 11 01
PLC:receiveinsteonraw=02 03 6F 97 00 80 01 EB 13 00
PLC:receiveinsteonraw=01 03 6F 97 00 D4 2C 65 13 01
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: April 27 2008 at 21:40 | IP Logged
|
|
|
The first two messages in the last post look like a top paddle press.....
group broadcast from 03.6F.97 for group 1, cmd ON
group cleanup from 03.6F.97 to 00.D4.2C cmd ON, for group 1
with one problem. A 0x20 is OR'ed into the flag byte of both messages. Turning a CF into an EF in the first message and a 45 into a 65 in the second message.
The last two messages look like a bottom paddle press....
group broadcast from 03.6F.97 for group 1, cmd OFF
group cleanup from 03.6f.97 to 00.D4.2C cmd OFF, for group 1
with the same problem. A 0x20 is OR'ed into the flag byte of both messages. Turning a CB into an EB in the 3rd message and a 45 into a 65 in the 4th message.
Was this a trace of a paddle switch manual ON followed by the same paddle switch manual OFF? If these type of trace entries are occurring from one switch, I would assume the switch (you know what assume stands for!) has a problem. If this is happening from multiple switches, than the PLC or smd3 is suspect, or maybe another device that is repeating the Insteon messages, turning on the 0x20 in error.
EDIT: Sorry, I should have started from the beginning of this thread. With multiple switches having the same symptom it is not the individual switch. The excerpts of the trace entries reflect the same situation, the basic messages look as expected, except for the extra 0x20 bit in the flag byte. The messages that do not have a "to" address are Group Broadcast messages which do not contain an Insteon address in the "to" field. The content of the "to" field varies a little by device but has the group number in the low byte (00.00.01 for group 1), at least this is true for the devices in my network.
Since the Group Broadcast message does not have a NAK in the Insteon architecture (because it is not sent to any specific device), native device operation may not be affected. It would be the "responder", not the "controller", that is responsible for issuing an ACK to the group cleanup message so not sure what native devices might do when the ACK appears to come from the "controller". Software will no doubt be confused by the invalid Insteon protocol.
Still thinking PLC or smd3, but it could be one device that is repeating messages incorrectly. Is it possible to pull the little off tab on your devices, except the one you are testing with. Also, if you find one device that is working with correct trace entries, that might be the one that is broken because it is not repeating its own messages.
EDIT2: Corrected text. Had NAK on the brain. Should have said ACK when discussing response to group cleanup.
Edited by grif091 - April 28 2008 at 00:20
__________________ Lee G
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 27 2008 at 22:48 | IP Logged
|
|
|
Good ideas, Lee! I'll have to try this tomorrow.
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: April 28 2008 at 00:42 | IP Logged
|
|
|
If you go back to your April 27 post, there is a series of group broadcast, group cleanup messages for devices where no triggers exist and a series of group broadcast, group cleanup messages for devices that have triggers. All the messages are wrong, regardless of whether there are triggers or not. There is a 0x20 bit on in the flag byte of every message in that post. You may need a trigger defined before the erroneous bit causes a visible symptom, but all the messages are wrong. The problem may actually be easier to track because the failure is occurring more widely than the symptoms would indicate.
__________________ Lee G
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 28 2008 at 07:22 | IP Logged
|
|
|
I just think i found a complication. The 0x20 seems to only apply to ACK's from paddle presses...
Quote:
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[03.6F.97] To Address:[00.D4.2C] Flags:[47] Cmd1:[17] Cmd2:[255]. Decode: Direct ACK. From: FOYER LIGHT To: POWERLINC1, On
Incoming Insteon received on Insteon DM controller INSTEON-1. From Address:[01.7A.9F] To Address:[00.D4.2C] Flags:[47] Cmd1:[17] Cmd2:[0]. Decode: Direct ACK. From: BATHROOM LIGHT To: POWERLINC1, On |
|
|
Edited by TonyNo - April 28 2008 at 07:25
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: April 28 2008 at 11:38 | IP Logged
|
|
|
Not sure how to interpret the previous post. You are looking at the Insteon message flow today and no longer see what was in the April 26 post ......
PLC:eventraw=03
PLC:eventraw=02
PLC:receiveinsteonraw=02 03 6F 97 00 00 01 EF 13 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 03 6F 97 00 D4 2C 65 13 01
PLC:eventraw=03
PLC:eventraw=02
PLC:receiveinsteonraw=02 03 6F 97 00 00 01 EF 13 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 03 6F 97 00 D4 2C 65 13 01
PLC:eventraw=02
PLC:receiveinsteonraw=02 01 7A 9F 00 00 01 EF 11 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 01 7A 9F 00 D4 2C 65 11 01
PLC:eventraw=03
PLC:eventraw=02
PLC:receiveinsteonraw=02 01 7A 9F 00 00 01 EF 13 00
PLC:eventraw=03
PLC:eventraw=01
PLC:receiveinsteonraw=01 01 7A 9F 00 D4 2C 65 13 01
PLC:eventraw=03
which are "Group Broadcast", "Group Cleanup Direct" messages coming from the "Controller" device (where paddle was pressed) with the extra 0x20 bit in all the flag bytes. Even though an "ACK of Group Cleanup Direct" is theoretically a valid message, it is not valid in the above message sequence. An "ACK of Group Cleanup Direct" message comes from the "Responder" device, not the "Controller" device as indicated in the above messages. That is why I believe the 0x20 in the flag byte in all the above messages is erroneous.
The complete message flow has to be looked at to know from the message flow what is actually correct. If you pressed the paddle on the FOYER LIGHT switch or the BATHROOM LIGHT switch (something I can't know from a single message), that switch is the "Controller". Receiving an "ACK of Group Cleanup Direct" message (as in the immediate previous post) would not be valid from the "Controller". What you would expect to see is this ......
"Group Broadcast" from Controller device to no specific Responder device
"Group Cleanup Direct" from the Controller device to specific Responder device
"ACK of Group Cleanup Direct" from the Responder device to the Controller device
The "ACK of Group Cleanup Direct" from the Responder is not always seen in raw traces because of the speed at which the Responder device responds with the ACK. None of the "ACK of Group Cleanup Direct" messages in the April 26 post are valid because they are coming from the Controller. I believe they are actually "Group Cleanup Direct" messages coming from the Controller with the erroneous 0x20 in the flag by the time the message gets to the PLC/sdm3.
Suggest looking at the complete message flow from sdm3 for a paddle press to see what is actually happening.
__________________ Lee G
|
Back to Top |
|
|
TonyNo Moderator Group
Joined: December 05 2001 Location: United States
Online Status: Offline Posts: 2889
|
Posted: April 28 2008 at 13:30 | IP Logged
|
|
|
The latest ones were not from paddle presses (I guess I was not clear on that). Those were responses from commands sent by the PLC to turn on/off.
The previous posts were the complete SDM log for those paddle presses.
|
Back to Top |
|
|