Well, on my way towards an MQTT connected layout, I came across the idea to implement signals based on this.
My layout uses searchlight signals, so my LEDs need to display at least four states (off, red, yellow and green, as well as the special state flashing). Originally, I planned to use three wire 3 mm dual LEDs. To controll each of these on a three head signal, I would need to run 7 wires through the mast. Possible but complex, so I turned my attention to NeoPixel LEDs, which are controlled by three wires, but can be daisy-chained, whi h mrans it’s always three wires for one or a lot of LEDs. Great.
I decided to use an ESP-12E MCU module, as it offers WiFi and a lot of Memory, as well as decent computing power. It only generates 3.3V and us only 3.3V tolerant, but NeoPixels work with external power and can be fed from my 5V layout utility power bus.
So I „sketched“ a sketch, that incorporates all relevant CROR Rules and their Aspects and Aspect Names, which hopefully allows for sending a rule number (e.g. Rule 405, Clear Signal, green, red, red) via MQTT (hopefully to JMRI and vice versa) and use the subscription of the same topic as the actual change of the signals LED colors. This way any (authorized) MQTT client could send „405“ to /JMRI/track/mast1/ to apply green to head3, red to head2 and red to head1. As JMRI also references lights within a head, I might need to publish/subscribe to JMRI/track/mast1/head1/light1, JMRI/track/mast1/head2/light1, JMRI/track/mast1/head3/light1, instead, which the sketch will take care of. Maybe I need a special topic called JMRI/track/mast1/rule which takes care of the handling.
Visual and Readable Feedback
I plan to incorporate the indication for each rule as a callback to be displayed on the fascia using cheap tiny 0.96in TFT displays. These would then show for rule 405: „Proceed“. And for 408: „Clear to diverging“. That would be neat.
I am aware, that there already is a signal implementation for MQTT in JMRI. So this is also an exercise for me. Maybe I’ll learn programming one of these days.
Notes and Thoughts
By the way, I planed to put the heads in reversed order for better wire management, as the cables for each mast tend to run through the mast, emerging beneath the lowest signal head, which has the first index. The signals however – as I understood the logic are read top down. I need to consider that, when doing the dual and single head signals (which are read assuming the missing heads showing a solid red light). Rule 405 would therefore show green on a single head and green plus red on a dual head. I might be wrong though. However, I thought some more about that and came to another (hardware) solution. The only cable that needs to enter the LEDs in the direction the heads are read is the data-in cable.
Considering, that I planned to make more use of the MCU by daisy-chaining several identical signals on the same controller, I would have had a data-out cable leaving the other end in any case. So all I really need to take care of, is to feed the data from the top. The pixels actually dont care whether the voltage comes from the top, bottom or somewhere in the middle, which is somehow convenient.
I’ll post a video this weekend to illustrate the implementation. The header image shows the three signals I’m currently implementing (single head, double head and triple head searchlight signals). As you might see, all three have a Mirco-USB Plug, This eases development, but might actually be a great idea in general, to plant removable signals on the layout.
So after a few more days of development, I got the signal to behave, like it was supposed to. I implemented 28 rules, of which most are genuine (though not the most current) CROR rules, to display the respective signal aspects. The two extra rules are an „unlit signal“ for special conditions and all heads flashing red – which I named „emergency stop“ for testing. I am in the process of updating the Aspects to current standards.
The MCU actually provides two independent functionalities.
1. A website to publish preformatted MQTT-messages.
2. A routine to read the MQTT-messages of a signal specific topic, to control lighting and color of the LEDs.
The main advantage of this is versatility. MQTT is probably THE Internet of things (IoT) communication standard and very much capable of communicating states as well as reports of a model railroad layout.
So this implementation allows me to send the actual command to change the signal from any (locally authorized) MQTT client, like JMRI itself, a homebrew web frontend, or an App, like IoT MQTT Panel or MQTT Explorer.
As soon as a message is sent to the appropriate topic, with the appropriate content (payload), the MCU reads it from the subscribed topic and changes the signal to the new state.