If the ESP-1 message is being sent to the web server, and not the WiThrottle server, then your problems would be explained purely by that misconfiguration on your end.
Do note that for DCC throttle commands, there is no real two-way communication* between the throttle and the controlled locomotive; that¡¯s not built into the NMRA DCC protocol, meaning JMRI can¡¯t ensure there is two-way communication either.
The web server *is not* used by Engine Driver to control locomotives, but is used to get roster entry pictures if present. JMRI apps (DecoderPro, PanelPro) contains both a web server and WiThrottle server.
* RailCom and Digitrax Transponding provide some exceptions to this
On Mar 6, 2018, at 04:33, despxkdcc@... [jmriusers] <jmriusers@...> wrote:
Hi SteveT,
I assume you mean the WiThrottle server, as the JMRI Web Server isn't >>>involved in this communication.
No Engine Driver communicates with a web server consisting of an ESP-1 and a pic18F26J50.
You retrieved this list of messages from the JMRI System Console (or the >>>session.log file). Is that correct?
I>>>t would be helpful to see the entirety of the messages, including the >>>timestamps and such. Are there any intervening messages?
No, I rely on the log I read in Engine Driver and debug on usb2com + Realterm port.
----------------------------------------------------------
?????????? Where Egnine Driver save the log file in Android ??????????
----------------------------------------------------------
The "*10" is the heartbeat from the WiThrottle server to the client. Is that >>>always involved when you encounter this issue?
A 3-second timed routine sends this message from the web server to the Engine Driver.
What command station are you using?
DIY command station.
I don't recall if any of the command station adapters wait for an >>>acknowledgement of a function change such as this.
This is the problem, if for example I send the command F1 ON, Engine Driver sends the command to the web server and waits for the answer from this but if the web server does not give the answer, Engine Driver discards the error without correcting it by resending last command.
This behavior seems to me absurd and a source of problems in the control of a locomotive.
From what I understand, between the web server and the Engine driver there is no real two-way dialogue with error correction.
am i right or wrong?
If I'm wrong, explain to me how can I enable error correction?
Losing a packet on the track bus is a normal occurrence, but this example >>>seems to indicate the WiThrottle server failed to respond to a function >>>change, which I've never seen with my Loconet setup.
If you have never seen it does not mean that it can not happen ;-) That's why I do not understand why there is no error correction nor even a command that can allow the web server to request the last command sent by Engine Driver or alert it that it is busy.
I have read and reread
<>
but I did not find any information about it and at <> I did not find a shred of documentation about the app.
I hope someone can help me
Best Regards,
Despx
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]