Bob,
Answering some of your questions, though I'm not an expert on this so hopefully others will add or correct as need be..
The existing JMRI turnout sends (unless very low-level configuration is done) ¡°THROWN¡± and ¡°CLOSED¡±. Does only specific hardware understand that, or is there a way in the broker to transform it?
It's up to the user to write the software to process the message published in MQTT so, for example, an arduino can be programmed with a MQTT client to get the message (topic+payload) from the MQTT broker and then do as instructed to throw or close the turnout. The topic and payload it sees is exactly the payload that was published. The current MQTT turnout topic + payload shows "/trains/track/turnout/88 THROWN" so the arduino sketch needs to know whether turnout 88 is one under its control, which pin it is attached to and to do whatever it has to do to throw it.
Likewise, it's up to the user to write the software to process the sensor activity and publish it into MQTT in the format we require so if we say, for example, that the topic is to be /RailroadID/sensor/{JMRI sensor system name} with payload ON or OFF (or perhaps ACTIVE or INACTIVE to use JMRI terminology), all you need to do is subscribe to topic /RailroadID/sensor/#, you will get a message for each sensor change so set the JMRI sensor nominated to the relevant status.
?
Retention (last entry only for that topic so that gives last known state) is set by the MQTT client publishing the message so JRMI will set most of those but not for sensors. Retention is enabled in the current JMRI MQTT turnout code. When a client subscribes to a MQTT topic, it has the option whether or not to receive the retained message. It seems to me that retention is a good thing but Speed has warned that on startup, JMRI may receive a lot of messages in a rush though can choose not to see them. Finding out the status but that is perhaps a good thing, JMRI sensors can be set to the last known status instead of Unknown.
As for making that user definable, I have no opinion on the granularity that may be desired, I'll leave that for someone else to respond.
If the system name in JMRI is effectively free text for each turnout or whatever, then we're free to use whatever we like in JMRI to match however we code the processing nodes. Everyone can do their own thing but the big gain we get is a fairly simple way of integrating our service nodes with JMRI.
Regards, Dave Mc
