rocstatusupdater

Sends parseable status updates over the network.

Status wire format

The format is similar and compatible to the Log wire format. It is possible to use it over the same ZMQ links.

It consists of a two part ZeroMQ message with the following two parts:

ROCS<sensorId>
<status>

Where the <sensorId> ist a unique sensor name. It should be given hierachically and separated by dots (e.g. “mount.encoder” or “mount.encoder.1”.

<status> is a JSON-encoded object with current status information. The JSON object may have its on hierarchy, which continues the <sensorId> hierarchy. This means that the following two messages are equal:

ROCSmount.encoder.1
37.5

and:

ROCSmount.encoder
{'1': 37.5}

There is a tradeoff between both variants. The former allows for finer SUB filtering and the latter is more bandwidth efficient when multiple status updates occour at the same time.

class runmacs.roc.rocstatusupdater.RocStatusUpdater(destination=None, ctx=None)[source]

Allows to send ROC status update messages.

emit(sensorId, data)[source]

Send a status update message.

Parameters:
  • sensorIdstr containing the dot-separated prefix of the sensor
  • datadict or list or nested of both contaning updated values

To update cpu and memory usage of the host “foo”, one might send the data as follows:

updater.emit('system.foo', {'cpu': 0.3, 'memory': 0.7})

Which should be interpreted by the receiver as a partial status three like:

{'system':
    {'foo':
        {'cpu': 0.3, 'memory': 0.7}
    }
}
runmacs.roc.rocstatusupdater.statusUpdateIterator(source, mask='', ctx=None, timeout=None)[source]

Iterator over received status updates.

Parameters:
  • source – Source address or Endpoints instance of the broker.
  • mask – Prefix of the subtree of updates of interest (e.g. ‘system’ or ‘system.foo’), can be a list
  • ctx – ZeroMQ Context to use
  • timeout – Timeout after which an empty status is yielded in any case.

Printing all updates can be done like:

for msg in statusUpdateIterator(ep):
    print msg