There is a Group Broadcast from device 11.77.09 for Group 1 Cmd1 0x13 OFF
12/29/2009 8:52:10 PM – PLM_ProcessInBuffer received STX 0x50 (Raw Insteon Rec):01 11 77 09 00 00 01 C7 13 00
which starts a sequence that eventually leads to an InvalidOperationException in a call from the INSTEON plugin ..
12/29/2009 8:52:10 PM – ***:Error in TransmitDeviceCommand: Collection was modified; enumeration operation may not execute. — Details System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
at util.DeviceUpdateManager.SearchForDevice(String DeviceDescrip)
at util.DeviceUpdateManager.AmUpdatingDevice(String DeviceDescrip)
at HSPI_INSTEON.HSPI.SetHSDeviceStatusAndValue(String Hc, String Dc, Int32 Level, Boolean IsAPollUpdate)
at HSPI_INSTEON.HSPI.TransmitDeviceCommand(String Hc, String Dc, Int32 Cmd, Int32 Dimlvl, Int32 Data1, Int32 Data2)
That is something that should be reported to your software supplier.
I noticed that you replaced the PLC with a PLM. That means a device address change for any device that had a link to the PLC had/has to be changed to the PLM address. Do not know if that is related to the trap that is now happening.
Now that the EZSnsRF is no longer issuing Broadcast messages because the Group has been linked to a responder the PLM may not be reacting to anything sent from the EZSnsRF when it receives the Dakota Alert RF message. The PLM has to be linked as a responder just as the I/O Linc is a responder. No idea if the HS plugin does that automatically or that is something you must do explicitly. A PLC has less stringent requirements regarding links than the PLM does. The HS plugin may have written a generic link record in the PLC which allowed it to receive messages that the PLM will ignore unless there is a specific link from the controller (EZSnsRF in this case) to the responder (PLM in this case). You can use the SHN Utility through the PLC to display the link database in the EZSnsRF and the PLM to see what link records exist in both devices. The PLM is likely to have a “Large” memory size (as they now support 2000+ link records) which requires the “Large” Link Database Size option when the Utility displays link records in the PLM. The EZSnsRF probably has a “Small” memory size link database. If you do not see any link records displayed in the EZSnsRF using the “Small” memory size option, try using the “Large” option. Will not hurt anything if the wrong memory size option is specified besides not displaying active link records that actually exist.
The lack of the PLM as a responder to the EZSnsRF may explain why you no longer get email messages. The PLM and therefore HS is not aware of anything happening from the EZSnsRF.