Properly parse F7 and F9 telegram type about ems-esp32

[proddy]

thanks for sharing. Lots of interesting stuff happening when your CS200 is booted. It looks like the thermostat is trying to figure out the capabilitites of the solar units. The first byte of the version (0x02) is the device type. Norbert has a nice list at https://github.com/norberts1/hometop_HT3/blob/master/HT3/docu/HT_EMS_Bus_messages.pdf

[yazend]

Proddy asked to put my collected data here,
the protocol ems-esp_protocol is this one that was already attached in discord,
Today I had time to log the whole thing again while starting the system, once normally and once as RAW data, I hope this helps with the analysis, In the file Bootup_log_F7_F9 I have already sorted the sequences a bit, these are with ############ divided up.
Bootup_log_F7_F9.txt
ems-esp_protokoll.txt
RAW_Bootup_log_F7_F9.txt

[MichaelDvP]

I think this a bug from very old v2.0.1b software, the thermostat is requesting 0x0358 from solar and not sending 0x02.
The raw messages i suppose is 10 B0 FF 00 02 58 B2 or a extendened F7/F9 message.

000+04:41:59.594 N 241: [emsesp] Thermostat(0x10) -> Solar Module(0x30), Version(0x02), data: 58 B2
000+04:41:59.651 N 242: [emsesp] Solar Module(0x30) -> Thermostat(0x10), (0x358), data: 21 66 08 00 8E

[hpanther]

CS200-MS100 startup fixed.txt
CS200-MS100 startup raw fixed.txt
These logs taken with a current 2.0.1 from main

[MichaelDvP]

Ok, when receiving ems+ read requests the telegrams are not handled correctly, i can fix this.

But there is something strange with some of the F7 requests, having an extra byte at the end or using 24 bit type. I don't know what this is and how to handle it. Also the sequence you posted on gitter left some questions.

N 223: [telegram] Rx: 90 B0 F7 00 01 FF 02 65 30
this is a normal read <src><dst>F7<offset><length>FF<id><id><crc> (type 0265, offset 00, len 01)
and the reply is handled correctly
this is also normal read for ems+: N 227: [telegram] Rx: 90 B0 FF 30 18 02 8D B7
(type 02D8, offset 30, len 18)
I'll add this to the dev-branch.

But this seems to have a 24bit type-id 0x020000?
N 85: [telegram] Rx: 90 B0 F7 00 02 02 00 00 96
N 86: [telegram] Rx: B0 10 F7 00 02 00 00 1F 00 8F

and posted on gitter:
N 74: [telegram] Rx: 90 B0 F9 00 11 FF 02 5A 03 AF
there is an extra 03 at the end,
N 75: [telegram] Rx: B0 10 F9 00 FF 02 5A 03 17 00 00 00 14 00 00 00 3C 00 00 00 5A 00 00 00 5A 2A
the answer is ok, 0x11 bytes long as requested.
N 77: [telegram] Rx: 90 30 FF 03 02 5A 59 B3
write 59 to offset 3
N 78: [telegram] Rx: B0 00 FF 03 02 5A 59 2D
confirmed the write at offset 3
N 79: [telegram] Rx: 90 B0 F9 00 11 FF 02 5A 03 AF
another request with the strange 03 at the end.
N 80: [telegram] Rx: B0 10 F9 00 FF 02 5A 03 17 00 00 00 14 00 00 00 3C 00 00 00 5A 00 00 00 59 29
answer, but here the value in offset 17 has changed!

@proddy: Do you have a clue how these telegrams work?

[MichaelDvP]

@hpanther please check the latest dev build here
The normal read request should now work, The F7 with long id are ignored, but gives a debug log-message.

[MichaelDvP]

@proddy: i have found a description of F7/F9 types in emsesp/EMS-ESP#109.
But i'm not sure how to handle it in code. Maybe, as long as not really used, it's best to handle it as ems 1.0 types F7, F9?

[proddy]

@MichaelDvP I thought I coded in the F7/F9 to read out the data? I would need to check. I based it off some of Norberts code and also what I found in https://emsesp.github.io/docs/#/Deciphering-EMS-Plus

[hpanther]

@MichaelDvP I agree with your latest implementation (of handling F7/F9 as EMS1.0)

[MichaelDvP]

I thought I coded in the F7/F9 to read out the data?

Yes, but (appart from missing read-bit detection) you handle it like a ems+ telegram, only skipping the extra 0xFF. But why should Bosch use FF, F7 and F9 codings to send the same data? There is a difference in what data are send, and some of the F7, F9 telegrams uses a different format from ems+ (FF).

You read something like 90 10 F7 00 FF 02 A5 <data> as equvalent to 90 10 FF 00 02 A5 <data> but i'm sure that <data> is different with different meaning, and if you get both telegrams for id 02A5 you get changing values.

Also some telegrams hpanther posted have different format: 90 B0 F9 00 11 FF 02 5A 03 AF This is not a ems+ request, this asks for 0x11 bytes, but has additional data 03 in the end, an ems+ request does not have data at the end!

In emsesp/EMS-ESP#109 Th3M3 described it as a mask, but i dont know what 02A5 contains and how the mask works in this case.

As you see above in my post N77 is a ems+ (FF-02A5) write to offset 3, N78 is the ems+ (FF-02A5) answer that offset 3 is written. N79 is a read request with F9-02A5 and the strange extra byte in the end. The N80answer F9-02A5 are 17 bytes but offset 3 does not contain the 59 written with the ems+ command.

@hpanther can you test the output to send telegram "8B B0 FF 00 20 02 A5"
I'm sure the answer is different from F9-data in N80.

[proddy]

that actually makes more sense. We could ask @norberts1 if he's figured out what F7 and F9 actually do.

[norberts1]

@MichaelDvP @proddy I have never received that F7/F9 messages in my heater-system, but what I found is:

F7/F8 (messageID's:247,248) are used to transfer transparent data between moduls. At maximum 26 bytes are possible.
F9 (messageID:249) seems to be also transparent data with special handling, see below.
FD/FE (messageID's:253,254) used for serial-number exchange at least with 27 bytes.

In that context they seems to be 4byte-header messages like:
<src><dst>F(x)<offset><payload><crc>
For that example above with F9 it seems to be:
90 B0 F9 00 11 FF 02 5A 03 AF :=>
<src><dst>F9<offset>< <requested length><FF 02 5A><offset> ><crc>
:=> request of 17 byte response for 'FF 02 5A' (ID:858) starting at offset 3

I found this handling in logfiles at emsesp/EMS-ESP#390 and compressed it to file:
https://github.com/proddy/EMS-ESP/files/5029794/Bosch_6000_mesg_ems26june-Info.zip
I can't check it on my Junkers/Bosch-system, hopefully somebody else can do.