Thanks Mark. Please don't worry about altering the code at this stage. If Mike is close to having an ESP8266 base station, then I should be fine. I did take a bit of a crack at it yesterday, but failed. And it turns out that the previous iteration of the mobile Decoder just commented out/deleted a pile of code!! I turned my attentions to slow servo movement. VarSpeedServo.h hasn't been modified for ESP8266 and for some reason my "millis() + 50" in the for loops isn't having an effect. Delay(50) does work but we don't want that..
I have my setup successfully connecting to wifi and JMRI is successfully connecting to the base station now via wifi. A custom firmware is needed on the ESP though since the AT approach was pitifully slow. I will be pushing the modified base station code after I clean up the code from the debug code.
Finally had a chance to move forward today. WiFi - finally cracked some of the 'handshake' elements, so now have <s>, <1>,<0>,<T>,<S>,<Z> responses. I'm not sure what JMRI is expecting for the <s> response I have just copied the response per below. My PuTTY connection into the Host showed DCCppOverTCP Mark (TD) I note in the comments in https://github.com/JMRI/JMRI/blob/m...ccpp/dccppovertcp/DCCppOverTcpPacketizer.java // TODO: Consider ditching the LocoNet-inherited "RECEIVE" and "SEND" prefixes // and just rely on the already-present "<" and ">" to mark start and end // of frame. This would pretty much make DCCppOverTCP redundant with the // Network Port interface to the Base Station (that is, the "host" JMRI // application would look just like a Network Base Station to the "client" JMRI // application). May I suggest that this server is an attractive concept? If we do indeed strip out the SEND/RECEIVE elements, and the Host is broadcasting all expected DCC++ commands, we have a very neat package in JMRI which provides; Ethernet connection to a specified IP/port (expected 1 client, albeit that client could be a chat server, which could be 'localhost' but needs to be configured by the user), Serial connection (e.g. USB, simples) TCP server - (allows multiple clients, e.g. WiFi decoders in 20 locomotives, WiFi base stations) On the Decoder side, I tried to slow down the servo travel speed using the following methods; Millis()+30; in the for loop. Didn't work, don't know why Delay(30); in the for loop. Worked, but we are NOT using delay! State machine, didn't work, don't know why, writeMicroseconds(). Gave a slower speed just because you are going from say 1250-1500 (i.e. 250 steps) rather than 45-90 (i.e. 45 steps). I decided that was good enough!
Happy days! I got it to work. WiThrottle=>JMRI=>ESP8266 That was until something stalled, and then it didn't all reconnect.. Finer details; HOST = RPi3 JMRI DCC++ Ethernet Connection to 192.168.54.65:2560 CLIENT = ESP8266 Found the expected < s > response details in DCCpp_UNO.ino SerialCommand.cpp line 370 Set power to <p1>, Hard coded the Arduino type, shield and DCC++ version. Set up notification of communication type No throttles, No turnouts, No sensors. ESP8266 needs to be active before JMRI. I haven't found something to get JMRI to re-start the Ethernet (WiFi) connection if lost? Started DCCppOverTCP PuTTY into JMRI DCCppOverTCP - seeing 'RECEIVED' messages only, responses to the < s > status command prompt, being <p1><><>. So it is not showing the content of the DCC++ status details, nor the communication type Power changes < p1 >, < p0 > Response for throttle changes (i.e. < T nReg nSpeed nDir > No sending of throttle or function command packets Quite chuffed that I got it all to work along some lines at least. The Ethernet connection as discussed above is not a good idea IMO as you would have 1 DCC++ connection for every locomotive. But it does work. If Mark (and any other users) are happy for the DCCppOverTCP to be altered, then that will be a very elegant solution. I will need to change my Decoder code to be a client which seeks out and connects to the server. I will need some sort of stop motor if command too, so that the loco stops if it loses connection to the server.
Planning to change my wifi connection code to be more client centric like https://www.arduino.cc/en/Reference/WiFiClientConnected
JMRI Recommends using port 12080 for the Withrottle. Yes you can use other port numbers, but my experience is getting the results you described above.
I may have been unclear. 192.168.54.65:2560 is the IP address of the ESP8266 Decoder. I have been connecting the WiThrottle on port 12080 as per the defaults. The loss of connection was the battery getting low, after I'd played with the setup for a few days. Having said that, I didn't gain control over the Decoder with subsequent experience ta tonight. I did get 'new client connected' in the serial monitor but nothing further. My wifi client experiments didn't work either. More fun tomorrow then!
Simon, Are you in a position to clone/download a branch of JMRI code from my repository and build/test it? I think I have the changes done to remove the SEND/RECEIVE prefixes from the DCCppOverTCP transmissions... need to test them later, but I can push them to github.com/msunderwd/JMRI if you can get them from there and make use...
Also, it just occurred to me that the DCCppOverTCP server can handle multiple client instances, so one of its uses should be helping to connect multiple remote client JMRI instances to a single DCC++ Base Station. Not sure how useful that is... I just forgot the multiple-client aspect... It's inherently set up to receive Commands from multiple Clients and funnel them all to a single Base Station, then broadcast the Base Station's responses to all of the Clients. In this scheme, the Clients are, say, acting as throttles or panels, or other instances of JMRI. Would it be useful to INVERT this relationship so that the host JMRI instance instead takes Commands from a single "source" and broadcasts them to multiple Base Stations, then funneling the responses back to the "source"? Seems it would be problematic to figure out which response should be considered the "real" response... or whether all the responses should be logically ANDed or ORed together, or how to handle conflicting responses...
I have the time (retired), so I'll give it a crack. Might be on the laptop rather than on the RPi3, but that shouldn't make a difference. Yeah, I'd seen the multi-client capability when I used PuTTY and JMRI at the same time, and got a bit excited. Yes, this would be awesome. Other folks may use this for boosters or districts.
I can't get JMRI throttles working today. The ESP8266 serial monitor for the decoder is showing 'new client connected' followed by repeated <s> and occasional <S> commands. JMRI acknowledges there is a connection ('DCC++ Ethernet' pointed at 192.168.54.65:2560), but doesn't seem to want to send anything other than the <s> command, I gather because the status command response isn't as expected. JMRI Traffic monitor shows; So the 'handshake' isn't right. The PuTTy response to <s> is; So I plugged in my Uno, send an <s> to it and got back I added a space before the local IP, and added the Sensor/Turnout/Output response of <X><X> (I do have those outputs set for the <S> and <T> commands). Now I can't get the traffic monitor window to open, so I can't see if this has worked. I'm going to shut everything down and see what I can get. I CAN 'send a DCC++ command', eg <0>,<1>, <t 1 5565 100 0>, <t 1 5565 0 0>. Curiously, I can't directly send function commands (eg <f 5565 152>, and the serial monitor shows that all throttle commands are sent as full speed! eg <t 1 5565 126 1>. So things are alive, just rather sick...
OK, just spotted this in the 'Help' - limitations 'JMRI currently supports the V1.1 Base Station Interface. Some V1.0 commands may not work.' I think I'll change my reported version! And no traffic monitor after reboot because 'jmri.jmrix.dccpp.swing.mon.DCCppMonPane due to:java.lang.NullPointerException [AWT-EventQueue-0] java.lang.NullPointerException'
I changed the connection to be my Black 5 "45341", ip addr 192.168.54.41:2560. This allowed the JMRi traffic monitor to open. Changed the reported version to 1.1. Still no recognition. Comm reporting and nil Sensor/Turnout/Output works. I started the DCC++OverTCP server and got in via PuTTY, more data is coming through I did get the SEND bit to work, once. Now it doesn't! None of the DCC++ throttle/power interfaces work. The 'Generate DCC++ packet' does work as noted above, only full throttle or stop, and power on or off. Mark looked into the JMRI->DCC++ V 1.2 at www.trainboard.com/highball/index.php?threads/dcc-software-jmri.90326/#post-960457 and it should have been picked up on 4.3.3. I'm on VERSION JMRI Server 4.6-R81496dc, but it doesn't seem happy? (maybe I'm at 1.2.1+
Sorry to re-respond. Yes, for me, the host instance of JMRI would be the source. And it would transmit the base station commands to all clients. As you indicate, there will be multiple client responses. At present I have done my Decoder to only respond the Throttle command <T 1 126 1> if it relates to its specific CAB address. The problem with having n clients and expecting n responses is that a PuTTY instance won't respond! Beyond that, I wouldn't want to undo the current functionality - noting that the JMRI simple server doesn't seem to handle locomotive commands
Simon JMRI needs to know it is 'talking' to a connected Base Station instance. So for initial testing you could emulate this by sending.... <p0><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1+ / Feb 14 2017 11:49:47><N1:192.168.54.65> from a PuTTY instance. Once JMRI has received that 'handshake' in theory you should be good to go. Then start connecting your decoders and see if you can get a response from a JMRI throttle.
I'll try that in PuTTY. But that is exactly what I'm sending from the ESP8266. And the stock sketch on the UNO is getting the same failure...
And just so you know for sure how all this is going to work, let's go over the Server Client thing one more time. The Server is an application that will provide some form of communication network to it's clients. Everything connected to a server is a Client. Some clients can have special status. The JMRI Client needs special status. It should be the first Client to connect and should be acknowledged as such with the required hand shake. The decoder Clients should then be allowed to log on to the Server adhoc and get a duplex TCP route to the special Client, JMRI. JMRI does not need to know they are there, it just needs to be satisfied it is 'talking' to at least one instance of a DCC++ Base Station, or in your case another client that is listening and responding in the DCC++ command protocol. When the JMRI client 'talks' all the decoder clients should be able to 'hear'. Only one decoder client should respond to a given command with the DCC++ reply protocol, and the JMRI client needs to 'hear' that reponse. An Emergency stop all, or power off will only require one reply to the JMRI client, this could be built in to the server code.
Thanks Steve. Hence the comments above by Mark re the DCC++OverTCP server. It turns things on its head as I think DCC++ is currently a server. JMRI sends <s> and DCC++ sends the above status command. I'm wondering which port I would point PuTTY at? The config i am testing on is the DCC++ Ethernet connection, so in JMRI I specify 192.168.54.65:2560. Is it 192.168.54.100:2560 to go back the other way and talk to JMRI? I'm pretty sure this would be needed for a standalone chat server if I end up going down that route. Sorry, total ignoramus here!
All connections to the Server would normally be on the same port. If a connection is made to the server from within the same machine you would normally specify the IP as localhost:2560 or 127.0.0.1:2560 if 2560 was the specified port. If external, to the machines IP on the network to the same port. However in your case the special Client (JMRI) could do to have it's own port, as this could define it as the 'Special' client. Do you not think that your current 'sticky tape' approach is ultimately delaying progress here? It must be a few weeks since you started looking at this, by now for me at least, I'd have done the home work and written my own custom server, which I'd proudly be announcing on here. I know as much as you about writing Java servers, but it doesn't seem like any big deal to do, the hard stuff is all done for you in the .net includes. Java can look a bit confusing I know, but its pretty high level stuff and another string to your bow, no? And anyways, I'd never be happy with my project if I didn't have some understanding of how all the code works!
