A short introduction about myself - I have no train. - was introduced to DCC++ by UK Steve in the Nextion Forums - Steve discovered the Nextion b[.id] component array (v0.38) - I am merely putting it to good use The other day Steve suggested "give your hard work away for free ..." So here I am with some of that hard work Nextion DCC++ Throttle v1.1 Dcc++v1_1 by patrick_martin posted Dec 17, 2017 at 3:10 PM - uses the Nextion Enhanced 3.2 NX4024K032_011R - uses Nextion Editor v0.53 - Assumed wifi bridge or really easy wifi MCU side coding - up to 10 trains with 29 functions exposed - transmits DCC++ in text directly - Power outputs <0> or <1> - Train select (selectable in blue, active in green) - Switching trains retains train settings between being active - Speed selected by slider (outputs on change) - All Stop between fwd/rev direction (output on change) - Direction switching will issue All Stop (output on change) - User settable delay (1 delay for each speed decrease All Stop) - Functions in color coded groupings -- Green Functions F0..F4 -- Red Functions F5..F8 -- Orange Functions F9..F12 -- Cyan Functions F13..F20 -- Olive Functions F21..F28 - Individual Functions select and retained for use again - Bottom Line Function Group sends selected - Long hold (2.5 sec) Function Group to clear - Gray Function Button as a clear all Functions - Display of Wifi IP Address - Display of Date Time (uses Enhanced RTC) - Display of Incoming Messages. - Power button off, clears trains: All Stop, functions, and track Nextion Termination is three bytes = 0xFF 0xFF 0xFF. to display wifi-IP send - host.txt="192.168.2.18" with termination to set date send YYYYMMDD formatted - date.val=20171217 with termination to set time send HHMMSS formatted - time.val=154513 with termination to set revdelay ms interval (default 40ms) in ms - revdelay=50 with termination to set train numbers send a 50 character text string (5 each) - trains.txt="0059200099...00000" with termination above trains.txt setting at power button on will set - sends <1><t 1 592 0 1><t 2 99 0 1> - therefore two trains selectable and each 00000 as not. to send message to user display (max 28 chars) holds 4 sec. - msg.txt="Hello DCC++ People" with terminator Power button must be on to select a train Train must be selected to use speed/direction/functions. So here it is, the DCC++.HMI file (hopefully zip files upload) - enjoy. PS: if there is anything missed or incorrect, I am sure you'll post
Very cool! Some questions... 1) Can this be used on the non-Enhanced displays? 2) Also is it possible to have it not send <t X ### 0 1> for power-on/off? 3) Does this handle any feedback from the base station? 4) Any details on connecting this to the base station? So far it looks like some sort of MCU or bridge chip, something like an ESP-01 perhaps?
Update 1.11 includes: - Fix to Track Power Off - train All Stop and cab functions off. - Updated Date Time to support both Nextion 3.2" Basic and Enhanced models - Fully documented the HMI Nextion event code Basic_DCC++.zip contains the HMI for the Nextion 3.2" Basic NX4024T032_011R - Date and Time is updated via MCU command Enhanced_DCC++.zip contains the HMI for Nextion 3.2" Enhanced NX4024K032_011R - Date and Time is handled by Nextion RTC and updated by MCU command Updated the pdf documentation to include model.val - this variable selects between Basic or Enhanced model date/time handling.
Atani - I will try to answer some questions (where I can) 1) Can this be used on the non-Enhanced displays? The Basic 3.2" display can be used with version 1.11 (just uploaded) 2) Also is it possible to have it not send <t X ### 0 1> for power-on/off? These values are usable settable in trains.txt In version 1.11: - Power-on output is on line 33: click t50,0 - Power-off output is on line 145: click m2,0 Although these two lines could be commented out the HMI is also resetting all the values elsewhere Good news is almost every line is now documented and you have the HMI file. But was there a reason I wasn't thinking of? Can you explain? - if track power was turned off should cab functions, and speed not also be turned off (Perhaps a thought for 1.12 if I can be enlightened?) 3) Does this handle any feedback from the base station? I have not dug into the base station yet at all 4) Any details on connecting this to the base station? So far it looks like some sort of MCU or bridge chip, something like an ESP-01 perhaps? I am trainless. But I was aiming for input handled by Nextion Logic internally. So a serial wifi bridge like an ESP, or much less MCU side coding was the goal.
That helps a ton! The thinking is that the throttle shouldn't manage track power but more of be a consumer of it. The current behavior is more inline with an "emergency stop" procedure which should send the STOP command to the base station for all locos that the throttle is managing. Perhaps have two buttons, "emergency stop" which does what OFF does today and update the OFF button to only send <0> by default with an option to stop all locos/functions. base station should not require modifications for this, but the question I guess should be can the HMI process incoming DCC++ packets? Fewer components = better I would think the minimal setup could be an ESP-01, battery and Nextion display. The ESP-01 would connect to WiFi and find the base station via mDNS and then feed the Nextion the minimal details that are required for operation. It might make sense to have a WiFi info page on the Nextion that the ESP-01 (or other MCU) could trigger for the user to enter the required details and then have the Nextion feed the user input back to the ESP-01 for connecting to WiFi.
Discussion: Track Power button I thought an Emergency stop is the "All Stop" <t 1 592 -1 1> accomplished by pressing the "stop" between the rev and fwd. But if we wanted to have the power button perform the "All Stop" for all active trains and maybe create a long press for the Power button to issue <0> ? Power on to still issue the track power <1> ? Handling Base Station Messages My thoughts would be using a ESP you have an ability to intercept base station then after turning the base station message into a string, issue: msg.txt="base message"ÿÿÿ msg.txt is currently processed on the v1.11 by the timer to hold display for 4s :: I need a list of what messages you need processed and how. :: Nextion v0.53 has this new feature called protocol reparse. :: - with a little work just about everything is nearly possible in incoming. Can you get a list of all the incoming packets and how you want processed? Wifi Information Page - currently, the HMI host.txt is to hold the IP Address by the MCU/ESP issuing: host.txt="192.168.2.18"ÿÿÿ - host.txt is updated to the display on the Wifi button toggled to on. - but make a list - I could design the Wifi button with a long press to enter a Wifi page.
I didn't even notice that was there! That is perfect for an emergency stop. I guess then the question is for the power on/off button is what is the correct behavior.. Should it issue <1>/<0> only or should it do more, I think this is going to be where people will have different opinions. Perhaps the current behavior is correct, sending <0><t X ### 0 1>.. But I have a feeling it may be better to have the power icon be a long press to change state to prevent inadvertent changes. This makes sense for some aspects but others maybe not. The idea here would be that the base station is already sending responses to certain commands (<t X ### SPD DIR> => <T X SPD DIR>, <0> => <p0>, <1> => <p1>, etc). Basically the throttle needs to respond to changes at the base station, such as overcurrent detected or power state changing. It would also be good to have the throttle ACK be displayed somehow but that may not be necessary entirely. There are certainly some packets that can be fully ignored: <iXXXXX> (check the output from <s>, it is used by JMRI for heartbeat), <q>, <Q>, <H>, <Y>, <S>, <e>. Many (or all?) of these can be intercepted by the MCU but the MCU would need a way to feed certain status packets to the display. The most critical of these being the power state I think. If there are two of these Nextion throttles in use you don't need both to send <1> just to be usable, same as if the throttle gets restarted it should pick up the current state from the base station rather than assume power is OFF.
Maybe we can have track power <0> and <1> as normal and have a long press to register All / long press EmStop All. (special feature if long pressed for those that may like) - could be long press and longer press as well
I think this sounds good, as long as the MCU/Nextion setting the current power state does not trigger a packet to be sent to the base station. In other words, the only way a packet should get sent is by a user triggering state change.
Well, reading the board, would you be the wifi base station guru? - So, ideally I build you the throttle that has everything it possibly can. - Would there be a logical reason why to leave anything out? (or toggle options) Multiple Wifi Nextion throttles Well, what we need during the connect is a query for this - ESP "could" hold that query to say track power is on, etc. - but decide whether or not to pass the track power on to base OR, better I can separate these out into better ways to call piece by piece Nextion Address Mode (new in Nextion v0.53) - interestingly can optionally add 2 bytes address to say which Nextion is to be addressed. - by address, or broadcast if the destination address is 65535. So you can start to see, huge jump in a Nextion Throttle future capabilities
I see version a v1.12 needed quickly regardless. Seems I have messed up something in cab function groups So action plan - divide power on and register into two - divide the power off and all stop to all into two - fix cab functions error I created
Yup, I am the one behind the DCCppESP32 and DCC++ ESP base station code. I have shifted most of my development effort over to the DCCppESP32 base station code now and the old Arduino+ESP base station code is in maintenance only mode (only critical bug fixes will be done now). Having everything is good. Some outputs from the base station are not very useful on the throttle though so they can be discarded. This is more critical if you have JMRI talking to the base station as it will send <s> to the base station around once per minute I believe. The response to <s> can be pretty verbose and aside from the power status not very useful on the throttle. The power status is sent from the base station whenever there is a change (command received from client or over current activity). So, it may make sense to filter some responses. If you plan to have the throttle interact with sensors / outputs then it may make sense to receive those and update local state details. Something like the slot system used by LocoNet or similar? DCC++ doesn't currently have the notion of "reserve register X for this throttle". I am not sure if that is necessary entirely. With DCCppESP32 the register system has been reduced to being maintained for DCC++ protocol usage and matching the locomotive commands to a locomotive instance in the base station. It is no longer used by the base station for generating the signal. As for the ESP maintaining power state, that might make more sense since the Nextion code could be simplified and have the raw protocol parsing offloaded to the ESP which has plenty of CPU cycles to parse / translate the base station responses. One issue would be with the sensors, outputs and turnouts. These are dynamic in nature and I am not sure how you would display these on the Nextion. Perhaps the ESP could send pages of data to the Nextion on demand? I am not sure how this would be used. It sounds like a case where you have one MCU and two (or more) displays on the same serial connection. It might be useful though, just not sure.
The base station only responds with register content today, as an example: Code: ==> <s> <== <p1 MAIN><p1 PROG><T 1 45 1><T 2 0 1> <T 3 0 1> <T 4 0 1>...<Q 123 51 0><Q 124 52 0>... <Y 456 40 0 0><N1: 192.168.0.100> So you send <s> and it responds with all of that. There is no way to query just the registers today. It should be possible to store/retrieve the locomotive state from the base station, but that would require the base station to be modified. Also note that the <p1 MAIN> notation is only valid for the DCCppESP32 and DCC++ ESP.
Updated v1.12 - New page with Wifi Information, Output Options, Cab Entry - Track Power (long press) separated from Throttle on/off - Option added to suppress all train Auto-Stop on Throttle off - Option added to suppress all train Registration on Throttle on - Added on screen Cab Number Entry - Fixed: cab function group clear (was in error in 1.11, ok in 1.10)
So still taking requests for throttle upgrades Next will be to work on an ESP8266-12F for handling Throttle/Base communications over wifi. Questions: 1) what is max_length of <s> (does it exceed 1000 bytes?) 2) If I understand base station transmits info periodically. is it the <s> response. 3) Would it be practical to eavesdrop all packets to pick up Throttle relevant data.
The response to <s> can be more than 1000 characters in total, it really depends on the setup of sensors, outputs, turnouts, locomotives (registers). With that said though, no single packet will exceed about 50 characters (<iDCC++ BASE STATION FOR ESP32: V-1.0.4 / date time> is the longest single packet). Each individual packet can (and should) be handled individually. Having the esp catch and parse these is a good approach, you can look at my esp8266 code for one approach to this. Also the base station will not send any packets out unless there is a change in state (power or sensor) or it received a command from a client (jmri, throttle, etc). So there are no periodic outputs by default. Having the esp/throttle intercept all packets is a good approach. It will let you handle a lot of different options in the long run. One note is that the base station does not broadcast the commands that are sent to it. Just responses. Sent from my ONEPLUS A5010 using Tapatalk
