EMS+ telegram type 0x100 higher then in raw data

[Th3M3]

It's been a long time since I dealt with the EMS bus of my then new Buderus (GB125, EMS+) heating system...

Now I have finally got myself an ESP32 to test this interesting project.
I have to say that flashing the firmware with the EMS-ESP-Flasher tool even worked straight out of the box.

When I now observe the bus with ems-esp, I notice the following:

For all EMS+ telegrams, the decoded EMS+ specific telegram type is 0x100 higher than in the raw data.

Example (observed in Telnet console):

• in raw format: [telegram] Rx: 10 0B FF 00 01 A5 <data>
• decoded: [emsesp] thermostat(0x10) -W-> me(0x0B), RC300Monitor(0x02A5), <data>

-> The EMS+ telegram type (raw 01 A5) is output as 02 A5.
What is the meaning behind this? The raw telegrams match my earlier observations.

I had a look into the docs, in section For Developers > The EMS protocol there is a description about the structure of an (EMS1.0) telegram. But I didn't found something EMS+ specific.

So I did some digging in the source code, and found something in telegram.cpp in lines 189, 195, 341 & 347.
But it doesn't quite make sense to me 🤔

[proddy]

It's by design. There was a recent remark also in #1212 (reply in thread)

We can think about whether to change it

[MichaelDvP]

It's the same scheme as Norberts1 uses and is described here on first page: https://github.com/norberts1/hometop_HT3/blob/master/HT3/docu/HT_EMS_Bus_messages.pdf

EMS telegrams have one byte address and telegram <src><dest><addr><offset><data...>
EMS+ have 3 byte address <src><dest><addr0><offset><addr1><addr2><data...>
where addr0 is 0xFF for data, 0xF7 for menu entry and 0xF9 for parameters (0xF6 also seen sometimes).
As we only deal with data (add0 = 0xFF) we store the addr as 2 byte.
For an ems+ address 0x000C (IPM Settings) we need to know that it is send as ems+ and not ems, so we store as 0x010C and subtract the 0x0100 before sending.
The correct way is to store all telegrams adresses as 3 byte, 0xFF000C for the IPM, but we always try to save memory.