HTML5 is pretty much a requirement at this point for some pieces of the code but almost all current browsers support it already so it is not a major problem. Simplicity in calling things like $.ajax() and the like. Most of the code leverages underlying ajax calling styles to offload most of the processing from the browser to the base station side where everything is cached in memory and is relatively fast to filter. Yes, but leveraging an existing framework that does most of the grunt work is a lot easier Well, that may be even easier. On a mobile device we can detect the media (screen) size and drop entire elements via CSS. I was doing this on the old html code to drop the loco count from 10 to 5 automatically on the throttle. I'm thinking for smaller screens it may be beneficial to drop the second tab entirely and maybe the functions section in favor of a limited functions display with button for extras.
I've had an issue bugging me for the past month or so, hoping maybe someone can offer some suggestions. I started out with a single loco on my test track and the base station code from January. In the past month I have added two more locos to the track and upgraded the code to the dev release... The problem I'm seeing is that when I change the throttle for a loco, it takes 4-6 seconds before that speed change starts to kick in. This persists even if I remove the inertia settings or remove all but one loco from the track. It used to be that when I would set the throttle the loco would respond immediately. The only other thing I can think of is that I added 16 turnout definitions (although I'm not sure if those persisted after the software upgrade). One loco has a 2-digit address (03), and the other two have been given 4-digit addresses, if that matters, but all three locos see the same delay. Any thoughts on troubleshooting? Has anyone else seen this happen?
I'll need to see if I can reproduce that but it doesn't seem like something I have seen in my testing. This should have no impact as these are not part of the critical path for throttle updates etc. At least it is consistent. That will make narrowing it down a bit easier probably. Are you using the web browser based throttle, JMRI, some sort of telnet/network based throttle? Is there anything between the base station track outputs and the locomotive (like a custom decoder or similar?). How is the signal sent from the base station to the locomotive?
JUST the web-based throttle, although I do have telnet access from another room. One of these days I'll get my wife down here to watch for me and see if there are any delays through telnet. (Oddly enough, on the new software none of the commands are showing up in telnet except for the power commands -- I used to see throttle and turnout commands appearing in telnet.) I don't run JMRI or anything else, I'm just using the base station throttle from my cell phone or telnet commands from my desktop, so everything is straight DCC through the rails.
The web throttle doesn't send the commands via the same mechanism as jmri/telnet so that is why you don't see them now. I'll do some timing tests on it soon and see if I can figure out what might be causing a delay, anything over 1/2sec is too long. Sent from my ONEPLUS A5010 using Tapatalk
OK I did some playing around, and have good news and bad news. The good is that I don't think I've reset my ESP32 since I flashed the dev code on it. After a reset, the throttle is once again responding almost instantly, so it looks like that was actually an easy fix. The bad... it seems that throttle commands via telnet are broken now and seriously mess things up. When I issue a throttle command (example: <t 1 3179 40 1>) the loco kind of starts to move, stops, a few seconds later tries to move again, rinse and repeat. If I then reacquire the loco on the web interface it also won't make the loco move. I had to reset my ESP again to regain throttle control. Now, a quick word about the telnet interface... Honestly I really liked having ALL of the commands echoed on telnet because I could verify commands from my phone interface were being received when I had problems. I'm hoping (but never thought to ask) that S88 sensor readings would also be shown through telnet as there are already strings defined on the DCC++ wiki page for retrieving and setting sensor data. That really helped a lot when I was first setting up DCC, and would also help as I set up and learn about S88... but looking forward I was also expecting to have all that information available via telnet because it's such an easy interface to connect to and when I start writing control scripts I was planning on having access to all of the information through that. I also hope some day to have an ESP32-powered loco decoder which can receive commands both through the rails and over wifi, and again the telnet interface would provide that connection. So please don't toss telnet aside, it really is very useful in a number of ways, and redundancy is a good thing here.
That is very odd as the flash process normally ends with a hard reset. But good to know that a reset brought the speed back to what it should be. If you can reproduce this and capture the console output it would be great, I'm not sure what might cause this sort of oddness.. S88 sensors are reported using the same base sensor trigger/clear responses you would expect over telnet. This was done intentionally for JMRI support. The only difference is how you create the S88 sensor bus, this is implemented as <S88 ....> for the network interface and is not supported by JMRI at this time. Having web throttle commands echoed on the network interface can be done, and probably should be. It is not currently as the web throttle was recently reworked to avoid using websockets for the transport layer and to extend the capability of the throttle interface. I'll need to add this to the TODO list so we can get this brought back in. It isn't going anywhere as it is the primary interface for JMRI support. The only problem is that the text protocol has its limitations and as the feature set expands the text based protocol is not suitable for most of the communication between the base station and some of the advanced interfaces that are being developed (web throttle, nextion interface, loconet, Z21, etc)
Sorry, I meant it hadn't been restarted since the day I flashed it. It WAS restarted at that time, but the thing runs so reliably that I can usually ignore it for months at a time. It shouldn't be difficult to capture the console output this weekend. I reproduced the behavior three times last night (with a full reset between each) so there was no difficulty in getting it to happen each time. Glad to hear about telnet remaining a large part of the interface. I don't use JMRI myself but that is comforting to know that others also rely on telnet.
@Shdwdrgn pull the latest development code and you should see the throttle details being sent over the network interface as they change.
Awesome, will grab that tonight! I assume nothing has changed that would affect the issue I saw with sending throttle commands over telnet? Will try to reproduce again under the latest code.
the only change is to broadcast the throttle status updates at the end of processing of a web request to update the speed etc.
I see you fixed the 128 speed issue as well. Is there a debug I need to enable to see things on the serial console? I get the boot info from the ESP32, but I'm not seeing anything after that. [EDIT] Oops... I didn't set the debug level in the compiler, bet that was the issue. Working on that now...
Well... this is frustrating. Flashed the code with the debugging enabled, now I can see the output on the serial port, but everything is working correctly now! I didn't change anything in the code except turning on debugging to 'info', I just recompiled what was already on the screen. So unless the issue has something to do with enabling debugging, I guess this doesn't really help you any.
That is quite frustrating. If it is related to console output then that is even more difficult to trace as it would imply a timing issue somewhere. I normally run with debug enabled as I'm testing things but I'll test with it turned off (should be default) Sent from my ONEPLUS A5010 using Tapatalk
To add even further to the confusion... I thought I'd test some different compiles to see if I could help narrow it down. I started by changing the debug level back to 'error'. While there was no output to the serial console, telnet throttle commands worked normally. So then I changed debug back to 'none' again... and now THAT is working just fine as well?!? The only thing I can make of this is that enabling debug must have set something that was never cleared when I turned it off again, so I tried closing and restarting the arduino IDE and compiled the code once more with debug turned off... and telnet throttle commands are *still* working. Finally I pulled the plug to completely reset everything, but still no change. Despite debugging being turned off as I originally compiled the code, I now cannot get the telnet commands to fail. The only other possibility I can see would be to pull a whole new copy of the code and recompile it fresh, in case the IDE saved something in the code itself that isn't being cleared. I really hate trying to figure out problems like this...
Nope, that wasn't it either. Downloaded a fresh copy and compiled it with debug turned off, and telnet is still working fine. I dunno, I don't have any other ideas here as to what might have caused that problem.
well that is very curious... not sure what it could have been but glad that it is gone now I can go back to laying sheets of cork for my staging yard and get my first track down on the new layout so I can hook up my DCC++ESP32 base station in its new home!
Aww you're getting started on your layout? Still gonna be awhile for me, maybe I can get started on the framework next year, but for now I have to be content with my test loop. Just received the reed switches today so maybe I'll flash an arduino with Rudy's S88 code and start playing with that.
I'm interested to see how you get on. Let me know how it goes - you're welcome to the code I used to do the testing during Mike's development.
