Hi,

Trying a similar thing per a previous post with RPI 3 running JMRI 4.12, Java 191 but using the Loconet simulator for testing purposes.? The client is a Pi zero wireless with same pieces of software on the same network. (The zero with a small touch screen is actually cheaper that iPads, etc.).??

Set up the server start action in preferences.? Restarted JMRI on the RPI.? ?Opened a Panel Editor panel.? Started JMRI on the zero.??

No joy with any of the JMRI client/server options: Simple server, Loconet 'direct', Loconet over IP...

The zero says cannot connect to the server and opens the preference dialog to update.? The Loconet tab is highlighted in red.
The RPI does?not?seem to start the Loconet Server at init, even though I get?

INFO - Using jmri-n- as the JMRI Node identity [AWT-EventQueue-0]
INFO - lnPacketizer Started [main]?

in the console
and starting it manually gives:

WARN - Could not Create RMI Registry, Attempting to locate existing Registry for: LoconetServer [AWT-Eventque-0]

Both systems can ping each other across the network.
Please advise, and thanks,

Martin Booker
BTW: the Web pages for client server configuration need an update as those screens are not the same in 4.12

I name the locomotives by the manufacturer's part number, and they are unique.

I have been having similar issues. I agree that this is not a JMRI problem, but one which was caused by the short sighted people who set up the original specification for DCC

Hi Klaus

Sorry the correct init-jmri code should have read:

Hi all,
Thanks for all the responses.? I just bought a PR4 and plugged that into my DCS51 loconet port and plugged my Laptop into the PR4 or the Pi into the PR4 through usb port and all is happy and communicating now.

This is an AWSOME! group
thanks for the timely remarks

Shag.

开云体育

I think Paul and Dave are on to something so I converted the images from JPEG to PNG and problem is solved.

Thanks for all your responses.

Nick,

One trick people have used for masts when the next thing is an end of track
buffer is a signal that only has stop enabled. Then whatever points at it
would figure approach at best.

For your case of manual signals, without Logix to drive them, you'd need the
mast logic and it deals with mast pairs. Think of the sensors like the
sensors in the signal head logic, any active sets stop. Clicking on a mast
will cycle through the enabled aspects.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Hi Klaus

Thanks for your response in the previous post, Here's some feedback:

Q1. JMRI simulator mode

You can use JMRI without a connection to the layout. This is the simulator mode. I use the LocoNet Simulator () and VSD works fine with it.

Please create a new profile in Edit >> Preferences >> Config Profiles >> New, if you want to give it a try. After a JMRI restart select "Digitrax" as the system manufacturer and "LocoNet Simulator" as the
system connection.

Awesome !!? I got that going pretty quickly in my study on my Windows laptop, changed a few settings and tidied up my roster, copied the changed files up to my Google Drive and replaced them from the GD onto the memory stick in the RasPi which runs the layout. Love the simulator mode as it allows me to do heaps "offline".? My wife thought I'd moved the layout into the study, with all the Bells and Whistles going off !

Q2. Throttles

When I add a VSDecoder in VSDecoder Manager, I add a JMRI throttle as well. One JMRI throttle for each VSDecoder. When I have a connection to my layout, I prefer physical throttes. The DCC address in VSDecoder and throttle must match, of course. Using WiThrottle and Engine Driver is a common way to control locos (up to four, I think). An open VSDecoder Manager with minimum one VSDecoder is required to control a loco.

Copy that !! What a good idea. I did that in the simulator and also on the layout with monitor/keyboard attached to the RasPi. Then I SSH'd and VNC'd into the RasPi from my Linux laptop and iPad in the garage and removed the monitor/keyboard?(which gets in the way of running the trains.? So now I've got a match-box size computer running everything with remote UI access to change anything !

Q3. "VSD faceless" is not yet part of JMRI. The setup could be something like:
1) Create and configure a roster for each VSDecoder
2) Put them into a roster group named "VSD"
3) Configure a throttle key for each VSDecoder to start/stop the engine
4) Set JMRI startup: Start Virtual Sound Decoder Manager and Web Server
5) Run JMRI with option apps.JmriFaceless

On your last SD> comment:
It should be possible to auto-start RasPi and JMRI and VSD without any interaction, and to shutdown as well. On my local test environment I can drive a loco with VSD sound (simulator mode) via JMRI Web server (http://localhost:12080/web/webThrottle.html). Open point: how to shutdown.

I'm going to leave the faceless stuff for now, but I'm already able to start the RasPi from cold or reboot with the following Startup "init-jmri" code in the Pi:


This code mounts and syncs Google Drive each time i start/reboot the RasPi then starts up VNC server with the required settings, then launches JMRI which has a bunch of internal startup commands which start WiThrottle, Webserver, VSDecoder, roster, turnout-table, turnout panel, etc. so that when I VNC into the Pi a can see and interact with all these windows on the laptop.

As for shutting down, i just ssh a Linux "reboot" command to make a fresh start of JMRI, or else ssh "poweroff" to shut down the RasPi completely.

I'm going to have a play with configuring the VSD files, including looking at which function buttons (is that the same as "notches" ?) each sound is allocated to. Is there any JMRI or other standard specs for what particular function applies to a particular button ?

BTW. Is there any provision for including photos in the jmriusers posts ?? I wanted to include a shot of the RasPi JMRI UI as seen by my iPad.

Cheers

Graham - @SettleDown

On Tue, Jan 1, 2019 at 04:53 PM, Dave wrote:

Folks,
On re-reading this thread, I've noticed that MQTT software libraries for the small devices that will probably be commonly used in our situations have a restriction of 64 characters for the payload (I think just the payload, not the combined topic+payload) so the ideas I floated some days back are way off the mark.
Using JSON for the payload will eat up 64 characters very quickly so becomes a severe limitation.? It will work for simple cases in which case the benefits of JSON are diminished anyway.?

I'm not greatly fussed over whether we do or don't use JSON for payloads, happy to go with the flow of popular opinion though I do think JSON is the better way to handle more complex payloads.? However, the 64 character restriction makes me feel that we need to abandon JSON payloads, and therefore need more rigid (ugly) formatting to make best use of the 64 characters available to be able to handle the more complex situations and the valid desires that some people will have to pass additional information in payloads.

We need to have a set specification for the content and format of both the topic and payload for the proposed JMRI coding to be done.
I think we've had some very good ideas expressed in this discussion and reasonably well aligned but the details not yet set.

Regards, David.?
?

Dave,?

Can you share where you got that 64 character limit for the payload? I can understand on small devices like on an ESP8266, ESP32, or Arduino board this can maybe a problem. In the Home Automation world JSON is used as payload in MQTT and a Home Automation Hub like Home Assistant or OpenHAB is no different as JMRI. JMRI is a hub for model trains. For instance Home Assistant uses this payload over MQTT for an RGB light bulb.


{ "brightness": 255, "color_temp": 155, "color": { "r": 255, "g": 180, "b": 200, "x": 0.406, "y": 0.301, "h": 344.0, "s": 29.412 }, "effect": "colorloop", "state": "ON", "transition": 2, "white_value": 150 }


On Wed, Jan 2, 2019 at 10:52 AM, Speed wrote:

We should start with something simple, like using the Topic in the System Name (as Bob suggested) and then use, at first, the same Message or Payload as JMRI already does it, may that be Turnouts with "Closed/Thrown", Sensors with "Active/Inactive", Signals with "Red/Yellow/Flashing Green" and Masts with "Stop/Clear/Approach/Dark", for the publishing part.

I agree that sensors, turnouts, and records don't need to be JSON. The topics can be simple clear and concise text for the payload such as Closed, Thrown, Active, Inactive, On, Off, and so on. I do think however that for signals it may need to be JSON such to make it easier for the the board controlling the physical signal. I also feel that lights can use utilize json like above example for reply back to Dave. Maybe you don't need effect or a few other things, but this would allow JMRI to better support LED lighting that all or most of us are using for our buildings, street lights, etc.

On Wed, Jan 2, 2019 at 10:52 AM, Speed wrote:

I do not completely understand the?use?of JSON, but most libraries for embedded systems have limits to the message size, the library I am using for example () has a 128 byte limit: "MQTT_MAX_PACKET_SIZE".? Sure, we could change that number, but where does that leave the 8-bit controllers with limited memory space?? I imagine JMRI would publish to a Broker, and the Broker would then send it directly to the described small devices. When we publish an 'ACTIVE' to a topic that contains 'sensor', is it worth unpacking the JSON string to find out that it is a sensor and the state is now active? Not saying there is no need for JSON, I just don't see the need in the end device receiving the MQTT message.

You are absolutely are correct by what you are saying, but as I stated earlier in this reply. In home automation the embedded systems are reading JSON in the payload and are used in this manner for RGB lights for example.?

I think major think to consider when implementing MQTT into JMRI is to keep it as simple as possible. MQTT is lightweight and powerful communication protocol for network capable devices. Maybe we should be looking at how Home Assistant or implemented JMRI into their system, since JMRI is similar in nature except it is controlling a model railroad and not a whole home. Another thing to remember is that a node device can publish to a topic and another node device change a state of a turnout or whatever without JMRI telling it to do so. This allows things to work when JMRI crashes for some reason too.?

Chris

Mark,
I notice in your log file that you have a 'no acknowledge from locomotive' message. This is the same problem that my friend is having with his PR4. Like you we tried the Digitrax SoundLoader and that seemed to work. He sent his PR4 back to Digitrax for repair (just before the hurricane) and just heard back that they cannot find anything wrong. It is beginning to sound like there are more differences between the PR3 and PR4 than Digitrax is letting on. JMRI may need to be modified to accept the PR4.

Just my $0.02
Stefan
--
Stefan Bartelski

Home layout: The Blue Ridge Line, an HO representation of the L&N Etowah Old Line from Etowah to Elizabeth, set in 1986 9under construction)
Modular Layout: Shoofly module of the Country RRoads Modular group

Nick,

The biggest issue people have with masts is the masts want to follow the
rules. Doing things 'with modeler license' are not so easy.

The concept is you build the one mast by telling it which is the next mast.
Then you add what turnouts have to be set which ways for that to be the next
mast. Add the block sensors in between, and it works. For the most part,
that's what the logic builder does for you automatically. I generally let
the builder do its thing.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

A serial link, with JMRI thinking its talking to a C/MRI system and your hardware-control PC emulating a C/MRI system, will work for Turnouts and Sensor.

But it won’t work for throttle control from JMRI. C/MRI, hence the C/MRI protocol, doesn’t know how to do that.

So you can either use a 2nd serial link from JMRI to the EasyDCC system directly, bypassing your PC, or you can use a 2nd serial link from JMRI to your PC that’s carrying the EasyDCC protocol.

Bob

On Jan 2, 2019, at 1:31 PM, Don Weigt <dweigt47@...> wrote:

Thanks, Bob. I'm a little closer to understanding. All of your reply was clear, until the final question about two serial links to the PC. Does C/MRI always and only use a serial link to the computer? Or, where else were you envisioning it? I didn't expect to duplicate C/MRI interface hardware, only mimic enough to use the same message structures.

It seems I should research C/MRI before asking anyone on this list to answer questions about connecting JMRI to it with my hardware.

Don Weigt

--
Bob Jacobsen
rgj1927@...

Andy,

The problem with my DCS-51 is it will not allow me to Program anything.? I discovered this when it wouldn't allow me to program anything.

Mark DeSchane

If you truly want to create a simple ABS signal system with PRR signals, the easiest would be to use signal mast logic.? You have already done the hard part of building the signal head in JMRI.? Just create masts from them now.? The PRR-1956 system has a single head absolute mast with 4 aspects.? You can disable the permissive aspect during the process of building the masts.? That will leave you with clear, approach, and stop.? Once the masts are defined, all that other stuff you want to be rid of will be gone.? Setting up ABS will be super easy.? In the signal mast logic, instead of using discovery, manually set the destination signal and the block sensor and your done.? You could use discovery but that adds the complexity of making sure the layout is drawn properly in the layout editor.? I don't think there is a way you can do it that is any easier or simpler than that.? The red x's when the panel starts will go away as well.

Greg McCartney

This isn't a JMRI issue but an ID naming issue on your part. Gerry has already suggest one way to do it.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -