Service Devices In Karabo

Karabo comes with a selection of service devices, which in principle may be interacted with through their public interface, although this is normally not necessary if appropriate clients, such as the GUI are used.

C++ Service Devices

namespace karabo::devices

Namespace for package core

Typedefs

typedef boost::function<void()> AsyncHandler
typedef boost::function<void(const karabo::net::HttpResponse&)> InfluxResponseHandler

Functions

template <class T>
void addToSetOrCreate(Hash &h, const std::string &key, const T &object)

Helper function used below: Add object to set<T> at key’s position in h - if no such key exists, create one

Variables

const unsigned int defVectorMaxSize = 100
class AlarmService
#include <AlarmService.hh>

The AlarmService device keeps track of alarms raised in the distributed system.

The AlarmService device keeps track of alarms raised in the distributed system. It registers itself to the alarm signals and maintains a list of currently known alarms, when they were first and last raised, their severity, additional information and whether they need acknowledging before they disappear.

The device provides interfaces for clients to query this information and interact with the alarms known to the system. Specifically, clients may send requests to acknowledge a pending alarm.

Additionally, the alarm service periodically saves alarms it manages to disk. This is done to allow for quick recovery from system wide errors: if the alarm service for which-ever reason needs to be restarted, it will query only the differences of the last persisted alarms from the distributed system. For this purpose a storagePath and flushIntervall may be configured in the device’s expected parameters.

Inherits from karabo::core::Device<>

Private Functions

void registerNewDevice(const karabo::util::Hash &topologyEntry)

Callback for the instanceNew monitor. Connects this device’s slotUpdateAlarms function to the new devices signalAlarmUpdate signal. If the device was previously known it will ask this device to submit its current alarm state.

void connectedHandler(const std::string &deviceId)

Callback for connecting to a device’s “signalAlarmUpdate”

void instanceGoneHandler(const std::string &instanceId, const karabo::util::Hash &instanceInfo)

Called when a device instance disappears from the distributed system. It will trigger the alarm service to set all alarms pending for this device to need acknowledgement and acknowledgeable. This means alarms will not silently disappear, but because it can’t be assured that the device instance that disappeared will ever clear them for acknowledgment they are acknowledgeble. Note that if the device instance does happen to reappear it will be asked to resubmit its current alarm state, bringing all alarms pertinent to it back into a consistent needsacknowledging, acknowledging and cleared condition.

Parameters
  • instanceId: the instance id of the device the disappeared
  • instanceInfo: not used but forwarded by the device client

void slotUpdateAlarms(const std::string &deviceId, const karabo::util::Hash &alarmInfo)

This slot is to be called to let the alarm service device know of an update in device alarms. As parameters it expects a device id, alarmInfo Hash, which should have the following structure:

toClear -> property A -> alarm type 1 -> bool -> property A -> alarm type 2 -> bool -> property B -> ….

The bool field is not evaluated but serves as a placeholder

deviceId -> toAdd -> property A -> alarm type 1 -> Hash() deviceId -> toAdd -> property A -> alarm type 2 -> Hash() deviceId -> toAdd -> property B -> …

Entries underneath the “toClear” hierarchy are used to evaluated clearing of existing alarms. Two scenarios are handled:

  • alarm does not require acknowledging -> it is deleted from the alarm list
  • alarm does require acknowledging -> it is made acknowledgable

Entries in the “toAdd” hierarchy result in one of the following two scenarios

  • an alarm for this property and type does not yet exist -> it is added
  • an alarm for this property and type does exist -> it is updated but the first occurance is set to that of the existing alarm.

void setupSignalsAndSlots()

Add signals and slots which need to be set up during initialization in this function

void flushRunner() const

Runner for flushing table

void reinitFromFile()

Reinitializes the alarm services state from its persisted information

karabo::util::Hash addRowUpdate(const std::string &updateType, const karabo::util::Hash &entry) const

Add an update to a row in the alarm system

Return
: a Hash to add to the updated rows.
Parameters
  • updateType: type of update: init, update, delete, acknowledgeable, deviceKilled
  • entry: alarm entry

void addDeviceAlarms(const std::string &deviceId, const karabo::util::Hash &alarms, karabo::util::Hash &rowUpdates)

Add/update the alarms for a device

Parameters
  • deviceId: A device ID
  • alarms: A hash of property names -> hashes of alarm type entry hashes
  • rowUpdates: A Hash of updated rows which will be emitted to connected slots

void removeDeviceAlarms(const std::string &deviceId, const karabo::util::Hash &alarms, karabo::util::Hash &rowUpdates)

Clear the alarms for a device

Parameters
  • deviceId: A device ID
  • alarms: A hash of property names -> hashes of alarm type entry hashes
  • rowUpdates: A Hash of updated rows which will be emitted to connected slots

void slotAcknowledgeAlarm(const karabo::util::Hash &acknowledgedRows)

Slot to be called if a client wishes to acknowledge an alarm

Parameters
  • alarmServiceId: Alarm service the alarm should be registered at. Should be this device’s instance id
  • acknowledgedRows: the rows which should be acknowledged. It is a Hash where the keys give the unique row id, the value is currently not evaluated.

void slotRequestAlarmDump()

Request a dump of all alarms currently managed by this alarm service device

void slotRequestAlarms(const karabo::util::Hash &info)

Request a dump of all alarms currently managed by this alarm service device generically

void sendAlarmInformation()

Implementation method to reply the alarmInformation for slotRequestAlarms and slotRequestAlarms

bool allowLock() const

This device may not be locked

Return
false

void makeMoreSignificantAcknowledgeable(karabo::util::Hash &propertyAlarms, const karabo::util::AlarmCondition &lastAdded, karabo::util::Hash &rowUpdates)

Make all alarm types which are of a lower significance ‘acknowledgeable’ if ‘needsAcknowledging’ is set for them.

NOTE: m_alarmChangeMutex must be locked when calling this method!

Parameters
  • propertyAlarms: The sub-Hash of m_alarms containing all the alarm type hashes for a single property
  • lastAdded: An alarm type to compare against
  • rowUpdates: A row updates Hash which will be emitted to connected slots

class DataLogger
#include <DataLogger.hh>

A DataLogger device is assigned devices in the distributed system and logs their slow control data.

DataLoggers are managed by the karabo::devices::DataLoggerManager.

Each is able to log any number of devices. This list can be specified at instantiation, but can also dynamically changed by the slots slotTagDeviceToBeDiscontinued and slotAddDevicesToBeLogged. When the logger is ready to log data, its state changes from INIT to NORMAL.

Inherits from karabo::core::Device<>

Subclassed by karabo::devices::FileDataLogger, karabo::devices::InfluxDataLogger

Protected Functions

void initializeLoggerSpecific()

Do some actions here that may require asynchronous logic … and, finally, startConnection() should be called This function may be overridden by derived classes but at the end the ‘startConnection’ function should be called as a last step of initialization

bool removeFrom(const std::string &str, const std::string &vectorProp)

Helper to remove an element from a vector<string> element. Note that if the same element is in the vector more than once, only the first one is removed.

Return
whether could be removed
Parameters
  • str: the element to remove
  • vectorProp: the key of the vector<string> element

bool appendTo(const std::string &str, const std::string &vectorProp)

Helper to add an element to a vector<string> element. Note that if the same element is already in, it will not be added again.

Return
whether it was added (i.e. false if ‘str’ was already in the vectorProperty
Parameters
  • str: the element to add
  • vectorProp: the key of the vector<string> element

void preDestruction()

Override preDestruction from Device class

Private Functions

void slotTagDeviceToBeDiscontinued(const std::string &reason, const std::string &deviceId)

FIXME: Update text This tags a device to be discontinued, three cases have to be distinguished

(a) Regular shut-down of the device (wasValidUpToNow = true, reason = ‘D’) (b) Silent death of the device (wasValidUpToNow = true, reason = ‘D’) (c) Start-up of this (DataLogger) device whilst the device was alive (wasValidUpToNow = false, reason = ‘L’)

This slot will be called by the DataLoggerManager

void handleConfigConnected(const DeviceData::Pointer &data, const boost::shared_ptr<std::atomic<unsigned int>> &counter)

Helper for connecting to both signalChanged and signalStateChanged.

void updateTableAndFlush(const boost::shared_ptr<SignalSlotable::AsyncReply> &aReplyPtr)

Flush data in file hierarchy or to the database tables

Parameters
  • aReplyPtr: if pointer to an AsyncReply that (if non-empty) has to be called without argument when done

virtual void flushImpl(const boost::shared_ptr<SignalSlotable::AsyncReply> &aReplyPtr) = 0

“Flush” data accumulated in the internal cache to the external storage (file, database,…)

bool allowLock() const

This device may not be locked

Return
false

class DataLoggerManager
#include <DataLoggerManager.hh>

The DataLoggerManager manages device loggers in the distributed system.

In the Karabo distributed system two types of data archiving exist:

  • run associated archival of scientific data through the DAQ system
  • constant device state and slow control logging using the data logger services

This device manages the data loggers used in the second logging scenario. It is the central configuration point to set via its expected parameters the

  • flushInterval: at which loggers flush their data to disk
  • maximumFileSize: of log files after which a new log file chunk is created
  • directory: the directory into which loggers should write their data
  • serverList: a list of device servers which each runs one logger. Each device in the distributed system is assigned to one logger. They are added to the loggers on these servers in a round robin fashion, allowing for load balancing. Assignment is made permanent in a loggermap.xml file that is regularly written to disk. This allows to distribute the servers in the serverList to be distributed among several hosts and still have fixed places for reading the data back.

Inherits from karabo::core::Device<>

Private Functions

std::pair<bool, std::string> checkSummary()

Assemble summary from m_checkStatus and clear for next use. The boolean returned tells whether the status requires operator attention.

void printLoggerData() const

Print internal cash of logger status. Needs to be protected by m_strand.

void forceDeviceToBeLogged(const std::string &deviceId)

If deviceId’s logging status is fishy, re-add to its logger. Needs to be protected by m_strand.

Parameters
  • deviceId: the fishy device

void slotGetLoggerMap()

Request the current mapping of loggers to servers. The reply contains a Hash where the the logger id is the key and the server id the value.

std::string loggerServerId(const std::string &deviceId, bool addIfNotYetInMap)

Get id of server that should run logger for given device that should be logged

Return
the server id - can be empty if addIfNotYetInMap == false
Parameters
  • deviceId: the device that should be logged
  • addIfNotYetInMap: whether to create a server/logger relation in the logger map in case it does not yet exist for deviceId

std::string serverIdToLoggerId(const std::string &serverId) const

Get id of DataLogger running on server with id ‘serverId’

std::string loggerIdToServerId(const std::string &loggerId) const

Get id of server that should run logger with id ‘loggerId’

bool allowLock() const

This device may not be locked

Return
false

Private Members

karabo::util::Hash m_checkStatus

1st level keys: entries in m_serverList, 2nd level: “state”, “backlog”, “beingAdded” and “devices”

karabo::net::Strand::Pointer m_strand

Keep track of all important stuff during check.

class DataLogReader
#include <DataLogReader.hh>

DataLogReader devices read archived information from the Karabo data loggers.

DataLogReader devices read archived information from the Karabo data loggers. They are managed by karabo::devices::DataLoggerManager devices. Calls to them should usually not happen directly, but rather through a karabo::core::DeviceClient and it’s karabo::core::DeviceClient::getPropertyHistory and karabo::core::DeviceClient::getConfigurationFromPast methods.

Inherits from karabo::core::Device< karabo::core::OkErrorFsm >

Subclassed by karabo::devices::FileLogReader, karabo::devices::InfluxLogReader

Protected Functions

void slotGetPropertyHistory(const std::string &deviceId, const std::string &property, const karabo::util::Hash &params)

Use this slot to get the history of a given property The slot replies a vector of Hashes where each entry consists of a Hash with a key “v” holding the value of the property at timepoint signified in “v“‘s attributes using a format compatible with karabo::util::Timestamp::fromHashAttributes

Parameters
  • deviceId: for which to get the history for
  • property: path to the property for which to get the history from
  • params: Hash containing optional limitations for the query:
    • from: iso8601 timestamp indicating the start of the interval to get history from
    • to: iso8601 timestamp indicating the end of the interval to get history from
    • maxNumData: maximum number of data points to retrieve starting from start

void slotGetConfigurationFromPast(const std::string &deviceId, const std::string &timepoint)

Request the configuration Hash and schema of a device at a given point at time. Depending on the device status and on the availability of logged data, the configuration and schema returned will be:

  1. If the device was online and logging data at the given timepoint, the configuration and the schema will be the ones that were active at the timepoint;
  2. If the device was offline at the given timepoint, but there is data logged for it before the timepoint, the last active configuration and schema before that timepoint will be returned;
  3. If the device was offline at the given timepoint and there’s no data logged before the timepoint, an empty configuration and an empty schema will be returned.

The slot replies with a tuple of 4 values. The first two are the Hash and Schema objects containing the configuration Hash and the corresponding device schema for timepoint. The third is a boolean whose true value indicates the device was online and actively logging data at the timepoint. The fourth value is the string form of the timepoint for the configuration returned and will be the latest timestamp among the timestamps of the properties in the configuration returned.

Parameters
  • deviceId: of the device to get the configuration from
  • timepoint: in iso8601 format for which to get the information

An important note: if no configuration is found for the device at the timepoint (or before the timepoint), the third value in the reply will be false and the fourth will be the string form of the Epoch (01/01/1970 at 00:00:00).

struct DeviceData

Inherits from boost::enable_shared_from_this< DeviceData >

Subclassed by karabo::devices::FileDeviceData, karabo::devices::InfluxDeviceData

Public Functions

virtual void handleChanged(const karabo::util::Hash &config, const std::string &user) = 0

Called when configuration updates arrive for logging

Parameters
  • config: a Hash with the updates and their timestamps
  • the: user responsible for this update - if any

virtual void handleSchemaUpdated(const karabo::util::Schema &schema, const karabo::util::Timestamp &stamp) = 0

Called when a Schema update arrive for logging

Parameters
  • schema: - the new one
  • stamp: - the timestamp to be assigned for that update

void getPathsForConfiguration(const karabo::util::Hash &configuration, const karabo::util::Schema &schema, std::vector<std::string> &paths) const

Retrieves the paths of the leaf nodes in a given configuration. The paths are returned in ascending order of their corresponding nodes timestamps.

Note
karabo::devices::DataLogReader depends on the configuration items being properly sorted in time to retrieve configuration changes.
Parameters
  • configuration: A configuration with the nodes corresponding to the paths.
  • schema: The schema for the configuration hash.
  • paths: The paths of the leaf nodes in the configuration, sorted by nodes timestamps.

class FileDataLogger

Inherits from karabo::devices::DataLogger

Private Functions

void flushImpl(const boost::shared_ptr<SignalSlotable::AsyncReply> &aReplyPtr)

“Flush” data accumulated in the internal cache to the external storage (file, database,…)

struct FileDeviceData

Inherits from karabo::devices::DeviceData

Public Functions

void handleChanged(const karabo::util::Hash &config, const std::string &user)

Called when configuration updates arrive for logging

Parameters
  • config: a Hash with the updates and their timestamps
  • the: user responsible for this update - if any

bool updatePropsToIndex()

Helper function to update data.m_idxprops, returns whether data.m_idxprops changed.

void ensureFileClosed()

Helper to ensure archive file is closed. Must only be called from functions posted on ‘data.m_strand’.

std::pair<bool, size_t> ensureFileOpen()

Helper to ensure archive file (m_configStream) is open. Must only be called from functions posted on ‘data.m_strand’.

Return
pair of * whether it is a new file (in contrast to a re-opened existing one)
  • current file position, size_t(-1) tells that file could not be opened (permissions?)

void handleSchemaUpdated(const karabo::util::Schema &schema, const karabo::util::Timestamp &stamp)

Called when a Schema update arrive for logging

Parameters
  • schema: - the new one
  • stamp: - the timestamp to be assigned for that update

struct FileLoggerIndex
#include <FileLogReader.hh>

A compound for representing indexes in text file logged data.

class FileLogReader
#include <FileLogReader.hh>

A reader for data logs stored in text files by the class karabo::devices::FileDataLogger.

Inherits from karabo::devices::DataLogReader

Private Functions

void readToHash(karabo::util::Hash &hashOut, const std::string &path, const karabo::util::Timestamp &timestamp, const std::string &type, const std::string &value) const

Internal helper: Place ‘value’ interpreted as ‘type’ (and with given ‘timestamp’) into ‘hashOut’ at ‘path’.

std::pair<bool, FileLoggerIndex> findLoggerIndexTimepoint(const std::string &deviceId, const std::string &timepoint)

Retrieves, from the logger index, the event of type “device became online” that is closest, but not after a given timepoint. The retrieved logger index event can be used as a starting point for sweeping the device log for the last known given configuration at that timepoint.

Return
a pair whose ‘first’ is a boolean that indicates whether configuration was active at the timepoint (true) or whether it is a configuration from the most recent activation of the device prior to the timepoint because the device was not active logging at the timepoint. The pair’s ‘second’ value is the logger index of the given device that is the closest “device became online” event that is not after the given timepoint.
Parameters
  • deviceId: the device whose logger index event should be retrieved.
  • timepoint: the timepoint that will be used as the reference to find the logger index event.

FileLoggerIndex findNearestLoggerIndex(const std::string &deviceId, const karabo::util::Epochstamp &timepoint, const bool before)

Find logger closest index from archive_index.txt file that is before/after (according to ‘before’) ‘timepoint’. If there is none before (after) but that is asked for, take the one just after (before).

size_t findPositionOfEpochstamp(std::ifstream &f, double stamp, size_t left, size_t right, bool preferBefore)

Find index of that MetaData::Record in ‘f’ (between indices ‘left’ and ‘right’) that matches the Epochstamp ‘stamp’. In case no exact match (within 1 ms) is found, ‘preferBefore’ decides whether the index with a smaller or larger time stamp is returned.

void extractTailOfArchiveIndex(const std::string &tail, FileLoggerIndex &entry) const

Helper to extract DataLoggerIndex values out of the tail of a line in archive_index.txt. The tail is everything after event, timestampAsIso8061 and timestampAsDouble. The entry has to be partly filled (m_event and m_epoch) and partly serves as output (m_train, m_position, m_user and m_fileindex). Works for lines written to archive_index.txt by >= 1.5

class GuiServerDevice
#include <GuiServerDevice.hh>

The GuiServerDevice mediates between GUI clients and the distributed system.

The GuiServerDevice acts as a mediator between the distributed system and GUI clients, which connect to it through (tcp) channels. The device centrally manages updates from the distributed system and pushes them to the clients. Conversly, it handles requests by clients and passes them on to devices in the distributed system.

Inherits from karabo::core::Device<>

Private Functions

void loggerMapConnectedHandler()

Wrapping requestNoWait

void postReconfigure()

Called if configuration changed from outside.

void startDeviceInstantiation()

Starts the deadline timer which throttles device instantiation.

void startNetworkMonitor()

Starts the deadline timer which triggers network stats collection

void startForwardingLogs()

Starts the deadline timer which forwards the cached log messages

void startMonitorConnectionQueues(const karabo::util::Hash &currentSuspects)

Starts the deadline timer which monitors connection queues

Parameters
  • currentSuspects: Hash with pending message counts - keys are bad client addresses

void collectNetworkStats(const boost::system::error_code &error)

Perform network stats collection

void forwardLogs(const boost::system::error_code &error)

writes a message to the specified channel with the given priority

Parameters
  • channel:
  • message:
  • prio: Perform forwarding logs

void deferredDisconnect(const boost::system::error_code &err, WeakChannelPointer channel, boost::shared_ptr<boost::asio::deadline_timer> timer)

Deferred disconnect handler launched by a deadline timer.

void safeAllClientsWrite(const karabo::util::Hash &message, int prio = LOSSLESS)

writes message to all channels connected to the gui-server device

Parameters
  • message:
  • prio:

void onError(const karabo::net::ErrorCode &e, WeakChannelPointer channel)

an error specified by ErrorCode e occurred on the given channel. After an error the GUI-server will attempt to disconnect this channel.

Parameters
  • e:
  • channel:

bool violatesReadOnly(const std::string &type, const karabo::util::Hash &info)

validate the incoming type and info hash if a readOnly command is requested to be executed

Return
bool whether the request violates read-only restrictions
Parameters
  • type:
  • info:

bool violatesClientConfiguration(const std::string &type, WeakChannelPointer channel)

validates the client configuration

currently only validating the type versus the client version.

Return
bool whether the request violates client validation
Parameters
  • type:
  • channel:

void onGuiError(const karabo::util::Hash &hash)

an error further specified by hash occurred on a connection to a GUI client. The GUI-server will attempt to forward the error to the debug channel of the GUI client.

Parameters
  • hash:

void onConnect(const karabo::net::ErrorCode &e, karabo::net::Channel::Pointer channel)

connects a client on to the GUI server on channel. The channel is registered with two priority handlers: remove oldest and loss-less. The onRead and onError handlers are registered to handle incoming data and faults on the channel. Both upon successful completion and exceptions in the process the acceptor socket of the GUI-server is re-registered so that new client connections may be established.

Parameters
  • e: holds an error code if any error occurs when calling this slot
  • channel:

void registerConnect(const karabo::util::Version &version, const karabo::net::Channel::Pointer &channel)

Creates the internal ChannelData entry and update the device Configuration

void onLoginMessage(const karabo::net::ErrorCode &e, const karabo::net::Channel::Pointer &channel, karabo::util::Hash &info)

handles incoming data in the Hash info from channel

When the client has connected, only the login type is allowed. The expected hash must contain a version string and a user string. The version string is verified against the minimum client version. The user string is required but currently not used.

Upon successful completion of the login request the onRead function is bound to the channel, allowing normal operation. In case of failure the ``onLoginMessage is bound again to the channel.

Parameters
  • e: holds an error code if the eventloop cancel this task or the channel is closed
  • channel:
  • info:

void onLogin(const karabo::net::Channel::Pointer &channel, const karabo::util::Hash &info)

Handles a login request of a user on a gui client. If the login credentials are valid the current system topology is returned.

Parameters
  • channel:
  • info:

void onRead(const karabo::net::ErrorCode &e, WeakChannelPointer channel, karabo::util::Hash &info)

handles incoming data in the Hash info from channel. The further actions are determined by the contents of the type property in info. Valid types and there mapping to methods are given in the following table:

onRead allowed types
type resulting method call
requestFromSlot onRequestFromSlot
reconfigure onReconfigure
execute onExecute
getDeviceConfiguration onGetDeviceConfiguration
getDeviceSchema onGetDeviceSchema
getClassSchema onGetClassSchema
initDevice onInitDevice
killServer onKillServer
killDevice onKillDevice
startMonitoringDevice onStartMonitoringDevice
stopMonitoringDevice onStopMonitoringDevice
getPropertyHistory onGetPropertyHistory
getConfigurationFromPast onGetConfigurationFromPast
subscribeNetwork onSubscribeNetwork
requestNetwork onRequestNetwork
error onGuiError
acknowledgeAlarm onAcknowledgeAlarm
requestAlarms onRequestAlarms
updateAttributes onUpdateAttributes
projectUpdateAttribute onProjectUpdateAttribute
projectBeginUserSession onProjectBeginUserSession
projectEndUserSession onProjectEndUserSession
projectSaveItems onProjectSaveItems
projectLoadItems onProjectLoadItems
projectListProjectManagers onProjectListProjectManagers
projectListItems onProjectListItems
projectListProjectsWithDevice onProjectListProjectsWithDevice
projectListDomains onProjectListDomains
requestGeneric onRequestGeneric
subscribeLogs onSubscribeLogs
setLogPriority onSetLogPriority

Both upon successful completion of the request or in case of an exception the onRead function is bound to the channel again, maintaining the connection of the client to the gui-server.

Parameters
  • e: holds an error code if the eventloop cancel this task or the channel is closed
  • channel:
  • info:

void setTimeout(karabo::xms::SignalSlotable::Requestor &requestor, const karabo::util::Hash &input, const std::string &instanceKey)

Sets the appropriate timeout to a Requestor

If input has a “timeout” key, set the maximum value of that and the gui server timeout on the requestor, except if input.get<std::string>(instanceKey) is one instance of the classes in “ignoreTimeoutClasses”.

void forwardReconfigureReply(bool success, WeakChannelPointer channel, const karabo::util::Hash &input)

Callback helper for onReconfigure

Parameters
  • success: whether call succeeded
  • channel: who requested the call
  • input: will be copied to the key input of the reply message

void forwardHashReply(bool success, WeakChannelPointer channel, const karabo::util::Hash &info, const karabo::util::Hash &reply)

Callback helper for generic actions called by the gui server.

Parameters
  • success: whether call succeeded
  • channel: who requested the call
  • info: the input info Hash
  • reply: the reply from the remote device or an empty Hash on failure

void onRequestGeneric(WeakChannelPointer channel, const karabo::util::Hash &info)

Request a generic action internally. Generic interface to call slots that take a single Hash as argument and reply with a single Hash.

Parameters
  • channel: from which the request originates
  • info: is a Hash that should containing the slot information.
    • type: requestGeneric
    • instanceId: the instanceId to be called
    • slot: the slot name of the instance
    • empty: if this property is provided, the input Hash is not bounced back
    • replyType (optional): the value of the key type in the reply to the client
    • timeout (optional) [s]: account for the slot call a specified timeout in seconds!
    • args: The Hash containing the parameters for the slot call

The forwardHashReply method is used to relay information to the gui client.

Returns:

In the default case, the return Hash is composed as follows::

  • success: boolean to indicate if the generic request was successful
  • reason: information on the error if not succesful otherwise empty
  • type: if specified in the input Hash, the replyType is used otherwise requestGeneric
  • request: the full input Hash information, including args
  • reply: The reply Hash of the instanceId

.. note: If the info Hash from the client provides a empty property, an empty Hash is send back to the client instead of the input Hash.

void onReconfigure(WeakChannelPointer channel, const karabo::util::Hash &info)

Calls the Device::onReconfigure slot on the device specified in info.

The info should have the following entries:

  • string at deviceId defines the target device
  • Hash at configuration is the configuration update to apply
  • bool at reply: if given and true, success or failure will be reported back to channel by a message of type reconfigureReply that contains
    • input: the Hash given here as info
    • success: bool whether reconfiguration succeeded
    • failureReason: string with failure reason
  • optional int at timeout: if a reply should be reported back, defines seconds of timeout. In case timeout is missing, timeout errors will report success as true but provides a failureReason mentioning the timeout

Parameters
  • channel: to potentially send “reconfigureReply”
  • info:

void forwardExecuteReply(bool success, WeakChannelPointer channel, const karabo::util::Hash &input)

Callback helper for onExecute

Parameters
  • success: whether call succeeded
  • channel: who requested the call
  • input: will be copied to the key input of the reply message

void onExecute(WeakChannelPointer channel, const karabo::util::Hash &info)

Calls a command slot on a specified device.

The info should have the following entries:

  • string at deviceId defines the target device
  • string at command is the slot to call
  • bool at reply: if given and true, success or failure will be reported back to channel by a message of type executeReply that contains
    • input: the Hash given here as info
    • success: bool whether execution succeeded
    • failureReason: string with failure reason
  • optional int at timeout: if a reply should be reported back, defines seconds of timeout. In case timeout is missing, timeout errors will report success as true but provides a failureReason mentioning the timeout
    Parameters
    • channel:
    • info:

void onInitDevice(WeakChannelPointer channel, const karabo::util::Hash &info)

Enqueues a future device instantiation. The relevant information will be stored in m_pendingDeviceInstantiations and initSingleDevice will take care of the actual instantiation when it is called by the instantiation timer.

Parameters
  • channel:
  • info:

void initSingleDevice(const boost::system::error_code &error)

Instructs the server at serverId to try initializing the device at deviceId as given in info. The reply from the device server is registered to the initReply callback.

NOTE: This should only be called by m_deviceInitTimer

Parameters
  • error:

void initReply(WeakChannelPointer channel, const std::string &givenDeviceId, const karabo::util::Hash &givenConfig, bool success, const std::string &message, bool isFailureHandler)

is the callback for the onInitDevice method. It is called upon reply from the device server handling the initialization request. The reply is passed to the calling channel in form of a hash message with type=initReply, deviceId, success and message fields.

Parameters
  • channel:
  • givenDeviceId:
  • givenConfig:
  • success:
  • message:

void onGetDeviceConfiguration(WeakChannelPointer channel, const karabo::util::Hash &info)

requests the current device configuration for deviceId specified in info and sends it back in a hash message on channel. The message contains the following fields: type=deviceConfiguration, deviceId and configuration. The configuration is retrieved using the device client interface.

Parameters
  • channel:
  • info:

void onKillServer(const karabo::util::Hash &info)

instructs the server specified by serverId in info to shutdown.

Parameters
  • info:

void onKillDevice(const karabo::util::Hash &info)

instructs the device specified by deviceId in info to shutdown.

Parameters
  • info:

void onStartMonitoringDevice(WeakChannelPointer channel, const karabo::util::Hash &info)

Registers a monitor on the device specified by deviceId in info Upon changes of device properties they will be forwarded to channel from a handler for changes in configurations of monitored devices that is kept internally by the gui-server.

Only one channel per client is maintained for passing monitoring information and only one monitor is registered by the gui-server for any number of clients monitoring deviceId.

After successful registration the current device configuration is returned by calling onGetDeviceConfiguration for channel.

Parameters
  • channel:
  • info:

void onStopMonitoringDevice(WeakChannelPointer channel, const karabo::util::Hash &info)

De-registers the client connected by channel from the device specified by deviceId in info. If this is the last channel monitoring deviceId the device is removed from the set of devices monitored by the device-client.

Parameters
  • channel:
  • info:

void onGetClassSchema(WeakChannelPointer channel, const karabo::util::Hash &info)

requests a class schema for the classId on the server specified by serverId in info. This is done through the device client. A hash reply is sent out over channel containing type=classSchema, serverId, classId and schema.

Parameters
  • channel:
  • info:

void onGetDeviceSchema(WeakChannelPointer channel, const karabo::util::Hash &info)

requests a device schema for the device specified by deviceId in info. This is done through the device client. A hash reply is sent out over channel containing type=deviceSchema, deviceId, and schema.

Parameters
  • channel:
  • info:

void onGetPropertyHistory(WeakChannelPointer channel, const karabo::util::Hash &info)

requests the history for a property on deviceId in the time range t0 and t1 as specified in info. Additional the maximum number of data points may be specified in maxNumData. The request is asynchronously sent to the device logger logging information for deviceId. The reply from the logger is then forwarded to the client on channel using the propertyHistory history callback.

Parameters
  • channel:
  • info:

void propertyHistory(WeakChannelPointer channel, bool success, const std::string &deviceId, const std::string &property, const std::vector<karabo::util::Hash> &data)

Callback for onGetPropertyHistory. It forwards the history reply in data for the property on deviceId to the client connected on channel. The hash reply is of the format type=propertyHistory, deviceId, property, success, data and failureReason which states the failure reason if any.

Parameters
  • channel:
  • success: whether the request succeeded
  • deviceId:
  • property:
  • data:

void onGetConfigurationFromPast(WeakChannelPointer channel, const karabo::util::Hash &info)

Request configuration for a device at point in time time as specified in info. The info hash can as well have a preview boolean which is send back to the client. The request is asynchronously sent to the device logger logging information for deviceId. The reply from the logger is then forwarded to the client on channel using the configurationFromPast history callback in case of success or configurationFromPastError for failures.

void configurationFromPast(WeakChannelPointer channel, const std::string &deviceId, const std::string &time, const bool &preview, const karabo::util::Hash &config, const karabo::util::Schema&, const bool configAtTimepoint, const std::string &configTimepoint)

Success callback for onGetDeviceConfiguration

void configurationFromPastError(WeakChannelPointer channel, const std::string &deviceId, const std::string &time)

Failure callback for onGetDeviceConfiguration

std::string getDataReaderId(const std::string &deviceId) const

Helper for history retrieval functions

Return
id of DataLogReader device to ask for history
Parameters
  • deviceId: of the device whose history is searched for

void onSubscribeNetwork(WeakChannelPointer channel, const karabo::util::Hash &info)

registers the client connected on channel to a pipe-lined processing channel identified by channelName in info in case subscribe is true. In case the pipe-lined processing channel is already connected to the gui-server no futher action is taken. Otherwise, a new connection is opened, set to copy and dropping behaviour in case the gui-server is busy, and with a maximum update frequency as defined by the delayOnInput property of the gui server. Network data from the pipe-lined processing connection is handled by the onNetworkData callback.

In this way only one connection to a given pipe-lined processing channel is maintained, even if multiple gui-clients listen to it. The gui-server thus acts as a kind of hub for pipe-lined processing onto gui-clients.

If subscribe is set to false, the connection is removed from the list of registered connections, but is kept open.

Parameters
  • channel:
  • info:

void onSubscribeLogs(WeakChannelPointer channel, const karabo::util::Hash &info)

registers the client connected on channel to the system logs in case subscribe is true. If subscribe is set to false, the logs will not be sent to the client.

Parameters
  • channel:
  • info:

void onSetLogPriority(WeakChannelPointer channel, const karabo::util::Hash &info)

sets the Log priority on a server. The info hash should contain a priority string and a instanceId string.

Parameters
  • channel:
  • info:

void forwardSetLogReply(bool success, WeakChannelPointer channel, const karabo::util::Hash &input)

Callback helper for onSetLogPriority

Parameters
  • success: whether call succeeded
  • channel: who requested the call
  • input: will be copied to the key input of the reply message

void onRequestNetwork(WeakChannelPointer channel, const karabo::util::Hash &info)

Receives a message from the GUI client that it processed network data from an output channel with name channelName in the info Hash.

Parameters
  • channel:
  • info:

void onNetworkData(const std::string &channelName, const karabo::util::Hash &data, const karabo::xms::InputChannel::MetaData &meta)

handles data from the pipe-lined processing channels the gui-server is subscribed to and forwards it to the relevant client channels, which have connected via onSubscribeNetwork. The incoming data is forwarded to all channels connected to this pipe-lined processing channel using the following hash message format: type=networkData, name is the channel name and data holding the data.

Parameters
  • channelName: name of the InputChannel that provides these data
  • data: the data coming from channelName
  • meta: corresponding meta data

void sendSystemTopology(WeakChannelPointer channel)

sends the current system topology to the client connected on channel. The hash reply contains type=systemTopology and the systemTopology.

Parameters
  • channel:

void instanceNewHandler(const karabo::util::Hash &topologyEntry)

sends the current system topology to the client connected on channel. The hash reply contains type=systemVersion and the systemVersion.

Parameters
  • channel:

void instanceChangeHandler(const karabo::util::Hash &instChangeData)

Handles events related to instances: new instance, instance updated, instance gone.

: Its signature matches karabo::core::InstanceChangeThrottler::InstanceChangeHandler).

void devicesChangedHandler(const karabo::util::Hash &what)

Acts upon incoming configuration updates from one or more devices. It is called back by a monitor registered on the device client. The reconfiguration contained in the what hash is forwarded to any channels connected to the monitor by onStartMonitoringDevice.

The message type of the hash sent out is type=”deviceConfigurations”. The hash has a second first level key, named “configurations”, whose value is a hash with the deviceIds as keys and the configuration changes for the corresponding deviceId as values.

Parameters
  • what: A hash containing all the configuration changes that happened to one or more monitored devices since the last update. Each node under the key “configurations” has the ‘deviceId’ as key and the changed configurations as a value of type Hash.

void slotProjectUpdate(const karabo::util::Hash &info, const std::string &instanceId)

Called from projectManagers to notify about updated Projects

Parameters
  • info: the info hash containing the information about the updated projects
  • instanceId: the instance id of the project manager device

void slotDumpToLog()

Slot to dump complete debug info to log file

Same info as received from ‘slotDumpDebugInfo’ with empty input Hash

void slotNotify(const karabo::util::Hash &info)

Slot to send a notification message to all clients connected - replies empty Hash

Parameters
  • info: a Hash with following keys
    • ”message”: a string containing the notification type
    • ”contentType”: a string defining the type of notification as the GUI client understands it
      • ”banner” means message will go to the GUI banner. Therefore it will be stored in the “bannerMessage” property of the GuiServerDevice and sent to any client that connects.
      • other types will likely just be shown in a pop-up window of the client

void slotBroadcast(const karabo::util::Hash &info)

Slot to send a Hash to the GUI clients connected - replies empty Hash

WARNING: No checks are performed on this slot. This slot can possibly disconnect all clients. Do not use it unless you understand the risks.

Parameters
  • info: a Hash with at least the following keys.
    • ”message”: a Hash that will be sent to the client(s). It should contain a “type” string.
    • ”clientAddress”: a string containing the GUI client address as coded in the slotDumpDebugInfo results. If the value for this key is an empty string, all clients will be notified.

karabo::util::Hash getDebugInfo(const karabo::util::Hash &info)

Helper for ‘slotDumpToLog’ and ‘slotDumpDebugInfo’

void slotDisconnectClient(const std::string &client)

Slot to force disconnection of client. Reply is whether specified client found.

Parameters
  • client: string to identify client, as can be received via slotDumpDebugInfo(Hash(“clients”, 0))

void updateNewInstanceAttributes(const std::string &deviceId)

Called from instanceNewHandler to handle schema attribute updates which were received at initialization time. The slotUpdateSchemaAttributes slot is invoked if any updates are pending.

Parameters
  • deviceId: the instance id of the new device

void slotAlarmSignalsUpdate(const std::string &alarmServiceId, const std::string &type, const karabo::util::Hash &updateRows)

A slot called by alarm service devices if they want to notify of an alarm update updateType is a string of any of the following: init, update, delete, acknowledgeable, deviceKilled, refuseAcknowledgement

Parameters
  • alarmServiceId: the instance id of the service device
  • type: the type of the update: can be alarmUpdate, alarmInit
  • updateRows: the rows which should be updated. This is a Hash of Hashes, were the unique row indices, as managed by the alarm service are keys, and the values are Hashes of the form updateType->entry

entry is a Hash with the following entries:

timeOfFirstOccurrence -> string: timestamp of first occurrence of alarm trainOfFirstOccurrence -> unsigned long long: train id of first occurrence of alarm timeOfOccurrence -> string: timestamp of most resent occurrence of alarm trainOfOccurrence -> unsigned long long: train id of most resent occurrence of alarm needsAcknowledging -> bool: does the alarm require acknowledging acknowledgeable -> bool: can the alarm be acknowledged deviceId -> string: deviceId of device that raised the alarm property -> string: property the alarm refers to id -> the unique row id

it send the following Hash to the client (lossless)

Hash h(“type”, type, “instanceId”, alarmServiceId, “rows”, updateRows);

void onAcknowledgeAlarm(WeakChannelPointer channel, const karabo::util::Hash &info)

Called if the client wants to acknowledge an alarm, by sending a message of type “acknowledgeAlarm”

Parameters
  • channel: the channel the client is connected to
  • info: the message from the client. Should contain the unique row ids of the alarms to acknowledge. It is a Hash of Hashes of the same form as described for slotAlarmSignalsUpdate, where the keys give the unique row indices

void onRequestAlarms(WeakChannelPointer channel, const karabo::util::Hash &info, const bool replyToAllClients = false)

Called if a client sends a message of type “requestAlarms”

Parameters
  • channel: the channel the calling client is connected to
  • info: message passed from the client. It is a Hash that needs to contain a string field “alarmInstanceId”, which either contains a specifiy alarm service’s instance id, or an empty string. In the latter case a request for current alarms is forwarded to all known alarm services, otherwise to the specific one. Replies from the alarm services trigger calling “onRequestedAlarmsReply” asynchroniously.
  • replyToAllClients: If true, reply to all clients instead of only the requesting client.

void onRequestedAlarmsReply(WeakChannelPointer channel, const karabo::util::Hash &reply, const bool replyToAllClients)

Callback executed upon reply from an alarm service to “onRequestAlarms”. instanceId -> string: instance id of the replying alarm service alarms -> Nested Hash of form given in “slotAlarmSignalsUpdate”

Parameters
  • channel: the client channel the request came from, bound by “onRequestAlarms”
  • reply: reply from the alarm service, expected to contain fields
  • replyToAllClients: If true, reply to all clients

It sends out a Hash of form: Hash h(“type”, “alarmInit”, “instanceId”, reply.get<std::string>(“instanceId”), “rows”, reply.get<Hash>(“alarms”));

void onUpdateAttributes(WeakChannelPointer channel, const karabo::util::Hash &info)

Executed when the gui requests an update to schema attributes via the updateAttributes signal.

Parameters
  • channel: gui channel that requested the update
  • info: updated attributes, expected to be of form Hash(“instanceId”, str, “updates”, vector<Hash>) where each entry in updates is of the form Hash(“path”, str, “attribute”, str, “value”, valueType)

void onRequestedAttributeUpdate(WeakChannelPointer channel, const karabo::util::Hash &reply)

Callback for onUpdateAttributes

Parameters
  • channel: gui channel that requested the update
  • reply: reply from the device that performed the attribute update. Is of form Hash(“success” bool, “instanceId”, str, “updatedSchema”, Schema, “requestedUpdate”, vector<Hash>) where success indicates a successful update, instanceId the device that performed the update updatedSchema the new valid schema, regardless of success or not, and requestedUpdates the original update request, as received through onUpdateAttributes

void connectPotentialAlarmService(const karabo::util::Hash &topologyEntry)

Checks if an instance at instanceId is an alarmService and connects to its signals if it is.

Parameters
  • topologyEntry: the topology Hash, from which the class of instanceId will be deduced

void typeAndInstanceFromTopology(const karabo::util::Hash &topologyEntry, std::string &type, std::string &instanceId)

Returns the instance type and instance id from a topology entry

Parameters
  • topologyEntry: a Hash of the topology format
  • type: string which will afterwards contain type
  • instanceId: string which will be filled with the instance id

bool allowLock() const

This device may not be locked

Return
false

void registerPotentialProjectManager(const karabo::util::Hash &topologyEntry)

Checks if an instance at instanceId is a ProjectManager. If so, register it to the list of known project services

Parameters
  • topologyEntry: the topology Hash, from which the class of instanceId will be deduced

std::vector<std::string> getKnownProjectManagers() const

Return a list of project services known to this GUI server

Return

void onProjectBeginUserSession(WeakChannelPointer channel, const karabo::util::Hash &info)

Initialize a configuration database session for a user. The token should continue to be passed to subsequent database interactions to identify this session.

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void onProjectEndUserSession(WeakChannelPointer channel, const karabo::util::Hash &info)

End a configuration database session for a user.

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void onProjectSaveItems(WeakChannelPointer channel, const karabo::util::Hash &info)

Save items to the project database

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user - identifies the session
    • items: a vector of Hashes where each Hash is of the form:
      • xml: xml of the item
      • uuid: uuid of the item
      • overwrite: Boolean indicating behavior in case of revision conflict
      • domain: to write this item to. For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void onProjectLoadItems(WeakChannelPointer channel, const karabo::util::Hash &info)

Load items from project database

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user - identifies the session
    • items: a vector of Hashes where each Hash is of the form:
      • uuid: uuid of the item
      • revision (optional): revision to load. If not given the newest revision will be returned
      • domain: to load this item from. For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void onProjectListProjectManagers(WeakChannelPointer channel, const karabo::util::Hash &info)

Request the list of project manager devices known to the GUI server Will write to the calling channel a Hash where “type” = projectListProjectManagers and “reply” is a vector of strings containing the project manager device ids. For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

Parameters
  • channel: from which the request originates
  • info: is given for compatability with all other calls but not further evaluated.

void onProjectListItems(WeakChannelPointer channel, const karabo::util::Hash &info)

Request a list of the items present in a domain. Optionally, an item type filter can be specified

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user - identifies the session
    • domain: domain to list items from
    • item_types: a vector of strings indicating the itemtypes to filter for. For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void onProjectListDomains(WeakChannelPointer channel, const karabo::util::Hash &info)

Request a list of the domains in the database.

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user - identifies the session For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void onProjectUpdateAttribute(WeakChannelPointer channel, const karabo::util::Hash &info)

Update item attributes in the project database

Parameters
  • channel: from which the request originates
  • info: is a Hash that should contain:
    • projectManager: project manager device to forward request to
    • token: token of the database user - identifies the session
    • items: a vector of Hashes where each Hash is of the form:
      • domain: to load this item from
      • uuid: uuid of the item
      • item_type: indicate type of item which attribute should be changed
      • attr_name: name of attribute which should be changed
      • attr_value: value of attribute which should be changed For the reply written to channel see the documentation of karabo.bound_devices.ProjectManager

void forwardReply(WeakChannelPointer channel, const std::string &replyType, const karabo::util::Hash &reply)

Forward a reply from a remote slot call to a requesting GUI channel.

Parameters
  • channel: to forward reply to
  • replyType: type of reply
  • reply: the reply to forward

void forwardRequestReply(WeakChannelPointer channel, const karabo::util::Hash &reply, const std::string &origin)

Forward a reply from a remote slot call to a requesting GUI channel adding a token relevant to the callee to the response

Parameters
  • channel: to forward reply to
  • replyType: type of reply
  • reply: the reply to forward
  • token: generated by the calling client

bool checkProjectManagerId(WeakChannelPointer channel, const std::string &deviceId, const std::string &type, const std::string &reason)

Check if a given project manager identified by id is known in the distributed system

Return
true if the project manager id exists in the distributed system
Parameters
  • channel: to forward a failure message to if not
  • deviceId: of the project manager device
  • type: of the request

void onRequestFromSlot(WeakChannelPointer channel, const karabo::util::Hash &info)

Calls the request slot on the device specified by deviceId in info with args given in info.args and returns its reply.

Parameters
  • info:

void onRequestFromSlotErrorHandler(WeakChannelPointer channel, const karabo::util::Hash &info, const std::string &token)

Error handler to be called in case of remote errors resulting from requests.

std::string getChannelAddress(const karabo::net::Channel::Pointer &channel) const

Utility for getting a “name” from client connections.

void tryToUpdateNewInstanceAttributes(const std::string &deviceId, const int callerMask)

Possibly update schema attributes on device

void onUpdateNewInstanceAttributesHandler(const std::string &deviceId, const karabo::util::Hash &response)

Response handler for updating schema attributes on device

bool skipExecutionTimeout(const std::string &deviceId)

Helper Function to identify whether a device belongs to the timeout violation list TODO: remove this once “fast slot reply policy” is enforced

returns true if a .timeout() should be skipped on execution requestor

void recalculateTimingOutDevices(const karabo::util::Hash &topologyEntry, const std::vector<std::string> &timingOutClasses, bool clearSet)

Helper Function to recalculate the list of timeout violating devices from the list of offending classes TODO: remove this once “fast slot reply policy” is enforced

Private Static Attributes

const std::string m_errorDetailsDelim

In reported failure reasons, this delimiter comes between short message and details like a trace.

class IndexBuilderService
#include <FileLogReader.hh>

A singleton class for building logger indices from logger files. It calls karabo-idxbuild with a list of command line arguments.

Inherits from boost::enable_shared_from_this< IndexBuilderService >

Public Functions

void buildIndexFor(const std::string &commandLineArguments)

Build an index by calling karabo-idxbuild with the supplied command line arguments

Parameters
  • commandLineArguments:

Public Static Functions

static Pointer getInstance()

Return a pointer to a singleton instance of IndexBuilderService. If no instance exists one is created.

Return

Private Functions

bool allowLock() const

This device may not be locked

Return
false

class InfluxDataLogger

Inherits from karabo::devices::DataLogger

Public Functions

void preDestruction()

Override preDestruction from Device class

Protected Functions

void initializeLoggerSpecific()

Do some actions here that may require asynchronous logic … and, finally, startConnection() should be called This function may be overridden by derived classes but at the end the ‘startConnection’ function should be called as a last step of initialization

void flushImpl(const boost::shared_ptr<SignalSlotable::AsyncReply> &aReplyPtr)

“Flush” data accumulated in the internal cache to the external storage (file, database,…)

struct InfluxDeviceData

Inherits from karabo::devices::DeviceData

Public Functions

void handleChanged(const karabo::util::Hash &config, const std::string &user)

Called when configuration updates arrive for logging

Parameters
  • config: a Hash with the updates and their timestamps
  • the: user responsible for this update - if any

void login(const karabo::util::Hash &configuration, const std::vector<std::string> &sortedPaths)

Helper to store logging start event

Parameters
  • configuration: full device configuration received when logging starts
  • sortedPaths: full paths of configuration, sorted by increasing timestamp

void handleSchemaUpdated(const karabo::util::Schema &schema, const karabo::util::Timestamp &stamp)

Called when a Schema update arrive for logging

Parameters
  • schema: - the new one
  • stamp: - the timestamp to be assigned for that update

class InfluxLogReader

Inherits from karabo::devices::DataLogReader

Private Functions

void asyncDataCountForProperty(const boost::shared_ptr<PropertyHistoryContext> &context)

Triggers the retrieval of the number of data points for a given device property during a time interval.

Parameters
  • context:

void onDataCountForProperty(const karabo::net::HttpResponse &dataCountResp, const boost::shared_ptr<PropertyHistoryContext> &ctxt)

Handles the retrieval of the number of data points for an ongoing GetPropertyHistory process. Responsible for invoking the appropriate async method for retrieving the property values depending on the number of data points received.

Parameters
  • dataCountResponse:
  • context:

void asyncGetPropertyValues(const boost::shared_ptr<PropertyHistoryContext> &ctxt)

Triggers the retrieval of the property values in an ongoing GetPropertyHistory process.

Parameters
  • context:

void asyncGetPropertyValuesMean(const boost::shared_ptr<PropertyHistoryContext> &ctxt)

Triggers the retrieval of the property values mean in an ongoing GetPropertyHistory process. This is used when the number of available data points for the property is larger than the maximum requested by the slot caller and all values are scalar numbers. The UINT64 properties are included in this despite being reinterpreted as INT64 on the backend and possibly returning incorrect data.

Parameters
  • context:

void asyncGetPropertyValuesSamples(const boost::shared_ptr<PropertyHistoryContext> &ctxt)

Triggers the retrieval of the property values samples in an ongoing GetPropertyHistory process. This is used when the number of available data points for the property is larger than the maximum requested by the slot caller.

Parameters
  • context:

void onPropertyValues(const karabo::net::HttpResponse &valuesResp, const std::string &columnPrefixToRemove, const boost::shared_ptr<PropertyHistoryContext> &ctxt)

Handles the retrieval of the values of a property in an ongoing GetPropertyHistory process. Responsible for transforming the json formatted values received from InfluxDbClient into a vector of hashes suitable to be returned to the slot caller. Also responsible for replying to the slot caller.

Parameters
  • valuesResp:
  • columnPrefixToRemove:
  • context:

void onMeanPropertyValues(const karabo::net::HttpResponse &valuesResp, const boost::shared_ptr<PropertyHistoryContext> &ctxt)

Handles the retrieval of the values of a property in an ongoing GetPropertyHistory process. Responsible for transforming the json formatted values received from InfluxDbClient into a vector of hashes suitable to be returned to the slot caller. This function extends the functionality of onPropertyValues while keeping the property history protocol.

Also responsible for replying to the slot caller.

Parameters
  • valuesResp:
  • context:

std::string unescapeLoggedString(const std::string &loggedStr)

Unescapes a logged string. A logged string has its new lines mangled, then its double slashes escaped and then its double quotes scaped. This functions applies those transformations in the reverse order.

Return
The unescaped original string.
Parameters
  • loggedStr: The string as it has been escaped by the Influx Logger.

bool handleHttpResponseError(const karabo::net::HttpResponse &httpResponse, const karabo::xms::SignalSlotable::AsyncReply &asyncReply)

Handles a given Http response whenever it indicates an error.

In the InfluxDb client <-> server communication context, any response with a status code greater or equal to 300 is considered an error and will be handled by this method.

The error handling consists of sending the appropriate error reply to the caller of the InfluxLogReader slot affected by the error.

Return
true if the httpResponse indicated an error that has been handled. false if the httpResponse didn’t indicate an error.
Parameters
  • httpResponse: the response that potentially indicates an error.
  • asyncReply: the reply to be sent to the caller of the slot where the error happened.

karabo::util::Epochstamp toEpoch(unsigned long long timeFromInflux) const

Convert a time point from influx to karabo Epochstamp

class PropertyTest
#include <PropertyTest.hh>

The PropertyTest device includes all types Karabo knows about in it’s expected parameter section. It is a test device to assure changes to the framework do not result in broken types.

Inherits from karabo::core::Device<>

Private Functions

void orderTest_slotStart()

The order test started with this slot works as follows:

  • ’stringProperty’ defines the ‘other’ PropertyTest device supposed to send messages to us
  • ’int32Property’ defines how many messages it should send
  • the number of messages and our own id are transferred to the other device
  • we connect our ‘slotCount’ to the other’s ‘signalCount’
  • we call the other’s ‘slotStartCount’ which will trigger sending messages to us, alternating between direct calls to our ‘slotCount’ and emitting ‘signalCount’ with count arguments starting from 0
  • we keep track of all counts received and their order (so do not run with billions of counts!)
  • end of messaging is signaled to us via a call with count = -1
  • we publish the number of received messages and those counts (well, up to 1000 only) that are not in order as “orderTest.receivedCounts” and “orderTest.nonConsecutiveCounts”, respectively.

struct PropFileInfo
#include <FileLogReader.hh>

A compound structure holding data on an logger archive file.

Python Bound Service Devices