my EMS+Wiki

[Th3M3]

Hi there,

I also started a wiki for my Buderus GB125 with EMS+.
Because I use another interface hardware I am actually only reading the bus.

Maybe there is something that helps here.
https://github.com/Th3M3/buderus_ems-wiki

[moustic999]

Hello,
I'm also working on the EMS+ decoding for RC300/RC310.
I'm filling corresponding page on this wiki.
It could be great to share our finding into a common place instead of duplicating the findings.
Do you have a Discord, so we could discuss our findings and validate them.

[Th3M3]

For me it seems not to be correct, that thelegram types >0xF0 are already EMS+ telegrams.

As I discovered here, the f9 telegram is used to query the setting parameters (minimal, maximal, default and current value) for the desired setting.

f7-type telegrams are used to show or hide settings on the RC, depending on previous settings.

f7 and f9 type telegrams can contain EMS+ types in their data, but the telegram header is in EMS format.

[moustic999]

EMS+ is an extension of EMS
so to define an EMS+ message, the EMS Type will be >=F0, then the EMS+TYPE Will be in the 2 first byte of message.

EMS

EMS+
<ems+type>

the type can be from F0 to FF, I'm not sure what it correspond
However I made some test and

F7 ... 01B9 is not the same at all than FF... 01B9

For now my priority is to get following type decoded and understood :
FF .. 01A5 this is the status of the HeatingCircuit 1 in thermostat. ( HC2.. HC4 are 01A6...01A8)
and
FF .. 01B9 control the mode and setting of temperature of HC 1 ( HC2 .. HC4 are 01BA .. 01BC)

01A5 is send cyclicly every 2 minutes completely in 2 telegrams ( offset 00->18, then offset 19 --> end)
01B9 is 21 data byte long.

F9 telegram are used by the Gateway to retrieve the current settings indeed. but is never used for Write.
I already seen how to decrypt them.

Do you have some example for F7 with the data decrypted and what is shown ?

i have tons in my logs :
(03:05:16.259) Gateway -> Thermostat, type 0x01FF telegram: 48 90 F7 01 01 FF 01 C4 (CRC=FE)
(03:05:16.286) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F7 01 FF 01 C4 00 (CRC=B6)
(03:05:16.613) Gateway -> Thermostat, type 0x11FF telegram: 48 90 F9 00 11 FF 01 9B 00 (CRC=C9)
(03:05:16.679) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F9 00 FF 01 9B 00 4F 00 00 00 01 00 00 00 01 00 1B 00 06 00 1B 00 01 (CRC=F7), #data=18

[Th3M3]

I understand the difference between EMS and EMS+ telegrams and I am sure that f7 type is not EMS+

As I have wrote in my wiki, the f7 telegram is sent out to hide or dis-hide some settings.

An example, on your Telegram 10 48 F7 01 FF 01 C4 00 (CRC=B6):

Because f7 is an EMS-Telegram, byte 4 is the offset.
The following three bytes (FF 01 C4) describes the dataset, where the settings are stored
And the last byte is a bitmask, which settings from the dataset should be visible.
Because the offset is 01 in your case, the the bitmask moves 1 byte higher and settings stored in offsets 08 to 14 from the EMS+ dataset 01 c4 are not visible on your RC (device 48)

Another example for my case:
The settings for external heat request are stored in EMS+ dataset 07 d0.

Sender	Target	Typ	Offset	EMS+ Typ	Byte Nr.	Comment
08	00	ff	00	07 d0
			00		7	Signal ext. heat request 00= 0-10V 01= on/off
			01		8	Setpoint ext. heatrequest at 0-10V 00= flow temperature 01= heater modulation (power)
					9	CRC
					10	BREAK (0x00)

On the RC310, I have changed the setting 'Signal external heat request' from on/off to 0-10V.
After that I saw telegram 08 00 f7 00 ff 07 d0 03 and the setting Setpoint ext. heatrequest at 0-10V appeared.
After changing back to on/off, telegram 08 00 f7 00 ff 07 d0 01 hides the Setpoint ext. heatrequest at 0-10V setting again.

Bitmask 01= 0 0 0 1 
Bitmask 03= 0 0 1 1 
             |  | |
             |  | Bit 0 masks Offset 0 of the telegram
             |  Bit 1 masks Offset 1 of the telegram
             Bits 2 & 3 are 0, because there are no more settings on this offsets```

[proddy]

That actually makes a lot of sense. One of my example telegrams I was given was 10 00 F7 00 FF 01 B9 35 19 so not sure what the last two bytes represent. They don't look like bit masks?

[Th3M3]

10 00 F7 00 FF 01 B9 35 19 has two masking bytes. The 01b9 type seems to have many offsets (data bytes).

35(hex) = 0 0 1 1 0 1 0 1 
19(hex) = 0 0 0 1 1 0 0 1

Because Offset is 00, the first maskbyte (35) masks Offsets 0-7 
and the following byte (19) masks the next (max.) eight offsets 8-14 of the given dataset:

So the Bitmask looks like this:

0 0 0 1 1 0 0 1 0 0 1 1 0 1 0 1 
      |                       |
      |                       Offset 00 of the 01b9 telegram
      Offset 0c of the 01b9 telegram

[proddy]

got it!

[Th3M3]

Ok, now lets concentrate on decoding the 01a5 telegrams:

01A5 is send cyclicly every 2 minutes completely in 2 telegrams ( offset 00->18, then offset 19 --> end)
01B9 is 21 data byte long.

I have the same telegram/data lengths, but I get them every 60sec.
Furthermore I get shorter telegrams with different offsets in between if the values changes.

Have a look into my telegrams

• At Offset 02 I am not sure what the values mean. For me it seems to be bits.
• Are you sure that offset 04 must be devided by 2 to get the target flow temp?
• Offsets 0a, 0b & 0c seems to be the working mode. In my case 0a and 0b has always the same value. I am not sure what eco, comfort1, comfort2, comfort3 is. I do not have the settings for this temperatures.

[moustic999]

Your explanation about F7 is really convincing. But I think is not yet complete.
This make sense in a Write or advertise scenario, but does not make sense in READ
Gateway send read request for these F7
in may example
(03:05:16.259) Gateway -> Thermostat, type 0x01FF telegram: 48 90 F7 01 01 FF 01 C4 (CRC=FE)
(03:05:16.286) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F7 01 FF 01 C4 00 (CRC=B6)

Gateway is generic and should support many kind of devices, to achieve that, it send a lot of message to see what is active/supported or not.
In my specific example, I wold like to think that gateway "ask": " Does this command is supported ( FF 01 C4 ) ?? "
answer is 00 --> not supported / not enabled.
then gateway will never send a read request on FF .. 01C4

does that make sense ?

I will collect more F7 line

[moustic999]

01A5 is send cyclicly every 2 minutes completely in 2 telegrams ( offset 00->18, then offset 19 --> end)
01B9 is 21 data byte long.

I have the same telegram/data lengths, but I get them every 60sec.
Furthermore I get shorter telegrams with different offsets in between if the values changes.

Have a look into my telegrams

01A5 is fired with offset 00 and offset 19 every 120 seconds.
This is the complete sending of the message.

it is also fired in between ( 60 seconds delay ) with offset 0D with 4 bytes data. That correspond to elapsed/remaining time in this mode.
This is only the subset of the message with changed timer value.

01A5 will be also fired if any change occurs, but these are not cyclic.

• At Offset 02 I am not sure what the values mean. For me it seems to be bits.

this Offset is quite strange, It is for sure bits, but not yet found their use ( working on it )

• Are you sure that offset 04 must be divided by 2 to get the target flow temp?

I'm pretty sure this offset is the target flow temp. I can see in logs that when this value change, it is also sent to the boiler.

• Offsets 0a, 0b & 0c seems to be the working mode. In my case 0a and 0b has always the same value. I am not sure what eco, comfort1, comfort2, comfort3 is. I do not have the settings for this temperatures.

0A has to be read in binary, it holds the mode and which level is ongoing
0B and 0C are current mode and next mode

technically in behind Bosch protocol is able to maintain 4 modes ( eco, comfort1, comfort2, comfort3 )

I have an RC300, when in Auto mode, I can schedule the heating to switch between 2 modes Eco or Comfort.

in my gateway it is seens as eco and Comfort2. I have seen Comfort3 used on a Junkers
Not sure how it is done on RC310 but I think it is almost same. I will check at a friend's home next time I'll visit him.
Maybe you are in Manual mode ? then these mode are ignored.

the temperature level associated to these mode can be set with FF.. 01B9 command chech in this Wiki ...

[moustic999]

I understand the difference between EMS and EMS+ telegrams and I am sure that f7 type is not EMS+

my setup is the following : MC10 (EMS), BC10 (EMS), RC300(EMS+), KM200(EMS+)

The gateway send lot of message to learn capabilities of others
and try to send this (see logs below ) to the boiler which is EMS only. the boiler just ignore these ! So I'm sure this is only used in EMS+ protocol.

These logs are the very first packet sent by the Gateway when you connect it to the bus :

(03:04:13.308) Gateway -> Boiler, type 0x01FF telegram: 48 88 F7 00 01 FF 03 A2 (CRC=DA)
(03:04:13.356) Gateway -> Boiler, type 0x01FF telegram: 48 88 F7 00 01 FF 03 A2 (CRC=DA)
(03:04:13.404) Gateway -> Boiler, type 0x01FF telegram: 48 88 F7 00 01 FF 03 A2 (CRC=DA)
(03:04:13.460) Gateway -> Boiler, type 0x01FF telegram: 48 88 F7 00 01 FF 03 A2 (CRC=DA)
(03:04:13.549) Boiler -> all, type 0x07 telegram: 08 00 07 00 03 01 00 00 00 00 00 00 01 00 00 00 00 (CRC=CA), #data=13
(03:04:13.954) Thermostat -> Boiler, type 0x35 telegram: 10 08 35 00 01 01 (CRC=00)
(03:04:14.030) Gateway -> Boiler, type 0xEF telegram: 48 88 EF 00 01 (CRC=56)
(03:04:14.062) Boiler -> 0x48, type 0xEF telegram: 08 48 EF 00 00 (CRC=65)
(03:04:14.598) Gateway -> Boiler, type 0x02 telegram: 48 88 02 00 0A (CRC=C2)
<--- Version(0x02) received
(03:04:14.621) Boiler -> 0x48, type 0x02 telegram: 08 48 02 00 73 05 09 00 00 00 00 00 00 00 (CRC=7A), #data=10
<--- Version(0x02) received
Boiler found. Model Nefit Topline Compact/Buderus GB162 (DeviceID:0x08 ProductID:115 Version:05.09)
(03:04:14.638) Gateway -> Boiler, type 0x01 telegram: 48 88 01 00 1B (CRC=DF)
(03:04:14.692) Boiler -> 0x48, type 0x01 telegram: 08 48 01 00 38 37 33 37 39 33 38 35 35 41 30 32 31 35 32 35 30 30 35 36 30 30 30 30 30 30 30 (CRC=B5), #data=27
(03:04:14.710) Gateway -> Boiler, type 0x01 telegram: 48 88 01 2B 1B (CRC=89)
(03:04:14.736) Boiler -> 0x48, type 0x01 telegram: 08 48 01 2B (CRC=50)
(03:04:14.758) Gateway -> Thermostat, type 0x02 telegram: 48 90 02 00 0A (CRC=02)
<--- Version(0x02) received
(03:04:14.801) Thermostat -> 0x48, type 0x02 telegram: 10 48 02 00 9E 0B 08 9E 00 00 00 00 00 (CRC=A0), #data=9
<--- Version(0x02) received
Thermostat found. Model RC300/RC310 (DeviceID:0x10 ProductID:158 Version:11.08)
(03:04:14.822) Gateway -> Thermostat, type 0x01 telegram: 48 90 01 00 1B (CRC=1F)
(03:04:14.898) Thermostat -> 0x48, type 0x01 telegram: 10 48 01 00 32 35 33 30 35 35 38 30 30 33 30 39 34 37 37 33 38 31 31 31 31 31 33 00 FF FF FF (CRC=32), #data=27
(03:04:15.126) Gateway -> Thermostat, type 0x01 telegram: 48 90 01 2B 1B (CRC=49)
(03:04:15.150) Thermostat -> 0x48, type 0x01 telegram: 10 48 01 2B (CRC=90)
(03:04:15.166) Gateway -> 0x09, type 0x02 telegram: 48 89 02 00 0A (CRC=CA)
<--- Version(0x02) received
(03:04:15.188) 0x09 -> 0x48, type 0x02 telegram: 09 48 02 00 44 02 03 (CRC=8D)
<--- Version(0x02) received
Device found. Model BC10/RFM20 Receiver with DeviceID 0x09, ProductID 68, Version 02.03
(03:04:15.206) Gateway -> 0x09, type 0x01 telegram: 48 89 01 00 1B (CRC=D7)
(03:04:15.223) 0x09 -> 0x48, type 0x01 telegram: 09 48 01 00 (CRC=73)
(03:04:15.246) Gateway -> 0x09, type 0x01 telegram: 48 89 01 2B 1B (CRC=81)
(03:04:15.264) 0x09 -> 0x48, type 0x01 telegram: 09 48 01 2B (CRC=58)
(03:04:15.286) Gateway -> Thermostat, type 0xEF telegram: 48 90 EF 00 01 (CRC=96)
(03:04:15.312) Thermostat -> 0x48, type 0xEF telegram: 10 48 EF 00 02 (CRC=FE)

afterwards gateway begins to send FF and F7 against almost all type code

2 specific message are broadcasted only once, which could interest you as well :

(03:04:16.341) Gateway -> all, type 0xFF0B telegram: 48 00 F7 00 FF 0B BC FF FF FF FF 1F (CRC=99)
(03:04:16.526) Gateway -> all, type 0xFF0B telegram: 48 00 F6 00 FF 0B BD 00 0F (CRC=8F)

For me this is enough to confirm >=F0 are EMS+

[moustic999]

• Are you sure that offset 04 must be divided by 2 to get the target flow temp?

I'm pretty sure this offset is the target flow temp. I can see in logs that when this value change, it is also sent to the boiler.

Here is the confirmation :

in the following 3 message type the byte (enclosed by ** ) showing the Target Temp Flow always change together :

(16:38:34.410) Boiler -> all, type 0x18 telegram: 08 00 18 00 **32** 01 F9 64 12 09 01 25 60 80 00 02 6E 01 B1 00 43 0D 2D 48 00 C8 00 02 00 (CRC=44) #data=25
<--- UBAMonitorFast(0x18)
(16:38:36.504) Thermostat -> Boiler, type 0x1A telegram: 10 08 1A 00 **32** 64 64 (CRC=A0) #data=3
(16:38:36.563) Thermostat -> all, type 0x0167 telegram: 10 00 FF 00 01 67 00 00 (CRC=AB) #data=2
(16:38:36.798) Thermostat -> all, type 0x01A5 telegram: 10 00 FF 00 01 A5 80 00 01 2A **32** 00 2A 20 02 00 03 03 01 02 00 01 84 00 00 11 01 03 FF FF 00 (CRC=BF) #data=25
<--- RCPLUSStatusMessage(0x1A5)

[Th3M3]

• Are you sure that offset 04 must be divided by 2 to get the target flow temp?

I'm pretty sure this offset is the target flow temp. I can see in logs that when this value change, it is also sent to the boiler.

Please read my question again. I did not ask if offset 04 is the target flow temp.
My question was if you are sure that the value must be devided by 2, because you wrote that on the wiki page.

[moustic999]

ah sorry, did not pay attention.
I checked twice, No the value must not be divided by 2, this is a copy/paste error in the wiki.
I changed.

[Th3M3]

Your explanation about F7 is really convincing. But I think is not yet complete.
This make sense in a Write or advertise scenario, but does not make sense in READ
Gateway send read request for these F7
in may example
(03:05:16.259) Gateway -> Thermostat, type 0x01FF telegram: 48 90 F7 01 01 FF 01 C4 (CRC=FE)
(03:05:16.286) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F7 01 FF 01 C4 00 (CRC=B6)

...

For me this is enough to confirm >=F0 are EMS+

@moustic999 You are right if you mean that f7 appears only on EMS+ devices.
But I think that it must be read as an classic EMS telegram because the data then makes sense.

In case of a f7 request, the data looks as followd:

sr = source ID
de = destination ID (read commands have the 8th bit set)
tp = type
of = offset
DATA = data block

sr de tp of DATA
-- -- -- -- ------------
48 90 F7 01 01 FF 01 C4

The DATA Section contains the requested length in first byte (started from the given offset) and an Dataset in the next three bytes to request the bitmask for this Dataset.

The destination replys and repeats in DATA section the queried dataset in three bytes and the requested Bitmask (in one byte, as requested) at last:

sr de tp of DATA
-- -- -- -- ------------
10 48 F7 01 FF 01 C4 00

[proddy]

made a reference in the Wiki to @Th3M3's page