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.


 Generated on 2024-02-29 by Rig4j 0.1-Exp-e7e2d73