Model Train-related Notes Blog -- these are personal notes and musings on the subject of model train control, automation, electronics, or whatever I find interesting. I also have more posts in a blog dedicated to the maintenance of the Randall Museum Model Railroad.
2018-08-27 - Meanwhile in Conductor 1…
Category Rtac
Conductor 2 is nowhere ready and I need changes now so they go in Conductor 1.
The desired next step is to support the presence-based activation rather than button activation.
Although I have plans for a Conductor 2 which would be route-based, at that point this is an orthogonal task and it can be deferred for later.
Profiles is a Conductor 2 feature, and not tied to a presence sensor.
What is the minimum “clean” approach needed for the sensor presence?
What is the minimum I need to provide?
Arduino / ESP. I have 2 options:
- ESP32 w/ OLED per original plan.
- Display is wasted.
- Can be anywhere convenient, as it would use the wifi.
- It would send an HTTP GET either to JMRI or to Conductor.
- Non-wifi Arduino such as Nano or Digikey.
- Connected to the tablet via USB cable.
- RTAC would poll status except when wifi/conductor is down (sleep mode).
- RTAC would send an HTTP GET either to JMRI or to Conductor, or use the KV server.
RTAC:
- We need a “next train” display. In fact it’s more about automation status.
- “Automation Not Working”
- “Automation Idle” (when no presence)
- “Next Train in X minutes“
- Suggested implementation is to not have any text hardcoded in RTAC. Instead RTAC would have a tab displaying text and Conductor would send the text. This makes it easier to update.
- Default to “Automation Not Working” when there is no connection.
Conductor:
- Need an automation mode
- Off: when the activation switch is down. It ignores presence.
- Idle: activation is on, waiting for presence.
- On: presence is detected, a train started running.
- Automation mode toggles between on and idle.
- Sensor brings the automation from idle to on. It does nothing if off.
- Each time, it resets a timer that would reset it from on to idle. Does nothing if off.
- There would be one mode per route.
- Script:
- Sensor PA-Toggle is the physical switch. Keep as-is.
- Enum PA-Mode : Off, Idle, On.
Enum PA-Motion = Off Idle On Export Int Motion = 0 PA-Toggle & PA-Motion == On & PA-State == Station → Train Starts !PA-Toggle → PA-Motion = Off PA-Toggle & PA-Motion == On & Sensor-Motion == 0 → PA-Motion = Idle PA-Toggle & PA-Motion == Idle & Sensor-Motion == 1 → PA-Motion = On ; PA-PresenceTimer Start PA-Toggle & PA-Motion == On & PA-PresenceTimer → PA-Motion = Idle |
- Where does the Presence var come from in the script? It could be an int-var or a fake JMRI sensor.
- Int-var set from the KV server.
- Virtual JMRI sensor set via its JSON API.
- How to send text to RTAC?
- By using an export string var.
- By using some kind of enum?
- Language has no provision to compute a dynamic “train in X minutes” string.
- Language has no function to set a string as a conditional action.
Export String rtac-text = “Automation not Working” PA-Motion == Off → rtac-text = “Train Automation Not Working” PA-Motion == Idle → rtac-text = “Train Automation Idle” PA-Motion == On → rtac-text = “Train is Running” PA-State == Station → rtac-text = “Train Stopped.\nNext train starts in {now+10m} minutes” |
One possibility is to let RTAC interpret the string format and replace it with the minute countdown.
There is no need for the script itself to take care of that.
I also think the string should have some basic formatting codes which RTAC can interpret:
- “\n” or | for a line break.
- {c:rgb} for a text color. Either RGB or names if they can be resolved.
- {b:rgb} for a background color. E.g. black/red for stopped and white/black for running.
That leaves the issue of stopping automation at 5 PM. There are multiple ways to do that. One would be to hardcode something in Conductor that sets the JMRI sensor to inactive at the expected time.
- Conductor would set ALL the route toggles to OFF at the given time. There is no need to configure the sensor names, as they are already configured in the routes.
- The way JMRI works, it will use the sensor override value till the actual physical toggle is changed. This can be used to our benefit: automation turns off at 5. If operators want it on, they can just flip the toggles off and then back on.
- The only thing to be configured is the turn-off time.