On Dec 7, 2018, at 09:35, Bob Jacobsen <rgj1927@...> wrote:
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?
What do you mean by look for?
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.
Ideally it looks like this. /trains/hardwareID/item
Hardware ID = Mac address
Item = sub item on that device
JRMI has a hardware id of MAC/item
JSON in the payload = to the JSON used in WebSockets.
This would make it THE most flexible, but the LEASE human readable.
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.
Not sure who the MQTT community is¡but I can write use cases, if that is what you are asking.
Bob
--
Bob Jacobsen
rgj1927@...
