Uhlenbrock devices now support LocoNet (from DigiTrax). Indeed even the Intellibox I supports a LocoNet interface from version 1.55 onwards. The Intellibox II uses Loconet exclusively.
So I decided to take a look at Loconet to see how much work it would be to redo the interface.
The system allows all the devices on the network to send packets of data that all the other devices can 'see'. Some devices then act on these commands, or simply decode their content to obtain information on what is going on, or they can ignore packets that they don't care about. For example when power is switched on, there is a packet of information that is sent around announcing the switch, similarly for power-off, etc. Turnouts and loco commands are also sent about in the same manner. I was able to get stuff working fairly rapidly but I found some gaps in the command set that is published for personal use.
Issue #1
If the computer connects to a LocoNet system, there is no way to know if the Loconet power is on or off! There is no special command to ask if the power is on or off! One is expected to obtain this data as part of loco slot messages, but the Intellibox does not include that data in their packets. This means that a device on the network has to either wait until it sees a power switching packet or send one itself. When my software connects to the digital controller, the first thing it does is send a power-off command. I do this for safety reasons. This means that issue #1 is not a major problem for me at all.
Issue #2
There is no official command that can be issued to obtain the state of all the sensors on the network! As with the power state, sensor state information can only be obtained if they change. As one can imagine, controlling a layout is very reliant on knowing where things are, and this information is conveyed by sensors that report the presence/absence of trains, and other switch settings. Users in the Loconet forum were quick to point out that there is a DCC interrogation command sequence that makes LocoNet sensors report their status, but of course that only works with LocoNet sensors (and if the manufacturer implemented that behavior.) Since the input sensors used by the Intellibox are typically s88 type modules on their own bus, the work around does not work. The Intellibox itself does not respond to the interrogation bytes either. I know that the Intellibox can handle both s88 and Loconet sensors as my software was able to detect changes on a friend's layout using the P50b command syntax of the Intellibox. So the Intellibox has the data, but LocoNet fails to provide a command to fetch the data! The Intellibox does in fact send the sensor states out when it powers up, but the software only connects after that has happened, at which point it is too late.
I wrote to Uhlenbrock and asked if there was a trick I could use. They replied (within hours) and said that it is only possible with the Intellibox II. This is good news at least, if ever I have to replace my system, I could conceivably use the Intellibox II.
Their workaround is that they have a Configuration Variable (CV 73) that allows one to define a turnout address that can be used to request the reporting of all s88 sensors. Therefore all one would need to do is have the software change that turnout when it starts up, and then consume the resulting sensor packets. This feature is also available in their IB-COM product at CV 5.
It is not yet clear if the IB would also relay LocoNet sensor states as well as the ones on the s88 bus, but if not, one would have to rely on the DCC interrogation bytes to get that data. What a mess.
What an absolute pain! Why does DigiTrax make it so difficult to get the all important data? The fact that these missing commands are fundamental to running a sophisticated layout control system, discourages me from using the protocol.
Issue #3
As yet, I do not see any way to fetch the special option data via LocoNet. If this is the case, I would no longer be able to have that feature in my software.
Conclusion
The prevalence of LocoNet may persuade me to implement support for it yet, but I will certainly consider more modern systems before doing so.
The 20 year old documentation of the command set also leaves much to be desired. It is poorly formatted, uses inconsistent nomenclature, contains obvious errors, and almost no examples of how to use the commands. It is not surprising that other software projects have republished the content in a more consumable form.
Addendum
After I very gently pointed out these issues in the "LocoNet hackers" web forum, I was hit by personal attacks. It seems one should not suggest that the system has any flaws.