...
| Code Block | ||
|---|---|---|
| ||
{
"data_object":{
"do_type":"TMA",
"do_station":12,
"do_address":71,
"do_value":-15,
"do_valid":1
}
} |
NB: if an attribute is not required, then it is not put in the output data object, which means that the output object structure always fits the protocol model object type.
HNZ command representation
This is the command representation of an HNZ message.
| Attribute | Description | Expected values | Mandatory |
|---|---|---|---|
| co_type | message type | TC, TVC | YES |
| co_address | message address | YES | |
| co_value | value | YES | |
| co_val_coding | coding of value | 0 or 1 | YES |
Example for a TC:
| Code Block | ||
|---|---|---|
| ||
{
"command_object":{
"co_type":"TC",
"co_address":325,
"co_value":1
}
} |
...
| Code Block | ||
|---|---|---|
| ||
{
"command_object":{
"co_type":"TC",
"co_address":49,
"co_value":1,
"co_val_coding":0
}
} |
NB: if an attribute is not required, then it is not put in the output data object, which means that the output object structure always fits the protocol model object type.
Path exploration
In redundant network configuration or generally in cases where several communication paths exist between one client and one server, the path checking exploration mechanism allows the client to try all the paths one by one without making any difference between them. The client uses the first available path. On disconnection this procedure starts again from the beginning.