Skip to main content

​
Implementations common functions

The monitors and recorders share some methods:
  • isConnected → Inform on the connection status with the Heex Kernel
  • getUuid → Return the uuid of the Implementation
  • getImplementationVersion → Return the implementation version of the Implementation
  • getSdkVersion → Return the Sdk version of the Implementation have been compiled with
  • getTimestampStr → Get the current time of the system in the iso_extended std::string format.
  • isReady → Return true when implementation is ready to begin it’s work.
  • awaitReady → Blocks until implementation is ready to begin it’s work. Returns true if the Implementation is ready or false if the connection failed.
  • disableLogToFile → Permanently disable logging ouput to files.
  • getTriggerInfo(triggerUUID) → Return the trigger information associate to the given trigger UUID.
  • getAllTriggerInfos() → Returns a map of all TriggerInfos related to the implementation.
  • getSystemId() → Returns the current system ID.
  • getSystemLabels() → Returns a map of all the System level labels.
  • getTriggerLabels() → Returns a map of all the Trigger level labels.
  • sendMessageToImplementation(messages, destinationImplementationId="") : All implementations can communicate with each other. To send a message, use this method by filling in the const std::vector<std::string>& messages as you please, and specify the destination implementation ID. You may leave this last one empty, and if so, it’ll broadcast to all other connected implementations.
  • handleMessageFromOtherImplementation(sourceImplementationId, messages) : All implementations can communicate with each other. When a message is received, this callback is called. It is up to you to overload this method and decide what to do with the messages.
  • onConfigurationChangedCallback → This is a callback method that is called every time a new configuration is sent to the edge. It is executed at the end of the loading of the new config. In order to use this, you’ll have to override a virtual void onConfigurationChangedCallback() override and implement any code you’d like to be executed in there. See the advanced ConfChangedCallback samples for more details.

​
Recorder utility functions

  • C++
  • Python
These methods need to be called on labels argument.
void RecorderLabels::addLabel(const std::string& key, const std::string& value)
↳ Assigns the value to the key. Values are defaulted to an empty string.
void RecorderLabels::addLabel(const HeexGps& heexGps)
↳ Assigns the x and y position of a HeexGps structure to the position label.

​
Recorder Query structure

​
Query for Labels

The query provided in the generateRequestedLabels() method is specified by the EventRecordingLabelsQuery structure. You may extract the following fields from the query element to extract your Labels:
  • query.eventId → Event ID
  • query.triggerId → Trigger ID
  • query.timestamp → requested timestamp following the iso extended format
For more details, it is defined in the code as: 
/// @brief Args structure for RecorderQueryLabel message used in the Recorder-HeexKERNEL interprocess communication.
/// This structure is used to store the result of the parsing of Recorder Label messages. Heex Kernel and Recorder shared that formalism for QueryEventRecLabelsSo and AnswerEventRecLabelsSo commands.
struct EventRecordingLabelsQuery
{
  std::string eventId{};   ///< id of the event generated
  std::string triggerId{}; ///< id of the trigger that generated the event
  std::string timestamp{}; ///< UTC timestamp in format 1970-01-01T00:00:00.000000Z
};                         // EventRecordingLabelsQuery

​
Query for Event Recording Parts

The query provided in the generateRequestedFilePaths() method is specified by the RecorderEventRecordingPartArgs structure. You may extract the following fields from the query element to generate your Event Recording Parts:
  • query.eventId → Event ID
  • query.triggerId → Trigger ID
  • query.timestamp → requested timestamp following the iso extended format
  • query.timestampedEventUuid → the event ID and timestamp concatenated
For more details, it is defined in the code as: 
/// @brief Args structure for RecorderDataFilePath message used in the Recorder-HeexKERNEL interprocess communication.
/// This structure is used to store the result of the parsing of Recorder DataFilePath messages. Heex Kernel and Recorder shared that formalism for QueryDataFile and AnswerEventRecPartsSo commands.
struct EventRecordingPartQuery
{
  std::string eventId{};              ///< id of the event generated
  std::string triggerId{};            ///< id of the trigger that generated the event
  std::string timestamp{};            ///< UTC timestamp in format 1970-01-01T00:00:00.000000Z
  std::string timestampedEventUuid{}; ///< UTCtimestamp_eventUuid : used for unique naming
};                                    // EventRecordingPartQuery

​
Implementation intercommunication

  • Sending messages
    All implementations can communicate with each other by calling their sendMessageToImplementation method (both Monitor and Recorders have this). Fill in the messages input, a vector of strings, and specify either a specific destinationImplementationId to address a specific implementation, or leave that argument empty to broadcast to all other running implementations.
  • Receiving messages
    A virtual callback method, handleMessageFromOtherImplementation, has been provided. It will be called everytime the implementation receives a message with the sourceImplementationId as an input, and the vector of strings messages:
  • C++
  • Python
In your SampleMonitor or SampleRecorder class, overload the following method:
virtual void SampleMonitor::handleMessageFromOtherImplementation(const std::string& sourceImplementationId, const std::vector<std::string>& messages) override
{
  // Handle the messages as you please
}