Add ability to define a turnout as using OpenLCB/LCC instead of DCC

[TrainzLuvr]

How will this work in reality - is there going to be some mapping of OpenLCB events to DCC accessory numbers, kept by the CS, or...?

[atanisoft]

The CS will already map the well-known DCC accessories range when received as OpenLCB events.

What this will be is to present turnouts in WebUI and throttle (via WiThrottle) and generate an OpenLCB event rather than send the request as a DCC packet.

[TrainzLuvr]

It should present turnouts to the UWT-100 in LCC mode though, because that's what UWT-100 connects with to the CS

[atanisoft]

I think that would be great but I don't know how the UWT-100 would obtain the list of turnouts in LCC mode. In WiThrottle mode it downloads a list of turnouts from the server. I'll do some digging.

[TrainzLuvr]

Come to think of it, that was the conversation we were having on the OpenLCB list, I just can't recall whether the standard actually exists or not.

To be honest, I'd make it just like the Locomotive Roster Database. Could probably re-use the code verbatim because it maps Event IDs to DCC addresses. :)

[atanisoft]

I don't think it is part of a draft yet, it might be doable by adding a new node flag (like has cdi or snip) and sending a ping for all nodes that have that flag.

And as for implementation, that is kinda what I'm thinking. I'd extend the current turnout management to add a device type (DCC or OpenLCB) and for the OpenLCB type it would store an event pair to emit when the turnout is interacted with. The DCC address could be assigned fromthe 1-2044 pool or user provided. Then the UWT-100 could emit it's DCC accessory event and the CS translates it to the correct OpenLCB event based on the turnout state it believes the turnout is in (maybe more intelligence to have the CS inspect the accessory for current state at startup?)