The JMRIClient Connection provides a method of remotely connecting one JMRI program to another. It can be used to build a Panel on one computer, which is connected to the layout directly, but actually operate the Panel on a computer without a physical connection to the layout.
The JMRIClient Connection can also be used to share information between two adjacent operators without completely replicating the information on each computer. This configuration is particularly useful on modular layouts where multiple module builders are involved.
"Simple" in this case actually refers to the protocol, not the server itself. It uses pretty simple commands that include the device name (except for the power command) to send information bi-directionally. The protocol itself limits the actions that can be taken, so it will eventually be replaced with a more complete (and complicated) protocol.
The server currently supports throwing Turnouts, turning Lights on and off, Sensor feedback, Reporter feedback and controlling Power. You can start the server through a configuration action. It uses TCP port 2048. The port is set in a Preference, so you can change it if needed.
The JMRIClient works with the server to allow remote control of turnouts, lights, and power, and remote feedback from sensors and reporters.
To configure the JMRIClient, you can select the "JMRI (Network)" option in the systems manufacturer list. Under this option is "JMRI Network Connection". You may have multiple "JMRI Network Connection" interfaces configured.
The client currently uses the system prefix to determine what to send to the server. If your server has a connection with a prefix "XYZ", you need to configure your client with the prefix "XYZ" to be able to access the named devices on the server.
If you have more than one system connected to the server, you need to configure more than one client connection. NOTE: There currently is a warning when you configure more than one client, because all of the port information is the same. You can safely ignore this for a network connection.
Once the client has sent a request to the server about an object, any state changes are shown on both the client and the server.
The simplest operational use of the JMRIClient and the simple server is having one computer connected directly to the layout (the server computer) and a second computer ( the client computer) connected to the first via a computer network where you would like to operate a panel.
For this example, we will assume the server computer has a LocoNet connection with the prefix 'L'.
On the server computer, open the Preferences, and select the Start Up group. click the "Add ▾" button, select "Perform action..." and select "Start JMRI Simple Server" from the list of options. Save the preferences and restart the program.
On the client machine, add a "JMRI (Network)" connection. Change the system connection prefix to "L". and set the IP address to the IP address of the server. Save the preferences and restart the program.
Once both computers have restarted JMRI, you will be able to load a panel file on the client computer which was created on the server computer.
Each machine will have its own set of tables and ( optionally) panel files loaded, if the client causes an action, information will be transferred to the server, and the server will trigger an action on the layout. If an action occurs on the server, the server will transmit an indication of the action to the client if the client has indicated it is interested in the device.
Invert is defined for both sensors and turnouts. If invert is enabled on both the client and server, the actual device will have normal behavior when the client uses it.
This one is interesting, because it can be a bug or not a bug depending on your use case.
If your use case is that both the client and server machines have panels running, then you might consider this a bug. There are two work arounds in this case 1) load a panel without inverted set on the client or 2) Run the panel on the server through a second instance of JMRI which is acting as a client to the first instance.
If your use case is that the server just provides connections, but doesn't do any logic, then this is not a bug.