Retagger
Retagger
The Retagger is a sequencer block, that allows rewriting of the Path in the Data and Definitions events based on the metadata received earlier via Definition messages.
Retagger can be used to alter the Path of the values logged by CDPLogger. Typically this altering is needed before sending the logged data to some log consolidation service (like the cloud log server). Retagger can do different manipulations for the Path. These can be simple modifications like prefixing the Path or changing the Path separator from the CDP Path separator i.e. dot (.) to some other separator like a slash (/). But the Retagger is mostly meant to be used for complete Path rewriting (i.e. retagging), based on tagging information that was gathered and attached to the logged values from different levels of the CDP system.
The following is a block diagram of the typical usage of the Retagger block:
Events
Name | Description | |
---|---|---|
Init | Resets the metadata information received via Definition events for all Paths. Should be sent to before new definitions will be (re)sent, to clear any previous definitions and collision counters. Inited event is emitted after the reset is done. | |
Inited | Output | Will be emitted after Init is done |
Definition | Should contain the metadata for a Path that needs to be re-tagged. Metadata can be in the form of semicolon-separated TagName=Value pairs in the Tags argument or it can be added via user-configurable arguments, tag-by-tag. The Definition events can be sent here for example from CDPLogger.ValueLogReader or CDPLogger.EventLogReader. The RetaggedDefinition will be emitted with the rewritten Path set into the argument specified by the RetagTo property. | |
RetaggedDefinition | Will be emitted on every incoming Definition event with the rewritten Path set into the argument specified by the RetagTo property. | |
Data | The event to be forwarded to the output RetaggedData event with the rewritten Path set into the argument specified by the RetagTo property. | |
RetaggedData | Will be emitted on every incoming Data event with the rewritten Path set into the argument specified by the RetagTo property. |
Arguments
Name | Appearance | Description |
---|---|---|
Path | Predefined input argument | Node Path. This value will be rewritten, based on received metadata and PathFormat and other retagging configuration properties, and set into the argument specified by RetagTo property for output events. |
Tags | Predefined input argument | Metadata (tags) for the Path in the form of semicolon-separated TagName=Value pairs. Is expected with Definition events. Will be passed to the output Definition event unchanged. |
TagSources | Predefined input argument | Metadata (tag) sources for the Path in the form of semicolon-separated TagName=SourcePath pairs. The metadata source information helps the Retagger to decide what tags collide and create correct collision counter values for tags listed in CountedTags. Is expected with Definition events. Will be passed to the output event unchanged. |
Tag name | Any number of user-configurable input arguments | Tags, whose name and value can be used for rewriting. These arguments can be then selected in PathFormat or CollisionPathFormat for retagging. Are expected with Definition events. The tag value can be overridden by the Tags TagName=Value list. Will be passed to the output event unchanged. |
Timestamp, Value, ValueType or other data | Any number of user-configurable input arguments | Optional Data event members. Will be passed to the output event unchanged. |
Properties
Name | Description |
---|---|
PathFormat | List of tags (i.e. arguments named as tag name) whose values to use for Path rewrite. Note, that when the tag value is empty for some Path, it will not be included in rewriting. When PathFormat is completely left empty, then the CollisionPathFormat will be used instead. |
CollisionPathFormat | When not empty, specifies the list of tags (i.e. arguments named as tag name) whose values to use for Path rewrite when two different Paths calculate the same rewritten path (i.e. collision happens, using PathFormat). Note, that similarly to PathFormat, when the tag value is empty for some path, it will not be included in rewriting. |
PathSeparator | Separator to use between tag values specified in PathFormat and CollisionPathFormat for Path rewrite |
CountedTags | List of tags (i.e. arguments named as tag name), that allowed to have multiple values at the same level. Retagger can then create a unique Path for different elements by suffixing the occurrence number to these tag values. CountedTags can be used both in PathFormat or in CollisionPathFormat. |
CountFormat | Printf-like format for the occurrence number suffix for tags specified in CountedTags |
RetagTo | Argument name that will be added or replaced with rewritten path value when sending output Definition or Data events |
Note: When the PathFormat or CollisionPathFormat property contains the Path argument, it will be used in the changed form, where the CDP default path separator i.e. dot (.) is replaced by the value specified in the PathSeparator property.
Example 1 - Path Rewriting Based On Tags
This example shows how to use the Retagger to rewrite the home automation system CDP application Paths to be somewhat easier to read and to be in a unified pattern, like /DATA/{optional roomname}/{devicename-counter#}/{metric} .
For that, the room and device tags should be added to the CDP nodes that correspond to rooms and devices accordingly, and the CDPLogger should be configured to find them. For example, let's assume the following tags for these CDP nodes have been configured:
CDP application node(s) | Tag(s) to be added |
---|---|
App.HeatB1, App.HeatB2 | room=Bedroom, device=Heater |
App.F1, App.F2 | device=Fan |
After these additional tags are added, the CDPLogger.ValueLogReader will start to emit these Tags with Definition events, for example for some logged values like this:
Path | Tags | TagSources |
---|---|---|
App.HeatB1.Power | label=Power;device=Heater;room=Bedroom | label=App.HeatB1.Power;device=App.HeatB1;room=App.HeatB1 |
App.HeatB1.Temp | label=Temp;device=Heater;room=Bedroom | label=App.HeatB1.Temp;device=App.HeatB1;room=App.HeatB1 |
App.HeatB2.Power | label=Power;device=Heater;room=Bedroom | label=App.HeatB2.Power;device=App.HeatB1;room=App.HeatB1 |
App.HeatB2.Temp | label=Temp;device=Heater;room=Bedroom | label=App.HeatB2.Temp;device=App.HeatB1;room=App.HeatB1 |
App.F1.Speed | label=Speed;device=Fan | label=App.F1.Speed;device=App.F1 |
App.F2.Speed | label=Speed;device=Fan | label=App.F2.Speed;device=App.F2 |
App.CPULoad | label=CPULoad | label=App.CPULoad |
Now, the Retagger can be configured to use these tag metadata like this:
Name | Description |
---|---|
prefix | Sequencer.Argument<string> to be added and set to the value /DATA, for constant prefix tag |
room,device,label | Empty Sequencer.Argument<string> to be added, for tag lookup |
PathFormat | Set to the value prefix;room;device;label |
PathSeparator | Set to the value / |
CountedTags | Set to the value device |
CountFormat | Set to the value -%d |
With the configuration and definitions above, and with the Definition event routed from CDPlogger, the Retagger will rewrite the Paths to the Definition and Data output events, like this:
Incoming Path in the input events | Rewritten Path in the output events |
---|---|
App.HeatB1.Power | /DATA/Bedroom/Heater-1/Power |
App.HeatB1.Temp | /DATA/Bedroom/Heater-1/Temp |
App.HeatB2.Power | /DATA/Bedroom/Heater-2/Power |
App.HeatB2.Temp | /DATA/Bedroom/Heater-2/Power |
App.F1.Speed | /DATA/Fan-1/Speed |
App.F2.Speed | /DATA/Fan-2/Speed |
App.CPULoad | /DATA/CPULoad |
Example 2 - Auto-Count Logged Values
For some simple setups, it can be enough to just auto-count logged sensor values without the need to add any tag information, to a pattern like /SENSORS/{metricname-2-digit-counter#}
For that, the Retagger can be configured to benefit pre-configured label tag included with every logged value, like this:
Name | Description |
---|---|
prefix | Sequencer.Argument<string> to be added and set to the value /SENSORS, for constant prefix tag |
label | Empty Sequencer.Argument<string> to be added, for tag lookup |
PathFormat | Set to the value prefix;label |
PathSeparator | Set to the value / |
CountedTags | Set to the value label |
CountFormat | Set to the value -%02d |
With the configuration above, and with the Definition event routed from CDPlogger, the Retagger will rewrite the Paths to the Definition and Data output events, like this:
Incoming Path in the input events | Rewritten Path in the output events |
---|---|
App.Signal | /SENSORS/Signal-01 |
App.Comp.Signal | /SENSORS/Signal-02 |
App.Comp.Subcomp.Signal | /SENSORS/Signal-03 |
Example 3 - Prefix and Replace Path Separator
For some simple cases, it can be enough to just prefix the CDP original Path with a prefix and with different path separator (slash).
For that, the Retagger can be configured to benefit PathSeparator replaced Path, like this:
Name | Description |
---|---|
prefix | Sequencer.Argument<string> to be added and set to the value /CDP, for constant prefix tag |
PathFormat | Set to the value prefix;Path |
PathSeparator | Set to the value / |
With the configuration above, and with the Definition event routed from CDPLogger, the Retagger will rewrite the Paths like the Definition and Data output events, like this:
Incoming Path in the input events | Rewritten Path in the output events |
---|---|
App.Signal | /CDP/App/Signal |
App.Comp.Signal | /CDP/App/Comp/Signal |
App.Comp.Subcomp.Signal | /CDP/App/Comp/CubComp/Signal |
See also CDP Logger, ValueLogReader, and EventLogReader.
Get started with CDP Studio today
Let us help you take your great ideas and turn them into the products your customer will love.