A few more things to think about...
- will JMRI subscribe to every topic that contains a sensor/turnout/mast? I have found there are limits (in performance and memory) for subscribing to too many things. About a year ago I created this Jython script () to publish and subscribe to MQTT for "Virtual Masts" from within JMRI. I simply used the "Username" to keep the topic for each virtual mast, which was simple at the time: "mast.0003". Today I would go with /TxNamib/mast.0001/03, where the mast.0001 is the board where the masts are connected to.?
- Do we use retention? I found it convenient in my ESP implementation to save the state of the turnout in /TxNamib/servo.0003/01 as a '0' or a '1' with retention on, so when the ESP boots up, it knows where to move the servo without keeping the state saved in local EEPROM. I know some don't like physical addressing boards, but I found it convenient to simply subscribe to /TxNamib/servo.0003/# for all 16 turnouts connected to the ESP. So if retention is used, JMRI is going to turn on and get hundreds of messages (that it needs to keep up with) and also might have the "INCONSISTENT" state if it determines the turnout to be otherwise.?
- JMRI typically (or used to) only generate a message to hardware when there is a state change, so without retention in MQTT, the servo won't know where to go until there is a change in JMRI.
- Like Bob said, somethings work different than others. A block detector sensor is by nature controlled by the block detection circuit, but a global "I need the Dispatcher's attention" sensor could be turned on by more than one. (And who turns it off?). Masts should also be single sourced, in this case I would say JMRI determines the aspect.
- Will JMRI allow us to pick what messages to send? For example, "Active" and "Inactive" versus '1' and '0' versus 'True' or 'False'? Might not sound important here, but who wrote the code on the other side, it matters over there.
- And Masts having 'Clear', 'Approach' and Signal Heads using 'Green', 'Flashing Red', 'Dark', ...? Or do we start with only Heads?
- JMRI also need to allow, not only the username and password as mentioned earlier, but also the QOS (quality of service), and other (or future), settings.
[ Disclaimer about my Jython script: I can't promise the "threading" part is working well enough, sometimes you need to restart JMRI. The JButton on the Desktop was a simple way to remove the Listeners when you needed to rename a mast, instead of restarting JMRI. ]
