You can't, unfortunally, and here are some reasons why: 1: This is still a work in progress. My brother is building a new layout in scale 0, and that is not ready yet. But it's partly driveable. I'm building the control system. It's not ready yet, but useable. 2: The communication protocol that i'm using is MQTT. If you don't know what that is, you wont understand the code. 3: I don't use any librarys when communicating with Nextion display. It's all read and write serial commands. There is no code on the display, only labels, buttons and images. Everything is controlled by ESP32. 4: This is not "plug & play" for beginners. If you are familiar with coding on ESP32 you can build it yourself, with your choice of communication protocol. So if you don't have exactly the same setup like I have, nothing will work for you. But if you need help with bits and pieces I'm glad to help. For ex, how to communicate with Nextion display without librarys. Or how to test MQTT in your application.
If you are interested in an ESP32 Command Station, take a look (if you haven't already) at Philipp Gahtow's Z21 implementation (https://pgahtow.de). The ESP32 code isn't quite ready yet, but certainly works adequately. The z21 mobile App (Android or IOS) provides the user interface. I can't promise much in terms of future/further Nextion development - I'm finally busy working on my main HO layout which has been lying fallow for the last 10 years...
Thanks for that link to Philipps's site, very interesting. I have a question on your handheld throttle: how do i program a stationary decoder start address? I.e. when using one of Geoff Bunza's decoders I can get it to work with JMRI, for example starting address 40 for 16 digital I/O outputs: how to set up your Nextion display to access this address 40?
I'm away from my dev machine right now Erik, and my old memory isn't as fresh as it used to be:-(. I'll look into it tomorrow. From memory, you'd need to create a turnout with an absolute address. In other words the first turnout in "group" 40 would have address 641. Sometimes this number is offset by 16 depending on whether the first group is 0 or 1. Hope that makes a little sense:-(
Yes this does make sense to me. But how on your display can I access stationary decoder addressing (loco addressing is obvious enough there)? Please take your time, nothing urgent (this is our hobby after all ).
I will look into it tomorrow. At the time the only accessory catered for was a turnout. I'm sure it would be possible to expand this support, without too much re-working of what's already there...possibly just an extra page or two... What exactly do you wish to access? If we were to change the address structure to be something like 40:1 would that suit your needs?
Hi NormHal, if I could address 1. digital outputs, alternating on/off, and 2. switch servo's, left or right that would be great. Geoff Bunza's stationary decoders (ie. SMA20) are working fine in JMRI (decoder address is programmable, default starting at 24, in JMRI: 40, for the first), if they could be addressed through your Nextion display, that would be the max.
Great, thank you so much! For info: I am using DCCpp_Nextion_3.5_Throttle_2D_V4.01.hmi and DCCpp_Nextion_Throttle_V0.50.ino
I was about to ask you. I've just located my archives and see that I had a slightly later version called "DCCpp_Nextion_3.5_Throttle_2D_V4.01c.hmi". I don't (yet) know the difference:-(. For what it's worth, I had done a fair amount of work with "Atani" in the early days where the Nextion was (planned to be) being used as an optional device for his "ESP32 Command Station". The code was significantly different to the Dave Bodnar based version and had some really cool features. I'm happy to share the latest version if you're interested, however you will only be able to drive it via the Nextion simulator. We got as far as having dynamic addition and configuration of loco and turnouts, as well as having feedback from the Command Station reflecting the current state of both categories. Unfortunately it was decided to "abandon" the Nextion in favor of a Web Based interface, so I was kind of out the loop of development. My discovery of the z21 project has again re-kindled my interest and I'm going to be investigating implementing what I had done with Atani in the z21. Quite an ambitious dream - particularly if you knew my limited C++ skills. But I'm going to give it a bash - time is however not on my side:-( Did you ever try the "3D" version of the Nextion HMI, and if so, what were your thoughts?
Hi NormHal, I have the 2D version (DCCpp_Nextion_3.5_Throttle_2D_V4.01.hmi) , not the 3D: can you send it please? I will try that asap. Same for DCCpp_Nextion_3.5_Throttle_2D_V4.01c.hmi ? Web based interface: ie on a wifi tablet? Can you send a link please? Sounds interesting too. Kind regards, Erik
Hi Erik, I'll upload shortly - done The 3D version was my initial attempt using 3D "depressible" buttons - nothing more fancy I'm afraid. The WiFi/Web based throttle is perhaps the most elegant solution I've seen so far. I haven't been keeping up with Mike Dunston (I should really touch sides again - we shared many fun filled hours) to see how much further he has progressed. If you have an Arduino Mega, an EtherNet shield, and a WiFi router, or an Arduino Mega with WiFi, you can download the z21 code and the z21 app for Android or IOS and see just how nice and effective it can be. The mobile app is proprietary and not open source so it requires the "correct" host. But the implementation is very good. For Android, go to Play Store and search for z21. It's free and gives you a good idea of how it would work.
I've had a brief look at the SMA20, in particular the Servo Control. Do I understand that controlling a servo is limited to making it rotate Clockwise or anti-clockwise - ie like a turnout? I wondered if it had the option to increment in either direction one step at a time? Regards, Norm
With regards to your initial question, I think we can achieve what you're looking for quite easily. My current thinking is to add one or two new page "Types" - one for Servos, and one for single button accessories. Servos might only need a different image for the Nextion, that is IFF the SMA20 is only controlled by the two addresses as I mentioned above. Single buttons might need extra properties like toggle, pulse, and/or repeat pulse. Maybe there are more... The address method can be changed possibly by simply allowing either board:index and a qualifier to specify how many addresses are supported by each board. This could however become quite complicated if different board types are intermixed? I see the SMA20 can control 17 outputs - I'm not sure how he converts his board:index address to a sequential number, as used by the DCC system? I would imagine that the standard should/would be 16 index numbers per board... I'll do some work this evening and report back Cheers, Norm
Started doing some memory refresh... I notice that the DCC++ protocol for turnouts is already in the form of "module:index" or more specifically "TOAddress:TOSubAddress" which comprises 4 TOSubAddresses (or indices) for each TOAddress (or board). It'll be a rather trivial piece of code to do a similar calculation for 16 indices per board. However, the benefit of using sequential addresses is that it makes life a lot easier when mixing and matching different board types. If we were to change the address representation on the Nextion to be board:index, that would thus have to apply to ALL accessories being used. This could no doubt cause a fair amount of confusion. As it currently stands, all one is required to do is apply a simple formula to convert Board:index to a sequential address, and vice versa. In your example, assuming the board in question uses 0 as a starting value, and index values range between 0 and 15, board 40 with an index of 6 would be 40*16=640 + (6+1) = 647. If the board's numbering starts at 1 and indices range from 1 to 16, the calculation would be (40-1)*16 = 624, + 6 = 630. In my humble opinion,the system as it stands is the most flexible because it caters for any combination. Even servos using straight forward closed/thrown states are catered for with the turnout image. Perhaps we can add some new images to apply to servos? What is indeed missing is an accessory page for single button/output control. This is going to require an extra page type and associated images. I will do some more thinking, but I'm concerned we might be spending time and effort enhancing quite a basic and primitive implementation. I think I'd rather spend time trying to implement a more "intelligent" approach where Nextion and Command Station share bi-directional communication. This would involve an almost "Ground Up" rethink of the concept:-( I'd appreciate your thoughts Best, Norm
What a interesting "train" of thought (non-intended pun). If I may NormHal, maybe suggest before throwing the bathwater away, to go the way of the least effort and enhance what we have, without excessive effort? Changing the concept of an, albeit basic idea, to an enhanced version of 2-way communication between Nextion and the base station, will put realisation back a considerable time. For sure I will help wherever I can, from Photoshop image building to Nextion testing/prototyping/programming/.. Please let me know if I can do whatever it takes for you.
Hi Norm, I just discovered there are more means than the DCC++ protocol to address switches. I had initially thought that switches are best addressed through some decoder such as Geoff Bunza's, hence over DCC++. But after studiyng your code in DCCpp_Nextion_3.5_Throttle_2D_V4.01.ino I see that turnouts are addressed by simple decimal numbers. I guess these addressnumbers are forwarded to JMRI? Could it be that this is meant for C/MRI protocol usage? If that is the case then I think it would be a matter of using C/MRI IO hardware such as this from nopxor (in french) and this, from the same author (in english) ? Is this a correct way of thinking?
Hi Erik, I haven't played much with JMRI nor any of the other pieces of software - the work I did at the time was to firstly ride on what Dave Bodnar had done: simply to not fix something which was not broken. He had converted the simple decimal turnout number to what the DCC++ Command Station accepted at the time. IMHO the foundation of addresses is always the decimal numbering system - as an example, locos only have a single address (exception with consists of course) and within that address there are "modifiers" or functions pertinent to that address. In the case of turnouts (again an exception is double slip turnouts) there is always an address, and then a modifier (closed or thrown). Subsequent to this came various manufacturers who "packaged" more than one turnout support in a single device, or board. IIRC the first was Marklin with their K83 and K84 turnout controllers. As a convenience, they assigned (in their case) 4 sequential addresses to one device. This made "address boundaries" increment in numbers divisible by 4. In all cases, even though there was a board:index assigned to a turnout, it was still converted to a single decimal address number, I guess to keep it unique. But I ramble... I spent some time again today looking at your request and will en devour to complete a version 5.x which will retain the support for 50 turnouts, 21 routes, and add a page for I'm guessing either 21 or 18 "Buttons". I've yet to decide whether it's necessary to differentiate between single pulse and latching buttons. I'm currently of the mind to simply allowing latching buttons to latch until pressed again, and single pulse to simply reflect the on and off state as it's pressed. Do you think that would be acceptable? I'm trying to come up with a name to call the extra page. My thinking at this time is to move the "Routes" button to the center between the Loco and Acc1 buttons on the Throttle page, rename the Acc1 button to Acc, and call the three Accessory Pages Acc1, Acc2 and Acc3. Each page can then have a link to the other two Acc pages, and also have a "Done" button. Again, all thoughts and ideas are always welcome Cheers, Norm
