Decoding burner status telegram 0x05000213

[fredlcore]

Hi everyone,

I'm calling for assistance in further decoding the "burner status" telegram 0x05000213 which the boiler sends whenever there is a change in the boiler's activity. Please take note that this only works in BSB, so if you're running BSB-LAN on an LPB- oder PPS-connection, please ignore this ;)...

The 0x05000213 telegram has a four byte payload, like 01 00 00 19 in this case:

DC 80 7F 0F 02 05 00 02 13 01 00 00 19 21 3F
HEIZ->ALL  INF      05000213 01 00 00 19

We currently know only parts of the meaning of each of the four payload bytes, and it would be great if users could look out or even log this telegram (activate "log broadcast", in case you have an SD-card).

This is what we know:

• Byte 0:
  -- Bit 2 (0x04): Burner active on stage 1
  -- Bit 4 (0x10): Burner active on stage 2 (only oil-fired heaters)

• Byte 1:
  See table below for confirmed values of byte 1.

This is what we don't know:

• Byte 0:
  -- Bit 0 (0x01): What does it mean? When does it occur? What is the cause of it?
  -- Bit 3 (0x08): On some heaters, this bit turns on when chimney sweeper mode is active, even before byte 0 / bit 2 comes on when the actual flame has been generated. To do: Check if this bit is also affected by other non-normal operation modes, e.g. manual mode.
  -- Bit 6 (0x40): I've had a few logs where instead of 0x04 byte 0 showed 0x44. The burner was still running, but it wasn't clear what bit 6 would stand for.

• Byte 1:
  -- Bit 7 (0x80): This bit seems to be set when some kind of "special operations" are active, see table below.
  -- Bits 0 to 3 (or 4?): Type of "special operation". N.B.: The codes shown on the display (e.g., "301" for manual mode) do not align with the bit values here. The assumption is that bits 0 to 3 or 4 indicate what kind of special operation is in place. This value seems to be the same as the number displayed after you subtract 300 from the displayed number. This means that bits 0 to 3 (or 4?) from byte 1 should result in the same value as subtracting 300 from the displayed number, i.e. 301 (manual mode) minus 300 results in 1, and 0x81 AND'ed with 0x1F also results in 1. Parameters where this has been confirmed are listed below.
  Here's a list of statūs found in a manual, but not all of these seem to work on all heaters:

Display value	Confirmed value byte 1	Status
-	00	No special operation / Kein Sonderbetrieb
301	81	Manual operation / Handbetrieb
302		STB test / STB Test
303	83	Chimney sweep function / Schornsteinfegerfunktion
304	84	Controller stop / Regler Stopp
		Combustion optimization low-fire / Verbrennungsoptimierung Kleinlast
		Combustion optimization high-fire / Verbrennungsoptimierung Großlast
		Emergency operation / Notbetrieb
308	88	Output test / Ausgangstest
309		Simulation outside temp / Simulation Außentemperatur
310		Alternative energy mode / Alternativenergie-Betrieb
311		Commissioning function / Inbetriebnahmefunktion
312		Deaeration function / Entlüftungsfunktion
		Dry fire function / Strömungsüberwachungstest
314	0E	Eco operation / Ökobetrieb
		Initializing / Initialisierung
		DHW Push active / Trinkwasser Push
		Release without source protection / Freigabe ohne Quellenschutz

Especially interesting here would be the value of byte 1 for "DHW push active" and "Release without source protection" because these would mean that byte 1 exceeds into the 0x10 or 0x90 range. On my heater, however, after initiating a DWH push, "DHW push active" was not indicated in byte 1, even though the DHW status parameter showed that the push is active.
So if you could "provoke" some of these status situations and check what kind of telegram is being sent, this would help a lot. For example, check if you have parameter 7154 ("Release without source protection / Freigabe ohen Quellenschutz") and see if changing that parameter temporarily results in a 0x05000213 telegram!

• Byte 2:
  -- Mostly seems to be 0x00, but 0x0C and 0x62 have also been sighted.

• Byte 3:
  -- Variying values, but mostly 0x09 in the lower nybble: 0x19, 0x29, 0x49, 0x59, 0x69. However, 0x00, 0x0B, 0x41 and 0x42 have also been observed.

Any help is highly appreciated and will straightforwardly improve the evaluation of this telegram. Thank you!

[uschindler]

Hi, in case anybody is interested. In some other issue @fredlcore and I discussed how to log the 3 bytes via MQTT. Basically the idea is to define a new parameter 100014 and do not decode it at all. There is a special type VT_CUSTOM_BYTE which allows to compine up to 8 bytes into a long and print it as a new parameter.

To get the three bytes of the bruner status telegram logged via MQTT (where you can record it and extract values in the history of e.g. Home Assiatnt modify your custom_defs.h file like that:

First add strings and the configuration of the custom type, just before cmd_tbl definition:

const char S_BURNER[] = "Brenner Status INF-Telegram";
const char E_BURNER[] = "\x00\x04";  // config of VT_CUSTOM_BYTE: the first byte is offset in telegram, second byte is length

and then add the new parameter into the cmd_tbl at the correct place:

{0x05000213,  VT_CUSTOM_BYTE,     10014, S_BURNER, sizeof(E_BURNER),   E_BURNER,     FL_RONLY, 255, 255},

After that listen on the MQTT topic (the ts adds timestamps, which helps to get a better overview when you begin to modify settings or enter "Schornsteinfegermode"):

# mosquitto_sub -u XXXX -P XXXX -v -t "BSB-LAN/+/+/10014/status" | ts

The result then looks like this:

Jan 18 13:31:41 BSB-LAN/0/24/10014/status 0
Jan 18 13:32:57 BSB-LAN/0/24/10014/status 262144
Jan 18 13:33:28 BSB-LAN/0/24/10014/status 0
Jan 18 13:35:52 BSB-LAN/0/24/10014/status 262144
Jan 18 13:36:23 BSB-LAN/0/24/10014/status 0
Jan 18 13:38:48 BSB-LAN/0/24/10014/status 262144
#### entering schornsteinfeger mode (while burner is at stage 1):
Jan 18 13:39:18 BSB-LAN/0/24/10014/status 819968
#### exit schornsteinfegermode
Jan 18 13:40:10 BSB-LAN/0/24/10014/status 262144
Jan 18 13:48:10 BSB-LAN/0/24/10014/status 262144
Jan 18 13:48:42 BSB-LAN/0/24/10014/status 0

Please note the bytes are in reverse order due to the way how it is decoded. The highest byte is the first one, lowest byte is at end.

In hex:

262144 = hex 04 00 00, binary 00000100 00000000 00000000
819968 = hex 0C 83 00, binary 00001100 10000011 00000000

The line is fine for first one, it is just "Burner Stufe 1", it has 0x04 in byte 0.
The second line has "0x83 = Schornsteinfeger" in byte 1 turned on, but why has it 0C in byte 0, which should not happen for gas only-burners!?

P.S.: It looks like theres a bug in above issue description: 0x04 is bit 2 (not 3), here the new one seen is 0x08 (which is bit 3) in addition to 0x04 (0x04+0x08 = 0x0C).

[fredlcore]

A lot of work for something that can be done with the built-in logging feature "log unknown bus messages" to SD card or flash memory. But if it helps you to eventually help me, that's fine.

BTW: The 8 bits in a byte are usually numbered from 0 to 7 to reflect the powers of 2, i.e. 0x10 = 16 = 2^4 = bit 4, not bit 5.

[uschindler]

When entering Schornsteinfeger Mode from no activity:

Jan 18 14:08:23 BSB-LAN/0/24/10014/status 0
Jan 18 14:08:57 BSB-LAN/0/24/10014/status 557824  => 00001000 10000011 00000000
Jan 18 14:09:18 BSB-LAN/0/24/10014/status 819968  => 00001100 10000011 00000000
Jan 18 14:09:28 BSB-LAN/0/24/10014/status 0

So looks like byte 0 goes from 00001000 to 00001100 (which comes in line with the "Flamme Symbol"; When Flamme Symbol turns on on display, bit 2 goes on (entering Brenner Stufe 1).

Bit 3 (0x04) is always on when Schornsteinfeger Mode is on, in addition to the documented values in byte 1 (see above).

[uschindler]

BTW: The 8 bits in a byte are usually numbered from 0 to 7 to reflect the powers of 2, i.e. 0x10 = 16 = 2^4 = bit 4, not bit 5.

I know this but in your original description it is inconsistent: 0x04 (burner state 1) is bit 2 and not bit 3 as written above.

[fredlcore]

That's one typo up there, thanks for highlighting that, but the rest of the text clearly refers to how I explained it in my previous comment. Can I assume that you follow my naming/counting convention when you speak of bits 3 and 4?

[uschindler]

That's one typo up there, thanks for highlighting that, but the rest of the text clearly refers to how I explained it in my previous comment. Can I assume that you follow my naming/counting convention when you speak of bits 3 and 4?

I think easiest is to look at the patterns exposed in the dumps of the three bytes in big endian order. I converted them to binary and hex.

A lot of work for something that can be done with the built-in logging feature "log unknown bus messages" to SD card or flash memory. But if it helps you to eventually help me, that's fine.

I have no access to the device and inserting a SD card is not easy possible! Logging it externally over the network with MQTT is much more straightforward. That's a different opinion than yours, but changing the custom_defs is way easier than walking down into heating room, opening bruner and attaching a non-existent SD card.

I have already posted many patterns seen, wil, try out your questions now.

It is already new that theres an additional bit in first byte when Schornsteinfeger Mode is on (0x08). Heater: Brötje WBS 22C (Gas).

[uschindler]

Let me just change by config to extract all 4 bytes. I haven't seen that theres a 4th byte, too. I will change it to predefined DWORD type.

[fredlcore]

changing the custom_defs is way easier than walking down into heating room, opening bruner and attaching a non-existent SD card.

You can easily log to the ESP32's flash memory. Unknown bus telegrams come by rather seldom, so it will neither wear down the flash, nor will it fill up even the limited flash memory available. It can simply be activated via the webinterface, no need to even leave your desk.

I think easiest is to look at the patterns exposed in the dumps of the three bytes in big endian order. I converted them to binary and hex.

I'm sorry, but what counts is not what is easiest, but that we talk about the same bits and bytes. And it would help me if you would just follow my naming/counting convention, whether that's easier or not.

It is already new that theres an additional bit in first byte when Schornsteinfeger Mode is on (0x08). Heater: Brötje WBS 22C (Gas).

Have you confirmed that this is only applicable for the chimney sweeper mode? Or is it also coming up in manual mode? Or when the burner is on?

[uschindler]

I'm sorry, but what counts is not what is easiest, but that we talk about the same bits and bytes. And it would help me if you would just follow my naming/counting convention, whether that's easier or not.

You want to have the four bytes? In which format is best: big endian or little endian?

Have you confirmed that this is only applicable for the chimney sweeper mode? Or is it also coming up in manual mode? Or when the burner is on?

Working on that. Additional bit 0x08 in first byte goes on when you toggle the chimney mode on the display unit. After a while the "flamme symbol" goes on and then also bit 0x04 turns on, resulting in 0x0C. The second byte is as documented above, so on display it shows "303-Schornsteinfeger" which is in line with your description 0x83.

I will try manual mode next, how to enter it with display unit?

[uschindler]

I now log all 4 bytes, will watch for the forth one (which is lowest nibble in big endian display as done by the printTelegram decoding for VT_CUSTOM_BYTE).

[fredlcore]

You want to have the four bytes? In which format is best: big endian or little endian?

The easiest way for me (and everyone else) to compare is how it is displayed in the log file. Endianness doesn't really apply here because it's four individual bytes that do not form a single number.
What is most important is that the naming convention is solid. Can you please check and if necessary edit your posts above so that the first bit is referred to as bit 0 and the last bit is referred to as bit 7? The same for the byte numbering, the first byte (in order of the telegram) is byte 0 and the last byte of the payload is byte 3.

Additional bit 0x08 in first byte goes on when you toggle the chimney mode on the display unit. After a while the "flamme symbol" goes on and then also bit 0x04 turns on, resulting in 0x0C.

That is interesting: Does it mean that there are two changes in the telegram? Because I don't see that in any of the logs from users that I have gone through. It's in most cases either 0x04 or 0x44 if the burner is on, irrespective whether it's in chimney mode or not. Only in very few cases, 0x08 (bit 3) is set.

[fredlcore]

In any case, the most relevant aspect would be byte 1 as it corresponds to the values displayed under "Sonderbetrieb" when pressing the "info" button, so this would come closest to a new parameter.

[uschindler]

I changed the above comments to use correct byte and bit numbering starting with 0 each.

The new bit 3 (0x08) in byte 0 is interesting, but looks like byte 1 corresponds to "Sonderbetrieb". Byte 2 is always 0 for me and byte 3 has random values. Will check which ones.

[uschindler]

Additional bit 0x08 in first byte goes on when you toggle the chimney mode on the display unit. After a while the "flamme symbol" goes on and then also bit 0x04 turns on, resulting in 0x0C.

That is interesting: Does it mean that there are two changes in the telegram? Because I don't see that in any of the logs from users that I have gone through. It's in most cases either 0x04 or 0x44 if the burner is on, irrespective whether it's in chimney mode or not. Only in very few cases, 0x08 (bit 3) is set.

If the burner is off and you trun on chimney mode, the telegram is sent 2 times:

• at first the new with 0x08 in byte 0 is enabled, in addition to the 0x83 in byte 1
• when the burner goes on in addition 0x04 in byte 0 is enabled (this turns the "flamme" on in display)
• when you turn of chimney mode, byte 0 and 1 go to zero within a few seconds.

Thats how it logged; I converted the decimal value to bytes manually. Byte 0, Byte 1, Byte 2 (byte 3 is still missing but it is more random), looking into those now.

Jan 18 14:08:23 BSB-LAN/0/24/10014/status 0
Jan 18 14:08:57 BSB-LAN/0/24/10014/status 557824  => 00001000 10000011 00000000
Jan 18 14:09:18 BSB-LAN/0/24/10014/status 819968  => 00001100 10000011 00000000
Jan 18 14:09:28 BSB-LAN/0/24/10014/status 0