Insteon: Invalid "link_cleanup_report" Set as State

[peloy]

I installed a brand new KeypadLinc (i2CS engine, probably very recent firmware [as of late April 2013]) and pressing a button on the KPL causes an alllink/link_cleanup_report message to be sent at the very end of all message activity. This causes the state of the device to be set to an invalid "link_cleanup_report". I believe inter-device links are properly configured (I can provide the link tables if it's important).

It's possible that "link_cleanup_report" messages are being generated by recent devices but it's just a guess on my part.

An an example, see the last message and last set() in the following log excerpt, which was obtained after a single press of one button of the KPL:

04/29/13 10:10:45 AM [Insteon::BaseInterface] DEBUG2: Message received with 2 hops left, delaying next transmit to avoid collisions with remaining hops.
04/29/13 10:10:45 AM [Insteon::BaseInterface] Received message from: $kpl_garage_button_a; command: off; type: alllink; group: 03
04/29/13 10:10:45 AM [Insteon::BaseObject] $kpl_garage_button_a::set(off, $kpl_garage_button_a)

04/29/13 10:10:45 AM [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops.
04/29/13 10:10:45 AM [Insteon::BaseInterface] Received message from: $kpl_garage_button_a; command: off; type: alllink; group: 03
04/29/13 10:10:45 AM [Insteon::BaseObject] $kpl_garage_button_a::set(off, $kpl_garage_button_a)
04/29/13 10:10:46 AM KPL scene A button pressed; toggling garage door

04/29/13 10:10:46 AM [Insteon::BaseInterface] Received message from: $kpl_garage_button_a; command: off; type: alllink; group: 03
04/29/13 10:10:46 AM [Insteon::BaseObject] $kpl_garage_button_a::set(off, $kpl_garage_button_a)

04/29/13 10:10:46 AM [Insteon::BaseInterface] Received message from: $kpl_garage_button_a; command: off; type: cleanup; group: 03
04/29/13 10:10:46 AM [Insteon::BaseObject] Ignoring Received Direct AllLink Cleanup Message for $kpl_garage_button_a since AllLink Broadcast Message was Received.

04/29/13 10:10:46 AM [Insteon::BaseInterface] DEBUG2: Message received with 2 hops left, delaying next transmit to avoid collisions with remaining hops.
04/29/13 10:10:46 AM [Insteon::BaseInterface] Received message from: $kpl_garage_button_a; command: link_cleanup_report; type: alllink; group: 03
04/29/13 10:10:46 AM [Insteon::BaseObject] $kpl_garage_button_a::set(link_cleanup_report, $kpl_garage_button_a)

[dracoventions]

I see a similar problem with my system, but at least with a Switchlinc, the link_cleanup_report message causes the state to be set to "on" instead of "link_cleanup_report":

04/29/2013 08:36:31 AM [Insteon::BaseObject] Ignoring Received Direct AllLink Cleanup Message for $sl_StairsTop since AllLink Broadcast Message was Received.
04/29/2013 08:36:32 AM [Insteon_PLM] DEBUG3: Received PLM raw data: 0250211195130101cb0600
04/29/2013 08:36:32 AM [Insteon_PLM] DEBUG4: Milliseconds 066.37
         PLM Command: (0250) insteon_received
            From Address: 21:11:95
              To Address: 13:01:01
           Message Flags: cb
                Message Type: (110) All-Link Broadcast Message
              Message Length: (0) Standard Length
                   Hops Left: 2
                    Max Hops: 3
         Insteon Message: 0600
                       Cmd 1: (06) All-Link Cleanup Report
                       Cmd 2: (00) Fail Count
04/29/2013 08:36:32 AM [Insteon::BaseInterface] DEBUG2: Message received with 2 hops left, delaying next transmit to avoid collisions with remaining hops.
04/29/2013 08:36:32 AM [Insteon::BaseInterface] Received message from: $sl_StairsTop; command: link_cleanup_report; type: alllink; group: 01
04/29/2013 08:36:32 AM [Insteon::BaseObject] DEBUG3: Adding hop count of 1 to hop_array of $sl_StairsTop
04/29/2013 08:36:32 AM [Insteon::BaseObject] $sl_StairsTop::set(on, $sl_StairsTop)

Note that this bit of log came from me pressing the OFF button on the Switchlinc, so it was not going into an "on" state at any point.

[peloy]

On 04/29/2013 11:55 AM, cdragon wrote:

I see a similar problem with my system, but at least with a Switchlinc,
the link_cleanup_report message causes the state to be set to "on"
instead of "link_cleanup_report":

04/29/2013 08:36:31 AM [Insteon::BaseObject] Ignoring Received Direct AllLink Cleanup Message for $sl_StairsTop since AllLink Broadcast Message was Received.
04/29/2013 08:36:32 AM [Insteon_PLM] DEBUG3: Received PLM raw data: 0250211195130101cb0600
04/29/2013 08:36:32 AM [Insteon_PLM] DEBUG4: Milliseconds 066.37
PLM Command: (0250) insteon_received
From Address: 21:11:95
To Address: 13:01:01
Message Flags: cb
Message Type: (110) All-Link Broadcast Message
Message Length: (0) Standard Length
Hops Left: 2
Max Hops: 3
Insteon Message: 0600
Cmd 1: (06) All-Link Cleanup Report
Cmd 2: (00) Fail Count

04/29/2013 08:36:32 AM [Insteon::BaseInterface] DEBUG2: Message received with 2 hops left, delaying next transmit to avoid collisions with remaining hops.
04/29/2013 08:36:32 AM [Insteon::BaseInterface] Received message from: $sl_StairsTop; command: link_cleanup_report; type: alllink; group: 01
04/29/2013 08:36:32 AM [Insteon::BaseObject] DEBUG3: Adding hop count of 1 to hop_array of $sl_StairsTop
04/29/2013 08:36:32 AM [Insteon::BaseObject] $sl_StairsTop::set(on, $sl_StairsTop)

Strange. What branch are you running? I am running Michael's
merge_i2_aldb_support.

Cheers,

Eloy Paris.-

[dracoventions]

I'm using merge_i2_aldb_support with a few of my own tweaks but nothing that has much chance of causing this kind of a bug.

[peloy]

On 04/29/2013 12:26 PM, cdragon wrote:

I'm using merge_i2_aldb_support with a few of my own tweaks but nothing
that has much chance of causing this kind of a bug.

Beats me then. The only difference I can think of is different handling
of messages based on device type (you have a SwitchLinc, and I have a
KeypadLinc).

Thanks for the details.

Cheers,

Eloy Paris.-

[krkeegan]

I have also noticed this, I don't think it is limited to specific devices, but rather is an issue with very new devices.

In the short term, we just need to ignore link_cleanup_report messages.

In the long term, we could add a feature to MH that actually looks at the link_cleanup_report to determine whether or not all members in a scene have been successfully changed.

[peloy]

On 04/29/2013 12:54 PM, krkeegan wrote:

I have also noticed this, I don't think it is limited to specific
devices, but rather is an issue with very new devices.

In the short term, we just need to ignore link_cleanup_report messages.

Sounds good.

In the long term, we could add a feature to MH that actually looks at
the link_cleanup_report to determine whether or not all members in a
scene have been successfully changed.

Dumb question... you mean add a feature for cases where MH (the PLM,
rather) is the controller, right? The situation in which I am
(currently) seeing these link_cleanup_report messages is for a
KeypadLinc as the controller and the PLM as the responder, which makes
me wonder -- why would a responder want to know, via this
link_cleanup_report message, that some members of a scene did not change
successfully?

Thinking about this a bit more, though, I think there's value from a
troubleshooting point of view to see in the log something like "Warning:
link cleanup report from $kpl_garage_button_b fail count N".

Cheers,

Eloy Paris.-

[krkeegan]

Yes, in a simple version, MH could at least send a warning to the log stating that a device may have failed to receive a scene command from another device. In a more complicated version, MH could try to rectify the problem by sending a direct command itself (not sure if the link report contains enough detail to do this).

[krkeegan]

All_Link_Report Format:
Type: SD Command
Type: Group Broadcast
From: Dev_ID
To:

• Hi = cmd1 being cleaned up
• Mid = Number of devices in scene
• Low = Group Number

Cmd1: 0x06
Cmd2: 0x00-0xFF (number of failed cleanups)

It looks like at best we can only issue a warning, it doesn't look like the failed devices are identified