Commit c07a0143 authored by Micha Mueller's avatar Micha Mueller
Browse files

Further fixes to README

parent 3004a8b1
......@@ -113,9 +113,10 @@ For communication between the different DCDB-components (database, dcdbpusher) t
2. mqttpart of entity (if supported by plugin, e.g. /BB)
3. mqttpart of group (e.g. /1122)
4. mqttsuffix (e.g. /3344)
Then the topic for the sensor is /00112233445566778899AA/BB/1122/3344.
# Plugins
# <a name ="Plugins">Plugins</a>
The core of dcdbpusher is responsible of collecting all the values read by the sensors and sending them to the database. However, the main functionality of the sensors comes from the various plugins. Every plugin corresponds to a special sensor functionality.
All the different plugins share some same general principles in common regarding the sensor structure and configuration. Those principles should also be obeyed when [writing own plugins](#WOP).
......@@ -125,15 +126,17 @@ All the different plugins share some same general principles in common regarding
3. Entities (optional)
2. There are no sensors on its own. Every sensor belongs to a group.
3. Multiple groups may or may not be aggregated by an entity. Entities can be optionally used by the plugin developer to aggregate groups which belong together, e.g. because they all query the same host.
4. Every hierarchical level is associated with some attributes. In the following are some hints on how one should decide which attributes are associated with which level. Also for every level the common base attributes are listed (with explanation), which are specified independently of a plugin:
1. Entities (if present) hold all attributes which are required to query the represented entity or all its associated groups have in common. As an entity is optional there are no mandatory base attributes. However, here are some examples which could be entity attributes: mqttPart, protocol-version, host address and port.
2. Groups hold all attributes which multiple sensors belonging to it share in common. Common for all plugins are:
* _interval_ (Time in [ms] between two consecutive sensor reads. Default is 1000[ms] = 1[s])
* _minValues_ (Minimum number of sensor reads the sensors in a group should gather before they are sent together to the database. Useful to reduce MQTT-overhead. Default is 1 (every sensor value is sent on its own))
* _mqttPart_ (Part for the [mqtt-topic](#MQTT) all sensors in this group should share in common)
* _default_ (One can define the name of a template sensor (see below) which values and sensors should be used as default)
4. Every hierarchical level is associated with some attributes. In the following are some hints on how one (when developing own plugins) should decide which attributes are associated with which level. Also for every level the common base attributes are listed (with explanation), which are specified independently of a plugin:
1. Entities (if present) hold all attributes which are required to query the represented entity or all its associated groups have in common. Common entity attributes:
* __default__ (One can define the name of a template group (see below) whose values and groups should be used as default)
* Other entity attributes could be: mqttPart, protocol-version, host address and port.
2. Groups hold all attributes which multiple sensors belonging to it share in common. Common group attributes:
* __interval__ (Time in [ms] between two consecutive sensor reads. Default is 1000[ms] = 1[s])
* __minValues__ (Minimum number of sensor reads the sensors in a group should gather before they are sent together to the database. Useful to reduce MQTT-overhead. Default is 1 (every sensor value is sent on its own))
* __mqttPart__ (Part for the [mqtt-topic](#MQTT) all sensors in this group should share in common)
* __default__ (One can define the name of a template group (see below) whose values and sensors should be used as default)
3. Sensors hold only those attributes which are necessary to uniquely identify the target sensor. Common base attributes:
* _mqttsuffix_ (to make its [mqtt-topic](#MQTT) unique)
* __mqttsuffix__ (to make its [mqtt-topic](#MQTT) unique)
5. Be aware that naming of sensor/group/entity is not fixed. A plugin developer can name them as he likes, e.g. counter/multicounter/host.
6. It is possible to define template groups or entities in the config file, but not template sensors (as a sensor should only consists of attributs which make him unique this would not be too useful). To specify a template group/entity simply prefix its definition with `template_` (see the example below). You can reference them later by using the `default` attribute. A template entity can consist of groups and these in turn can consist of sensors. When using a template, all of its attribute values are copied to the actual sensor. Copied attributes can be overwritten in the actual entity/sensor (some of them even should be overwritten, e.g. the mqttPart). However, groups/sensors associated with a template are copied to the actual entity/group and can NOT be overwritten. One can specify further groups/sensors which are then added to those copied from the template. Template entitys/groups itself or sensors within them are never used in live operation of the plugin. They are purely cosmetic for convenient configuration.
......@@ -225,6 +228,7 @@ entity ent1 {
...
```
One should have noticed the global section in the examples which was not mentioned before. In this section the use can (but is not obligated to) overwrite values from the `global.conf` for this plugin or specify other settings which are global for this plugin.
## <a name="IPMI">IPMI</a>
......@@ -442,6 +446,7 @@ Possible values for cntData:
* uncorrectableErrors
## <a name="WOP">Writing own plugins</a>
First make sure you read the [plugins](#Plugins) section.
Try out the `pluginGenerator/generatePlugin.sh` script!
TODO!
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment