search

Th3M3 / buderus_ems-wiki

EMS und EMS+ Telegramme
4 stars 1 forks source link

EMS+ : F7 messages investigation #1

Open moustic999 opened 5 years ago

moustic999 commented 5 years ago

to help you decoding this F7, here is the log I got : F7 Message for 01B9

(03:04:21.204) Gateway -> Thermostat, type 0x03FF telegram: 48 90 F7 00 03 FF 01 B9 (CRC=83)
(03:04:21.234) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F7 00 FF 01 B9 35 19 08 (CRC=87)

F7 message for 01A5

(03:04:21.956) Gateway -> Thermostat, type 0x0FFF telegram: 48 90 F7 00 0F FF 01 A5 (CRC=FF)
(03:04:21.993) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F7 00 FF 01 A5 DF FF F7 7F 1F (CRC=F2)

Request Content for 01A5 ( in 2 times because msg longer that MAX lenght)

(03:04:32.778) Gateway -> Thermostat, type 0x1401 telegram: 48 90 FF 00 14 01 A5 (CRC=80)
(03:04:32.845) Thermostat -> 0x48, type 0x01A5 telegram: 10 48 FF 00 01 A5 80 00 01 2C 29 00 2C 20 01 C8 03 03 01 01 C8 02 16 00 00 11 (CRC=34), #data=19
<--- RCPLUSStatusMessage(0x1A5) received
(03:04:32.866) Gateway -> Thermostat, type 0x1201 telegram: 48 90 FF 14 12 01 A5 (CRC=38)
(03:04:32.929) Thermostat -> 0x48, type 0x01A5 telegram: 10 48 FF 14 01 A5 01 03 FF FF 00 06 04 00 00 00 00 FF 64 4B 00 3C 01 FF (CRC=C9), #data=17
<--- RCPLUSStatusMessage(0x1A5) received

Request Content for 01B9

(03:04:35.058) Gateway -> Thermostat, type 0x1401 telegram: 48 90 FF 00 14 01 B9 (CRC=9C)
(03:04:35.124) Thermostat -> 0x48, type 0x01B9 telegram: 10 48 FF 00 01 B9 FF 2E 2C 26 20 03 00 FF FF 00 25 01 E1 20 01 0F 05 00 00 01 (CRC=68), #data=19

Hopefully it will help you to explain how it works and maybe find the use of many offset...

Th3M3 commented 5 years ago

So far I have seen the f7 telegram only in context with hiding or dis-hiding of settings on my RC310.

This means that the telegram appears to have a bit mask for displaying offsets of a selected data set.

(03:04:21.204) Gateway -> Thermostat, type 0x03FF telegram: 48 90 F7 00 03 FF 01 B9 (CRC=83)
(03:04:21.234) Thermostat -> 0x48, type 0xFF01 telegram: 10 48 F7 00 FF 01 B9 35 19 08 (CRC=87)

I guess that's how it works:

With the first telegram the gateway queries the thermostat for the f7 telegram for EMS+ dataset 01 b9 and requests to get data from offset 00 with desired lenth of 03 bytes. The thermostat replies and sends the f7 telegram. In its datablock it repeats which dataset gets masked, followed by the bitmask in three bytes.

The bitmask 35 19 08 masks the Offsets of the 01b9 telegram like this:

    0x08     0x19     0x35
00001000 00011001 00110101
    |  | |      | |      |
    |  | |      | |      Offset 0x00
    |  | |      | Offset 0x07
    |  | |      Offset 0x08
    |  | Offset 0x0f
    |  Offset 0x10
    Offset 0x13

It would also be possible that the bitmask is not to hide the setting, but to mark it as write-protected (so the setting disappears on the RC in my case). But I can't check this with my hardware, because I only read on the bus.