I'm not sure whether this should be considered a feature request or a bug, but anyway...
The ability to channel received serial data to more than one device may prove beneficial but I'm not sure how. What I've found (i.e. stumbled upon) is that by the setting of this property to ALL in the hardware device setup is essentially creating a "network" of all serial devices and their associated COM ports. The problem (if it is one, and I think it could be) is that unrelated/dissimilar devices (projector, alarm controller, AV receiver..) really have no need to hear from the other devices on the network. For example, the ELK M1 alarm controller streams status messages out its port to the HB server every 30 secs. My other equipment has no need for that info so it either ignores it or worse, responds with a NAK or similar "WTF" type message. This could cause problems with the device's input buffer or the device may actually think it understands the message and try to interpret and act on it. This could cause the device to lock up or freeze. Changing the "Received Data Serial Device Destination" for each serial device hardware interface from the default "ALL" to only the device interested in the data removes the network chatter problem. I think the default during serial hardware device setup should not be ALL but rather prompt for the name/description of a serial device. But maybe I don't understand the value of this property...
You have a good point. The feature works well with Devices that can handle the broadcast events. It used to be the default, because that's the way the other plugins work (e.g. x10 interfaces will broadcast event updates to all X10 Devices, which is what you want). I added the ability to 'tune' the communication to be able to match specific serial hardware interface connections with their appropriate Device logic.
But I like your idea of a sub-network of devices that could be used for broadcasting events. I'm not sure how it would be used either, but it's an interesting idea.
I could do without this property as well. Almost second nature to set it directly to the device name itself after creating the hardware device and actually never wondered how to use it differently. Forgetting it may cause problems especially when multiple devices are hooked up using the same serial protocol and I am sure that bugged me a few times in the past.
Richard, that is what I was encountering. A recently added Marantz tuner (e/w RTS232 control) was found to be in Nah-Nah Land - would not turn on manually with the front panel - apparently due to the constant stream of Elk data that it was seeing. After that, I realized what was happening and reset all those property values to their own device. My point to Scott was that there may be a value to the broadcast feature, but the property value should not default to ALL. Force the user to provide a value, or give them a drop-down list of devices to choose from (oops: "from which to choose").
