Bob
Why does it mean that?
You're right, it doesn't necessarily mean that, my mind was still on using wild cards for sensors. The main point I tried not very well to explain was that we can't use wild cards for device type now that we've dropped the idea of including device type somewhere in the topic.? JMRI can subscribe to each of the sensor topics by specifically naming each of them and knows that they are sensors. One subscription process can have a list of topics (with or without wild cards) or you can have one subscription process for each topic (with or without wild cards).?
?
We probably don't even need to care what the device type is if all we are going to do is update its state. For sensors, this is how JMRI detects sensor state changes. For other device types, we're just eavesdropping in case a device gets changed by something else so we can update it in JMRI.
?
Regarding top level, there have been a few preferences expressed to retain a channel name on the connection page though user choice instead of "trains". I anticipate this to mean than when a user creates an MQTT device, that channel name will be added so if a user has a channel name foo/ they enter the hardware address as bar/whatever so the system name will be MTfoo/bar/whatever. If the decision is to abandon the channel name, then the full topic gets added as the hardware address. The end result is the same system name and topic name.
?
To use wild cards instead of listing each and every object, you would subscribe to foo/# if we have that as the channel, else it would be +/# or just #, then with each message, scan JMRI MQTT objects for a match else ignore the message.
?
Doesn't bother me which way you go though my vote is to retain the channel concept.
- David.
