That is the problem. There's no way of uniquely determining the JMRI ID (user-created and stored in the roster entry) from what is stored in (and we can read back from) the decoder (DCC ID, CV7, CV8). (That is what the original poster asked for.)

JMRI attempts to do just that. In some cases you may be lucky, in other cases (see Gerry's, mine is similar) you are going to get many matches to the only readable information.

The Identify button is a blunt instrument. If it works for you, count yourself lucky.
--
Dave in Australia

Marc,

I've already checked that out and sent an image showing him what to fix on the Defaults screen.
--
Dave in Australia

Marc,
Thanks for your reply.? If the PR4 works with Soundloader but not JMRI, but my PR3 (same computer, same JMRI and same loco and same power supply) works fine with both SL and JMRI, does that not indicate that there IS some kind of difference between the two? Maybe not command wise, but hardware wise, which could have an influence on how it communicates with decoders.

Regarding #4, all I have been saying is that there are a number of messages in this forum of PR4 users exhibiting similar issues. aI know there are few messages that say "my PR4 works fine". So is the issue a DT quality control issue, that the PR4s that do not seem to accept JMRI are maybe on the edge of some tolerance. Or is there another factor??

One alternative I told my friend to try when his PR4 arrives back, is to use the PR4 to drive the control station programming, rather that using it standalone. Perhaps that is why the "my PR4 works" crowd is successful? But I will also suggest to him that we check his power pack (currently a PS14, if I am not mistaken, so not 12V)
--
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

That's why I want Mark to install V4.15.1. The log will then tell us what JMRI actually read.
--
Dave in Australia

--

...and is the discussion about the DCC ID or the JMRI ID? I am totally confused.
--
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

开云体育

On Wed, Jan 2, 2019 at 09:27 PM, Dave wrote:

Chris,

Re: 64 byte limit - I saw it in a message from Speed on 15 Dec. Yes, it is referring to ESP type devices, it's certainly not a problem with MQTT itself. Does anyone know what the smallest payload limit is on the devices we are likely to use for model railroads, perhaps NodeMCU ESP8266???

For signals, it may be simpler to use signal heads where the payload only needs to be the appearance - red, flashing yellow, dark, etc (also mentioned by Speed)? Masts can be built using Signal Head Controlled Mast driver, already available in JMRI.?

Simplest case payloads:

?

Device type? -? ?Payload options

?

Turnout - Closed | Thrown

Sensor - Active | Inactive (or 1 | 0 )?

Signal Head - Red | Yellow | Green | Dark | Flashing Red | Flashing Yellow | Flashing Green

and perhaps though maybe later down the track
Signal Mast - the aspect name (which isn't as simple as it sounds because there are in some railroads multiple appearance options for the same aspect name)?
? ? ? ? or? ? ? -? ?the combination of head appearances with comma separators e.g.? red,flashyellow,red

(Note: There appears to be some inconsistency between Heads and Masts currently in JMRI in the use of? flashyellow vs Flashing Yellow and where lunar is an option. I don't yet understand why that is so, will look a bit deeper)


Things start to get more complicated when you want to include more detailed configuration information to reduce the configuration information needing to be held in the actioning device or for having flexible devices and therefore requiring more instruction.? We can consider making allowance for this, perhaps using the Comments value in the JMRI table, or, at least as an interim step, just make it a requirement that such configuration is for the actioning device to sort out.?

- David.

Dave,?

I have some serious doubts that ESP8266 or ESP32 will have problems with JSON as shown in my last post. These two specific boards are very popular in the home automation spectrum and have the ability to parse these JSON:

{ "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 }

I am not saying there are limits, but I have some serious doubts a JMRI payload will reach 64 bytes. As long as the the simple things like turnouts and sensors are kept simple. I believe that lights, signals should have the ability to be in JSON and this should allow more dynamic things for example. Reporters can also be simple text or JSON. If JSON are used for reporters the user would have to probably develop a custom script, since they are more than likely doing something special.?

Chris

开云体育

???????

Here is just a small section of my roster - all have the same Road identification, most have the same road number, but different decoders. This roster only has 1,405 entries - some N Scale, Some HO and Some O scale. These locos are all green.

NSW 3801	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 ar	3801	Econami Steam	ECO-200 Steam
NSW 3801 bd	3801	Tsunami Steam	TSU-1000 Light Steam
NSW 3801 dt	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 gh	3801	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 gw	3813	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 jb	3830	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 jp	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 js	3801	Tsunami Steam	TSU-1000 DRGW K-Class Steam
NSW 3801 mp	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 mw	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 mw fl4	3801	TCS Function Decoders	FL4
NSW 3801 SM	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3801 tsu	3801	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 wh	3801	Tsunami Steam	TSU-750 DRGW K-Class Steam
NSW 3801 wh2	3801	QSI Steam Ver. 7	Eureka C38 4-6-2
NSW 3802	3802	QSI Steam Ver. 7	QSI Revolution Steam
NSW 3802 ls	3802	Tsunami Steam	TSU-1000 DRGW K-Class Steam
NSW 3802 rb	3802	Tsunami Steam	TSU-1000 DRGW K-Class Steam

This is why the application needs a database engine under the hood. That would also allow picklists for road names and locomotive models. That would make it very easy for make an indexable ID system.?

-- 
Gerry Hopkins MMR #177 FNMRA
Great Northern Downunder




NMRA Australasian Region
Contest & AP Chairman
Web Administrator

Chris,

Re: 64 byte limit - I saw it in a message from Speed on 15 Dec. Yes, it is referring to ESP type devices, it's certainly not a problem with MQTT itself. Does anyone know what the smallest payload limit is on the devices we are likely to use for model railroads, perhaps NodeMCU ESP8266???

For signals, it may be simpler to use signal heads where the payload only needs to be the appearance - red, flashing yellow, dark, etc (also mentioned by Speed)? Masts can be built using Signal Head Controlled Mast driver, already available in JMRI.?

(Note: There appears to be some inconsistency between Heads and Masts currently in JMRI in the use of? flashyellow vs Flashing Yellow and where lunar is an option. I don't yet understand why that is so, will look a bit deeper)


Things start to get more complicated when you want to include more detailed configuration information to reduce the configuration information needing to be held in the actioning device or for having flexible devices and therefore requiring more instruction.? We can consider making allowance for this, perhaps using the Comments value in the JMRI table, or, at least as an interim step, just make it a requirement that such configuration is for the actioning device to sort out.?

- David.

I don't know where we're at now with the MQTT extension proposal.

I’m waiting for a consensus to emerge so I can code it.

I think that consensus has emerged for the addressing (the topic will be taken from the system name, so people can use what they want), but not for the payload.

I’ve learned to insist on a real, multi-person consensus on things like this because there’s a natural inclination for people to add more and more and more complexity based on their own experience and desires. JMRI needs something that will work for lots of people, from simple (which tends to not get valued in these conversations) to more complex.

It would be great if the roughly half-dozen people in this thread could agree on something that would work for all of them.
--
Bob Jacobsen
=============
I think the topic parts need to be two types.
Global
Individual
The global would be:
Trains/
Sensors/
Reporters/
Turnouts/
Signals/
Lights/

This way JMRI could send out a message to address every item of a type.
For an example would be: Trains/ ALL STOP
Trains/ ACK .....This so that a keep alive function for the link. The item does not have to do anything but acknowledge the message.
Sensors/ STATUS ....So you could get a status report of every sensor.

This way JMRI could ensure that all the connections remain alive if sent every couple of minutes.

The individual would the item name
BNSF_907/
NW_789/
Turnout_mile_104/
T_134/
North_section/
My_Town_Yard/

The last two are for those who have a node that connects more that one item.
My_Town_Yard/Ladder_1/
My_Town_Yard/Ladder_15/

Now this does mean that each node will need to subscribe to more than one main topic.
The BNSF_907 would have BNSF_907/#/ and Trains/#/

The WiFi Throttle would have to be able to subscribe to numerous locomotives in case of a consisting. But as the Message would need to be sent to all the locomotives in that consist separate anyhow a minor problem if the locomotives are using WiFi for the connection.

The setup of the items in JMRI would have the main link to the node as the main part; The item name; the payload.

The actual items on the layout would never send a global message.

As for the payloads.
Have some global define words
NOP is No Operations required.
ACK is Acknowledge for keep alive link.
STATUS is send a report of all the variables.
ALL STOP

Other things to include would be:
Quote marks for ASCII characters. This is so if someone need the word "Thrown" they can use it or send the binary value of Thrown (0/1).
The different definitions of how to send the values Like Logical/Binary/Hex/Integer/Floating...
Standard notation could be used for this.

As for the length of the messages. I would suggest an upper limit of 96 characters for each the topic section and the payload section.

Donald

Hi Nick.
Signal masts.
Create 2 or more. Disable aspects you don't want, so just leave clear and stop say.
Add signal mast icon to panel. - not assigned to block join or turnout or any of that stuff.
Red X appears. Left click, edit signal mast logic. Add route to another mast (that's why you need more than one). All the auto stuff at the top should be unchecked. Manually add turnouts, sensors, blah blah. Or none.
Save panel.?
Next time you open no red X. Click on icon to change aspect, or what ever you set in the logic.
Signal heads work the same way. Add Signal Head icon, not signals to block join or turn out.?
Free form.?
Steve G.
You can design your own signal mast system if you don't like any of the existing ones. To make simple ones, copy one that's over stocked and delete the bits you don't want..
Can't use these for auto engineer trains.

This is why the application needs a database engine under the hood. That would also allow picklists for road names and locomotive models. That would make it very easy for make an indexable ID system.?

Martin, you mention several different connection mechanisms. If your target is Loconet, I suggest focusing on the LoconetOverTCP connection and ignore the others. I use it regularly on my home and club layouts with excellent results (Win10 laptop client to RPi server).
Make sure you are specifying the same port on the server and client sides. I believe the default for that connection is 1234, but check both sides anyway.
--SteveT

The Identify button is a crude identification procedure because it relies on reading CV information from any arbitrary decoder and matching it to the roster entries.

What identification is in the roster entry is limited. No matter what manner the roster entry has been created (read type from decoder or simple manual selection), the only (hopefully reliable) information is the DCC address (in CVs 29,1,17&18) stored in the roster entry (provided the user either read or set and wrote that). There's no guarantee that CVs 7 and 8 have been read by the user either (however the identify procedure does attempt to match them as well - hopefully only if non-zero, I haven't checked the code).

Any attempt to read (and store) ProductID from a decoder during Identify is not only time consuming but not gaining anything because again there's no guarantee the user used the "Read type from Decoder" rather than manually picking (possibly incorrectly).

There's no way JMRI can tell the difference between liveries etc. from the decoder.

Furthermore many Sound decoders share ProductIDs between decoders with different sound projects, or have differing ProductIDs due solely to hardware batch numbers.
--
Dave in Australia

Marc,

We don't actually know when Mark read the decoder type (as you said there is nothing in the log to indicate when) in relation to the 308. He could have been busy transcribing the answers I requested from the other screens before trying the identify.

I have asked Mark to install V4.15.1 because in it I had already changed the IdentifyDecoder code to always log an INFO message with the values of ManufacturerID, VersionID and ProductID it finds. (The code previously only did it for some ManufacturerIDs.) This will make it a lot easier to diagnose these problems and also for an average user to easily report meaningfully when there is an identify failure or a misidentification, assisting definition developers greatly.

Dave in Australia

I guess the right response is that the ID for every locomotive is the manufacturers part number. So the NYC 4301 PA unit is?106-0701-B, and the MRL SD70ACE is?176-4301-9999 where the 999 in my scheme means it is a custom painted and numbered locomotive. As I said all my ID's are unique.

Another try with more robust iMac as client to same RPI server.

Log file:

2019-01-02 16:05:46,872 node.NodeIdentity? ? ? ? ? ? ? ? ? ? ?INFO? - Using jmri-lVjxtcZsGhNiaaypSc6P96-3eeb2581 as the JMRI Node identity [AWT-EventQueue-0]

2019-01-02 16:05:47,253 locormi.LnMessageClient? ? ? ? ? ? ? ?ERROR - Exception while trying to connect: java.rmi.ConnectException: Connection refused to host: 192.168.1.15; nested exception is:?

java.net.ConnectException: Connection refused (Connection refused) [main]

2019-01-02 16:05:47,255 configurexml.ConnectionConfigXml? ? ? ERROR - Error opening connection to 192.168.1.15 was: {} [main]

jmri.jmrix.loconet.LocoNetException: Failed to Connect to Server: 192.168.1.15

at jmri.jmrix.loconet.locormi.LnMessageClient.configureRemoteConnection(LnMessageClient.java:93)

at jmri.jmrix.loconet.locormi.configurexml.ConnectionConfigXml.load(ConnectionConfigXml.java:110)

at jmri.jmrix.ConnectionConfigManager.initialize(ConnectionConfigManager.java:106)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:264)

at jmri.implementation.JmriConfigurationManager.lambda$3(JmriConfigurationManager.java:260)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:259)

at jmri.implementation.JmriConfigurationManager.lambda$3(JmriConfigurationManager.java:260)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:259)

at jmri.implementation.JmriConfigurationManager.lambda$1(JmriConfigurationManager.java:183)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.load(JmriConfigurationManager.java:182)

at jmri.implementation.JmriConfigurationManager.load(JmriConfigurationManager.java:170)

at apps.Apps.<init>(Apps.java:261)

at apps.PanelPro.PanelPro.<init>(PanelPro.java:40)

at apps.PanelPro.PanelPro.main(PanelPro.java:120)

2019-01-02 16:05:47,286 locormi.ConnectionConfig? ? ? ? ? ? ? WARN? - Unexpected call to setInstance, multi-replica capability not yet present [main]

2019-01-02 16:05:47,293 jmrix.ConnectionConfigManager? ? ? ? ?ERROR - Unable to create jmri.jmrix.loconet.locormi.configurexml.ConnectionConfigXml for [Element: <connection/>], load returned false [main]

2019-01-02 16:05:47,295 plementation.JmriConfigurationManager ERROR - Exception initializing jmri.jmrix.ConnectionConfigManager: Unable to create connection "LocoNet" (L). [main]

2019-01-02 16:05:47,646 jmri.InstanceManager? ? ? ? ? ? ? ? ? ERROR - Should not set default of type jmri.CommandStation to null value [main]

2019-01-02 16:05:47,647 managers.ManagerDefaultSelector? ? ? ?WARN? - SystemConnectionMemo for LocoNet (class jmri.jmrix.loconet.LocoNetSystemConnectionMemo) provides a null interface jmri.CommandStation instance [main]

2019-01-02 16:05:47,648 plementation.JmriConfigurationManager ERROR - Exception initializing jmri.managers.ManagerDefaultSelector: System connection LocoNet provides a null manager for interface jmri.CommandStation [main]

2019-01-02 16:05:47,720 plementation.JmriConfigurationManager ERROR - Exception initializing apps.StartupActionsManager: jmri.util.prefs.InitializationException: Unable to run startup actions due to earlier failures. [main]


There is no firewall that I am aware of on the RPI.

Thanks,
Martin Booker

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.