MRIIOT
commented
3 years ago Okay, now to the MQTT payloads and topics. Note that I tested this on a single machine. Note that this would be useful to document somewhere (like in the
docs/folder within the repo), where I’d move all thefanuc-driverdocumentation (even fromREADME.md).TL;DR
Document all MQTT JSON objects. I could not find any in depth documentation of
payloadobject (there’s a bit of it inREADME.md, but it isn’t much).
DISCO
- The first
topicis$SYS/{broker_id}/new/clients. Itspayloadcontains2e58c25b4bb14c9ba7b86efb0c1838b1—what is it for? I could not find it anywhere else in the payloads.
$SYS is MQTT broker internal stuff.
brokerCountercan be used to make sure no messages are omited and that they are processed in order, right?
Don't know.
- Please describe the contents of
payloadinfanuc/DISCO.
Discovery topic is there for discovery of what machines are online and their relevant topics. Disco is controlled by:
broker:
publish_disco: !!bool true
disco_base_topic: fanuc
a. At first I though that
addedandseenare timestamps (UNIX epoch), but they are not and they are same in everyfanuc/DISCOtopic.
Data is published to discovery whenever a Fanuc controller is interrogated with a Focas call.
b. Why do we have
machineIdwhen the whole object is named as the machine ID?
True. It is redundant.
c. What is the purpose of
arrivalTopicandchangeTopic? Again they are all the same in everyfanuc/DISCOtopic.
arrivalTopic - data is published whether it changed or not.
changeTopic - data is published only when it has changed.
Controlled with:
broker:
publish_status: !!bool true
publish_arrivals: !!bool true
publish_changes: !!bool truepublish_status: publish heartbeat to fanuc/machineid/PING
Most of these configuration settings are relevant to l99.driver.fanuc.handlers.Native, fanuc handler.
- I understand that
qosis quality of service and is used for message prioritisation.
qos is used for message delivery. qos 0 - fire/forget, qos 1 - require that broker acks, qos 2 - require that a receiving client acks... if i remember correctly.
- As I understand the docs, when
retainis set totrue, those topics are changes to the previous machine state (and there the downstream apps should process it).
The purpose of retain is that the last message hangs out at the broker forever (or configurable in MQTT5), so when a new client connects and subscribes, it receives that message, instead of hanging around until a publisher sends a new message.
dup(I presume it stands for duplicate) which is always set tofalsein my output. Is there any situation whendupis set totrue?
ahhh, I forget.
Order of topics
- What is used order of messages/topics? From what I can see, it is something like this: a. First topic is always
$SYS/{broker_id}/new/clients. b. Second topic is alwaysfanuc/DISCO. This topic always comes before any other topics. c. Third topic is alwaysfanuc/{machine_id}/connect.- What is the different between
fanuc/{machine-id}andfanuc/{machine-id}-all? From my tests, both contain/broadcast the same data.
You will see that fanuc/{machine-id}-all receives more messages. All Focas responses are published there every single sweep. This is not the case with fanuc/{machine-id}. Messages there are only published when Focas responses change.
Deltas
Related: MQTT Payload Structure - Suggested
- As I understand it, first
deltaobjects of each (let’s say) type contains all information of that particular type, but all subsequentdeltascontain only the changes to that particular type, right? However, there are some exceptions to this rule, which always contain the same data, for example:
fanuc/{machine_id}/connect, where it always contains thetimesince (?)fanuc-driverstart and if it was successfully connected;fanuc/{machine_id}/cnc_id, where it always contains thetimesince (?)fanuc-driverstart andcncid;fanuc/{machine_id}/cnc_id, where it always contains thetimesince (?)fanuc-driverstart,minuteandmsec.
Yeah, delta would be the "difference". Maybe a better name here would be "state" ?
Anyway, I have no idea why
fanuc/{machine_id}/connectandfanuc/{machine_id}-all/connecthave differenttimevalues.
Because fanuc/{machine_id}/connect "reports by exception" or "on state change" or "on data change". In which case:
"data" { "success" : true }is the same as the previous sweep of the series of Focas calls.
fanuc/{machine_id}-all/connect reports every second (or whatever the interval is set to) regardless of data changes.
That said, I don’t think that the above-mentioned exceptions above should be called the deltas. I suggest to rename it to something like
metadataorstatus(or whatever else). Usually, a delta is a difference between the previous version and current version, but the above information is not a delta in this sense.
Correct, 'state' makes more sense. delta.time or state.time is the interval between status.data changes.
"delta": {
"time": "00:00:01.2500674",
"data": {
"success": true
}
}"state": {
"time": "00:00:01.2500674",
"data": {
"success": true
}
}
tukusejssirs
Okay, now to the MQTT payloads and topics. Note that I tested this on a single machine. Note that this would be useful to document somewhere (like in the
docs/folder within the repo), where I’d move all thefanuc-driverdocumentation (even fromREADME.md).TL;DR
Document all MQTT JSON objects. I could not find any in depth documentation of
payloadobject (there’s a bit of it inREADME.md, but it isn’t much).DISCOThe first
topicis$SYS/{broker_id}/new/clients. Itspayloadcontains2e58c25b4bb14c9ba7b86efb0c1838b1—what is it for? I could not find it anywhere else in the payloads.brokerCountercan be used to make sure no messages are omited and that they are processed in order, right?Please describe the contents of
payloadinfanuc/DISCO.a. At first I though that
addedandseenare timestamps (UNIX epoch), but they are not and they are same in everyfanuc/DISCOtopic.b. Why do we have
machineIdwhen the whole object is named as the machine ID?c. What is the purpose of
arrivalTopicandchangeTopic? Again they are all the same in everyfanuc/DISCOtopic.I understand that
qosis quality of service and is used for message prioritisation.As I understand the docs, when
retainis set totrue, those topics are changes to the previous machine state (and there the downstream apps should process it).dup(I presume it stands for duplicate) which is always set tofalsein my output. Is there any situation whendupis set totrue?Order of topics
What is used order of messages/topics? From what I can see, it is something like this:
a. First topic is always
$SYS/{broker_id}/new/clients.b. Second topic is always
fanuc/DISCO. This topic always comes before any other topics.c. Third topic is always
fanuc/{machine_id}/connect.What is the different between
fanuc/{machine-id}andfanuc/{machine-id}-all? From my tests, both contain/broadcast the same data.Deltas
Related: MQTT Payload Structure - Suggested
deltaobjects of each (let’s say) type contains all information of that particular type, but all subsequentdeltascontain only the changes to that particular type, right? However, there are some exceptions to this rule, which always contain the same data, for example:fanuc/{machine_id}/connect, where it always contains thetimesince (?)fanuc-driverstart and if it was successfully connected;fanuc/{machine_id}/cnc_id, where it always contains thetimesince (?)fanuc-driverstart andcncid;fanuc/{machine_id}/cnc_id, where it always contains thetimesince (?)fanuc-driverstart,minuteandmsec.Anyway, I have no idea why
fanuc/{machine_id}/connectandfanuc/{machine_id}-all/connecthave differenttimevalues.That said, I don’t think that the above-mentioned exceptions above should be called the deltas. I suggest to rename it to something like
metadataorstatus(or whatever else). Usually, a delta is a difference between the previous version and current version, but the above information is not a delta in this sense.