Skip to content

Message Definitions

Jump to bottom
Corey Thompson edited this page Jan 22, 2023 · 3 revisions

V2 Messages

coilWriteMsgV1

{ 
"requestedValue" : 20, //uint16 
"contentType":"coilWriteMsgV1", //required 
"sessionId":"session-820923084792", //requestor supplied, not guaranteed unique 
"resTopic":"cmd/security/app1/res" //where to send results 
}

coilWriteResV1

Format of result message published to a command's resTopic
{ 
"requestedValue" : 20, //uint16
"actualValue" : 20, //unit16
"contentType":"coilWriteResV1",
"sessionId":"session-820923084792", //requestor supplied id, will be generated if empty
}

registerWriteMsgV1

{
"requestedValue" : true //boolean
"contentType":"registerWriteMsgV1",
"sessionId":"session-820923084792", //requestor supplied, not guaranteed unique
"resTopic":"cmd/security/app1/res" //where to send results
}

registerWriteResV1

Format of result message published to a command's resTopic
{ 
"requestedValue" : true, //boolean 
"actualValue" : true, //boolean
"contentType":"registerWriteResV1",
"sessionId":"session-820923084792", //requestor supplied id, will be generated if empty
}

V1 Messages

Messages in V1 are for incoming commands only with no response enabled.

Note: This message structure was an unnamed object at time of release in 0.1.0beta and 0.1.0

registerWriteMsg

{ "value" : 20 //uint16 }

Important Resources

Platform updates

Please make sure to bookmark the following pages, as they will provide you with important details on API outages, updates, and other news relevant to developers on the platform. Check out our releases to find the latest binaries and a history of all released binaries. Visit the Tulsa Software Repositories to find related open-source codebases. In case of any document conflicts, assume the Vfdctl readme is most accurate.

MQTT reference material

MQTT is extremely flexible and not as rigidly enforced as communications such as RPC or REST communications. This leaves lots of room for one-off implementations if systems are not intentionally designed. For our communications architecture, we have based our topic and payload structures off of the AWS best practices to ensure ultimate usability.

  • Even if not using AWS IoT cloud communications, their MQTT communication patterns are widely applicable
  • A good client GUI like MQTTX or MQTT Explorer makes troubleshooting your system much easier but any app supporting MQTT 3.1.1 communications will suffice
  • Using a IoT Rules Engine such as Node Red, AWS IoT Core, etc is essential to utilizing data with minimal coupling and maximal scalability

Still have questions?

For the questions not covered here or to learn what we're currently working on, visit the Tulsa Software slack channel to review topics, ask questions and learn from others.

Clone this wiki locally