Triggerlinc not sending cleanup messages?

[Ross S]

I bought a few open/close sensors (2843-222, v.34). I'm having a hard time understanding the messages it's sending. Here's what the ISY sees when a sensor in solid RF coverage changes state from closed to open:

 

Sun 12/23/2012 06:37:21 PM : [iNST-SRX    ] 02 50 21.42.CF 00.00.01 CB 11 01    LTONRR (01)
Sun 12/23/2012 06:37:21 PM : [std-Group   ] 21.42.CF-->Group=1, Max Hops=3, Hops Left=2
Sun 12/23/2012 06:37:21 PM : [  21 42 CF 1]      DON   1
Sun 12/23/2012 06:37:21 PM : [  21 42 CF 1]       ST 255
Sun 12/23/2012 06:37:22 PM : [iNST-SRX    ] 02 50 21.42.CF 00.00.01 CB 11 01    LTONRR (01)
Sun 12/23/2012 06:37:22 PM : [std-Group   ] 21.42.CF-->Group=1, Max Hops=3, Hops Left=2
Sun 12/23/2012 06:37:22 PM : [iNST-DUP    ] Previous message ignored.
Sun 12/23/2012 06:37:22 PM : [iNST-SRX    ] 02 50 21.42.CF 11.00.01 CB 06 00           (00)
Sun 12/23/2012 06:37:22 PM : [std-Group   ] 21.42.CF-->11.00.01, Max Hops=3, Hops Left=2
Sun 12/23/2012 06:37:23 PM : [iNST-SRX    ] 02 50 21.42.CF 11.00.01 CB 06 00           (00)
Sun 12/23/2012 06:37:23 PM : [std-Group   ] 21.42.CF-->11.00.01, Max Hops=3, Hops Left=2
Sun 12/23/2012 06:37:23 PM : [iNST-DUP    ] Previous message ignored.

 

The first message makes sense - group broadcast with the "on" command. I don't know why it's duplicated, but I'm not so worried about that. I'm more worried about:

 

1) What is that next group broadcast? Command 0x06 to address 11.00.01? When the sensor goes from open to closed, the message stays the same except for the destination, which changes to 13.00.01.

 

2) Why are there no group cleanup messages? One of my sensors is near the edge of RF reception, and the ISY will occasionally not catch a state change. Retries would help with this, but I can't figure out why my Triggerlinc won't send cleanups. Does it just not do this? Or perhaps sending the second group broadcast message I'm confused about above is cancelling the remaining cleanup tasks from the first group broadcast? Even so, there are no cleanups for that second group broadcast either.

 

Here's the device links table (directly queried - not the ISY links table). 1F.23.BB is my PLM:

 

0 : 0FF8 : E2 01 1F.23.BB FF 1F 01
1 : 0FF0 : E2 02 1F.23.BB FF 1F 02
2 : 0FE8 : 00 00 00.00.00 00 00 00

 

Thanks for the help!

[LeeG]

Multiple Group Broadcast messages from RF only devices is consistent across the various types of RF devices. The TriggerLinc is an I2CS device. The 2nd set of Group Broadcast messages are in the I2CS format. The command code is located in a different location in those messages. My I2CS Motion Sensors have the same sequence, 2 normal Group Broadcast messages followed by two I2CS format Group Broadcast messages, and no Group Cleanup Direct messages.

[Ross S]

Oh, I2CS. Interesting. I wish there was more publicly available information on that.

 

Since Houselinc2 is free, I downloaded it and played with this a bit more. Houselinc decodes these second messages similarly to how I understand them, at least in terms of byte order. Perhaps that means it doesn't fully support I2CS yet. It lists C1 as 0x06 and the destination as 11.00.01 (or 13.00.01). It decodes command 0x06 as "Success Broadcast". Some googling gives me an alternative name "Success Report Broadcast".

 

By accident, I also managed to get the Triggerlinc to start sending cleanup messages... All it took was manually linking it to another device (also an I2CS device). At that point, the "Success Broadcast" messages changed, so I did more experimenting.

 

I think the "Success Broadcast" command (C1=0x06) reports the success/failure of cleanup messages sent by a controller following a broadcast. The number of responders that should receive and acknowledge a cleanup appears in the middle byte of the "to address". The number of responders that didn't ack a cleanup is listed in C2. The LSB of the "to address" I'm guessing is still the group number like a normal broadcast message, and I have no idea as to the significance of the 0x11 or 0x13 in the MSB.

 

I'm guessing there's a way during linking via I2CS to tell the controller whether or not you want it to send cleanup messages to the responder you're linking it with. When I link a responder via ISY, the link table entry on the Triggerlinc is:

 

E2 01 20.B6.06 FF 1F 01

 

When I link the same responder manually after factory resetting, the link table entry is:

 

E2 01 20.B6.06 03 00 00

 

I can't really decypher this, other than to point out that they're not the same. I bet it's possible that the ISY's I2CS device linking logic can be changed to request that controllers send cleanups.

[LeeG]

The 0x11 is an Insteon On command and the 0x13 is the Insteon Off command. The last 3 bytes of a Controller (E2) link record have no meaning, at least pre I2CS. Pre I2CS the last three bytes of a Set button link is the responder device cat/subcat.

 

I agree it would be nice if SmartLabs made public everything they consider Confidential but I see no sign of that happening. Over time much of the information makes its way into public domain but it takes time.

 

The ISY recognizes the TriggerLinc messages at the first Group Broadcast, setting any Status change that is necessary and triggering Programs so the lack of a Group Cleanup Direct should have no functional impact.

[Ross S]

Ah, of course, so the MSB of the "to address" must be the command the controller is reporting about.

 

I fiddled directly with the link table of my Triggerlinc. Changing:

 

E2 01 20 B6 06 FF 1F 01

 

to

 

E2 01 20 B6 06 03 1F 01

 

caused the Triggerlinc to start sending cleanup messages to the ISY. I agree that this shouldn't normally provide any functional improvements, but in my case where the ISY might miss the initial broadcast messages due to poor RF reception, the cleanups are nice to have.

[LeeG]

Looks like another I2CS unique change. UDI has been chasing them ever since I2CS devices started shipping

 

EDIT: made the same change to the motion sensor, same result. There is now a Group Cleanup Direct message in additional to the other messages that were there previously.

 

EDIT2: the I2CS Group Broadcast message now has a count of 01 where there was originally a count of 00

 

Mon 12/24/2012 12:31:17 AM : [iNST-SRX ] 02 50 14.99.51 11.01.01 CB 06 00 (00)

[Michel Kohanim]

Hi all,

 

I2CS devices do things a little differently. For instance, it's no longer necessary to have a master link/slave link (in the responder) as they do also send a broadcast to group 255 (some of them). This was apparently done to reduce the number of links needed. Furthermore, the send a success report message.

 

I cannot really comment on changing links manually as I do not know the ramifications.

 

With kind regards,

Michel