开云体育

  1. Jmriusers
  2. Messages
Expanded Topics Messages Polls
Date
Locked Re: MQTT Connection in JMRI

 

David,

That is true. I just wanted to point out that JMRI likes that "M2T" to be way in the front, and it does not use it in the "addressing" to the real thing. (L5T123 being thrown only gets accessory 123+ON on the LocoNet connection with the prefix "L5".)

Speed
Locked Re: MQTT Connection in JMRI

 

Dave,?

I think this is a "yes"!

If your turnout is in JMRI with the topic "foo/bar/biff/21/mine", JMRI should promise to publish a message to the MQTT broker to that topic when the state of the turnout in JMRI changes. Keep in mind that JMRI does not know who else is subscribed to the topic, so it can't guarantee that the turnout changed state. If "retention" is on, meaning the MQTT broker will keep the message in that topic until it is override with something else (or NULL), everyone who turns on later and subscribes to the same topic (yes, either through wildcards or directly) will receive the message.

Maybe I don't understand your question completely, but, yes, JMRI will send a payload to that specific topic, even if the topic, did not exist prior to this publishing event.?

Speed
Locked Re: MQTT Connection in JMRI

 

Correct. If the MQTT system is in JMRI as “M”, creating a turnout with system name MTfoo/bar/biff/21/mine will result in JMRI subscribing to and publishing to the topic foo/bar/biff/21/mine

Bob

On Jan 9, 2019, at 9:24 PM, Dave Lowe <dlowe30971@...> wrote:

On Thu, Jan 10, 2019 at 04:48 AM, Bob Jacobsen wrote:
Two examples: If the system letter is M, then:

*) MTfoo/bar/biff/21/mine is a turnout that uses foo/bar/biff/21/mine as the MQTT topic

*) MSrailroad/stuff/notMentioningSensorsHere/yardOSwest is a sensor that uses railroad/stuff/notMentioningSensorsHere/yardOSwest as the MQTT topic

Etc. The first letter (optionally followed by digits) is the system prefix; the following T/S/R/L defines the type, and all that follows is the specific topic for that item.

Bob
All, I like this idea the best as it let the user create/specified whatever their requires are. I have one question to get this straight in my mind. So with the table (say turnouts) the turnout that would be associated with MQTT will have the corresponding topic? In the case above, it would be "foo/bar/biff/21/mine"?

For my understanding,

Dave, Brisbane Australia.
--
Bob Jacobsen
rgj1927@...
Locked CV-18 debate CLOSED !!

Nick
 

Friends,

I have been a member of this group from the beginning. I have always been proud and happy to help whenever possible. Recently, I made a post about programming using CV 18 to create a 4-digit address with NO information about the system, interface, or the method.?

I suggested a method I learned from Loy Spurlock of Loy's Toys back in 1993 using a Digitrax system with a DCS100 and a throttle.?

Evidently, this suggestion was considered to be the same as reporting a flying saucer or flying monkeys .

To those members that do not know me, I apologize that you do not understand I try not to spread bad info that I have not tried and I do not make it a habit of misleading people . True, I did not think about folks that have never experimented with new technology , nor did I think I would need to provide "proof" as most member know my "reputation" , such as it is.

I truly apologize that I might have predicted the end of the world, or the possibility that the Earth is not the center of the universe. To those that I have "offended", I apologize and I will no longer attempt to assist someone on-list. For anyone interested, I have the almost 30 year-old documentation from Loy's Toys stored in my shed along with my Atari Computer with a hard drive (I was told, that couldn't be done either). I'm not going to dig it out but I have learned a lesson today that I will not forget. Accusations without investigations help no one. To be quite frank, I honestly do not care if you believe me or not.

Respectfully,
Nick Kulp
Locked Re: MQTT Connection in JMRI

 

On Jan 9, 2019, at 6:59 PM, Dave <davemc@...> wrote:

With unconstrained topic path with no mandated device type component, it means the JMRI MQTT client will need to subscribe to all events under the channel top level ( channelname/# ) for all device types and then search all JMRI MQTT objects for a match. I think regardless of the object type, the desired action is to update the state if it differs though without re-publishing the message.
Why does it mean that?

The JMRI code for doing the subscribe would be _identical_ to what’s there now (which doesn’t have to do that), _except_ that the topic string would be completely generated from the JMRI system name string, without an fixed prefix part.

Bob
--
Bob Jacobsen
rgj1927@...
Locked Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style

 

Hi David,

Just to give you an indication of how I've done this with MERG kits for my DC / DCC test layout,
I was also looking for a low-cost option for block occupancy / signalling, with a high element of self-build.

1x TOTI12? - ?15.50 ( 12 DC / DCC diode block detectors, NOT a CAN module ),
? ? I've got this board in 1 place but can be split around the layout
? ? These come with opto-isolators so I connect them to straight to CANPAN inputs ( or probably Audrino inputs? )
? ? approx ?1.29 per block ( + 2x separate 5v supplies to feed the main TOTI boards )

1x CANPAN - ?13.94 this has 32 multiplexed inputs and 32 LED multiplexed outputs
? ? 8 of the inputs wired to the TOTI8 , so 1 block per input, would have 20 spare inputs though always handy ;-)
? ? 4 of the outputs used per 4 aspect signal, driving the LEDs directly from the CANPAN
? ? approx ?0.22 per input or output

1x CANUSB4 - ?11.04 Provides a CAN to PC / laptop / Rasp Pi interface.
? ? 1 per layout

Extra bits of kit used
JMRI - listening to events ( input state changes ) from the CANPAN, sending events to the CANPAN to change the LED signals
Existing DC train controller
1x CANACT CAN network activity monitor ( ?3.72 )
2x resistors for terminating the CAN network
CAT5 cable for the CAN low, CAN high and CAN ground between CANPAN and CANUSB4
1x decent 12v power supply ( existing )
2x 240v to 5v USB charger wall packs ( existing, for powering the TOTI's )
1x MERG membership
LEDS from auction site
Home-made signals ( basically a mount for the LED's )
Soldering iron ( existing )
Solder ( existing )
Anti-static kit ( existing )
MERG Youtube videos for the soldering tutorials
Cups of tea ( loads )
When system worked OK, I added a MERG CANCMD DCC controller to the CAN network + appropriate power switching before the TOTI stage
Have also got some laser spot detectors ( a MERG pocket money project ), which I've run through opto-isolators then fed into spare inputs on the CANPAN.

I started with a few of the pocket money kits before working my way up to some of the more intricate kits ( the CANPAN does require SMD soldering ).
Extra CAN modules added by extending the CAT5 cable either direction from CANPAN or CANUSB4 and moving the termination resistors.

There is much discussion of the Arduino on the MERG members forum, though much of the technical debates are beyond me!

MERG is not for everyone, but if you're OK with soldering ( or willing to learn! ) it could be a good route.
Hope this helps, and apologies if it sounds like an advert, it's just the most cost-effective solution I found,

Steve
MERG M6460
Locked Re: What gets saved when

 

Thanks Dave. ?Just to summarize:

A) “Store configuration only” (File menu on Tools windows): ?Turnouts, signals, sensors, lights, memories, etc.
B) ”Store configuration and panels” (Same place as in A): ?All that is saved in A, plus Control Panels, Layout Panels, etc.
C) ”Save panels” (File menu on Layout or Contril Panek Editor Windows): Same as B.

Is that right? ?So no way to just Store layout and control panels separate from turnouts, sensors, etc., but a way to do the reverse.

And, if I have this right, a clear warning is not to do A that overwrites a file stored with B or C or you will lose your layout and control panels!

Thanks, Jerry
__________________________________________
jerryg2003@...
Locked Re: Setting serial port speed for CMRI connection to JMRI

 

Thanks for the suggestion Ken. ?That’s actually more or less what I did. ?Based on CMRI monitor times, my boards are responding to a poll from JMRI in the range of 100ms. ?What I’m really asking about is the time till the next poll from JMRI, which is in the range of .8-1.2 seconds. ?Is that right? ? I thought JMRI was supposed to poll pretty fast.

Thanks, Jerry
___________________________________
jerryg2003@...
Locked Re: Setting serial port speed for CMRI connection to JMRI

 

Jerry,

Keep in mind that JMRI will poll a node then give it time to reply. Then it
gets that reply or times out before polling the next node. So how fast each
node responds adds up quick. Use the Command Monitor under CMRI to watch the
traffic and do your timings. I would take a sample to a file for 10-20
seconds. Then using Excel I'd process it and compute the delays and
specifically look for how much any single delay varies. So if a given node
usually replying in 50mSec but every now and then 300mSec, I'd be curious
why.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
Locked Re: Continued ECoS Issues...think I am near a solution. It is the ECoSDetector RC 4 ports

 

Oh hit send too fast….

Does anyone have a document that has the ECoS commands defined? I figure while I am in here I might see if there are other things I should handle.

Nathan

On Jan 10, 2019, at 07:33, Nathan Tableman <nathan@...> wrote:

I have changed the EcosSensorManager to work (I think) with my 4 port detector. I have to say I am really disappointed here, because the reporter has the address not the roster name - but useful that much. But I know see 4 sensors and 4 reporters.

I don’t know if it breaks the other ESU devices - I might buy one to see.

As software engineer for decades I don't overly criticize others code, so this is more about thinking over a way to flip the code around and instead of using the port count to know which one is Railcom; just take that number and loop/query initial state building a hash of some kind which has the type of each sensor.

I am hunting through the other classes of this type to maybe reuse a model that exists.

Because this is not the only issue: none of the s88 sensors are exposed in JMRI it seems.

I am curious how I am the only/first person to notice both of these.

Nathan



On Jan 9, 2019, at 17:00, Nathan Tableman <nathan@...> wrote:

Setting it up now, I have code I am ready to test…might need some help making sure I am complying with the community guidelines for submitting it back, but…here I go…

Be back soon!

On Jan 9, 2019, at 13:59, Bob Jacobsen <rgj1927@...> wrote:

Not an ECoS expert at all, but happy to work with you on tracking this down.

Can you build & run JMRI from a GitHub branch? If so, I can push a version with a bunch more diagnostics in this area for you to try.

Bob

On Jan 9, 2019, at 3:58 AM, Nathan Tableman <nathan@...> wrote:

This one is making me nuts! So I started reading the code and I think I found the issue (maybe)…I have these two devices:

ECoS - ECoS 50200
ECoSDetector RC - 50098 which only has four ports
Custom s88 module based on MQTT - unlimited ports (limited to the hard limit) (this doesn’t work in JMRI either, but I am not certain that is ECOS/JMRI or me…)

iTrain “sees” all my ports coming from the ECoS, so I am pretty confident in the statement that this is a JMRI issue.

So I turned on debug on log4j.category.jmri.jmrix.ecos=DEBUG

This is what happens

There are a lot of which I think is related to me not having my turnouts setup right in JMRI, which is my fault...

2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]

BUT this seems to be the doozie:

2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]

This is the exchange

cmd: queryObjects(26, ports)
rep: <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>

So I have JMRI/java/src/jmri/jmrix/ecos/EcosSensorManager.java open and taking a look a where it might need to be changed locally for me to work…but before I get too far I wanted to see if anyone else has seen this and has input/solutions/I’m crazy :)

Nathan
ps I am long overdue on posting on my blog all the MQTT work, but my goal is a FULLY MQTT setup.

Details below:

2019-01-09 06:40:52,640 util.Log4JUtil INFO - * JMRI log ** [main]
2019-01-09 06:40:53,911 util.Log4JUtil INFO - This log is appended to file: /Users/ntableman/Library/Preferences/JMRI/log/messages.log [main]
2019-01-09 06:40:53,912 util.Log4JUtil INFO - This log is stored in file: /Users/ntableman/Library/Preferences/JMRI/log/session.log [main]
2019-01-09 06:41:00,282 profile.ProfileManagerDialog INFO - Automatically starting with profile Cmd_Tableman_Rail.3e58af63 after timeout. [AWT-EventQueue-0]
2019-01-09 06:41:00,388 node.NodeIdentity INFO - Using jmri-o_sX5dfJrhNiaaDe7duAwF-3e58af63 as the JMRI Node identity [AWT-EventQueue-0]
2019-01-09 06:41:00,697 ecos.EcosPreferences DEBUG - creating a new EcosPreferences object [main]
2019-01-09 06:41:00,742 ecos.EcosTrafficController DEBUG - creating a new EcosTrafficController object [main]
2019-01-09 06:41:00,747 ecos.EcosLocoAddressManager DEBUG - Waiting for the Ecos preferences to be loaded before loading the loco database on the Ecos [Wait for Preferences to be loaded]
2019-01-09 06:41:00,765 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1, status)>
1 status[STOP]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosPowerManager DEBUG - POWER OFF DETECTED [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(11, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(11, addrext)>
20000 addrext[90g,90r]
20001 addrext[91g,91r]
30000
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,799 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,804 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Found sensor object 200 ports 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]
2019-01-09 06:41:00,816 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,818 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20000,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,819 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000,state)>
20000 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,840 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,850 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000, name1, name2, name3)>
20000 name1["east"]
20000 name2[""]
20000 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20001,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,879 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001,state)>
20001 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001, name1, name2, name3)>
20001 name1["west"]
20001 name2[""]
20001 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:01,489 roster.Roster INFO - Roster rebuilt, stored in /Users/ntableman/Documents/Model-Rail/JMRI/roster.xml [AWT-EventQueue-0]
2019-01-09 06:41:01,515 simpleserver.SimpleServer INFO - JMRI SimpleServer started on port 2048 [AWT-EventQueue-0]
2019-01-09 06:41:01,643 server.WebServer INFO - Starting Web Server on port 12080 [WebServer]
2019-01-09 06:41:01,749 ecos.EcosTrafficController DEBUG - Send a message and wait for the response [Wait for Preferences to be loaded]
2019-01-09 06:41:02,064 server.WebServer INFO - Starting ZeroConfService _http._tcp.local for Web Server with properties {path=/, json=4.1} [WebServer]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(10, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(10, addr, name, protocol)>
1000 name["MRCE 194.640"] addr[1060] protocol[DCC128]
1001 name["BR245 / Traxx DE"] addr[1000] protocol[DCC128]
1002 name["GySEV 1047"] addr[1020] protocol[DCC128]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,281 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,285 json.JsonServer INFO - Starting JSON Server on port 2056 [AWT-EventQueue-0]
2019-01-09 06:41:12,026 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1000, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, speed)>
1000 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, dir)>
1000 dir[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1001, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, speed)>
1001 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, dir)>
1001 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[7])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[8])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1002, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, speed)>
1002 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, dir)>
1002 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,037 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path program: is /Applications/JMRI/ [main]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path preference: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path profile: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path settings: is /Users/ntableman/Library/Preferences/JMRI/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path home: is /Users/ntableman/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path scripts: is /Applications/JMRI/jython/ [main]
2019-01-09 06:44:29,939 mqtt.MqttAdapter WARN - Lost MQTT broker connection... [MQTT Rec: JMRI-MQTT]
2019-01-09 06:44:29,940 mqtt.MqttAdapter INFO - ...trying to reconnect [MQTT Rec: JMRI-MQTT]



--
Bob Jacobsen
rgj1927@...
Locked Re: Continued ECoS Issues...think I am near a solution. It is the ECoSDetector RC 4 ports

 

I have changed the EcosSensorManager to work (I think) with my 4 port detector. I have to say I am really disappointed here, because the reporter has the address not the roster name - but useful that much. But I know see 4 sensors and 4 reporters.

I don’t know if it breaks the other ESU devices - I might buy one to see.

As software engineer for decades I don't overly criticize others code, so this is more about thinking over a way to flip the code around and instead of using the port count to know which one is Railcom; just take that number and loop/query initial state building a hash of some kind which has the type of each sensor.

I am hunting through the other classes of this type to maybe reuse a model that exists.

Because this is not the only issue: none of the s88 sensors are exposed in JMRI it seems.

I am curious how I am the only/first person to notice both of these.

Nathan

On Jan 9, 2019, at 17:00, Nathan Tableman <nathan@...> wrote:

Setting it up now, I have code I am ready to test…might need some help making sure I am complying with the community guidelines for submitting it back, but…here I go…

Be back soon!

On Jan 9, 2019, at 13:59, Bob Jacobsen <rgj1927@...> wrote:

Not an ECoS expert at all, but happy to work with you on tracking this down.

Can you build & run JMRI from a GitHub branch? If so, I can push a version with a bunch more diagnostics in this area for you to try.

Bob

On Jan 9, 2019, at 3:58 AM, Nathan Tableman <nathan@...> wrote:

This one is making me nuts! So I started reading the code and I think I found the issue (maybe)…I have these two devices:

ECoS - ECoS 50200
ECoSDetector RC - 50098 which only has four ports
Custom s88 module based on MQTT - unlimited ports (limited to the hard limit) (this doesn’t work in JMRI either, but I am not certain that is ECOS/JMRI or me…)

iTrain “sees” all my ports coming from the ECoS, so I am pretty confident in the statement that this is a JMRI issue.

So I turned on debug on log4j.category.jmri.jmrix.ecos=DEBUG

This is what happens

There are a lot of which I think is related to me not having my turnouts setup right in JMRI, which is my fault...

2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]

BUT this seems to be the doozie:

2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]

This is the exchange

cmd: queryObjects(26, ports)
rep: <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>

So I have JMRI/java/src/jmri/jmrix/ecos/EcosSensorManager.java open and taking a look a where it might need to be changed locally for me to work…but before I get too far I wanted to see if anyone else has seen this and has input/solutions/I’m crazy :)

Nathan
ps I am long overdue on posting on my blog all the MQTT work, but my goal is a FULLY MQTT setup.

Details below:

2019-01-09 06:40:52,640 util.Log4JUtil INFO - * JMRI log ** [main]
2019-01-09 06:40:53,911 util.Log4JUtil INFO - This log is appended to file: /Users/ntableman/Library/Preferences/JMRI/log/messages.log [main]
2019-01-09 06:40:53,912 util.Log4JUtil INFO - This log is stored in file: /Users/ntableman/Library/Preferences/JMRI/log/session.log [main]
2019-01-09 06:41:00,282 profile.ProfileManagerDialog INFO - Automatically starting with profile Cmd_Tableman_Rail.3e58af63 after timeout. [AWT-EventQueue-0]
2019-01-09 06:41:00,388 node.NodeIdentity INFO - Using jmri-o_sX5dfJrhNiaaDe7duAwF-3e58af63 as the JMRI Node identity [AWT-EventQueue-0]
2019-01-09 06:41:00,697 ecos.EcosPreferences DEBUG - creating a new EcosPreferences object [main]
2019-01-09 06:41:00,742 ecos.EcosTrafficController DEBUG - creating a new EcosTrafficController object [main]
2019-01-09 06:41:00,747 ecos.EcosLocoAddressManager DEBUG - Waiting for the Ecos preferences to be loaded before loading the loco database on the Ecos [Wait for Preferences to be loaded]
2019-01-09 06:41:00,765 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1, status)>
1 status[STOP]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosPowerManager DEBUG - POWER OFF DETECTED [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(11, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(11, addrext)>
20000 addrext[90g,90r]
20001 addrext[91g,91r]
30000
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,799 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,804 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Found sensor object 200 ports 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]
2019-01-09 06:41:00,816 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,818 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20000,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,819 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000,state)>
20000 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,840 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,850 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000, name1, name2, name3)>
20000 name1["east"]
20000 name2[""]
20000 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20001,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,879 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001,state)>
20001 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001, name1, name2, name3)>
20001 name1["west"]
20001 name2[""]
20001 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:01,489 roster.Roster INFO - Roster rebuilt, stored in /Users/ntableman/Documents/Model-Rail/JMRI/roster.xml [AWT-EventQueue-0]
2019-01-09 06:41:01,515 simpleserver.SimpleServer INFO - JMRI SimpleServer started on port 2048 [AWT-EventQueue-0]
2019-01-09 06:41:01,643 server.WebServer INFO - Starting Web Server on port 12080 [WebServer]
2019-01-09 06:41:01,749 ecos.EcosTrafficController DEBUG - Send a message and wait for the response [Wait for Preferences to be loaded]
2019-01-09 06:41:02,064 server.WebServer INFO - Starting ZeroConfService _http._tcp.local for Web Server with properties {path=/, json=4.1} [WebServer]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(10, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(10, addr, name, protocol)>
1000 name["MRCE 194.640"] addr[1060] protocol[DCC128]
1001 name["BR245 / Traxx DE"] addr[1000] protocol[DCC128]
1002 name["GySEV 1047"] addr[1020] protocol[DCC128]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,281 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,285 json.JsonServer INFO - Starting JSON Server on port 2056 [AWT-EventQueue-0]
2019-01-09 06:41:12,026 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1000, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, speed)>
1000 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, dir)>
1000 dir[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1001, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, speed)>
1001 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, dir)>
1001 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[7])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[8])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1002, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, speed)>
1002 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, dir)>
1002 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,037 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path program: is /Applications/JMRI/ [main]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path preference: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path profile: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path settings: is /Users/ntableman/Library/Preferences/JMRI/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path home: is /Users/ntableman/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path scripts: is /Applications/JMRI/jython/ [main]
2019-01-09 06:44:29,939 mqtt.MqttAdapter WARN - Lost MQTT broker connection... [MQTT Rec: JMRI-MQTT]
2019-01-09 06:44:29,940 mqtt.MqttAdapter INFO - ...trying to reconnect [MQTT Rec: JMRI-MQTT]



--
Bob Jacobsen
rgj1927@...
Locked Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style

 

Have emailed Merg now was slightly confused by how many actual kits and bits I would need but may well pay the membership and ask about on there site. They do seem ramble off in their own language fairly quickly !
Locked Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style

 

Hi Paul thanks for the info.

I think I could manage to solder however my programming skills are probably fairly basic. It's why I was trying to reach out to someone who had been there done it and got the teeshirt so to speak.? I have found things like git hub and hackaday as well as some good YouTube videos. Also I am mindful that it all has to work together.

Budget is the main factor here to other wise I will just have to save up and buy a system off the peg.
Locked JMRI DecoderPro Programmer Format Question

 

When you open up DecoderPro in either ops or service mode and select a loco to work with there is a section at the bottom of the Decoder Pick Tree that says "Programmer Format".? There are two selections in that pick list that I have always wondered about:? "Advanced" and "Comprehensive".?? What's the difference?? Is one a super set of the other?????

Thank you for taking the time to answer one of those JMRI trivia questions that have I always wanted to know the answer to.??
Locked Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style

 

David,

I think a lot of your choices in this area will depend on how happy and confident you are about mucking about with electronics, soldering kits and hacking Arduino code. ?My understanding is that 'out of the box' the DCC++ base station will forward DCC commands to track connected decoders (mobile and stationary) or use Arduino pins as simple ON/OFF inputs or outputs, so these are your base options.

There's a MERG 8 channel current (transformer rather than diode) block detector at c. ?26 (+ MERG membership) that I've used directly connected to an Arduino and if you use one pin per channel you should be able to configure the relevant pin as an input on your DCC++ base station. ?It also has a shift register output option which is more economic on pin usage, especially if you daisy chain them, but that is unlikely to be supported by the standard DCC++ code.

I haven't used optical sensors for block detection with JMRI, but I understand that JMRI signalling automation works on the basis that block detection is contiguous and all blocks have detection. ?At least one block will always be showing as occupied for a specific train. ?This may be difficult to arrange using optical detectors. ?It may be that Martin's experience is different.

Designing an Arduino shield was well beyond my competence but I found that there are header boards available with PCA 9685 chips already mounted (search your ?favourite market site) which can be used with Arduino. ?I've used one of these in a prototype version that does a 4 aspect signal + feather(optional) ?so plenty more channels to go. ?These can be daisy chained too. ?Alternatively if you are using LED signals you should be able to drive the LEDs from the Arduino output directly using with a suitable series resistor using the standard DCC++ base station software.

Paul

?
Locked Re: What gets saved when

 

Jerry,

On 10 Jan 2019, at 4:53 PM, JerryG via Groups.Io <jerryg2003@...> wrote:

Clearly, my “preferences” get saved when I hit Save on the Preferences window.
Correct.

I also understand that different things get “stored“ when I “Store configuration only“ versus “Store configuration and panels“ from the File menu in the various Tools windows (I assume “Save” and “Store” are both supposed to be words indicating “Save to a more or less permanent file on a disk or in the cloud”). But what are the differences between these two choices?
What is the “configuration” information that gets saved
Turnouts, Signals, Sensors etc.

Into the specified file.

vs. the “panels” that get saved?
Control Panels, Layout etc. as well as Turnouts, Signals, Sensors etc.

Into the specified file.

Similarly, what gets stored (or doesn’t) when I select “Save panels“ from the File menu on a Layout or Control Panel Editor? Is some configuration information completely lost or just any changes since the last time?
Control Panels, Layout etc. as well as Turnouts, Signals, Sensors etc.

Into the specified file.

And while we are at it, when do my roster entries get saved since there does not appear to be a “Save rosters“ choice anywhere.
When a Roster Entry is open, there is a File->Save menu item. There is also a "Save to Roster" button on the Roster Entry pane.

Unlike panels, when you attempt to close a Roster Entry with unsaved changes, it will warn you and give you the option to "Save and Close"

Unrelated, if you have made changes and not written them to the decoder using your DCC system (as opposed to the roster file), you will get a different warning, so you will possibly see both.

If you change editable information in any row on the main DecoderPro roster page, that change will be saved as soon as you press Enter.

If you add or remove a roster entry to/from a Roster Group, that change will immediately be saved into the roster entry itself.
--
Dave in Australia
Locked Re: Broadway ltd

 

On 10 Jan 2019, at 3:46 PM, forfoum@... wrote:

From personal experience with both the DCC Specialties PowerPax and the Soundtraxx PTB-100: get the PTB-100. PowerPax did not provide satisfaction for me on a DCS50 or a DCS100. It worked but was very finicky about the decoder it was facing. The minute I added the PTB-100 it was a dream come true an has worked ever since. The PowerPax is in the drawer and it's power supply is powering the PTB-100, permanent.
Similar experience with NCE Power Pro (except the PTB-100 is now powered from the NCE's 16VAC main power supply).
--
Dave in Australia
Locked Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style

 

Hi David

Have you had a look at MERG kits? (merg.org.uk). There wouldn't be the programming involved (unless you wanted to get into designing things to work with their kits) but the range of kits they do would do everything you could want and their CBUS system works very well with JMRI.

Cheers

Fraser
Locked What gets saved when

 

I thought I understood this but the more I think about it the more I realize that perhaps I don’t, so here goes…

Clearly, my “preferences” get saved when I hit Save on the Preferences window. I also understand that different things get “stored“ when I “Store configuration only“ versus “Store configuration and panels“ from the File menu in the various Tools windows (I assume “Save” and “Store” are both supposed to be words indicating “Save to a more or less permanent file on a disk or in the cloud”). But what are the differences between these two choices? What is the “configuration” information that gets saved vs. the “panels” that get saved?

Similarly, what gets stored (or doesn’t) when I select “Save panels“ from the File menu on a Layout or Control Panel Editor? Is some configuration information completely lost or just any changes since the last time?

And while we are at it, when do my roster entries get saved since there does not appear to be a “Save rosters“ choice anywhere.

Thanks, Jerry
_________________________________
jerryg2003@...
Locked Re: Setting serial port speed for CMRI connection to JMRI

 

Thanks all for the interesting discussion. I have tried several speeds and it looks like I may be losing some messages at 57.6 so I am going to stick with 19.2 for now with my three Arduino boards running via RS 485.
?
A related question: my boards seem to respond to a poll request in about a 10th of a second, but it takes JMRI almost another full second before it issues another poll request. ?Does this sound right? ?This seems to be consistent across communication speeds. ? Running the latest experimental version of JMRI 4.15.1.?

Jerry
___________________________________
jerryg2003@...
85001 - 85020 of 240610