Event Channels
Event Channels exist outside of the Domain since they are a part of the underlying network infrastructure. However in the context of rest-python, we maintain the nod that event channel data often contains the domain of origin. So, we maintain that in this API.
/ redhawk / rest / events
{
"command" : "ADD", /* Or "REMOVE" */
"domainId" : "DOMAIN_NAME", /* Domain Name */
"topic": "ODM_Channel" /* Channel Name */
}SUBSCRIBE to specific event channels using the channel name, called a topic in websocket parlance, and the Domain ID (name) by writing the above JSON structure to the socket.
UNSUBSCRIBE from a specific event channel by changing the command to REMOVE and specifying the topic.
/ redhawk / rest / events
These structures are exclusively defined as one would find on the ODM and IDM channels in a REDHAWK system since those structures are simply converted into dictionaries and lists, as appropriate, but using JSON for syntax.
NOTE: The provided enumeration value for the affected fields was arbitrarily chosen as the index within the defining list so that the structure provided here is similar to Properties.
ODM Events
{
"producerId": "DCE:9ae444e0-0bfd-4e3d-b16c-1cffb3dc0f46",
"sourceId": "DCE:820e3275-4462-4823-b754-e09b4712869e",
"sourceName": "FEIDevice_1",
"sourceCategory": {
/* See enumerations */
"value": "DEVICE"
"enumerations": {
"DEVICE_MANAGER" : 0,
"DEVICE" : 1,
"APPLICATION_FACTORY" : 2,
"APPLICATION" : 3,
"SERVICE" : 4
}
},
"sourceIOR": "" /* OPTIONAL */
}The sourceIOR and other object reference types are stripped since they’re of little use on the other side of the socket. Instead you will see the key name, like sourceIOR, but the value will be a string indicating it does not represent what the real value was in any way. NOTE: The presence of the sourceIOR key indicates the entity was added to the Domain.
IDM Events
{
"producerId": "DCE:9ae444e0-0bfd-4e3d-b16c-1cffb3dc0f46",
"sourceId": "DCE:820e3275-4462-4823-b754-e09b4712869e",
"stateChangeCategory": {
/* See enumerations */
"value": "ADMINISTRATIVE_STATE_EVENT",
"enumerations": {
"ADMINISTRATIVE_STATE_EVENT" : 0,
"OPERATIONAL_STATE_EVENT" : 1,
"USAGE_STATE_EVENT" : 2
}
},
"stateChangeFrom": {
/* See enumerations */
"value": "LOCKED",
"enumerations": {
"LOCKED" : 0,
"UNLOCKED" : 1,
"SHUTTING_DOWN" : 2,
"ENABLED" : 3,
"DISABLED" : 4,
"IDLE" : 5,
"ACTIVE" : 6,
"BUSY" : 7
}
},
"stateChangeTo" : {
/* Identical behavior to stateChangeFrom */
}
}/ redhawk / rest / events
At present the best way to get Messages and property change events out of rest-python is to attach the associated port (in REDHAWK) to a named event channel. Then subscribe to that channel name as your topic to read those messages and property events as they happen.
Messages
{
"id": "propertyId",
"value": [
/* List of id-value pairs */
{ "id": "propertyId::field1", "value": 42 }
]
}Messages are encapsulated as they appear on the event channel which is similar to struct Properties. The notable difference is the lack metadata (type, scaType, etc.).
propEvent
{
"sourceId": "entityId",
"sourceName": "entityName",
"properties": [
/* List of Message-like objects */
]
}The properties is a list of objects formatted like Messages, above, meaning each lacks any metadata usually associated with Properties.
/ redhawk / rest / events
That would be really awesome. Thank you for volunteering to add that feature. :-)
At this time we do not have a way to inject Messages back into an event channel. If you would like to write the handlers for this, please do so and submit a pull request. Otherwise, just know it’s on our To Do list.