EMS sensor mapping issues/fixes for WB Greenstar Life 8000

[gwilford]

Initial observations

Some EMS entities appear to be incorrectly mapped, described or missing for this boiler (details below). I have found the following;

1. heatingpump2mod represents "Burner current power" - % power measured against the boiler rating plate
2. curburnpow represents "Burner current ranged power" - % power measured against range-limited heating power (burnmaxpower)
3. burnmaxpower represents "Maximum heating power" rather than max burner power - in my case 65%. Max DHW power remains at 100% however max (range-limited) heating power is set to 65%.

Explanation: This 35kW boiler can modulate down to 15%. I have range-limited heating power to 65%. At minimum modulation, the value for (1) displays as 15% and the value for (2) displays as 22% (approx 15/65). They both rise and fall in tandem except (2) is bounded at 100% when (1) exceeds the 65% range limit.

4. emergencyops represents "Manual heating control" in the manual
5. emergencytemp represents "Manual flow temperature" in the manual
6. wwcomfort1 doesn't appear to show or manage comfort mode on this boiler.
7. Ignored 0x2D6 telegram [00 00 00 00 00 xx 00] where xx represents "Heating set temperature" in hex. This appears to be a readonly feedback of selflowtemp (just like wwseltemp and wwsettemp)
8. 0x05 telegram is sent as a signal from controller to boiler to select DHW comfort mode (data: 55) and DHW eco mode (data: AA) settings. I'm not sure if this is also relayed out from the boiler to 0x00 destination

000+00:34:34.422 N 51: [emsesp] Controller(0x09) -> Boiler(0x08), ?(0x05), data: 55 (offset 70)
000+00:34:48.760 N 52: [emsesp] Controller(0x09) -> Boiler(0x08), ?(0x05), data: AA (offset 70)

Device information

WB Greenstar Life 8000 (GR8300iW 35 C)

ems-esp:$ show devices
These EMS devices are currently active:

Boiler: Worcester Condens 5000i/Greenstar 8000 (DeviceID:0x08, ProductID:195, Version:04.08)
Received telegram type IDs: 0xBF 0xC2 0x15 0xD1 0xE3 0xE4 0xE5 0xE9
Fetched telegram type IDs: 0x14 0xE6 0xEA
Pending telegram type IDs: 0x10 0x11 0x1C 0x18 0x19 0x1A 0x35 0x16 0x33 0x34 0x26 0x2A
Ignored telegram type IDs: 0x2D6 0xD7 0x2E

Controller: Condens 5000i (DeviceID:0x09, ProductID:241, Version:01.04)

Firmware info

EMS-ESP32 v3.4.4

[proddy]

Thanks for reporting this. 1-5 we can rename the entities but I can't validate (@bbqkees @MichaelDvP make sense?)

6 - changing the comfort zone with wwcomfort1 should be a new issue, as a bug if the functionality isn't working

7- The 0x2D6 telegram with the "Heating set temperature", is this useful to add?

8 - 0x05 telegram, noted. We won't include it, but should add it to the telegram library in the wiki.

[gwilford]

Thanks for following up.

1-3 - these remain as originally reported.

4 & 5 - these controls don't appear to work (via EMS-ESP) or I haven't worked out how to engage them properly so they may not actually map to the manual controls - suggest leaving for now.

6 - I'll raise separately in due course

7 - I don't think it really adds any value right now - just reporting as an observation and comparison to the ww*temps

[MichaelDvP]

Renaming is always a bit difficult. The names vary from brand to brand, manual to manual, software to software. And we have to use names that fit for all. If i search the RC35 manual on buderus website, i get 7 versions of user-manuals and 8 installation manuals and none of them fit's all entities of my RC35 display.
1: If this is burner related, the emsesp name is wrong and should be changed.
2 - 3: seems there is a difference in rating plate laws in GB and EU. Nearly all modulated gas boilers have different power for heating and dhw, depending on vessel size and flow rate. dhw preparation have short pipes with high flowrate, and can heated faster without overheating. But in EU bosch rates the heatingpower mostly/always 100% and for dhw the power goes up to 160%. Seems in GB it's 100% of ratng plate for dhw and 65% for heating.
4 - 5: These are entities Thomas (@tp1de) have added from his RC310. I think this is the name that is displayed. Maybe it's version/brand/country dependent?
6: What's wrong with comfort1? This was also introduced by Thomas, because the existing comfort (heat, eco, intelligent) does not fit the RC310 settings.
7: Is the 0x2D6 broadcasted, readabble, or only used to send commands? Is setFlowTemp and selFlowtemp always the same, or differ in some modes (wwselflowtemp and wwsetflowtemp can be different, )
8: A lot of people tried to find this setting without success. Is this a command like reset? Can you read 8 5 and read 9 5 to see the state? Or is the current mode eco/comfort shown in comfort1 field (0xEA, offset 13) and we have to use these button command to change?

[gwilford]

Further info on 1-3...

• heatingpump2mod is giving me the absolute % power delivered by the burner against combi rating (35kW) for both heating and DHW loads
• curburnpow is giving me the relative % power delivered by the burner for both heating and DHW loads against any range-limited max heating set by burnmaxpower
• Setting a range limit for heating is optional. The factory default is 100% so for many, curburnpow and heatingpump2mod will show the same value.
• I have manually tested burnmaxpower at 65% and 80% and the values for curburnpow were 22% (15/65) and 18% (15/80) at minimum burner modulation (heatingpump2mod = 15%).
• For reference only, I noticed burnmaxpower also manages the pump's modulation slope when pump speed is set to 'proportional to thermal output' i.e. pump speed = 'pump max output' (also configurable) when heatingpump2mod is running at burnmaxpower

[MichaelDvP]

The heatpump2mod was added in jun 2020 (29d74d7), but i can't fnd the issue which references this as pump modulation.
In https://github.com/Th3M3/buderus_ems-wiki/blob/master/Quelle_08.md this value (0xE3, offset 13) is also mentioned as burner power. Can we rename this value to normBurnPow, as a normalized burner power in relation to rating plate, and leave the others untouched?

[tp1de]

On my side there are about 10 entities for RC310 which are not filled or do not make sense or are wrongly filled. I think that's the price for making one solution for so many different boilers / heatpumps / thermostats.

I learned from Buderus that for my thermostat RC310 there a different software versions available with different functionality and ems+ support. For the master controller as well. It's not a good solution from Bosch/Buderus that the software is not upgradeable - so I might need a new thermostat and a new master controller to support extended functionality.

Very long time ago I made a proposal to introduce "customizable" entities by telegram-type and offset. Maybe still an idea to support special installations and requirements. ( I implemented this some month ago as a hidden functionality within my ioBroker adapter by using an imbedded syslog server which reads all telegrams from ems-esp in hex and analyses them to create the respective entities for read / write. Works fine just creates quite heavy CPU load.)

[proddy]

Very long time ago I made a proposal to introduce "customizable" entities by telegram-type and offset. Maybe still an idea to support special installations and requirements.

I don't recall that, but its really good idea. We could add to the Customization page the ability to add a new Telegram to the EMS device in which you choose a name, the type (short, int), the divider (div10, div2 etc) and position. This would only be for read telegrams though.

[gwilford]

The customization addition sounds great and @tp1de comment about logging telegrams got me thinking about on-device discovery.

This is blue-sky and I appreciate it may not be possible to add to the ESP32 or desirable or worthwhile...

Imagine a "Discovery" page which displayed a table of unregistered (read) telegram/offset fields with current and last values (in decimal), ordered by most recently updated. Something like:

Last updated (s)	Telegram	Offset	Previous value	New Value
10	0xE9	4	60	61
10	0xE9	5	43	45
30	0xE9	6	0	1
300	0xE9	7	32	33
300	0xE9	8	10	80

This could be filtered by Telegram (specific/all), offset(range/unregistered/all), new value(range) and last updated (max seconds ago).

I think something like this would really help users discover and map missing entities.

[proddy]

merged into dev-16. The customization idea is continued in a different issue #922