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

[fredlcore]

Yes, byte 1 is "Sonderbetrieb", but the values do not match the ones displayed on the heater (which start at 301). Also, most are in the 0x8X region, while at least one is in the 0x0X range. That's why it's important to enter each "Sonderbetrieb" state and see how this reflects in the value of byte 1.

As for bit 3, I would assume that it does not just mean "chimney sweeper mode" because in none of the other logs I have, this bit is set when that mode was entered. I saw it active in one log where the heater, however, was not in chimney sweeper mode. These observations come from both gas and oil fired heaters.

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

And that is why an actual log would be more helpful than MQTT logs because it would be easier to identify what else is going on in your heater at that moment. It's also strange that there is a 20 second gap between setting bits 3 and 2. Why would it take that long to ignite the burner? When I press the chimney sweeper button, the heater turns on immediately...

[uschindler]

It takes 20 seconds until it turns on after entering chimney mode. You can listen while you wait in front of it. When you look at "Betriebsanzeige FA" on parallel, you see that it goes through modes 2, 3, 4 and once it reaches 5 or 6 (not exactly sure because that goes fast), the burner turns on and the info message is sent with byte 0 bit 2 set. I found the documentation on Betriebsanzeige FA. It might be a good idea to create an enum from it in the definition of parameters:

https://forum.fhem.de/index.php?topic=29762.msg1328364#msg1328364

(I implemented this with a lookup table in Home Assistant)

[uschindler]

FYI, byte 3 is always 0x19 on my system, no changes - all the time.

[fredlcore]

So just to get it right: Bit 3 on your heater turns on immediately when you activate chimney sweeper mode and bit 2 turns on once it has reached burner control stage 5 or 6? And this can be reproduced each time? Then I'd have to check with some of the other users who have also done this kind of log observation before.

As for turning burner control stage into a parameter with "meaning", that's not possible because this information is not communicated by the heater in the parameter dump (other than for the error messages, for example). Some of the stages that are listed in the manual page you linked to would only apply to gas heaters, so it's not possible to generalize from that one. One would have to consult their manual to figure out what the values in the corresponding status parameter mean, but to assume that we have a "one size fits all" situation here is highly unlikely.

[uschindler]

Yes and that's reproducible. I can make a video showing me pressing the button and showing the display unit and my Home Assistant screen with the decoded hexadecimal values (plus secondly updated Betriebsanzeige FA).

Important: byte 1 changes instantly when turning on chimney mode, byte 0 bit 3 turns on immediately when I activate chimney sweeper mode and bit 2 turns on once it has reached burner control stage 5 or 6 (the flame 🔥 shows up in display, too). I can't give more information, the serial log is not giving more info. I can still record this if needed (using a journal.txt on esp directly).

I agree with the "Betriebsanzeige FA". I was not aware that the text strings for other enums or enum like stuff are coming from the LMU during the discovery/parameter dump (I have not looked into how this is done). Indeed the FA values are also not shown in the display unit, too.

Uwe

P.S.: I just add the human readable texts in my HomeAssistant with a lookup map in the "value_template" of the MQTT sensor. Of course, I could still turn it to an enum for my own hardware as the custom_defs is specific to my heater system.

[fredlcore]

Ok, thanks, I've added this information above, can you switch your heater to manual mode ("Handbetrieb"/"Notbetrieb") which is on my heater parameter 7140 (temperature to be set with parameter 2214)? This is actually the same as chimney sweeper mode, except it doesn't always run on full power. If byte 0/bit 3 also comes up here, then a test with eco mode ("Ökobetrieb", set parameters 7119/7120 to "on") would be a necessary comparison because there, byte 1 is not in the 0x80 range based on previous reports. If then byte 0/bit 3 is not affected, then it might correlate to those operation modes that are non-standard, maybe similar to byte 1 which could be in the 0x80 range for non-standard operation modes and in the 0x00 range for standard operation modes.

[uschindler]

Moin,
I tested most of the stuff already yesterday and I also installed the 4 bytes (in hexadecimal form) as a sensor in my HASS installation. Because of that I can see now the full log of changes and can also correlate them with "Betriebsanzeige FA" or display of temperatures. The output is now 4 pairs of hexadecimal numbers, as you like to have them :-)

Here the information and observations I made:

can you switch your heater to manual mode ("Handbetrieb"/"Notbetrieb") which is on my heater parameter 7140 (temperature to be set with parameter 2214)?

As you see, the same as with Chimney mode, the byte 0 bit 0x08 goes on instantly (together with 0x81 in byte 1) and with a bit of delay the main burner starts (see discussion yesterday). At end I switched of "Handbetrieb", but this just cleared the flag and the byte 1 went zero. The reason for this was possibly because the control unit wanted to heat anyways and left the burner on.

If byte 0/bit 3 also comes up here, then a test with eco mode ("Ökobetrieb", set parameters 7119/7120 to "on") would be a necessary comparison because there, byte 1 is not in the 0x80 range based on previous reports. If then byte 0/bit 3 is not affected, then it might correlate to those operation modes that are non-standard, maybe similar to byte 1 which could be in the 0x80 range for non-standard operation modes and in the 0x00 range for standard operation modes.

Unfortunately, my device does not have 7119 and 7120. It was built in 2007, maybe they had no "Öko mode" at this time. The LMU 74 is newer (2019), but theres nothing with ÖKO/Eco whatever anywhere in custom_defs, only in the status enums.

Maybe the whole thing is simpler than you expect. I have the feeling that byte 0 is mainly for displaying the small icons in the display unit. 0x04 is the "flam symbol". 0x08 looks like corresponding to the "wrench symbol" (Schraubenschlüssel). This symbol appears on my device whenever you enter any of the Sonderbetrieb modes.

I also enabled 7143 (Reglerstoppfunktion). The same happens here and also byte 1 goes to correct value according to your documentation:

Please also note in this example that after switching of handbetrieb the burner did not get off (so byte 0 left at 0x04), but bit 0x08 of byte 0 and also byte 1 changed to zero. This is a good indication that a value in byte 1 "Sonderbetrieb" is just replicated in bit 0x08 on my older heater to control the "Schraubenschlüssel" symbol on the display unit.

Here are some more observations:

• byte 2 is always 0x00 and byte 3 is always 0x19, I have never seen any other pattern there. Not sure what I can to to trigger a change.
• Trinkwasser Push does not trigger anything on those bytes. But for this to full test it, I need to switrch off Trinkwasser to get the temperature down first.
• It looks like the heater control unit sends the INF telegram regularily (every 10 minutes if nothing happened inbetween. This was visible during the night when everything was "sleeping" and no activity at all.
• If you define INF telegram as a parameter like 10014 of type CUSTOM_BYTES, offset=0, length=4 and you actively query it (using poll), the main unit responds with a standard answer. This allows you to poll it in case the INF telegram was lost due to high activity in BSB-LAN.
• If you define multiple parameters all with cmd_id=0x05000213, you can query them separately, but when the INF telegram comes in only the first one is updated. The reason for this is quite clear: When you query, the code prefers the cmd_tbl line with the queried parameter ID (first part of the if statement where it searches for the line), but when the INF telegram comes in, it has no parameter id, so it cannot update all parameters with same cmd_id it has to choose one - and it takes first one. This means: We can define separate custom parameters for the 4 bytes of the telegram type, but when it is not actively queried but reported by INF its is impossible to send MQTT messages for all parameter numbers. To change this the code in printTelegram has to be completely refectored.... At moment printTelegram does a lot of different things (it searches for the parameter numer in cmd_tbl, it populates the decodedTelegram, calls the MQTT handler).

I hope above helps a bit!

[uschindler]

It often happens that inf telegrams get lost when you actively query many parameters with MQTT poll. Therefore I disabled all my parameter polling temporarily when creating above logs.

Maybe that can be improved a bit. It looks like when the BSB-LAN code is in the loop of multi-poll with a series of parameters and waiting for responses one by one, it misses inf telegrams.

[fredlcore]

Thanks a lot, that correlation was one thing I was looking for. There are other telegrams that also control some of the icons on the heater, sometimes that is useful (as in byte 0 / bit 2) to actually determine a relevant status, whereas the wrench icon is not really useful.

Just to understand your first log for manual mode: This means that the burner was already running (0x04), then manual mode was activated (0x0C), then the burner turned off (0x08) maybe because the setpoint temperature was reached, and eventually manual mode was deactivated and all flags cleared. Is that correct?

Other users also had problems activating DHW push, but if it's not possible to activate it via the display unit, using parameter 10019 might be a possibility.

And yes, scanning of incoming telegrams is currently limited to one hit because that is what all regular parameters transmit. In this case, it may still be fine to do so because the burner status is the one that is relevant here. The operating modes do not change by themselves but have to be changed actively. However, I don't think it would require a complete refactoring of the function, I guess a loop of some sort would suffice. If we find another relevant piece of information that is not redundant and calls for immediate logging, then I'll look into that.

As for the missed INF telegrams, this can happen, but is less of an issue with the Due/ESP32 which have a hardware UART with several bytes of buffering. You can observe that after running /JB for example, there will be several telegrams coming in immediately after the task is completed.

[uschindler]

Hi,

Just to understand your first log for manual mode: This means that the burner was already running (0x04), then manual mode was activated (0x0C), then the burner turned off (0x08) maybe because the setpoint temperature was reached, and eventually manual mode was deactivated and all flags cleared. Is that correct?

You need to read the logs in screenshots from bottom to top (this is how HASS log file display looks like). It started with 00 00 (nothing) => 08 81 => 0C 81 and after tuning off, it stayed on 04 00. At first I though it was a missing telegram, but the FA Betriebsanzeige stayed on "10 - Heizbetrieb" for several minutes, like during a normal heating circle.

In the last case the 04 00 also was the last state after turning of "Reglerstopp", but it changed to 00 00 a second later.

Other users also had problems activating DHW push, but if it's not possible to activate it via the display unit, using parameter 10019 might be a possibility.

That's the same for me. I always use 10019 to trigger push (see discussion on FHEM forum initiated by that other person). The problem is if the boiler is on Nenntemperatur already, the push does nothing. Actually the TWW push can be seen in the other INF telegram which reported by parameter 10018 (telegram 0x31000212).

And yes, scanning of incoming telegrams is currently limited to one hit because that is what all regular parameters transmit. In this case, it may still be fine to do so because the burner status is the one that is relevant here. The operating modes do not change by themselves but have to be changed actively. However, I don't think it would require a complete refactoring of the function, I guess a loop of some sort would suffice. If we find another relevant piece of information that is not redundant and calls for immediate logging, then I'll look into that.

I fully agree.

As for the missed INF telegrams, this can happen, but is less of an issue with the Due/ESP32 which have a hardware UART with several bytes of buffering. You can observe that after running /JB for example, there will be several telegrams coming in immediately after the task is completed.

Will check this. At least for recording I got the situation with missing telegrams go away after I disabled all HASS cronjobs polling parameters:

• 4 parameters every 7 seconds -- after triggered by the telegram we are talking about here, which is great to get notified that the burner is starting. To me the 0x05000213 telegram mapped to parameter 10014 is just a signal (push) to increase frequency of polls for some parameters. I don't really interpret it. The only useful one may be the burner state, but that can also be seen in "Betriebsanzeige FA".
• every 30 seconds for a larger number of circa 8-12 parameters like Heizkreis temperature values,...

In case you ask: No HASS was not blocking itsself, also the moqsquitto_sub was not reporting the telegrams.

[uschindler]

I have one idea, that may help to figure out what the telegram bits mean: How about letting BSB-LAN send arbitrary INF telegrams and we check how the display unit reacts on it? So if you just send a telegram with bit 0x08 enabled, does it display the wrench?

[fredlcore]

That's a great idea - and can already be done using the (undocumented, due to its potentially dangerous effects) /Y URL command. It's syntax is /Yxx,yyyyyyyy,aabbccddeeff!zwhere xx is the message type (02 for INF), yyyyyyyy is the command ID, aabbccdd... is the payload and the optional !z the (decimal) destination id (for potential broadcast, this would be 127 for BSB and 255 for LPB).
I don't have physical access to the heater for some time, so I cannot check the results on the display, but for BSB, something like this should display the wrench on the display:
/Y02,05000213,08000019!127
and this the flame symbol:
/Y02,05000213,04000019!127
And this should clear it:
/Y02,05000213,00000019!127

In the same way, one could test the "special operations" by iterating through the values of byte 1, for example
/Y02,05000213,00810019!127
should display "301: Handbetrieb" on the display when pressing the info button.

[uschindler]

Hi, I had to enable debug mode first (set it to serial), but then the Y command worked. But the display unit did not react on the telegrams sent at all - on none of the above commands. I was already preparing myself to create a "Lichtorgel" with the display unit!!!

Maybe the display unit only accepts INF telegrams coming from bus device 0 and not our own bus id 66. To emulate an INF telegram from central unit we may need to fake the source bus address. If I have some time later I could try to change the code for the Y command.

[fredlcore]

That is possible (both that the display only accepts messages from device id 0 as well as for BSB-LAN to pretend that it's that). Just change BSB-LAN's own address in the web configuration from 66 to 0. Alternatively, use /P0,0,10 to change it temporarily until reboot (or diffferent /P call) to assume own ID 0 and default destination 10 (i.e. display unit) or 127 instead of 10 to make all sent messages become broadcast messages.

[uschindler]

Unfortunately I wasn't aber to triger any action on the display unit. :-( I disabled all polling in my HASS to keep the whole BSB-LAN silent (to not confuse anybody with illegal messages) and then I tried all possible combinations:

• (0,127)
• (0,10)
• (0,0) and adding !127 at end of /Y

The display unit seems to be immune to any telegram, also valid ones as seen before. Or maybe there's still something wrong with the telegram's content. Hard to tell. Giving up now. I restored all to (66,0).

I leave it up to you when you are back at home. Maybe you have a better idea.

[fredlcore]

What would be helpful is a serial/telnet log to see if the telegram is actually 1:1 the same as the one that is sent from the heater in the event of, for example, chimney sweeper mode etc.
I won't be near my heater until September, so that's gonna be a while ;)...

[uschindler]

What would be helpful is a serial/telnet log to see if the telegram is actually 1:1 the same as the one that is sent from the heater in the event of, for example, chimney sweeper mode etc. I won't be near my heater until September, so that's gonna be a while ;)...

Was about to do this, but later after dinner time.

[uschindler]

Hi, I recorded an example telegram after first disabling all polling again and setting BSB address to (0,127). The telegram I recorded was to enable Chimney Sweeper Mode. This was recorded, including hexdump (I enabled full debugging options on telnet console):

DC 80 0A 0E 07 0D 3D 05 19 00 08 A1 93 E9
DSP1->HEIZ QUR 7130.0  - Schornsteinfegerfunktion:
DC 8A 00 0B 06 3D 0D 09 2A 0C D1
HEIZ->DSP1 ANS 7130.0  - Schornsteinfegerfunktion: 0 - Aus
DC 80 0A 0D 07 0D 3D 09 2A 00 00 FE A0
DSP1->HEIZ SET 7130.0  - Schornsteinfegerfunktion: 1 - Ein
DC 8A 00 0D 03 3D 0D 09 2A 01 01 44 4D
Publishing to topic: BSB-LAN/0/19/7130/status
Payload: 1 - Ein
Successfully published...
HEIZ->DSP1 ACK 7130.0  - Schornsteinfegerfunktion:
DC 80 0A 0B 04 0D 3D 09 2A C3 2C
HEIZ->ALL  INF 10014.0  - Brenner Status INF-Telegram: 142802969
DC 80 7F 0F 02 05 00 02 13 08 83 00 19 B0 42
INF: Brennerstatus: 8
HEIZ->ALL  INF      2D000211 01 01 27 87 FF FF FF FF 02 21
DC 80 7F 15 02 2D 00 02 11 01 01 27 87 FF FF FF FF 02 21 9C E6
HEIZ->ALL  INF 10014.0  - Brenner Status INF-Telegram: 209911833
DC 80 7F 0F 02 05 00 02 13 0C 83 00 19 7A B3
INF: Brennerstatus: 12
DSP1->HEIZ QUR 7130.0  - Schornsteinfegerfunktion:
DC 8A 00 0B 06 3D 0D 09 2A 0C D1
HEIZ->DSP1 ANS 7130.0  - Schornsteinfegerfunktion: 1 - Ein
DC 80 0A 0D 07 0D 3D 09 2A 00 01 EE 81
DSP1->HEIZ SET 7130.0  - Schornsteinfegerfunktion: 0 - Aus
DC 8A 00 0D 03 3D 0D 09 2A 01 00 54 6C

But when trying to send the first telegram (its printed decimal as 142802969, which is hex 08830019, it says:

GET /Y02,05000213,08830019!127 HTTP/1.1
Bus destination already set to 127, no change necessary.
bus send failed
HEIZ->HEIZ 00 20000.0  - Brennerlaufzeit Stufe 1: len ERROR 0

It says "HEIZ->HEIZ" but this is just the update of the 20000 parameter about heating time and unfortunatley no dump of the sent hex bytes was printed. "len ERROR 0" may be related.

[fredlcore]

First of all, if you set the addresses to 0 and 127 in the configuration, you don't need the !127.
Secondly, the /Y function expects a response from the heater which the INF telegram does not provide. I have uploaded a fix to the repository to cover for that, so please update to the most recent version and try again.
As for the HEIZ->HEIZ line and the error, this is just because, likewise, print_telegram does not cater for a non-existent response from the heater. But that's just cosmetics, so won't fix that for now.

[uschindler]

Sure, I did not see that you fixed this already before me trying. It was a bit hidden in the more global cleanup: 42433bd#diff-228b1d315444a8461515ac5c0f97909b36aee0b7e5849a717da1c7348fbad5bcR5457

Will report soon.

[uschindler]

This is the output (this time also without "!127":

GET /Y02,05000213,08830019 HTTP/1.1
HEIZ->ALL  INF      00050213 08 83 00 19
DC 80 7F 0F 02 00 05 02 13 08 83 00 19 81 5B
HEIZ->HEIZ 00 20000.0 - Brennerlaufzeit Stufe 1: len ERROR 0

The original telegram as sent in response to the Chimeny Sweeper button was (copied from above):

HEIZ->ALL  INF 10014.0  - Brenner Status INF-Telegram: 142802969
DC 80 7F 0F 02 05 00 02 13 08 83 00 19 B0 42

I sent the telegram multiple times, no reaction on display unit. So there seems to be a slight difference.

[uschindler]

If you compare the dump above and below it looks like the 02 and 05 at beginning of message are out of order and the possible checksum at end is different, too.

[uschindler]

There seems to be some problem in code for the "Y" command that swaps the first two bytes. I modified my CURL command line and sent again:

GET /Y02,00050213,08830019 HTTP/1.1
HEIZ->ALL  INF 10014.0 - Brenner Status INF-Telegram: 142802969
DC 80 7F 0F 02 05 00 02 13 08 83 00 19 B0 42
HEIZ->HEIZ 00 20000.0 - Brennerlaufzeit Stufe 1: len ERROR 0

Now the telegram is 100% identical to the one sent by heating (including the checksum):

HEIZ->ALL  INF 10014.0  - Brenner Status INF-Telegram: 142802969
DC 80 7F 0F 02 05 00 02 13 08 83 00 19 B0 42

But the display unit still does not react. So it looks like theres some filtering in the hardware (maybe due to the direct connection of the display unit to the heater that blocks). Maybe the FB1 connector has no direct connection to the display unit and there is some routing/filtering on those bus parts by the LMU.

So faking the display unit to show arbitrary information is not working.

We should maybe just fix the bug in the code for the "Y" command. It consistently swaps the first two bytes of the cmd_id.

[uschindler]

The only possibility I see is to disconnect the BSB-LAN from the FB1 connector on the LMU and connect it in parallel directly on the display unit wires. But this requires time and is a bit risky for me (I don't want to deal with that very small connectors and thin wires there).

About the swapping "bug": Actually the first two bytes are actively "swapped" in the send code, see here:

BSB-LAN/BSB_LAN/src/BSB/bsb.cpp

Lines 564 to 568 in 4e3d066

	// first two bytes are swapped
	byte A2 = (cmd & 0xff000000) >> 24;
	byte A1 = (cmd & 0x00ff0000) >> 16;
	byte A3 = (cmd & 0x0000ff00) >> 8;
	byte A4 = (cmd & 0x000000ff);

So it looks like the "Y" code does not respect that or the "swapping" behaviour is different for INF telegrams - because the INF telegram as sent by the heater has the bytes NOT swapped. Luckily I was able to fix this in my CURL command, but this inconsistency in the code looks strange to me. I am not a specialist of the BSB protocol, so I let it be. I hope what I found out is still of use!

[fredlcore]

We should maybe just fix the bug in the code for the "Y" command.
I am not a specialist of the BSB protocol, so I let it be.

Exactly. Not everything that doesn't work the way one expects it to, is a bug. In this case, it's a way the protocol works: Some telegram types (such as querying a parameter) swap the first two bytes of the requested CommandID, some don't (such as when setting a parameter), and then some do it sometimes (as with INF). As the main use of /Y is to query parameters with non-standard payloads, the swapping is done in-code. For SET telegrams as well as certain INF telegrams, this reversal has to be taken care of when calling the URL, just like you did.

But the display unit still does not react. So it looks like theres some filtering in the hardware (maybe due to the direct connection of the display unit to the heater that blocks). Maybe the FB1 connector has no direct connection to the display unit and there is some routing/filtering on those bus parts by the LMU.

No, there is a direct connection and the display reacts to requests from non-heating-controller devices, such as BSB-LAN. You can simply test this by calling /6224!10 which will show you the model of the display. It wouldn't make sense to add some filtering logic to block some telegrams but not others. After all, the controller sends a broadcast telegram, so this information is not meant to be privy to the display.

There are two things that I can think of: For one, that the telegram does not make it physically to the bus. You can test this by simulating parameter 10000 and send the room temperature via the /Y command like this:
/Y02,2D3D0215,03C000
This should set the currently measured room temperature to 15 degrees. You can check this by looking at parameter 8740 (if you have a room unit, do it quickly, otherwise the room unit will send another telegram). And by the way, this is an INF telegram that requires byte swapping.

If this command has the desired effect, we know that there is no hardware issue on your side. In that case it could be that the symbols are controlled directly via the X-connector and the display unit doesn't handle that part of the telegram – or we are wrong in the assumption that this controls any icon. If someone has a QAA75, that would be interesting because this is a room unit that is actually a smarter version of the heater's display. Maybe the telegram is evaluated on the QAA75?

But apart from the icons, have you pressed the Info button to see if the special mode number has changed? Just in case this has gone unnoticed, we could at least check/verify the validity of the other modes.

[uschindler]

Hi,

No, there is a direct connection and the display reacts to requests from non-heating-controller devices, such as BSB-LAN. You can simply test this by calling /6224!10 which will show you the model of the display. It wouldn't make sense to add some filtering logic to block some telegrams but not others. After all, the controller sends a broadcast telegram, so this information is not meant to be privy to the display.

Yeah this is all strange.

There are two things that I can think of: For one, that the telegram does not make it physically to the bus. You can test this by simulating parameter 10000 and send the room temperature via the /Y command like this: /Y02,2D3D0215,03C000 This should set the currently measured room temperature to 15 degrees. You can check this by looking at parameter 8740 (if you have a room unit, do it quickly, otherwise the room unit will send another telegram). And by the way, this is an INF telegram that requires byte swapping.

:->

I send the room temperature updates all the time, so the bus communication works well. The INF telegram can be seen in 8740 (and various other parameters). Of course I did not send that with a raw INF, can try this later.

If this command has the desired effect, we know that there is no hardware issue on your side. In that case it could be that the symbols are controlled directly via the X-connector and the display unit doesn't handle that part of the telegram – or we are wrong in the assumption that this controls any icon. If someone has a QAA75, that would be interesting because this is a room unit that is actually a smarter version of the heater's display. Maybe the telegram is evaluated on the QAA75?

The X-connector has more wires than needed for BSB, so you could be right,

The telegram I sent was also including the Chimney Sweeper moder, so basically something should happen. If I enable chimney sweeper mode from the BSB-LAN via setting parameters or pressing the button on display unit makes it change to the "30x Sonderbetrieb" display without any user interaction.

But apart from the icons, have you pressed the Info button to see if the special mode number has changed? Just in case this has gone unnoticed, we could at least check/verify the validity of the other modes.

Checked that, also to turn on the light on the display unit :-). For safety I will give it another try.

I will report back once I found out something, this would have been a great way to test the 30x codes on byte 1.

[fredlcore]

Of course I did not send that with a raw INF, can try this later.

But that's what I was asking from you. Just because the "normal" way works doesn't mean that the /Y way also works.

makes it change to the "30x Sonderbetrieb" display without any user interaction

Ok, this may vary from device to device, but should at least be consistent within one and the same device.

this would have been a great way to test the 30x codes on byte 1.

Yes, indeed, that's why I don't want to give up too early. I'll also ask in the FHEM forum if someone with a QAA75 can help out.
Another idea I'd have would be to use 10 instead of 127 as the destination device. In that case, the display unit would be directly addressed, in case it ignores broadcast telegrams.

[uschindler]

I tried http://bsb-lan.home/6224!10, it does not give a response after three seconds timeout. On the other hand http://bsb-lan.home/6224!0 (or without the '0') gives the version number "LMU7" of the main unit.

Because I got a timeout I still have the feeling there seems to be some blocking on the bus.... I know technically this makes no sense as it is a bus and adding "routing devices" inbetween is not really useful (we're not in IP world).

And, http://bsb-lan.home/Y02,2D3D0215,03C000 works, 15 degrees at various places (and my HASS also showed it on the thermostat entity). Of course this telegram was not broadcast, so theres still a difference.

I will now try several more ways to send the "corrected telegram" and watch the unit.

[fredlcore]

That's interesting. I just had a look at the dump you sent me when you set up BSB-LAN, and indeed, your display doesn't reply to the dump generating commands. This must be somewhat special to your system because I also have a LMU7, and my display responds at least to those (very basic) calls that actually all Siemens devices have to support for decades - even those that do not support a device specific parameter list.

[uschindler]

My display unit is very old from 2007. There are newer ones available which have better contrast. Older ones are often exchanged when they start to flicker, but they are expensive. Mine also flickered for some time while the heater was very active (heating up TWW), but I solved the problem with some "aluminium foil" shield between heater and the display unit. The shield was added for the ESP32 to prevent inference introduced by the heater, but it helped to make the display unit lighting and LCD flatwires more stable. The problem is that between heater and the electronics is only the plastic shield and all heat is directly absorbed by the LMU and display unit.