The Software Defined Blocks project uses an ESP32 with sensors to emulate block activations for a train model railroad.

The base idea is to use MQTT to publish block changes, instead of targeting the JMRI JSON protocol. I was originally going to support both, but that seems redundant. We’ll see. JSON is simple and very convenient for debugging, so it’s always a great idea to get started.

Here we’ll detail how that works for this specific project:

• ESP32 monitors sensors, sends messages to an MQTT broker.
• JMRI MQTT subscribes to messages from the MQTT broker.
• Requirement: An MQTT broker running on the network (either the same machine as JMRI, or another local one, or a public one).
• Requirement: Set up the ESP32 with the broker IP, and block/sensor topics.

For background, my RTAC Conductor automation software embeds “KV Server”, a distributed key-value server/client architecture which is fundamentally very similar to MQTT, except mine is nowhere as ubiquitous and it is buried somewhere in my LibUtils project. In the case of the Conductor automation software, I use the KV Server as a way to distribute configuration from the automation script to the accessories. Which means we can do the same here with MQTT, and we can take advantage of that to configure the ESP32 with block triggers defined in the automation script.

We have 3 options:

1. Local configuration stored in NVS (managed via onboard web page), ignore MQTT.
2. MQTT-provided configuration, override local configuration.
3. A mix of both.

To keep it simple, we’ll use option 2:

• Upon booting, SDB reads the NVS for potential trigger configuration.
• It also subscribes to a specific MQTT topic to get its configuration.
• If provided, this overrides any local configuration and saves it to the NVS.
• Since we subscribe to this topic, changes can happen anytime.
• The only thing we need to configure via the onboard web page is:
• The JMRI JSON server IP (w/ optional U/P).
• The MQTT broker IP (w/ optional U/P).
• The MQTT topic to use (we’ll want one ID per SDB node).

The advantage of this setup is that we can push a configuration to the node via the MQTT broker, e.g. from a Conductor script, and reloading that script would update the SDB node. But we also save it in the NVS so that when the board boots, it has trigger configuration even if the MQTT broker is not available.