OK, a bit of clarification... in JMRI, the "DCC++ over TCP" option basically assumes you have a SERIAL based DCC++ Base Station (no Ethernet or Wifi shield) and you want to use a host PC as a bridge from that base station to a remote instance of JMRI somewhere on the network. So you set the CLIENT (remote) JMRI instance to use "DCC++ Server" and point it at the HOST (local) JMRI instance that is directly connected to the Base Station. Then on the HOST JMRI, you launch the "Load DCC++ over TCP Server" from the "DCC++" menu. The HOST JMRI then just forwards the DCC++ commands back and forth between the CLIENT and the Base Station. You can also access the Base Station directly from the HOST as well. IF YOU HAVE AN ETHERNET SHIELD you don't need to do this. The Ethernet connectivity built into the Base Station does this for you. You just compile for Ethernet (in Config.h) and hook your Base Station directly to the network. Then on your (presumably remote) JMRI PC, you configure JMRI to use "DCC++ Ethernet" and give it the IP/Port of your Base Station. At that point JMRI+Base Station should work pretty much identically with the network connection as it does with a USB when compiled for Serial. The "DCC++ over TCP" stuff you quoted in your second quote of me is in reference to an early attempt to do the latter (direct network DCC++ control without JMRI in the middle). I honestly don't recall whether my code was used for this or whether somebody else beat me to the punch, but given my frustrations with Ethernet shields, I bet someone else did it (and probably better than I could). What I'm hoping to do now (if I can ever get working hardware) is to integrate the WiThrottle messaging protocol into the Base Station so that you can connect a smart phone with WiThrottle directly to an Ethernet connected Base Station without JMRI or anything else in the middle. I'm pretty sure I've got working code but I can't test the danged stuff!
I'm a bit confused about the server/client stuff being discussed though... If I understand correctly what has been built here is essentially a decoder that IS a Base Station, and responds directly to the same commands you would send to a Base Station. If that's the case, I'm not sure why you would need more than one or two connections from a throttle to a decoder... certainly not twenty. Why would you have twenty throttles connected to one decoder? Or one throttle talking to twenty decoders? (Ok maybe 4 or 5 in a consist, but...) Where does the 20 connections problem come from?
Hi TD, You have it right on what these decoders are and how they respond. But each is a separate instance with it's own wifi IP address on the network. So 20, 30 whatever decoders need access to the output from a throttle (jmri, DCC++ Controller whatever). In plain vanilla DCC the track acts as the communication network, in Simon's project he needs to do the same but with WiFi. As it stands the end connection for jmri in a conventional set up is just a client app that points a single connection at a server (command station). For sure you could point that output at any one of his multitude of decoders, but only one as as the output connection is not a server. So to clarify, it's not 20 throttles to one decoder, but just the opposite. Hence the need for a multi connection server to serve all his clients (decoders) simultaneously. This is a somewhat unusual configuration, and I doubt it's been done already, but I maybe wrong. As I wrote earlier, a server app is easy to write in java, and there are numerous examples all over the net. I wish him every success, and despite my earlier doubts, after doing a little research, it's all now looking very doable Steve.
With that many decoders and the throttle I would suggest adding a central node somewhere that could relay the commands out to the decoders. This could be a PC or even another Arduino. There are a lot of ways to implement such a system, the central node could keep a registry of decoders and IPs for them and relay the messages immediately or it could just store them and let the decoder connect to the node and pull the latest commands.
All, Out of curiosity, I grabbed a copy of Eclipse today. I've never done any java stuff before now, so had a quick 15 minute how to set up a new java project viewing on the Tube. Another 15 minutes sourcing/copy/pasting a few files and bingo! I got a multi Client Chat app running. This will surely present at least a starting point for the multi client server needed for the project. I've no intention of going the whole hog on this, it is however an interesting area to tinker around with. Here's a link to the GUI version I tried out first. See screen shot below http://www.dreamincode.net/forums/topic/259777-a-simple-chat-program-with-clientserver-gui-optional/ There is a problem with it though, in that there is a Client/Server message protocol built in to the code, I can't figure out at the moment. So if you try to hack in to the server with Putty or similar, I couldn't get any messages to transmit/receive. Not to be put off, I pressed on with another version, and while it doesn't have the nice GUI's, you can get straight into the sever with any TCP terminal tool and swap messages. So it's only one step away from logging in a bunch of esp's and doing some chatting......cool Here's the source..... http://makemobiapps.blogspot.co.uk/p/multiple-client-server-chat-programming.html note this line near the bottom of the page..... "To try this application you have to compile the two programs: Example 25 and Example 26 (updated)." This is a screenshot of the first app running with 2 clients. Click to see full size.
And then there was MESH networking on ESP8266! Read the description here.... https://github.com/Coopdis/easyMesh Be sure to check out the youtube link down the page (can't post here as it's private content)
Having spent another half day for no progress. Failed at getting Steve's example to work, despite perfectly clear instructions!. Not feeling up to learning java when I failed at what should have been a doddle. Failed at a weboicket server too!! So I'm going to try the mesh thingie, I think the commas need to be robust, self forming and healing etc, and at the base station level. As Steve suggested, wifi is replacing the track as a comms medium. Mesh also gets around the 4 client limit, and removes a single point of failure. Hopefully I can understand setting up the mesh on ESP, and also source compatible libraries for the RPi3 and an Arduino base station. Wifi uno and 2 more ESP arrived today. I need more power sources!!
Apparently easymesh was unstable, so some people started over and developed painlessmesh so I will have a go at that tomorrow with a bit of luck. I 'think' the mesh has an ssid/password, and a single IP/port, which I can point JMRI, a DCC++ base station and the ESP8266 at and hopefully away we go.
Edit: Ha crossed post, you beat me too it..... Hi Simon Oh no! Well of all the options, mesh might prove to be more difficult. I did some further research, and the library I mentioned earlier, turned out to be somewhat unstable! And to make matters worse the author seems to have abandoned the project. A small group of guys did get together on esp8266.com see..... http://www.esp8266.com/viewtopic.php?f=6&t=11849 However having made some progress, interest seemed to have waned by the end of last year. Still, there are other projects on Github you might like to look at. In a spin off on websockets, this would at first appearance do more than the 4 connection limit. https://github.com/Tibus/ESP8266-Websocket And another take on Mesh starts here..... https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266WiFiMesh which is part of the standard core libraries. If that all comes to nothing, then spend a few weeks learning the java code, no one said this would be easy
At least painlessmesh is still active, there's hope still for that then One issue to note though, the mesh code has to run along side the decoder code!
I figure something in the 'official' library is likely to be supported going forwards, so I'll try https://github.com/esp8266/Arduino/tree/master/libraries/ESP8266WiFiMesh first. Looking through the code, I can see similarities with the wifi communication structure in the base station code which I have copied across. So when you say 'mesh code runs alongside the Decoder code!', I'm interpreting that as substitute the wifi stuff I have now with the mesh stuff. However part of what I have now is the creation of a message string, and the actioning if applicable. The mesh code uses String with a capital S, which I spent some time avoiding like the plague!!! Anyways, off the have some fun..
Ah yes, Strings, I'm currently doing a rework of my throttle code to rid the whole thing of Strings. It tends to have a pro and con effect as you work through. Output becomes much easier with printf(), but building, copying, storing, accessing is a little more involved. It's great to learn some old school 'C' though so I'm sticking with it. Today I'm doing pointers and 2d arrays
Progress! So ESPWiFiMesh being a standard library meant that it was already there in the list. That bit was easy. I commented out most of the WiFi SSID/Server code and substituted the mesh code. I now have 2 ESP8266 talking with each other on a mesh, per the above example, whilst the decoder code sits idle Now to work out how to move forward from that example. The Mesh nodes are advertised as wifi networks (eg Mesh_Node2396170), but I failed to connect to either of the nodes just by clicking on them (wishful thinking!). I think the SSID is derived from the chip ID, not sure how I translate that to the laptop/arduino UNO sketch, or the RPi3. In the library (ESPWiFiMesh.h and ESPWiFiMesh.cpp), the IP addr is coded into the library as 192.168.4.1 port 4011, I'm unsure how that figures just yet. Then I can start to think about how to extract the strings - per above, the library is all String, and I don't know if I can build a C++ string at the same time as the library is building a String. I'll gladly take answers, but I'm expecting this is just me ruminating/learning in public.
Hi Simon. If you follow the basic rules of WiFi networks, you should be able to make some progress. If we want to join a network (Access point, server, router whatever) then we do so by pointing to the SSID and and quoting the password if there is one. Asking for a service connection (TCP, Websocket, HTTP etc.) once you're on the network is done with IP address and port #. That service could be on the main AP itself or any of its connected nodes. I personally would get the first node connected to my router and always use the same device and always switch it on first. This will give some consistency and automation of set up. For instance you would always point your JMRI connection at the same address on the main home network. Once that is running, let the decoder nodes do their mesh thing and connect as they like.
Fried another couple of hours searching on how to do the above connections to mesh networks. Am no closer to the light. Also, DCC++ base station doesn't include a config as far as I can see for an Arduino UNO WiFi. That was part of my next strategy, to try and get the base station to act as a server and broadcast its commands to the mesh.
The Ethernet gear takes up too much memory for the UNO. I had to strip everything but the serial interface itself to get a working test bed for my WiThrottle work last night. It would be interesting to offload all of the networking to the ESP so that the UNO is effectively just a serial version talking to the ESP
this is the approach I am taking with the ESP and setting it up so JMRI can talk to it. I plan on adding support for websockets after having the basic functionality working. I have already setup DCC++ to talk to a standard AT based ESP without too many issues but performance seems a bit too slow and JMRI fails to talk to it reliably. I am testing a new approach with the ESP handling all of the receiving work and passing through completed command strings to the base station and routing responses back out. I should have something working early next week hopefully.
In essence, this is what my ESP 'server' already does, and some other neat stuff as well. We can arrange the onboard memory space of the 4MB 12 series in such a way as to use 1MB for program space leaving 3MB for 'other stuff'. So using a webpage that you just call from the 'server' you can just dump files (over WiFi) in that space. There are 3 sets of code for my 'system' one is the sever itself, another is the ESP throttle code and finally the firmware for the touchscreen LCD (Nextion). After updating any of these files, I can dump them in the 'server' 3MB of 'spare room'. The throttle can then just update itself or the Nextion over the WiFi from that file store. And the Base Station server can also do the same if a new file is available at runtime. If you have any room left after that, then Webthrottle interface pages (Html) can be stored and called from there as well The point of all this, is that once your devices are in enclosures and such like, you can use WiFi for all future updates and never have to connect to a physical serial connection again. I think I've already mentioned that this should be possible with the next gen ESP32. Don't know were you're heading with this, it's a throttles job to send commands.
