Junkers Heater and Bosch CW400 - how do I activate circulation?

[aprospero]

Hi Guys,

I have a little project of my own going on, half for fun, half in all seriousness. My setup consists of a Junkers Cerapur gas boiler with hot water and a solar thermal circuit controlled by a Sorel MTDC. Since I am passionate about writing embedded software in C, and also like to wield a soldering iron, I built a combined Sorel/EMS+ controller from an NXP imx6 board, yocto, Grafana, influxdb and a few electronic components.

I know what you think now: I should better contribute to this project than doing everything a second time on my own, but as I said: I have so much fun doing it.... :)

Every now and then, when I run into problems, I come here to see if you may already have solved the problem. This was also the case with my latest challenge: until now I had only read parameters and used them for statistical evaluation. But now I also want to actively control the system. My first attempt was to remotely activate the circulation pump for the hot water heating system. This works really well when I do it with an EMS telegram directly on the boiler:

uint8_t msg_circ_on [] = { 0x8B, 0x08, 0x35, 0x00, 0x11, 0x11, 0x00 };
uint8_t msg_circ_off[] = { 0x8B, 0x08, 0x35, 0x00, 0x11, 0x01, 0x00 };

I send telegram type 0x35 to the boiler (0x08) and set/unset the appropriate bit. I have to use the inverse logic regarding read/write coding source and destination (at least that's how it's done here on my bus), hence the 0x80 bit is set for the local device address (0x0B) and unset for the destination (0x08).

This works like a charm but unfortunately the CW400 control unit seems to have something against this and regularly switches the circulation off again after 5 minutes at the latest.
I looked into:

bool Thermostat::set_wwcircmode(const char * value, const int8_t id)

If I get the code right I have to send a control telegram to the cw400 instead of the boiler. So I send:

/* switch thermostat not boiler? */
uint8_t msg_circ2_on [] = { 0x8B, 0x10, 0xFF, 0x03, 0xF5, 0x01, 0x01, 0x00 };
uint8_t msg_circ2_off[] = { 0x8B, 0x10, 0xFF, 0x03, 0xF5, 0x01, 0x00, 0x00 };

destination is 0x10, it's an EMS+ type telegram (0x01F5) and I set/unset the first bit at offset 3.
Note that the ems+ telegram type is 0x01F5, not 0x02F5 as in the Thermostat::set_circmode code, because that's the telegram type I get from the CW400 if I switch circ mode manually at the CW400 and I can successfully read all information from these 0x01F5 telegrams with the same layout as described for the 0x02F5 telegram type. I certainly tried it with 0x02F5 - unfortunately both to no avail. The circulation mode doesn't change at all.

Are there other prereqisites I need to consider in order to control the CW400?

What do you guys think?

All the best and keep up the great work!

  Aprospero

[MichaelDvP]

Yes, a thermostat takes control and overwrites any command you send to the boiler (or mixer, etc.) You have to control the thermostat to make a change.
We count ems+ telegrams with an offset of 0x0100 to differ from ems (one byte) telegrams. Norberts1 uses the same counting scheme.
So write telegram 0x02 to thermostat is a message 8B 10 02 00 xx and write 0x102 (ems+ 0x002) gives 8B 10 FF 00 00 02 xx
MSB in firstbyte depends on brand, Junkers set it, Buderus not.

{ 0x8B, 0x10, 0xFF, 0x03, 0xF5, 0x01, 0x01, 0x00 } looks odd, you're writing two bytes 0x0100 to offset 3 (and 4) in telegram 0xF501
I think { 0x8B, 0x10, 0xFF, 0x03, 0x01, 0xF5, 0x01} is wwcircmode on.

Hope you will share findings of new values in your system.

[aprospero]

Hi Michael,

thank you for answering! I really appreciate it, especially since I do my own thing and most likely won't have the opportunity to contribute. And while we're at it, let me straight answer your last point you made: I'm a huge advocat for Free Open Source Software. If it weren't that you have already a buttload of head start I would happily share everything I'd reverse engineer and would love to discuss my findings with you all. But that's the sad truth, I'm a bit late to the party... If you ever happen to plan to integrate Sorel device control (I don't say that would be wise!) I think I have sorted it out quite a bit and I'd be happy to help.

Regarding your comments:

1. 'Yes, a thermostat takes control and overwrites any command you send to the boiler (or mixer, etc.) You have to control the thermostat to make a change.'

Thanks for confirming that!

2. 'We count ems+ telegrams with an offset of 0x0100 to differ from ems (one byte) telegrams. Norberts1 uses the same counting scheme.'

I must have missed that information - clear case of RTFM. :) Thanks for pointing that out!

3. 'MSB in firstbyte depends on brand, Junkers set it, Buderus not.'

Ah, I already figured but good to have that confirmed, too! So the logic regarding setting the first bit for write attempts and leaving it zero for read requests is simply inverted for Junkers?

4. '{ 0x8B, 0x10, 0xFF, 0x03, 0xF5, 0x01, 0x01, 0x00 } looks odd, you're writing two bytes 0x0100 to offset 3 (and 4) in telegram 0xF501'

First, my bad, I should have explained in more detail: The last zero byte is a placeholder for the CRC. That way I don't have to copy the message and can directly send it from where it resides in RAM, without having to pour the crc calculation logic all over the code base.

Second, I swapped the EMS+ telegram type bytes because that's what I found on the bus. Eg. if I set circmode manually on the CW400 it sends the following telegram:

EMS+ Telegram (08) RX: 90 00 ff 03 f5 01 01 f6

I simply send the exact same telegram to the CW400, if I'm not completely lost...

I'll give it a try with the swapped type bytes, though, and be back when I have the results.

Thanks again for helping me!

[MichaelDvP]

Are you storing the type id as 16bit int? Maybe the wrong byte order comes from endianness of your processor.
The ems+ write telegram is serial send out <src><dest>FF<offset><highbyte><lowbyte><data>..<crc>
read telegram <src><0x80|dest>FF<offset><length><highbyte><lowbyte><crc>
the menu config write <src><dest>F7<offset>FF<highbyte><lowbyte><bitfields>..<crc>
the menu config read <src><0x80|dest>F7<offset><length>FF<highbyte><lowbyte><crc>
data config same scheme but with F9 and unknown data(not bitfields)

[aprospero]

Waaah!

you're completely right!

I have a common swap function for all multi-byte values - and sure, internally I don't treat those as byte arrays.

The only occasions I treat them as bytes is when I do debug output of telegrams and when I define fixed telegrams in order to test-send them.

Thank you!!!

And that's why I LOVE collaboration - sometimes everybody needs another pair of eyes and ears. If you ever happen to need some yourself and I can be of help, you know where you can find me!

All the best!

[aprospero]

One thing at last: you say that for ems+ write telegrams the format is:
<src><dest>FF<offset><highbyte><lowbyte><data>..<crc>

But on my bus I see the following:
<0x80|src><dest>FF<offset><highbyte><lowbyte><data>..<crc>

Eg. if I activate Circulation on my CW400 it sends the followowing data - this time without swapped type ;o)
90 00 ff 03 f5 01 01 f6

Did I miss something else here?

[MichaelDvP]

Junkers have the first bit in <src> set, buderus cleared. Bosch likes to make its brands incompatible.