it would be great if the community could converge on how JMRI should work with MQTT devices.
Some boundary conditions:
1) JMRI has specific control metaphors: Turnout (i.e. one-bit digital output), Sensor (i.e. one-bit digital input), Light, SignalMast/SignalHead, Reporter, etc. They each function a bit differently. _How_ they work with MQTT is something that needs to be defined: What does it mean when a MQTT-based light wants to set intensity to 75%? What should a Sensor look for to decide whether it should go to ACTIVE, INACTIVE, UNKNOWN or INCONSISTENT, and if something else happens, what should it do?
2) JMRI hardware flexibility comes from the system name metaphor. A Turnout (T) in the MQTT system (M) can have a system name like MT/stuff/morestuff/123/$5/dancing-bear-emoji for all JMRI cares. So you can put a lot of information into that system name to define the operation, so long as it can be unambiguously parsed. It¡¯s even possible to have different formats for the same underlying hardware devices, c.f. CT3001 vs CT3b1 and all the weird and wonderful MERGE CBUS formats.
So it would be _great_ if the MQTT community could come up with an addressing approach (which can have alternatives, i.e. with and without JSON) and an example of how a few cases, i.e. Sensor and Light. should work with it. We can then get that coded up for testing during the semester break that¡¯s coming.
Bob
--
Bob Jacobsen
rgj1927@...
Bob Jacobsen