Support for 0x02FF - Hot Water - Time Program? (CS6800i/WLW176i)

[MarkusMit]

The Bosch heat pump CS6800i supports hot water heating via a daily schedule for at which time of the day the temperature levels of the hot water reservoir should follow which kind of setting (eco, comfort, eco+, off). (Related to Start/Stop Temperatures)

For that purpose it is possible to define up to six "switch points" ([de] "Schaltpunkt/e") per day, at which a settings becomes effective:

Since I would like to display this "time program" ([de] "Zeitprogramm") also in Home Assistant, and eventually edit it there, it would be great if ems-esp could also process the telegrams for this data and provide according entities.

To support this I did some preliminary analysis of the telegrams and made a first attempt to interpret them.

This 0x02FF telegram from the thermostat(0x10) device seem to be the relevant one:

2024-08-03 01:15:21.285 TRACE 1011: [emsesp] thermostat(0x10) -B-> All(0x00), ?(0x02FF), data: 03 10 00 20 01 24 00 39 02 40 00 4C 01 2C 02 40 00 4C 01 FF 01 FF 01 FF
2024-08-03 01:15:21.285 TRACE 1012: [emsesp] thermostat(0x10) -B-> All(0x00), ?(0x02FF), data: 01 2C 02 40 00 4C 01 FF 01 FF 01 FF 01 2C 02 40 00 4C 01 FF 01 FF 01 FF (offset 24)
2024-08-03 01:15:21.285 TRACE 1013: [emsesp] thermostat(0x10) -B-> All(0x00), ?(0x02FF), data: 01 2C 02 40 00 4C 01 FF 01 FF 01 FF 01 2C 02 40 00 4C 01 FF 01 FF 01 FF (offset 48)
2024-08-03 01:15:21.285 TRACE 1014: [emsesp] thermostat(0x10) -B-> All(0x00), ?(0x02FF), data: 01 2C 02 40 00 4C 00 FF 00 FF 00 FF (offset 72)

If the time program is edited via the Bosch HomeCom app, the same telegrams are also coming through the gateway(0x48) device (ahead of the ones above):

2024-08-03 01:15:21.285 TRACE 1007: [emsesp] gateway(0x48) -W-> thermostat(0x10), ?(0x02FF), data: 03 10 00 20 01 24 00 39 02 40 00 4C 01 2C 02 40 00 4C 01 FF 01 FF 01 FF
2024-08-03 01:15:21.285 TRACE 1008: [emsesp] gateway(0x48) -W-> thermostat(0x10), ?(0x02FF), data: 01 2C 02 40 00 4C 01 FF 01 FF 01 FF 01 2C 02 40 00 4C 01 FF 01 FF 01 FF (offset 24)
2024-08-03 01:15:21.285 TRACE 1009: [emsesp] gateway(0x48) -W-> thermostat(0x10), ?(0x02FF), data: 01 2C 02 40 00 4C 01 FF 01 FF 01 FF 01 2C 02 40 00 4C 01 FF 01 FF 01 FF (offset 48)
2024-08-03 01:15:21.285 TRACE 1010: [emsesp] gateway(0x48) -W-> thermostat(0x10), ?(0x02FF), data: 01 2C 02 40 00 4C 00 FF 00 FF 00 FF (offset 72)

It seems that the time program for each weekday is represented by 12 bytes, of which always two bytes are the switch point data (setting & time), hence there are seven block of twelve bytes:

 03 10 00 20 01 24 00 39 02 40 00 4C 01 2C 02 40 00 4C 01 FF 01 FF 01 FF ..
|      day of week 1 (monday)       |      day of week 2 (tuesday)      | ..
| sp1 . sp2 . sp3 . sp4 . sp5 . sp6 | sp1 . sp2 . sp3 . sp4 . sp5 . sp6 | ..

The first byte of each switch point specifies the temperature setting (00=off, 01=ECO, 02=Comfort, 03=ECO plus).
The second byte specifies the day of time from which the setting should be active, and thus in "number of quater-hours since midnight" (qsm). (The time can only specified in 15 minutes granularity, see app screenshots above.)
e.g. "monday":

03 10 -> ECO+  04:00 ( 4 hrs x 4 qsm         = 16 = 0x10)
00 20 -> OFF   08:00 ( 8 hrs x 4 qsm         = 32 = 0x20) 
01 24 -> ECO   09:00 ( 9 hrs x 4 qsm         = 36 = 0x24)
00 39 -> OFF   14:15 (14 hrs x 4 qsm + 1 qtr = 57 = 0x39)
02 40 -> COMF  16:00 (16 hrs x 4 qsm         = 64 = 0x40)
00 4C -> OFF   19:00 (19 hrs x 4 qsm         = 76 = 0x4C)

For unused switch points the "time" is always FF.
The switch points of a day always seem to be in chronological order according to their respective time of day, even when an earlier switch point is added later. (Unused switch points at the end.)

Also I noticed, that the HomeCom app seems to always send the full telegram with the data for all seven weekdays, while the heat pump only sends the data for the one edited weekday, when changing the time program directly on the display.
e.g changing schedule for tuesdays:

2024-08-03 11:36:51.319 TRACE 1101: [emsesp] thermostat(0x10) -B-> All(0x00), ?(0x02FF), data: 01 2C 02 40 00 4C 00 FF 00 FF 00 FF (offset 12)

As I said, eventually I would like to be able to edit this information in Home Assistant (HA), but TBH currently I have no idea how to do that, and what the best data format would be for that.
I guess, it definitely would make sense to have one entity per weekday, since the switch points need to be sorted by time of day.
But I have no idea yet what would be the easiest format to be processed (and how) in HA (and how to do it on the Lovelace UI), maybe you have already some experiences in that regard?

Things to be clarified:

• Best data format for entities (for HA)?
  • Do translation of values (setting & qsm->time) already in ems-esp entity?
• Does order/meaning of weekdays change, depending on regional first-day-of-week (Su/Mo)?
• Is the "quater-hours since midnight" unit valid for all EMS devices with "time program"?

Attachements:
ems-esp log-file for further analysis

[proddy]

Interesting. I would need to think about this one. @tp1de, is this similar to what you were trying with IOBroker and programming the time switch schedules?

[tp1de]

@proddy Yes all these switchPrograms for EMS+ are decoded in ioBroker.
But I am sure that not all boilers or heatpumps are 100% covered.

I am using a Buderus gas boiler with RC310 thermostat and 2 heating circuits I can decode 4 switchTimes per hc.
Each hc has 2 switchTimes A and B and 2 variants with level and temps. Dhw has another 2 switchPrograms.
So in total I have 10 with 2 hc's. (Would be up to 18 with 4 hc's)

For dhw there are 2 switchPrograms:
01FF for warm water and 0209 for circulation pump - switch between eco/hot and on/off
(The example from @MarkusMit shows different levels for his heatpump)

The heating circuits can be switched between levels (eco/comfort) or absolute temps.
These are different telegram types. (see below all types are raw)

The switch is done by another telegram. Selection is valid vor both A and B:
01B9 for hc1 and 01BA for hc2 - offset 0x13 - "01" = levels / "02" = temps

switchTime A: hc1 telegrams level/temps are: 01C3 / 0583 and hc2: 01C4 / 0584
switchTime B: hc1 telegrams level/temps are: 0349 / 058D and hc2: 034A / 058E

There are challenges:
(1) switchTimes need to be polled by send commands and response can be between 1 and up to 30 seconds
(2) and any change needs multiple telegrams to be send - in ioBroker 1 telegram per day (7 in total)
(3) within ioBroker the result is stored in a JSON-structure (1:1 identical to km200 api response)
(4) depending on selected mode (levels or temps) the right telegram must be polled by send command and read / decoded.
(5) for HA I haven't found any correct way to store and manipulate the data yet.

The ioBroker JS-code is working within HA (node-red) as well. But I still hesitate to believe if this would make sense.
Timing is very critical - it took me many weeks to bring it to stable.

For HA it is maybe better - and much easier - to switch to manual mode and use the scheduler component from HACS.

I told you that I am trying to integrate this into the scheduler component. But I am not sure to bring it to stable working.

[tp1de]

... and btw the Buderus or Bosch HomeCom Apps are quite comfortable to manipulate the switchTimes and to switch between Programs A and B. The change of the switchProgramMode is supported as well.

[tp1de]

This is my JSON-structure for dhw within ioBroker:

[ { "dayOfWeek": "Mo", "setpoint": "high", "time": "5:30" }, { "dayOfWeek": "Mo", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "Mo", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "Mo", "setpoint": "eco/low", "time": "21:00" }, { "dayOfWeek": "Tu", "setpoint": "high", "time": "5:30" }, { "dayOfWeek": "Tu", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "Tu", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "Tu", "setpoint": "eco/low", "time": "21:00" }, { "dayOfWeek": "We", "setpoint": "high", "time": "5:30" }, { "dayOfWeek": "We", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "We", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "We", "setpoint": "eco/low", "time": "21:00" }, { "dayOfWeek": "Th", "setpoint": "high", "time": "5:30" }, { "dayOfWeek": "Th", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "Th", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "Th", "setpoint": "eco/low", "time": "21:00" }, { "dayOfWeek": "Fr", "setpoint": "high", "time": "5:30" }, { "dayOfWeek": "Fr", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "Fr", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "Fr", "setpoint": "eco/low", "time": "21:00" }, { "dayOfWeek": "Sa", "setpoint": "high", "time": "6:30" }, { "dayOfWeek": "Sa", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "Sa", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "Sa", "setpoint": "eco/low", "time": "21:00" }, { "dayOfWeek": "Su", "setpoint": "high", "time": "6:30" }, { "dayOfWeek": "Su", "setpoint": "eco/low", "time": "10:00" }, { "dayOfWeek": "Su", "setpoint": "high", "time": "17:30" }, { "dayOfWeek": "Su", "setpoint": "eco/low", "time": "21:00" } ]

[tp1de]

There is still no idea how to integrate this bunch of data in the ems-esp structure without blowing ram/mqtt/web.
If the raw response is too long, maybe we can add an entity with raw data, collecting the whole telegram. e.g. hc1/switchtime1 as hex-string with length 168 (84 bytes hex coded). In first step as read only, writing more than a telegram length is tricky. Or extend the raw custom entity to length > 25 by collecting data in a buffer?

As far as I can see all EMS+ installations (boilers and heatpumps) have an IP-gateway build in and are connected to Bosch cloud services. The Bosch HomeCom app and MyBuderus are identically and are connecting to cloud.

The internal IP gateway buffers data like switchPrograms and Recordings (energy consumption / temperatures).
While reading switchPrograms the data is read from IP gateway and not from the EMS-bus.
I do not believe that doing regular polling is the right way to do, since it produces additional load on the EMS-bus.

Since last update the Bosch apps are very convenient to use for managing switchPrograms and changing modes.
I believe that it is much easier in HA to switch to manual mode and use HACS extensions to manage switchTimes.

Up to yet I tried to set temporary values by home automation systems (ioBroker / HA) to secure that heating is working stable when home automation systems might be down down. (e.g. heat demand control)

It might make sense to build a timer for manual control (off, 12h,24h) which needs to be set every 12/24 hours to stay on manual mode for heating circuits and dhw. What do you think?

[tp1de]

Ups, forgot to add the entity name, fixed in my build, i'll make a PR.

@MichaelDvP Why have you made the entities to be a command and not enum?
The values are only within dashboard .../ api/thermostat when set once. And value is always "Absolut". "Levels" can not be selected.

[MichaelDvP]

? It's enum
https://github.com/MichaelDvP/EMS-ESP32/blob/ebb327edf61e683e5952a00592031ff8f37ea561/src/devices/thermostat.cpp#L4529

[tp1de]

I refreshed the browser ... and now its shown correct. But changing values still do not work.
You send with offset 0x0D and not 0x13. And reading might not be correct offset as well

[MichaelDvP]

You send with offset 0x0D and not 0x13.

Missed that, we always count offset and length decimal.

[tp1de]

@proddy @MichaelDvP I tried to install https://github.com/proddy/EMS-ESP32/releases
This version broke my gateway ... I could reach the gateway but nothing else worked ... I flashed again dev.29 and recognized that WiFi scan was not working. I connected by LAN and then scan worked. Isn't this a mistake?

[proddy]

is your SSID set? WiFi scan will only work on an E32 gateway if WiFi is activated. I checked with dev-29 and it works on my gateways, both the S3 and E32V2. I'll make a change to "gray out" the Wifi Scan feature if WiFi is turned off by the user.

[tp1de]

is your SSID set? WiFi scan will only work on an E32 gateway if WiFi is activated. I checked with dev-29 and it works on my gateways, both the S3 and E32V2. I'll make a change to "gray out" the Wifi Scan feature if WiFi is turned off by the user.

When flashing new access point is active. So I connect by WiFi to accesspoint and want to change network settings by scanning WiFi.
I think I haven't set any SSID ... but nevertheless it should work when connected by WiFi to access point.
I tried to set SSID and password manually, but I wasn't successful. I do not know why - maybe because still disabled?

[proddy]

#1922

[proddy]

WiFi scan issue is fixed.

[tp1de]

@MichaelDvP you intoduced raw custom entities. This works fine for shorter telegram lengths.

Is this supposed to work on EMS+ switchTimes as well? (telegram length 84 bytes)
Telegram length with 50 bytes work, but lengths of 60 bytes or higher produces a crash and a restart of the gateway.
This might be a memory problem?

[MichaelDvP]

Should work, Which gateway? Which version?

[tp1de]

I use BBQKees E32 V2 - crash with bytes >60

[tp1de]

... and latest dev.30. Crashing when bytes is > 53

[MichaelDvP]

This thread is getting more and more OT and a chaotic mix like discord. Please open new topics and keep on topic.

[tp1de]

#1934

[timostr]

@MarkusMit Very interesting topic - I've got same heatpump and trying to set "Anlageneinstellungen–>Zuheizer–>Einzelbetrieb" via ems-esp to heat up warm water only with electric heater.
So far without success. "aux heater only" is not doing the job.

Have you figured out how to do that?

[MarkusMit]

This thread is getting more and more OT and a chaotic mix like discord. Please open new topics and keep on topic.