Bob J. wrote: "Is it really known to be true that there¡¯s enough information in the DCC messages to do that for "DCC Signal Mast Decoder"? I.e. there¡¯s a way to tell held or not, lit or not from just the messages?"
Generally, the NMRA standard for "Extended Accessory Decoder Control Packet"s defines a signal mast number and a five-bit aspect value (for up to 32 possible aspects). Other than aspect 0 being "absolute stop", it does not define any specific aspect/value pairing - the user or the hardware implementation gets to decide the other aspect/value pairings.
Specifically, JMRI's "Dark" aspect is typically conveyed to a DCC extended accessory decoder as a unique "aspect number", with the mast hardware using that aspect number to turn off all lamps in the signal. Presumably the DCC extended accessory decoder supports a dark mast. JMRI already has the capability to express "dark" as a signal mast aspect. For those system JMRI configurations which support monitoring externally-generated aspect changes, such as "LNCP Signal Mast"s when operating on a LocoNet connection, JMRI will follow such external aspect changes.
Specifically, JMRI's "Held" condition is an internal state of JMRI and, so far as I can tell, is not (typically) exposed in the DCC message.
There is no reason why one could not map the "held" condition to an aspect on an extended accessory decoder, so long as there is only one aspect used in the "held" case. That "held" aspect could duplicate the appearance of another aspect, such as "absolute stop", but use a different, unused DCC aspect number. Hardware would interpret that new aspect number as an appropriate appearance. This would allow communication of the "held" state on the control communication media.
In the user's specific case, with the suggestion made above, this unique LocoNet message for the "held" state would be uniquely conveyed via LocoNet, and JMRI would be able to "detect" the message, regardless of the message's source. A JMRI mast configured as an LNCP Signal Mast, via a LocoNet connection, would have this capability, without any JMRI Java coding changes, for any signal system which defined a unique aspect for the "held" state.
So far as I know, no existing JMRI Signal System definition defines the "held" aspect as a unique aspect; I believe they all simply declare the "held" state to be equivalent to the "Stop" aspect or some similar aspect. But a simple set of changes to the user's "signal system definition" would enable this functionality.
The only limitation I can think of to such a solution to convey "held" information on the communication media is that there are only 32 possible mast aspect numbers in the DCC Extended Accessory Decoder packet. Any existing mast which implements 32 unique aspects without a defined "held aspect" would not allow adding an additional aspect for the "held" case.
Regards,
Billybob
