Appearance
VBus Protocol Specification
Published by RESOL - Elektronische Regelungen GmbH.
Main contact: VBus Development Group (EMail: vbus@resol.de)
Revision History
| Version | Date | Author | Changes |
|---|---|---|---|
| 10 | 2015-10-20 | Daniel Wippermann | Added VBus protocol specification 3.0 |
| 11 | 2015-10-26 | Daniel Wippermann | Added VBus master schematic |
| 12 | 2016-01-28 | Daniel Wippermann | Fixed error in "Physical layer" section about "MARK" and "SPACE" |
| 13 | 2023-12-14 | Daniel Wippermann | Added "Block type packets" section |
Authors
- Guido Filler (EMail: Guido.Filler@resol.de)
- Daniel Wippermann (EMail: Daniel.Wippermann@resol.de)
- Waldemar Lind (EMail: Waldemar.Lind@resol.de)
- Christian Leuner (EMail: Christian.Leuner@resol.de)
- Youssef Aljahed (EMail: Youssef.Aljahed@resol.de)
- Henryk Wieczorek (EMail: Henryk.Wieczorek@resol.de)
- Sabine Käß (EMail: Sabine.Kaess@resol.de)
Introduction
The RESOL VBus is a half-duplex bus system used by RESOL electronic controllers to communicate with each other and – e.g. using a PC interface – with external components.
One module on the bus system is the master, all other modules are slaves.
Physical layer
The VBus physical interface comes in two flavors:
- a 2-wire connection providing the bus signal and partial power supply over the same wires
- a 4-wire connection providing separate wire pairs for the bus signal and power supply
The master supplies the bus system with electric energy using a constant current source. This allows partial power supply of slave modules as well.
For the 2-wire connection the maximum current can vary from 35 mA (older products) to 62 mA (newer products) and the maximum votage is capped at approx. 8,2 V.
For the 4-wire connection the maximum current is 35 mA and the maximum voltage is capped at approx. 5,5 V.
During transmission a module pulls the bus voltage to ground level (GND) using a transistor in order to send a logical „0“ (SPACE). To send a logical „1“ (MARK) the bus voltage has to be kept at the specified maximum level.
During reception a module uses an analog comparator to distinguish between the two states MARK and SPACE (see below for details). The voltage difference between MARK and SPACE is used as a hysteresis.
Most slave modules rectify the bus voltage to ensure reverse-polarity protection. Due to the voltage drop over the rectifier diodes the master and slave modules use different trigger voltages for MARK and SPACE detection.
Trigger voltages at the comparator input:
| Master | Slave | |
|---|---|---|
| MARK: U >= | 3,25 V | 2,25 V |
| SPACE: U <= | 3,00 V | 2,00 V |
Appendix A contains several VBus schematics for both master and slave.
This schemetic is designed for use with a supply voltage of VCCL = 3,3 V. To use a supply voltage of VCCL = 5.0 V the following resistor values have to be adjusted:
| R205 | R207 | |
|---|---|---|
| 3,3 V | 820 Ω | 1600 Ω |
| 5,0 V | 2200 Ω | 1600 Ω |
The 4-wire connection uses a JST connector with a pitch of 2.00 mm. The pinning is:
VBus Protocol
For data transmission and reception a UART is used in half-duplex mode with 9600 bits per second, 1 start bit, 8 data bits and one stop bits. Neither parity nor handshakes are used.
1 data byte = 1 start bit + 8 bit data + 1 stop bit = 10 bits must be transmitted to send 1 data byte
Timing for different baud rates:
| Baud rate | Time per data byte |
|---|---|
| 9600 (default) | 1041,67 µs |
| 19200 | 520,83 µs |
| 38400 | 260,42 µs |
| 57600 | 173,61 µs |
| 115200 | 86,80 µs |
Since the VBus is a single-master-system the communication timing is controlled by the master. The master pauses for short moments during the transmission to ensure that all bus-powered slaves have enough time to recharge. In addition to that slaves are only allowed to send data after they have been requested to do so by the master. After a master's request an appropriate time frame is reserved for the answer.
SYNC-Byte
Every VBus data stream starts with a synchronisation byte (SYNC-Byte):
0xAA or 170 decimal
The reception of a SYNC-Byte starts a new data stream. If the current reception was incomplete it will be cancelled and discarded. This happens as well whenever a byte is received that has its MSB (Most Significant Bit) set (its value is greater than 0x7F or 127 decimal). All received bytes up to the next SYNC-Byte are ignored.
Reception is complete if the data stream reaches its announced length without MSB or checksum errors. The data stream is then processed and reception starts with next SYNC-Byte.
Checksums
To detect communication errors the data stream is protected by one or more checksums. The data stream's length and amount of checksums are depending on several factors:
- protocol version
- announced amount of payload
Checksums can be calculated using the following C function:
unsigned char VBus_CalcCrc(const unsigned char *Buffer, int Offset, int Length)
{
unsigned char Crc;
int i;
Crc = 0x7F;
for (i = 0; i < Length; i++) {
Crc = (Crc - Buffer [Offset + i]) & 0x7F;
}
return Crc;
}
Septet-Bytes
During transmission of payload data care must be taken that no byte is transmitted with its MSB set. To ensure this the MSBs of up to seven payload bytes are extracted for the duration of the transmission into an addition MSB collection byte (called „Septet-Byte“) and transmitted separately. The extraction and re-injection are handled by the following C functions:
void VBus_ExtractSeptett(unsigned char *Buffer, int Offset, int Length)
{
unsigned char Septett;
int i;
Septett = 0;
for (i = 0; i < Length; i++) {
if (Buffer [Offset + i] & 0x80) {
Buffer [Offset + i] &= 0x7F;
Septett |= (1 << i);
}
}
Buffer [Offset + Length] = Septett;
}
void VBus_InjectSeptett(unsigned char *Buffer, int Offset, int Length)
{
unsigned char Septett;
int i;
Septett = Buffer [Offset + Length];
for (i = 0; i < Length; i++) {
if (Septett & (1 << i)) {
Buffer [Offset + i] |= 0x80;
}
}
}
A payload data block of four bytes would be transformed like this:
| Before | After | Description |
|---|---|---|
| 0xE8 | 0x68 | First payload byte, MSB (=1) is extracted to Septet-Bit 0 |
| 0x03 | 0x03 | Second payload byte, MSB (=0) is extracted to Septet-Bit 1 |
| 0xF4 | 0x74 | Third payload byte, MSB (=1) is extracted to Septet-Bit 2 |
| 0x01 | 0x01 | Fourth payload byte, MSB (=0) is extracted to Septet-Bit 3 |
| 0x05 | Septet-Byte |
Beginning of a VBus data stream
The first 6 bytes of a VBus data stream (starting with the SYNC-Byte) share the same structure for all protocol versions:
| Offset | Description |
|---|---|
| 0 | SYNC-Byte (0xAA or 170 decimal) |
| 1 | Destination address (low-byte) |
| 2 | Destination address (high-byte) |
| 3 | Source address (low-byte) |
| 4 | Source address (high-byte) |
| 5 | Protocol version |
Addresses are assigned by RESOL. Every module on the VBus has at least one address. Modules that have an adjustable sub-address use the four least significant bits for that. See VBus Specification for a list of known addresses.
The remaing data stream structure differs depending on the „Protocol version“ byte. The following values are valid:
| Value | Description |
|---|---|
| 0x10 or 16 decimal | Protocol version 1.0 |
| 0x20 or 32 decimal | Protocol version 2.0 |
| 0x30 or 48 decimal | Protocol version 3.0 |
| 0x31 or 49 decimal | Protocol version 3.1 |
Protocol version 1.0
VBus data streams of protocol version 1.0 (called „packets“ for short) are used for continous data exchange of measurement, control and balance values between a master and its slaves. Packets start with a 10 byte header that can announce a variable amount frames containing additional payload.
| Offset | Description |
|---|---|
| 0 | SYNC-Byte (0xAA or 170 decimal) |
| 1 | Destination address (low-byte) |
| 2 | Destination address (high-byte) |
| 3 | Source address (low-byte) |
| 4 | Source address (high-byte) |
| 5 | Protocol version (0x10 or 16 decimal) |
| 6 | Command (low-byte) |
| 7 | Command (high-byte) |
| 8 | Number of payload frames |
| 9 | Checksum for offset 1-8 |
The payload is split into blocks of four bytes and transmitted together with its Septet-Byte and a checksum as a „frame“.
| Offset | Description |
|---|---|
| i + 0 | First payload byte, MSB is extracted to Septet-Bit 0 |
| i + 1 | Second payload byte, MSB is extracted to Septet-Bit 1 |
| i + 2 | Third payload byte, MSB is extracted to Septet-Bit 2 |
| i + 3 | Fourth payload byte, MSB is extracted to Septet-Bit 3 |
| i + 4 | Septet-Byte for offset (i + 0) to (i + 3) |
| i + 5 | Checksum for offset (i + 0) to (i + 4) |
The header field „Command“ can be one of the following values:
| Command | Explanation |
|---|---|
| 0x0100 | Packet contains data for destination |
| 0x0200 | Packet contains data for destination, answer required |
| 0x0300 | Request answer of destination |
The contents of the payload is depending on three header fields:
- Source address
- Destination address
- Command
After the header was received without errors the contents of the payload can be processed based on those header fields:
- if the "Destination address" is
0x0015and the "Command" is0x0100, it is a "block type packet" (see below for details) - in all other cases the payload structure needs to be looked up based on the header's address / command combination
See VBus Specification for a list of known packets (address / command combinations).
A short packet may look like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-Byte |
| 1 | 0x11 | Destination address (low-byte) |
| 2 | 0x44 | Destination address (high-byte) |
| 3 | 0x10 | Source address (low-byte) |
| 4 | 0x66 | Source address (high-byte) |
| 5 | 0x10 | Protocol version |
| 6 | 0x00 | Command (low-byte) |
| 7 | 0x02 | Command (high-byte) |
| 8 | 0x01 | Number of payload frames |
| 9 | 0x21 | Checksum for offset 1-8 |
| 10 | 0x07 | First payload byte |
| 11 | 0x04 | Second payload byte |
| 12 | 0x0F | Third payload byte |
| 13 | 0x00 | Fourth payload byte |
| 14 | 0x00 | Septett for offset 10-13 |
| 15 | 0x65 | Checksum for offset 10-14 |
This packet is sent by module 0x6610 (RESOL Midi Pro) and is directed to module 0x4411 (RESOL HKM1) including command 0x0200 (Packet contains data for destination, answer required). These three components define the payload contents.
Block type packets
"Block type packets" are used to transfer certain information aimed for product-independent VBus accessories (like SD3 smart displays or AM1 alarm modules). Block type packets are marked as such by using a "Destination address" of 0x0015 and a "Command" of 0x0100 in the packet's header. The "Source address" can be ignored in that case.
The payload of a block type packet contains a sequence of self-describing block type sections (called "section" for short). Each section consists of a section header and optional section payload. The section header has a size of four bytes and is always aligned to a frame boundary (i.e. its payload offset is a multiple of four). The section header is structured as follows:
| Offset | Description |
|---|---|
| 0 | Number of payload frames belonging to this section |
| 1 | Type of this section |
| 2 | Reserved |
| 3 | Reserved |
This structure allows product-independent VBus accessories to only find the information they are interested in, skipping all other sections.
The following section types are defined:
| Type | Description | Element size |
|---|---|---|
| 0x01 | Temperatures | 2 |
| 0x05 | Heat quantities | 4 |
| 0x08 | Relay speeds | 1 |
| 0x0A | Smart Display | 8 |
| 0x0B | Error mask | 4 |
| 0x0C | Warning mask | 4 |
| 0x0D | Status mask | 4 |
An example block type packet's frame payload may look like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0x02 | Section #1: Number of payload frames belonging to this section |
| 1 | 0x0a | Section #1: Type of this section |
| 2 | 0x00 | |
| 3 | 0x00 | Section #1: End of section header |
| 4 | 0x03 | Section #1: first byte of section payload |
| 5 | 0x00 | .. |
| 6 | 0x08 | .. |
| 7 | 0x00 | .. |
| 8 | 0x00 | .. |
| 9 | 0x00 | .. |
| 10 | 0x00 | .. |
| 11 | 0x00 | Section #1: last byte of section payload |
| 12 | 0x01 | Section #2: Number of payload frames belonging to this section |
| 13 | 0x0b | Section #2: Type of this section |
| 14 | 0x00 | |
| 15 | 0x00 | Section #2: End of section header |
| 16 | 0x00 | Section #2: first byte of section payload |
| 17 | 0x00 | .. |
| 18 | 0x00 | .. |
| 19 | 0x00 | Section #2: last byte of section payload |
| 20 | 0x04 | Section #3: Number of payload frames belonging to this section |
| 21 | 0x08 | Section #3: Type of this section |
| 22 | 0x00 | |
| 23 | 0x00 | Section #3: End of section header |
| 24 | 0x00 | Section #3: first byte of section payload |
| 25 | 0x00 | .. |
| 26 | 0x00 | .. |
| 27 | 0x00 | .. |
| 28 | 0x00 | .. |
| 29 | 0x00 | .. |
| 30 | 0x00 | .. |
| 31 | 0x00 | .. |
| 32 | 0x00 | .. |
| 33 | 0x00 | .. |
| 34 | 0x00 | .. |
| 35 | 0x00 | .. |
| 36 | 0x00 | .. |
| 37 | 0x00 | .. |
| 38 | 0x00 | .. |
| 39 | 0x00 | Section #3: last byte of section payload |
| 40 | 0x01 | Section #4: Number of payload frames belonging to this section |
| 41 | 0x0c | Section #4: Type of this section |
| 42 | 0x00 | |
| 43 | 0x00 | Section #4: End of section header |
| 44 | 0x00 | Section #4: first byte of section payload |
| 45 | 0x00 | .. |
| 46 | 0x00 | .. |
| 47 | 0x00 | Section #4: last byte of section payload |
This example packet contains four sections:
- Type 0x0A ("Smart Display") with a payload length of 2 frames = 1 element of 8 bytes
- Type 0x0B ("Error mask") with a payload length of 1 frame = 1 element of 4 bytes
- Type 0x08 ("Relay speeds") with a payload length of 4 frames = 16 elements of 1 byte each
- Type 0x0C ("Warning mask") with a payload lenght of 1 frame = 1 element of 4 bytes
Protocol version 2.0
VBus data streams of protocol version 2.0 (called „datagrams“ for short) allow access to all values that can be adjusted using the module's menu system. It's primarily used for remote parameterization.
Each datagram has a length of 16 bytes and allows to access a single data point (adjustable value). Every data point has an ID. IDs are module and version dependant. A complete list of IDs would go far beyond the scope of the document.
| Offset | Explanation |
|---|---|
| 0 | SYNC-Byte (0xAA or 170 decimal) |
| 1 | Destination address (low-byte) |
| 2 | Destination address (high-byte) |
| 3 | Source address (low-byte) |
| 4 | Source address (high-byte) |
| 5 | Protocol version (0x20 or 32 decimal) |
| 6 | Command (low-byte) |
| 7 | Command (high-byte) |
| 8 | ID of data point (low-byte) |
| 9 | ID of data point (high-byte) |
| 10 | Value of data point (low-byte) |
| 11 | Value of data point |
| 12 | Value of data point |
| 13 | Value of data point (high-byte) |
| 14 | Septet for offset 8-13 |
| 15 | Checksum for offset 1-14 |
The header field „Command“ can be one of the following values:
| Command | Explanation |
|---|---|
| 0x0100 | Answer from module with requested value |
| 0x0200 | Write value, acknowledgement required |
| 0x0300 | Read value, acknowledgement required |
| 0x0400 | Write value, acknowledgement required |
| 0x0500 | VBus clearance by master module |
| 0x0600 | VBus clearance by slave module |
In regular intervals the master broadcasts a datagram containing command 0x0500. This allows slave modules to temporarily take over the bus timing. A PC issuing a parameterization has to wait for such a clearance datagram before starting to send datagrams to read or write the master's data points. On completion of the parameterization the PC sends a datagram containing command 0x0600 to return the bus timing control back to the previous master.
| Destination | Source | Command | ID | Value | Description |
|---|---|---|---|---|---|
| 0x0000 | 0x7210 | 0x0500 | 0 | 0 | Broadcast for clearance |
| 0x7210 | 0x0020 | 0x0300 | 0x1234 | 0 | PC reads value for ID 0x1234 |
| 0x0020 | 0x7210 | 0x0100 | 0x1234 | 750 | Master sends value 750 for ID 0x1234 |
| 0x7210 | 0x0020 | 0x0300 | 0x1235 | 0 | PC reads value for ID 0x1235 |
| … | … | … | … | … | … |
| 0x0020 | 0x7210 | 0x0100 | 0x3456 | 12 | Master sends value 12 for ID 0x3456 |
| 0x7210 | 0x0020 | 0x0600 | 0 | 0 | PC returns bus timing to master |
Protocol version 3.x
VBus data streams of protocol version 3.x (called "telegrams" for short) are used to manage and evaluate digital sensors and actors. Telegrams start with a 8 byte header that can annouce a variable amout of additional payload.
| Offset | Description |
|---|---|
| 0 | SYNC-Byte (0xAA or 170 decimal) |
| 1 | Destination address (low-byte) |
| 2 | Destination address (high-byte) |
| 3 | Source address (low-byte) |
| 4 | Source address (high-byte) |
| 5 | Protocol version (0x30 or 48 decimal) |
| 6 | Command |
| 7 | Checksum for offset 1-6 |
The payload is split into blocks of seven bytes and transmitted together with its Septet-Byte and a checksum as a „frame“.
| Offset | Description |
|---|---|
| i + 0 | First payload byte, MSB is extracted to Septet-Bit 0 |
| i + 1 | Second payload byte, MSB is extracted to Septet-Bit 1 |
| i + 2 | Third payload byte, MSB is extracted to Septet-Bit 2 |
| i + 3 | Fourth payload byte, MSB is extracted to Septet-Bit 3 |
| i + 4 | Fifth payload byte, MSB is extracted to Septet-Bit 4 |
| i + 5 | Sixth payload byte, MSB is extracted to Septet-Bit 5 |
| i + 6 | Seventh payload byte, MSB is extracted to Septet-Bit 6 |
| i + 7 | Septet-Byte for offset (i + 0) to (i + 6) |
| i + 8 | Checksum for offset (i + 0) to (i + 7) |
Since the "Command" also determines the number of payload frames and their structure, the value of the corresponding header field "Command" contains an indication on how many frames are transmitted after the header, using the following structure:
| Bit | Description | Range |
|---|---|---|
| 0-4 | Command number | 0x00 - 0x1F |
| 5-6 | Number of payload frames | 0 - 3 |
| 7 | Always 0 | N/A |
The header field "Command" can have one of the following values:
| Value | Command number | Number of payload frames | Description |
|---|---|---|---|
| 0x01 | 0x01 | 0 | Request slave ID type 1 |
| 0x02 | 0x02 | 0 | Request slave ID type 2 |
| 0x23 | 0x03 | 1 | Slave ID response |
| 0x04 | 0x04 | 0 | Request slave data |
| 0x24 | 0x04 | 1 | Request slave data with control values |
| 0x25 | 0x05 | 1 | Slave data response |
| 0x26 | 0x06 | 1 | Change baud rate |
| 0x27 | 0x07 | 1 | Change sub address |
| 0x08 | 0x08 | 0 | Request extended data from slave |
| 0x69 | 0x09 | 3 | Slave response with extended data |
The reserved address space for sensors and actors using VBus protocol version 3.x is 0x2000 - 0x2F7F. The addresses use the following structure:
| Bit | Description | Range |
|---|---|---|
| 15, 7 | Always 0 (MSB) | N/A |
| 14-12 | Always 2 | N/A |
| 11-4 | Group address | 0-255 (partially) |
| 0-3 | Sub address | 0 - 15 |
Different types of sensors and actors each have their own group address. Currently the group address can have one of the following values:
| Value | Address pattern | Description |
|---|---|---|
| 0 | 0x2000 | Broadcast (all slaves from all groups) |
| 1 | 0x201? | VFD 1 - 20 l/min |
| 2 | 0x202? | VFD 2 - 40 l/min |
| 3 | 0x203? | VFD 2 - 40 l/min (fast) |
| 4 | 0x204? | VFD 5 - 100 l/min |
| 5 | 0x205? | VFD 10 - 200 l/min |
| 6 | 0x206? | RPD 0 - 10 bar |
| 7 | 0x207? | VFD 1 - 12 l/min |
| 16 | 0x210? | FlowCheck 0,5 - 20 l/min |
| 17 | 0x211? | VBus 3 Meteo |
| 18 | 0x212? | Pumpenansteuerung |
| 19 | 0x213? | GIR 7 |
All slaves have a sub address of 0 after power-up. The VBus master can then assign sub addresses to each of the slaves.
The following table list the possible combinations of destination address and respective slave groups:
| Destination address | Slave group |
|---|---|
0x2000 | All slaves with sub address 0 |
0x2GG0 | All slaves with group address GG and sub address 0 |
0x2GGS | The slave with group address GG and sub address S |
Adresses between 0x2001 and 0x200F are invalid.
The broadcast address 0x2000 can be used to force all slaves having sub address 0 to process the telegram. Responding slaves have to answer with their respective group address instead (e. g. 0x2010).
Slave detection and sub address assignment
All sensors and actors using VBus protocol version 3.x need to have the following information stored in the device permanently:
- VBus group address (7 bit)
- Product identifier (24 bit)
- Production week (6 bit)
- Consecutive number (17 bit)
This information is used to detect and configure slaves that are connected to a master.
When the master starts a slave detection cycle it performs the following operations:
- (optionally) switches the VBus supply voltage off and on again to reset all slaves to use sub address
0 - Sends telegram with command "Request Slave ID type 1" and waits for responses
- If a response from 2. was received, assign a sub address to the responding slave and repeat 2.
- Sends telegram with command "Request Slave ID type 2" and waits for responses
- If a response from 4. was received, assign a sub address to the responding slave and repeat 2.
The telegrams referred to in 2. and 4. can either be broadcasted (to address 0x2000) or group-casted (to address 0x2GG0 where GG is the respective group address). Only slaves that currently have a sub address of 0 and belong to the requested group (if not broadcasted) are allowed to respond to this type of requests.
But since the VBus is a single-master bus only one slave is allowed to answer this request at a time. This is achieved by calculating timeouts based on a slave specific device identifier value derived from the permanently stored values mentioned above.
The slave specific device identifier value and the corresponding timeouts are calculated using:
DeviceIdentifier = ProductionWeek * 2^17 + ConsecutiveNumber
TimeoutType1 = (DeviceIdentifier mod 100) * 8 + 50
TimeoutType2 = ((DeviceIdentifier mod 100) * 8 + ((DeviceIdentifier / 100) mod 100) * 8 + 50
For example: a sensor with the following permanently stored values:
ProductionWeek = 17
ConsecutiveNumber = 116406
calculates the following device identifier and timeout values:
DeviceIdentifier = 17 * 2^17 + 116406 = 2344630
TimeoutType1 = 30 * 8 + 50 = 290 ms
TimeoutType2 = 30 * 8 + 46 * 8 + 50 = 658 ms
If the slave receives a "Request slave ID type 1 / 2" request as a broadcast (to address 0x2000) or group-cast (to address 0x2GG0 where GG is the respective group address) it must wait for the calculated TimeoutType1 / TimeoutType2 respectively. If the slave receives another SYNC-byte during that wait it cancels its outstanding response and waits for another "Request slave ID" request. If no SYNC-byte was received while waiting for the timeout the slave is allowed to send its response.
Commands
Command 0x01 / 0x02: Request slave ID type 1 / 2
The master can send this telegram to a slave (or a group of slaves) to query their slave ID. Depending on the destination address the following slaves may respond:
| Destination address | Slaves | Timeout? |
|---|---|---|
0x2000 | All slaves having sub address 0 | yes |
0x2GG0 | All slaves having group address GG and sub address 0 | yes |
0x2GGS | The slave having group address GG and sub address S | no |
If a timeout is necessary the timeout values for both the slave response and the master's maximum wait timeout depend on the command:
| Timeout? | Command | Slave response timeout | Master maximum timeout |
|---|---|---|---|
| yes | 0x01 | TimeoutType1 | 1200 ms |
| yes | 0x02 | TimeoutType2 | 2200 ms |
| no | both | 0 ms | 80 ms |
The master's maximum timeout is the period the master has to wait for incoming responses after sending the request.
The request itself has no payload frames. An example telegram looks like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-byte |
| 1 | 0x10 | Destination address (low-byte) |
| 2 | 0x20 | Destination addres (high-byte) |
| 3 | 0x31 | Source address (low-byte) |
| 4 | 0x77 | Source address (high-byte) |
| 5 | 0x30 | Protocol version |
| 6 | 0x01 | Command |
| 7 | 0x76 | Checksum |
Command 0x23: Slave ID response
The slave sends this telegram as a response to a "Request slave ID type 1 / 2" telegram sent by the master.
Given a slave with the following permanently stored information:
- VBus group address: 0x2010
- Product identifier: 888888
- Production week: 17
- Consecutive number: 116406
The calculated device identifier is:
DeviceIdentifier = ProductionWeek * 2^17 + ConsecutiveNumber = 17 * 2^17 + 116406 = 2344630
An example telegram looks like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-byte |
| 1 | 0x31 | Destination address (low-byte) |
| 2 | 0x77 | Destination addres (high-byte) |
| 3 | 0x10 | Source address (low-byte) |
| 4 | 0x20 | Source address (high-byte) |
| 5 | 0x30 | Protocol version |
| 6 | 0x23 | Command |
| 7 | 0x54 | Checksum |
| 8 | 0x38 | Product identifier (low-byte) |
| 9 | 0x10 | Product identifier |
| 10 | 0x0D | Product identifier (high-byte) |
| 11 | 0x36 | Device identifier (low-byte) |
| 12 | 0x46 | Device identifier |
| 13 | 0x23 | Device identifier (high-byte) |
| 14 | 0x00 | Unused (0) |
| 15 | 0x1A | Frame Septet-Byte |
| 16 | 0x71 | Frame checksum |
Command 0x04 / 0x24: Request data from slave
The master send this telegram to request data from the slave and optionally send control values to it.
Depending on the destination address the following slaves may respond:
| Destination address | Slaves |
|---|---|
0x2000 | The slave having sub address 0 |
0x2GG0 | The slave having group address GG and sub address 0 |
0x2GGS | The slave having group address GG and sub address S |
It must be ensured that only one slave is elegible to respond even if the telegram is send to the boradcast or group-cast address.
An example telegram without control values / payload frames looks like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-byte |
| 1 | 0x10 | Destination address (low-byte) |
| 2 | 0x20 | Destination addres (high-byte) |
| 3 | 0x31 | Source address (low-byte) |
| 4 | 0x77 | Source address (high-byte) |
| 5 | 0x30 | Protocol version |
| 6 | 0x04 | Command |
| 7 | 0x73 | Checksum |
Command 0x25: Slave data response
The slave sends this telegram in response to a "Request data from slave" telegram sent by the master.
An example telegram looks like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-byte |
| 1 | 0x31 | Destination address (low-byte) |
| 2 | 0x77 | Destination addres (high-byte) |
| 3 | 0x10 | Source address (low-byte) |
| 4 | 0x20 | Source address (high-byte) |
| 5 | 0x30 | Protocol version |
| 6 | 0x25 | Command |
| 7 | 0x52 | Checksum |
| 8 | 0x68 | Data |
| 9 | 0x03 | Data |
| 10 | 0x69 | Data |
| 11 | 0x00 | Data |
| 12 | 0x00 | Data |
| 13 | 0x00 | Data |
| 14 | 0x00 | Data |
| 15 | 0x05 | Frame Septet-Byte |
| 16 | 0x26 | Frame checksum |
Command 0x26: Change baud rate
The master sends this telegram to prepare changing the baud rate. The following baudrates are supported:
- 9600 (default)
- 19200
- 38400
- 57600
- 115200
An example telegram looks like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-byte |
| 1 | 0x31 | Destination address (low-byte) |
| 2 | 0x77 | Destination addres (high-byte) |
| 3 | 0x10 | Source address (low-byte) |
| 4 | 0x20 | Source address (high-byte) |
| 5 | 0x30 | Protocol version |
| 6 | 0x25 | Command |
| 7 | 0x52 | Checksum |
| 8 | 0x00 | Baud rate (low-byte) |
| 9 | 0x42 | Baud rate |
| 10 | 0x01 | Baud rate |
| 11 | 0x00 | Baud rate (high-byte) |
| 12 | 0x00 | Unused (0) |
| 13 | 0x00 | Unused (0) |
| 14 | 0x00 | Unused (0) |
| 15 | 0x02 | Frame Septet-Byte |
| 16 | 0x3A | Frame checksum |
Command 0x27: Change slave sub address
The master sends this telegram to change the sub address part of the VBus address of a slave. All addressed slave check whether the product and device identifiers match their own and if it does set their sub address to the value at offset 14.
In VBus protocol version 3.0 slaves only needed to support changing the sub address from 0 to something non-zero. Starting with VBus protocol version 3.1 it is possible to change the sub address multiple times without having to switch power supply off and on again.
An example telegram looks like this:
| Offset | Value | Description |
|---|---|---|
| 0 | 0xAA | SYNC-byte |
| 1 | 0x10 | Destination address (low-byte) |
| 2 | 0x20 | Destination addres (high-byte) |
| 3 | 0x31 | Source address (low-byte) |
| 4 | 0x77 | Source address (high-byte) |
| 5 | 0x30 | Protocol version |
| 6 | 0x27 | Command |
| 7 | 0x50 | Checksum |
| 8 | 0x38 | Product identifier (low-byte) |
| 9 | 0x10 | Product identifier |
| 10 | 0x0D | Product identifier (high-byte) |
| 11 | 0x36 | Device identifier (low-byte) |
| 12 | 0x46 | Device identifier |
| 13 | 0x23 | Device identifier (high-byte) |
| 14 | 0x01 | New sub address |
| 15 | 0x1A | Frame Septet-Byte |
| 16 | 0x70 | Frame checksum |
Command 0x08 / 0x28: Request extended data from slave
TBD: for future use in protocol version 3.1
Command 0x69: Slave response with extended data
TBD: for future use in protocol version 3.1
Example telegram flow
The following topology is used in the examples:
- Slave 1
- VBus group address: 0x2010
- Product identifier: 888888
- Production week: 0
- Consecutive number: 1023
- Slave 2
- VBus group address: 0x2010
- Product identifier: 888888
- Production week: 0
- Consecutive number: 1099
- Slave 3
- VBus group address: 0x2020
- Product identifier: 888889
- Production week: 0
- Consecutive number: 1233
- Slave 4
- VBus group address: 0x2020
- Product identifier: 888889
- Production week: 0
- Consecutive number: 1333
The time ranges in the column "Time (ms)" represent transmission times for the telegram at 9600 bits per second. The times may vary for other baud rates.
Slave detection (without collision)
| Time (ms) | Master | Slave 1 | Slave 2 | Slave 3 | Slave 4 |
|---|---|---|---|---|---|
| (t1 + 0) ... (t1 + 8,4) | Request slave ID type 1 Master => 0x2010max. timeout = 1200 ms | ||||
| t1 + 8,4 | Timeout = 234 ms | Timeout = 842 ms | Not addressed | Not addressed | |
| (t1 + 242,4) ... (t1 + 260,2) | Slave ID response0x2010 => Master | Cancels timeout | |||
| t1 + 260,2 | Received slave ID from slave 1 | ||||
| ... | |||||
| (t2 + 0) ... (t2 + 17,8) | Change sub address Master => 0x2010Slave ID 1 | ||||
| t2 + 17,8 | Received sub adress | ||||
| ... | |||||
| (t3 + 0) ... (t3 + 8,4) | Request slave ID type 1 Master => 0x2010max. timeout = 1200 ms | ||||
| t3 + 8,4 | Has sub address | Timeout = 842 ms | Not addressed | Not addressed | |
| (t3 + 850,4) ... (t3 + 868,2) | Slave ID response0x2010 => Master | ||||
| t3 + 868,2 | Received slave ID from slave 2 | ||||
| ... | |||||
| (t4 + 0) ... (t4 + 17,8) | Change sub address Master => 0x2010Slave ID 2 | ||||
| t4 + 17,8 | Received sub adress | ||||
| ... | |||||
| (t5 + 0) ... (t5 + 8,4) | Request slave ID type 1 Master => 0x2010max. timeout = 1200 ms | ||||
| t5 + 8,4 | Has sub address | Has sub address | Not addressed | Not addressed | |
| t5 + 1208,4 | Timeout | ||||
| ... | |||||
| (t6 + 0) ... (t6 + 8,4) | Request slave ID type 2 Master => 0x2010max. timeout = 2200 ms | ||||
| t6 + 8,4 | Has sub address | Has sub address | Not addressed | Not addressed | |
| t6 + 2208,4 | Timeout |
Slave detection (with collision)
| Time (ms) | Master | Slave 1 | Slave 2 | Slave 3 | Slave 4 |
|---|---|---|---|---|---|
| (t1 + 0) ... (t1 + 8,4) | Request slave ID type 1 Master => 0x2020max. timeout = 1200 ms | ||||
| t1 + 8,4 | Not addressed | Not addressed | Timeout = 314 ms | Timeout = 314 ms | |
| (t1 + 322,4) ... (t1 + 340,2) | Slave ID response0x2020 => Master | Slave ID response0x2020 => Master | |||
| t1 + 340,2 | Received garbage from collision | ||||
| t1 + 1208,4 | Timeout | ||||
| ... | |||||
| (t2 + 0) ... (t2 + 8,4) | Request slave ID type 2 Master => 0x2020max. timeout = 2200 ms | ||||
| t2 + 8,4 | Not addressed | Not addressed | Timeout = 410 ms | Timeout = 418 ms | |
| t2 + 418,4 .. t2 + 436,2 | Slave ID response0x2020 => Master | Cancels timeout | |||
| t2 + 436,2 | Received slave ID from slave 3 | ||||
| ... | |||||
| (t3 + 0) ... (t3 + 17,8) | Change sub address Master => 0x2020Slave ID 3 | ||||
| t3 + 17,8 | Received sub adress | ||||
| ... | |||||
| (t4 + 0) ... (t4 + 8,4) | Request slave ID type 1 Master => 0x2020max. timeout = 1200 ms | ||||
| t4 + 8,4 | Not addressed | Not addressed | Has sub address | Timeout = 314 ms | |
| (t4 + 322,4) ... (t4 + 340,2) | Slave ID response0x2020 => Master | ||||
| t4 + 340,2 | Received slave ID from slave 4 | ||||
| ... | |||||
| (t5 + 0) ... (t5 + 17,8) | Change sub address Master => 0x2020Slave ID 4 | ||||
| t5 + 17,8 | Received sub adress | ||||
| ... | |||||
| (t6 + 0) ... (t6 + 8,4) | Request slave ID type 1 Master => 0x2020max. timeout = 1200 ms | ||||
| t6 + 8,4 | Not addressed | Not addressed | Has sub address | Has sub address | |
| t6 + 1208,4 | Timeout | ||||
| ... | |||||
| (t7 + 0) ... (t7 + 8,4) | Request slave ID type 2 Master => 0x2020max. timeout = 2200 ms | ||||
| t7 + 8,4 | Not addressed | Not addressed | Has sub address | Has sub address | |
| t7 + 2208,4 | Timeout |
Appendix A: Schematics
The following schematic shows an example VBus master:
The following schematics show example VBus slaves:
The following schematic shows an example VBus3 slave:
