Hardware development...

[t3kboi]

This approach makes a lot of sense to me.

I think that the 100% most valuable hardware to produce first (if you want buy-in from the modeling community) is the MQTT-LCP-DCC bridge specifically for the most popular DCC command stations - NCE, Digitrax, DCC++ etc. (NCE has the most widespread use in the circles I participate in). This gets all the DCC users on board.

Additionally - you need to produce a fully functional JMRI stack, that can allow mapping for all the MQTT topics to all of the existing JMRI support. This gets all the current DCC + JMRI users on board.

Once MQTT devices can talk to everyone's DCC and JMRI - then building the nodes is the easy part.

[rphughespa]

You make some good points.

I had not given much thought to NCE. I only choose to start with DCC++ because it has a very simple, clean USB command set. Also, I already have arduinos.

My other choice is to build a Loconet bridge. But only to get Railcom information from a Loconet connected Railcom device and maybe throttles. I was not planning full Loconet support

But, yes all the other command stations could be supported, I just don't think I have the bandwidth (or hardware) to do them. I will publish my two bridge (DCC++ ,and Loconet) as examples.

richard

On Fri, May 29, 2020 at 1:42 PM t3kboi notifications@github.com wrote:

This approach makes a lot of sense to me.

I think that the 100% most valuable hardware to produce first (if you want buy-in from the modeling community) is the MQTT-LCP-DCC bridge specifically for the most popular DCC command stations - NCE, Digitrax, DCC++ etc. (NCE has the most widespread use in the circles I participate in). This gets all the DCC users on board.

Additionally - you need to produce a fully functional JMRI stack, that can allow mapping for all the MQTT topics to all of the existing JMRI support. This gets all the current DCC + JMRI users on board.

Once MQTT devices can talk to everyone's DCC and JMRI - then building the nodes is the easy part.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rphughespa/mqtt-lcp/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/APWGFRWMYPTR2V7WADFFM2TRT7XWRANCNFSM4NOHIJAQ .

[TrainzLuvr]

Issue with the universal hardware bridge would be that it's a pretty big bite to chew on because it would need to speak and translate between all major Command Stations, generally speaking in their protocols.

I do not believe we want to send MQTT traffic through DCC bus either, as it's already crowded on many layouts that use it for both locomotive and accessory control. There's only so many bits you can squeeze in between pulses. :)

My suggestion is to build a PoC (Proof of Concept) MQTT node that would connect to the network (Ethernet) and be able to communicate with a MQTT broker. This node would be able to control/query any number of accessories through I2C, SPI, or whichever other format.

The idea here is to let everyone get their feet wet, fast. Many people already have hardware on-hand and if they just need to flash the firmware, or follow some example code and modify it for their need, it would quickly demonstrate the power and abilities of MQTT in their hands.

Also, JMRI integration would be crucial some point, as people will then be able to complete the circle and even without the MQTT bridge, use their existing DCC setup with this hardware.

[rphughespa]

Whoa, "universal hardware bridge" ? Not sure where that came from. If what I said implied anything like that, I apologize.

My MQTT-LCP message design is meant to be a distributed system with several small, dedicated node applications doing one task each. One, or more nodes handling turnout tasks, different nodes handling signals.

The only common communication is MQTT over TCP. The DCC bus will only pass DCC traffic to locoa nd stationary decoders., not MQTT messages.

However, I do plan on moving throttle commands over MQTT. An MQTT version of DCC++ / WiThrottle commands.

The "bridges" I am writing will each be a separate node application. One node will translate WiThrottle to/from MQTT-LCP CAB messages. My DCC bridge will translate MQTT-LCP command to/from DCC++. If different busses need to be bridged to MQTT-LCP, each should be done in a separate program.

As regards PoC. I have already built about a half a dozen node apps. I am in the process of cleaning up the code a bit and they will be posted in the next few days.

richard

On Fri, May 29, 2020 at 2:00 PM TrainzLuvr notifications@github.com wrote:

Issue with the universal hardware bridge would be that it's a pretty big bite to chew on because it would need to speak and translate between all major Command Stations, generally speaking in their protocols.

I do not believe we want to send MQTT traffic through DCC bus either, as it's already crowded on many layouts that use it for both locomotive and accessory control. There's only so many bits you can squeeze in between pulses. :)

My suggestion is to build a PoC (Proof of Concept) MQTT node that would connect to the network (Ethernet) and be able to communicate with a MQTT broker. This node would be able to control/query any number of accessories through I2C, SPI, or whichever other format.

The idea here is to let everyone get their feet wet, fast. Many people already have hardware on-hand and if they just need to flash the firmware, or follow some example code and modify it for their need, it would quickly demonstrate the power and abilities of MQTT in their hands.

Also, JMRI integration would be crucial some point, as people will then be able to complete the circle and even without the MQTT bridge, use their existing DCC setup with this hardware.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rphughespa/mqtt-lcp/issues/1#issuecomment-636107113, or unsubscribe https://github.com/notifications/unsubscribe-auth/APWGFRWBFQG772MSZ5W6Q6DRT7Z3FANCNFSM4NOHIJAQ .

[TrainzLuvr]

Ok, so I went out on a limb to coin that term "Universal Hardware Bridge". Maybe I can TM it.

I did not think that it would be necessary to interface with all commercial command stations individually either, as they all have to speak DCC after all, and so the MQTT Bridge would only have to do that.

My PoC suggestion is more geared towards people being able to pick it up and run with it, and realize possibilities that lay in their hands, without major investment of resources.

[t3kboi]

I didn't mean a universal hardware bridge - I meant one specific to each system. And only for DCC cab and accessory commands.

In other words - the throttle sends commands to the MQTT Broker - and they go to DCC interface to system X

All other advanced messaging is handled by the MQTT system itself directly, or through an intermediary like JMRI.

Right now, if I had an MQTT-NCE interface, then my MQTT throttle can replace all my cabs.

Over time, I can add as many MQTT nodes as I like, doing whatever (lights, turnouts, animation) - and build controls for those functions into my MQTT throttle or base station interface. (Android, iphone, pc, web page hosted on ESP32 - whatever.

JMRI can provide this with an interface to MQTT broker - but then someone is required to have JMRI and MQTT system - no hope for standalone MQTT system

[TrainzLuvr]

We are talking about the same thing, I just went several steps ahead in my mind to integrate all into a single be all, do all, unit.

Having a computerless setup would be beneficial, but one still needs to configure the Broker, and Nodes, etc. So, either some hardware interface as part of the system is made that does that, or one uses the computer, thus making the point moot. Even a mobile phone is considered a computer, or a RasPi. :)

Personally, I'd like to see a direct interface between Railcom+ and MQTT. A Node that connects to the track and at least listens to Railcom packets and passes them to the MQTT network, although bi-directional comm would be a final goal.

[t3kboi]

I am currently building esp32 based dcc decoder/16 servo controllers that have a full web interface for configuration (use anything on your network with a web browser).

Will be trivial to add MQTT to them...

No JMRI or PC needed (except to run the MQTT broker - but I bet I can run one on another ESP32....)

[TrainzLuvr]

You just proved my point that people already have the hardware needed to get the MQTT going.

We only need to provide essential concepts and primers, that could be directly applied to existing hardware.

[rphughespa]

To jump in and comment on the configuration issues. Frankly, configuration is a real pain.

Setting up mosquitto mqtt was a breeze. Download and install. On mine, I added a user and password. That took a bit of research, but not too bad.

But setting up ESP32's and PI's can take a while. I am using Python on both (well, micropython on ESP32).

On the ESP32 side, you have to plug the board into your computer via a usb cord (like you do with an arduino). Then using the app of your choice, you load up the code and configuration by flashing it to memory. That is not too bad. But if you need to change anything, you have to unplug the board from where you have it installed, move it back to your compter and repeat the loading process. No easy over the network updating.

The PI's on the other hand run a full Linux operating system. It takes a lot of steps to set it up. My instructions run several pages. But, the good news is that once you have one PI setup you can just clone the SDcard to set up others. Of course, over the air updates are cake (ssh, telnet, FTP, NFS, etc).

So, IMHO, doing MQTT is a bit computer geeky for now.

richard

On Fri, May 29, 2020 at 4:07 PM TrainzLuvr notifications@github.com wrote:

You just proved my point that people already have the hardware needed to get the MQTT going.

We only need to provide essential concepts and primers, that could be directly applied to existing hardware.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rphughespa/mqtt-lcp/issues/1#issuecomment-636169353, or unsubscribe https://github.com/notifications/unsubscribe-auth/APWGFRWJM5X4GZYDJLNGRFDRUAIZJANCNFSM4NOHIJAQ .

[t3kboi]

Indeed - for developing products. But for a commercial product, like what I am working on - you power it, you connect to it with your phone via bluetooth or wifi, and join it to your wifi network.

You can configure the entire device in a web browser on your phone - or on anything with a browser connected to the same network.

The buyer/end user never has to load software. The only time a software load might be needed is if new firmware is available - My intent there is to let users download the firmware, go to the web interface, and drop the firmware file in the browser. Then restart the device.

It is open source - so advanced users can fork the firmware, and do whatever they want.

Total work in progress - but this is what is running atm...

Controls 16 servo turnouts and 8 routes (macros), with 5V open collector outputs on each channel. 32 inputs to allow for physical switches to operate turnouts and routes, and update DCC status when manually operated. One DCC address for DCC programming, 24 accessory addresses (16 turnouts + 8 routes)

Web interface in progress (can't setup the wifi on this screen, but all DCC functions and servo adjustments are here).

[TrainzLuvr]

I was going to say...ESP32 could be configured via its file system and/or web, as long as the firmware is written to read the configuration file upon boot or restart.