Timer processing in RC310

[proddy]

Discussed in #1593

^{Originally posted by Nxtway January 30, 2024}
ems-esp supports timer processing of the RC35, #979
Could these functionality also implemented for the RC310, please ?

The type-id's in RC310 are:
circulation timer: thermostat(0x10) type(0x0309) | ON - FF | OFF - 00
warm water timer: thermostat(0x10) type(0x02FF) | COMFORT - 02 | ECO - 01 | OFF - ??, maybe 00
heating timer 1: thermostat(0x10) type(0x0683)
heating timer 2 thermostat(0x10) type(0x068D)

Log files attached:
WW_timer.txt
circulation_timer.txt
heating_timer1.txt
heating_timer2.txt

An additional improvement might be the holiday timer, but I didn't find the type-id up to now.

[MichaelDvP]

Oh, the heating timer for RC300 are 0x1C3-ff, and 0x349-ff. with mode instead of temperature setting. We have to split RC300 - RC310 - BC400. But product-id 158 includes RC300 and RC310, maybe second identifier (unknown).

But as mentioned in the lot of discussions before, i don't know how we get that much data in ram and mqtt.
Each program has 42 entries with Day-of-week, time and mode/temperature for progA, progB, DHW, circulation:
504 entities to display, holiday modes are in similar range.
For RC35 we use only a single switchpoint to show/edit with a command to change the index, but this way was always not accepted by the users.

[Nxtway]

but this way was always not accepted by the users.

yes, I can understand that argument.
Does it still make sense to raise the RC310 to the same level as the RC35 or leave it as it is?

[MichaelDvP]

For the holiday modes check #275. Same problem with a lot of entities.

The RC35 is dfferent, it's also 42 entries, but each has day, time, mode stored, We can set all 42 to monday, or 1.entry to Tu, second to monday, 3rd not set, 4th to mo, etc. The RC3x0 have groups with 6 entries for mo, 6 for tu, etc. To index them makes no sense, or count 0-5 for each day. Don't know how to manage.

Im thinking of store the raw telegram and generate a program json on api command (and maybe as own mqtt topic). We need to modify the api to forward the json to command. For web page this also can not be an entity in the thermostat section, it need a own editor page.
I'm asking the question if it is usefill to change the program via ems-esp? I've never changed the program online. Sometimes i use the "pause" function if nobdy is at home for the whole day, but never touched the program.

[Nxtway]

I agree. It's would be nice to display the timer entries in ems-esp but changing them is not the use-case.

With a JavaScript function in node-red:

The RC310 timers could be display in a node-red dashboard:

The timers can enabled or disabled with the wwmode, wwcircmode, etc. .
You can postpone this feature request

[Nxtway]

And here are the addresses of the vacation timers in the RC310:

vacation1:
000+04:41:20.516 T 386: [emsesp] Me(0x0B) -R-> thermostat(0x10), ?(0x0269), length: 0x19
000+04:41:20.580 N 388: [emsesp] thermostat(0x10) -W-> Me(0x0B), ?(0x0269), data: 18 03 08 18 03 0E 02 11 02 FF 00 00 00 00 00 00 00 FF 00
data 0..2, start: 2024.03.08 ---> 18 03 08
data 3..5, end : 2014.03.14 ---> 18 03 0E
data 6, heating mode: 0x01=as Saturday; 0x02=const temp; 0x03= off; 0x04=reduce
data 7, heating temp: 0x11 = 17°C
data 8, hot water: 0x01=as Saturday; 0x02=off: 0x03=off with disinfect
data 9, used for heating: FF=YES | 00=NO
data 17,used for hotwater: FF=YES | 00=NO

with a few lines of JS code in node-red it looks like:

[proddy]

what shall we do here @MichaelDvP ?

[proddy]

I don't have these features on my thermostat so not sure how to proceed. I'll remove this issue from the backlog.

[tp1de]

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 switchPrograms 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 buffer load and 0209 for circulation pump - switch between off, eco, hot, on and on, off

The heating circuits can be set to use levels (eco/comfort) or absolute temps per switchTime.
These are different telegram types the to be used. (see below all types are raw)

The switch is done by the entity hcx/switchprogmode for each heating circuit between levels and absolute (temps).
These entities have been build-in just recently.

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

Within #1934 long custom entities in raw are now realized and could be used to maintain the long 84 bytes telegrams.
Open questions is where to deconstruct these telegrams and which home automation systems should be supported.

Since quite some time I implemented this in my ioBroker adapter in read/write mode creating the same JSON-objects as the original km200 gateway does. But I needed to implement the right timing for getting the long telegrams and writing them back.
It is much better to do this in the EMS-ESP gateway.

[tp1de]

Each switchProgram has 6 switchTimes per day, 42 switchTimes per week combined with 42 values.
My 10 switchPrograms would create up to 420 mqtt entities if 1:1 implemented and enabled. (2 hc's and dhw with circ. pump)

[MichaelDvP]

@tp1de Please use the ems-esp notation for telegram-types. e.g. 0x2FF for dhw1. Thanks.

Can you confirm the value order:
first byte state, second byte time in 15min steps. --- time 0xFF stands for not_set? (i'm not sure)
first 6 pairs for monday, next 6 for tuesday, etc. (or other day order?) -- are the 6 pairs in row or can only first and last pair be set?
state is for:
dhw1, type 0x2FF, 0x01 for low, 0x02 for high --- other states, eg. 0 for off?
circulation dhw1, type 0x309, 0xFF for on, 0x00 for off
switchtime1 hc1 type 0x2C3, 0x03 for eco, --- ? for comfort -- are there other values?
switchtime2 hc1 type 0x683, temperature in 0,5°C steps -- is there min/max?

switchtime 1/2 is selected by program, 0x2B9, offset 11
mode/temperature telegrams (2C3/683) is selected by switchprogmode, offset 19

We can read the whole telegram in ram and generate a json on API command.
For RC35 i have done this a while ago to test. The byte order is different, RC35 have 42 switchtimes and each have also coded the day of week, there is no order in the settings, eg. offset 0/1 can be Fr evening, offset 6/7 mon morning, and 2-5 not set.
Here is the output for ems-esp.local/api/thermostat/hc2/switchtime
RC35_timer.txt

for RC300 i think the json should look

"value":{
  "mo":{
    "01:{
      "time":"07:00","mode":"comfort"
    },
    "02": {
       ...
    }
  },
  "tu":{
  }
}

For commands we can use the same json structure ans json object in value field.
Maybe only a single switchpoint per command, or more, to be discussed if additive or overwriting. to not set values.

But i have no idea

• how we can publish it to mqtt
• what HA needs to interprete this
• how to display in webUI

We need a complete concept before starting to code.

[tp1de]

Please use the ems-esp notation for telegram-types. e.g. 0x2FF for dhw1. Thanks.

EMS+ and EMS2.0 switchPrograms (For me RC310 and Moduline 2050)

1st step is to select the right telegram type defined by reading the new entities switchprogmodes.
If switchprogmode does not exist then use levels for hc.

hc1 - Mode A level 02C3 and absolute temps 0683 (A == program(1))
hc1 - Mode B level 0449 and absolute temps 068D (B == program(2))

hc2 - Mode A level 02C4 and absolute temps 0684 (A == program(1))
hc2 - Mode B level 044A and absolute temps 068E (B == program(2))

dhw1 - Mode A 02FF
dhw1 - cp (circulation pump) 0309

Each telegram has a length of 84 bytes:
per day there is a maximum of 6 switch points. Each switchpoint is represented by 2 bytes. Therefore each day is 12 bytes:
Mo offset 0 0x00
Tu offset 12 0x0C
We offset 24 0x18
Th offset 36 0x24
Fr offset 48 0x30
Sa offset 60 0x3C
Su offset 72 0x48

Telegram structure of one day looks like this with 2 active switchpoints:
P1 P2 P3 P4 P5 P6 ...........................P12
14 01 58 03 FF 03 FF 03 FF 03 FF 03

P1: time of 1st sp: unit 15 minutes --> 0x14 = 20 *15 = 300 minutes = 05:00 hours
FF: no active switchpoint

P2 are either levels or absolute temps depending on type. Valid for hc and dhw:

Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off"
temps: Number("0x" + hex) / 2

[tp1de]

km200 API JSON uses time in minutes:
[
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": 330
},
{
"dayOfWeek": "Mo",
"setpoint": "low",
"time": 600
},
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": 1050
},
..........
]

[tp1de]

Within ioBroker I write times:
[
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": "5:30"
},
{
"dayOfWeek": "Mo",
"setpoint": "eco/low",
"time": "10:00"
},
{
"dayOfWeek": "Mo",
"setpoint": "high",
"time": "17:30"
},
.......

[tp1de]

I think we do not need the index 01, 02 etc ... in JSON

Important: Any change in switchprogmode will require to re-read different telegram type for hc switchprogram.

[tp1de]

The API version with JSON will deliver the similar data object compared to the original Bosch API.
Using MQTT for HA I can not identify the right object yet.

At the end JSON structure is not nice to manipulate - neither in ioBroker nor in HA.
I am reading the km200 data with node-red as well and create the entities by using mqtt discovery.
This works nice and it would be possible to create single entities for all switchpoints. while reading the JSON.
Today the switchPrograms are just read-only sensors with JSON-content (text).

[MichaelDvP]

Telegram structure of one day looks like this with 2 active switchpoints:
P1 P2 P3 P4 P5 P6 ...........................P12
14 01 58 03 FF 03 FF 03 FF 03 FF 03

Ah, ok, first time, second mode. (RC35 have reverse order).
My question is: is this ordered? Or is it possible to have two setpoints this way (second and last set, others unset, last is before second):
FF 03 58 03 FF 03 FF 03 FF 03 14 01

I think we do not need the index 01, 02 etc ... in JSON

If it is not ordered and we want to skip all unset points, we need the number to edit/delete a position. Or we always have to publish/write all unset values.

Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off"

Does this affect all? Is it really possible to set a cirulation pump to "comfort", or heatingscircuit to "on"?
Or (what i think is more logical) does it depend on telegram: hc: comfort/eco, dhw: high/low, circulation on/off?

temps: Number("0x" + hex) / 2

Again: is there a limit? Is it possible to set temp to 3 (1.5°C) or 0xFF (127,5°C)? Or can we use the number to show mode for FF, 3, 2, 1, 0 and temp for all other values.

[tp1de]

Ah, ok, first time, second mode. (RC35 have reverse order).
My question is: is this ordered? Or is it possible to have two setpoints this way (second and last set, others unset, last is before second):

I have never seen non-ordered telegrams. An index is not necessary and is not used within original Bosch API
All unset values use "0xFF" for time and in my case "03" for value. (hc's with level). Temp values can be between 5 (off) and 30.

If it is not ordered and we want to skip all unset points, we need the number to edit/delete a position. Or we always have to publish/write all unset values.

I do always publish a full day if changed (12 bytes including unset points) - So max 7 telegrams
But writing just 2 switchPoints (4) bytes should work as well. (if there has been 2 before)

Levels: "FF": "on" / "03": "comfort" / "02": "high" / "01": "eco/low" / "00": "off
Does this affect all? Is it really possible to set a cirulation pump to "comfort", or heatingscircuit to "on"?
Or (what i think is more logical) does it depend on telegram: hc: comfort/eco, dhw: high/low, circulation on/off?

Decoding for reading telegram is as defined. But possible enum values for writing are:
hc level: "eco/low", and "comfort" (for my gas boiler - we might need to check heatpumps maybe "off" as well")
dhw (buffer): "off", "eco/low" and "high"
dhw cp: "off" and "on"

Again: is there a limit? Is it possible to set temp to 3 (1.5°C) or 0xFF (127,5°C)? Or can we use the number to show mode for FF, 3, 2, 1, 0 and temp for all other values.

Minimum temp is 5°C (off) and maximum is 30°C - the same for manual hc values. Only used for absolute temp telegrams.
Absolute temp telegram have a separate type and can be identified easily depending on value of switchprogmode.

[MichaelDvP]

The switchtimes do not deliver any values / results yet.

Upps, added the missing register/fetch for the telegrams in 3.7.0-test32

[tp1de]

@proddy @MichaelDvP

I implemented a prototype to manage EMS2.0 and EMS+ switchPrograms within Home Assistant using the HACS Scheduler compoment and Node-Red. This solution uses raw hex telegrams send / read by MQTT. It works fine, but was quite tricky for my RC310 thermostat.

I wrote a document about my findings during this process and some analysis I have done on my original Bosch / Buderus gateway.
I made a proposal what needs to be done within EMS-ESP to support these entities in a better way.
Please have a look. I hope that I have been clear enough ....

EMS switchPrograms.pdf

[MichaelDvP]

I've updated the test build https://github.com/MichaelDvP/EMS-ESP32/releases/tag/test
this should give a json structure for

• api/thermostat/hc1/switchtime1
• api/thermostat/hc1/switchtime2
• api/thermostat/dhw/switchtime
• api/thermostat/dhw/circswitchtime

the switchtime1/2 depends on setting of hc1/switchprogmode.

I have not tested writing yet, the implementation is to send a single time in one command as json: "value":{"day":"mo","time":"06:15","mode":"comfort","id":0}. Writing a complete program needs 42 commands, but editing is much easier.

Also mqtt is not implemented. I think of an extra topic thermostat_swichtimes as nested or thermostat_switchtime1_hc1, thermostat_circswitchtime_dhw, etc as not nested.

[tp1de]

I installed your testbuild. 1st test (read) is ok.
I would just recomment to keep the modes in English - today the are translated. This makes any logic flow to integrate in UI components (e.g. HASS scheduler) language dependend.

Writing should be per day with up to 6 switchTimes. How do you indicate otherwise deleted switchTimes?

... and may I repeat my recommandation to name the entities switchprograms. The switchtimes are the times to switch within...

[MichaelDvP]

I would just recomment to keep the modes in English

Ok

Writing should be per day with up to 6 switchTimes.

Does not work with RC20, RC30 and RC35 where day is coded and can be anywhere in the 42 data, Then i have to write all 42 at once.

How do you indicate otherwise deleted switchTimes?

Reading: values are ignored, writing with {"mode":"not_set",...}

.. and may I repeat my recommandation to name the entities switchprograms. T

We have translated word switchtimes, so i take this. Renaming and translating is a lot of work. If we have a complete concept and stick to it, we can rename. For now i dont make all the translations.

I've updated, setting should work now.

[MichaelDvP]

I think it's fixed now (bin will be generated in about 10 minutes), reading the new program should be a bit faster, but still we have to wait for next telegram. I use only one buffer for the program to save memory.

[tp1de]

I do not see any changes in respect to timing. It still takes 2 cycles until mode changes are seen.

Updating non int values on "Absolute" mode is working now without error messages but no update takes place.
Next mqtt topic send is still old values which is resetting to old values within my node-red flow. (changing times)
I need to check my flow it this comes from me.

[tp1de]

I think I found what causes the problem:

While updating thermostat_switchprograms I send data for 5 days (workdays), 2 days (weekend) or 7 days for (daily).
The code will transform this to telegram send. There are regular messages: Last Tx write rejected by host
The result will be that not all days are updated. Since I take Monday for workdays and Saturday for weekend this results in the situation described.

I still have my node-red workflow requesting and sending raw telegrams. While sending I send telegrams per day.
Doing this without any delay will result in the same result (errors). I tested different delays. Having more then 100 msec inbetween it is working reliable. I decided to use even 1000 msec to be on the save side.

I tested the behavior while changing the switchProgram with the MyBuderus app using the km200 gateway. While copying the values from one day to all other 6 days there are 3 telegrams send (2 days within one telegram). The delay is approx 400 msec between the telegrams send.

[MichaelDvP]

I've updated to a logic to readback the part after bus write before rend the next part. Maybe this gives the delay needed.
Also writing the absolute telegram should work now. After the mode change i trigger a read out of order of normal fetch interval, i think faster is not possible, or we have to fetch and buffer all 4 timer-telegrams.

[tp1de]

After the mode change i trigger a read out of order of normal fetch interval, i think faster is not possible, or we have to fetch and buffer all 4 timer-telegrams.

Yes it it is working for mode changes (next cycle) . Still not for changes of program (2 cycles)

I've updated to a logic to readback the part after bus write before rend the next part. Maybe this gives the delay needed.

Updates still do not work reliable. Approx 30-40% without errors (Last Tx write rejected by host) and the rest have 1 to 3 errors while updating 5 days.
I tested to send the update twice with 5 seconds inbetween - this is updating then all days but will this be 100% ?

[tp1de]

I tested again with my raw telegram version.

• using a telegram per day a time delay > 200 msec is sufficient not to get tx write errors
  but this doesn't mean that in all cases all days are updated !!
• using telegram length of 2 days a delay of > 400 msec is needed
  but still with some write errors and some days are not updated

I get for some tx writes error messages in log like "Last Tx write host reply: 0xB0" with different hex values.
What is the meaning for this log entries?

[MichaelDvP]

Updated with 400ms delay between sending telegrams with same type-id. Please check.

[MichaelDvP]

I get for some tx writes error messages in log like "Last Tx write host reply: 0xB0" with different hex values.
What is the meaning for this log entries?

The reply should be OK (01) or REJECTED (04), other values are not known.
I show them, but think this is not a reply and the master timeouts and just send a new poll to a different device. But maybe there is another reply code we don't know.

[tp1de]

I did extensive tests with more then 100 updates on switchprograms on my heating system.
At the end I can't avoid errors on read requests (Last Tx Read operation failed after 3 retries. Ignoring request: 0B 10 FF 00 02 09 0C) or on write requests (Last Tx write rejected by host).
Testing with raw telegrams these errors are less often when increasing the delay inbetween the commands.
But even with 2 seconds inbetween there are errors on maybe 5-10% of all cases.
Your updated testbuild with 400ms delay produces less errors but it is not error free.

At the end the update of switchprograms is not reliable since there is a chance of having 1-2 days not updated.

I do not see any difference between km200 ems-esp initiated commands towards thermostat. Maybe you can see the difference?
watch.txt

The gateway intializes non used switchTimes with "FF FF" while we are using "03 FF". I tested both versions on my raw version. This does not have any effect on the tx write errors.

I have no idea what to do else ......

[MichaelDvP]

Difficult, there are two commands withing a few ms, Why? So i can't see what was rejected, what executet.
Differences to gateway:

• gateway delay is around one second
• gateway sends a small block first (12 bytes), and larger after, ems-esp starts with 24 bytes.
  I'll update to 1 sec delay and 12 bytes first, maybe this works better. (-test.10)
  Please try to change one time per block, and log states before and after write, s we can see if a reject ignores the values or writes them. There is a reject, but thermostat publishes the first part, what normally only happen after a successful write.

[tp1de]

• gateway sends a small block first (12 bytes), and larger after, ems-esp starts with 24 bytes.

This because of MyBuderus app logic. First you can change the schedule of one selected day and then saving it. Than copying to all other days.

• Please try to change one time per block, and log states before and after write, s we can see if a reject ignores the values or writes them.

I have done it - the rejected days are not written
And don't forget that read request (raw) give errors sometimes as well:
2024-11-23 12:17:03.575 I 56: [command] Called command system/send (Sende EMS-Telegramm) with value 0B 90 FF 3C 0C 01 C4
2024-11-23 12:17:25.174 E 57: [telegram] Last Tx Read operation failed after 3 retries. Ignoring request: 0B 10 FF 00 01 C4 0C

[tp1de]

I tested -test.10 version with changing workdays (MO-FR) - 5 days are 3 telegrams.
Out of 10 times testing only one or two times are without errors. But delay is not 1 second:
watch1.txt

[MichaelDvP]

Oh, fixed the delay now.

And don't forget that read request (raw) give errors sometimes as well:
2024-11-23 12:17:03.575 I 56: [command] Called command system/send (Sende EMS-Telegramm) with value 0B 90 FF 3C 0C 01 C4
2024-11-23 12:17:25.174 E 57: [telegram] Last Tx Read operation failed after 3 retries. Ignoring request: 0B 10 FF 00 01 C4 0C

The error is not from that telegram sent 22 sec before. Also does not look like a read. Please send complete logs to see the context. Snipplets are mostly not usefull.

[tp1de]

With 1 second delay the number of tx write errors are a bit lower but there is no general change.

[Tim19791]

Hello,
Are there instructions on how I can get the entities, switchProgram A and B: hc1 from the RC310 into the iobroker?
Software is v3.7.2. Retrieved from https://github.com/MichaelDvP/EMS-ESP32/releases
Unfortunately these entities do not exist, what else do I need to do?
Thanks!

Hallo,
gibt es eine Anleitung wie ich die Entitäten, switchProgram A und B: hc1 von der RC310 in den iobroker bekomme?
Software ist v3.7.2. Von https://github.com/MichaelDvP/EMS-ESP32/releases
Leider sind diese Entitäten nicht vorhanden, was muss ich noch tun?
Danke!

[tp1de]

You need to install the latest test version from Michael .
The active switchProgram is then within switchprog.
The active version depends on program (1 or 2) and type ( Level or Absolute).

[tp1de]

@proddy @MichaelDvP I recommend to release the switchPrograms to dev version.

The tx write errors which happen sometimes are not related to switchPrograms. #2273
(I updated my ioBroker adapter and my node-red flow to issue the updates 3 times with some timedelay. This works)

[proddy]

ok. we would need some documentation too on how to use it and it's limitations. not everyone will use HA and NodeRed

[MichaelDvP]

It's mostly self explaining and in line with other entities, except that value is a json and build at publish time (stored only the raw telegram of 84 bytes).
Api shows entity thermostat/hc1/switchprog with type json and value as json array, attribute filtering works.

{"name":"switchprog",
"fullname":"hc2 switchprogram",
"circuit":"hc2",
"type":"json",
"value":[{"no":0,"day":"mo","time":"05:50","mode":"on"},{"no":1,"day":"mo","time":"21:30","mode":"off"},{"no":2,"day":"tu","time":"05:50","mode":"on"},{"no":3,"day":"tu","time":"21:30","mode":"off"},{"no":4,"day":"we","time":"05:50","mode":"on"},{"no":5,"day":"we","time":"21:30","mode":"off"},{"no":6,"day":"th","time":"05:50","mode":"on"},{"no":7,"day":"th","time":"21:30","mode":"off"},{"no":8,"day":"fr","time":"05:50","mode":"on"},{"no":9,"day":"fr","time":"21:30","mode":"off"},{"no":10,"day":"sa","time":"06:20","mode":"on"},{"no":11,"day":"sa","time":"21:30","mode":"off"},{"no":12,"day":"su","time":"07:00","mode":"on"},{"no":13,"day":"su","time":"21:30","mode":"off"}],
"readable":true,
"writeable":true,
"visible":true}

In mqtt this is published as extra topic thermostat_switchprog to not blow up the thermostat_data.
Command is as expected cmd: switchprog and value: as jsonObject { } for a single time or as jsonArray [{ },{ },.. ]for many switchtimes at once. Writing all at once (4 telegram parts for 84 bytes) seems to be randomly rejected by thomas' RC310, on my RC35 it always work.

Web shows this entity like a command without value, only an arrow.

You can enter a json in the input field.

If we want to edit the switchprog in web, this should go to an extra page. It has too much inputs fields.

Should work for RC35, RC20, RC3x0 and some junkers, but tested only for RC35 and RC310.

RC3x0 holiday modes are not implemented yet, but i want to do it similar as json and publish as own topic thermostat_holidays.

[Marcwa19197]

Would be great to see this feature added!
Also one note, you can choose between "levels" (2-temperature level, one for day and one for night) and also you can choose a switchprogram with exact temperatures.

Using exact temperatures you need to also define the "Absenkschwelle" under which temperature nightmode / reduced mode will be activated. This value is also missing right now in EMS-ESP, but if you plan to include the timing settings you will also need to be able to set this value (if you use "exact temperatures", not 2-level temperatures).

(its in german, sorry :-))

[tp1de]

The "Absenkschwelle" is defined in hcx reducetemp.
Btw this is active on Levels .

[Marcwa19197]

On my side, using a RC310 im not able to set the "Absenkschwelle" using 2-Level Mode, only while using absolute mode.

Also i do not have the "reducetemp" entity... The value set on "Absenkschwelle" tells the switchprogram under which value defined in the program reducetemp / reduce mode should be active.

For example if i set Absenkschwelle to 17°C i can define a absolute switchprogram starting at 8pm to 16°C then starting at 8pm heating will be go into reducemode (or will be off, depending on the setting) because 16°C is lower then 17°C defined in Absenkschwelle...

[tp1de]

You are not using the hc controlmode depending on outside temp, isn't it?
Do you have an outside temp sensor installed?

"reducetemp" and " noreducetemp" define outside temps for hc controls.
You are looking for "Absenkschwelle" for room temperature, which isn't defined yet within ems-esp.

[Marcwa19197]

I do use with outdoortempsensor and with room-influence.
See attached.

German:
Ich nutze die außengeführte Regelung mit Raumeinfluss (RC100 in der Wohnung), ich bin der Meinung, dass man die Absenkschwelle nur setzen kann, wenn man mit der "frei einstellbaren Temperatur" im Zeitprogramm arbeitet. Dann wird unter der eingestellten Temperatur der Absenkschwelle der absenkbetrieb aktiv (der wiederum je nach einstellung entweder einen reduzierten Betrieb unter einer eingestellten Außentemperatur fährt oder die Heizung komplett abschaltet). So steht es auch in der Anleitung von Buderus. War auch für mich anfangs verwirrend, ich konnte es aber gegentesten.

Stelle ich im Zeitprogramm eine frei wählbare Temperatur unterhalb der definierten Absenkschwelle ein, geht die Heizung ab dieser Zeit in den "Nacht/Absenkbetrieb". Oberhalb der Schwelle läuft sie ganz normal weiter.
Ich habe bei mir die Absenkschwelle auf 19 °C und ab 23:30 Uhr auf 17 °C im Zeitprogramm gestellt, "Absenkbetrieb unter" ist auf 0 °C Außentemperatur gestellt. Das hat zur Folge, dass ab 23:30 die Heizung, sofern es über 0 °C Außentemperatur ist, komplett aus bleibt. Ab unter 0 °C (und nach 23:30) wird im reduzierten Betrieb mit Solltemperatur 17 °C geheizt

Thermostat_RC310_RC3*0, Moduline 3000_1010H, CW400, Sense II, HPC410.csv

English CSV export:
Thermostat_RC310_RC3*0, Moduline 3000_1010H, CW400, Sense II, HPC410-2.csv

[Marcwa19197]

"reducetemp" and " noreducetemp" define outside temps for hc controls. You are looking for "Absenkschwelle" for room temperature, which isn't defined yet within ems-esp.

Yes, this is what i wanted to know. But it makes sense, if the switchprogram functionality will be added to also add the "Absenkschwelle" because it is needed for the absolute switchprogram.

[tp1de]

So richtig verstehe ich deine Regelungsparameter nicht. Ich habe einen RC310 mit Außentemperatur-geführter Regelung mit Raumeinfluss und benutze Levels.

Dann kann ich mit reducetemp die Außentemperaturschwelle setzen unter der der Absenkbetrieb aktiviert ist und mit noreducetemp die Schwelle wo durchgeheizt wird.

Ich bin aber aktuell nicht zuhause um zu testen.

P.S.:
Du verwendest sehr hohe Vorlauftemperaturen. Das heißt die Wohnung ist schlecht gedämmt. Die Heizung dann oberhalb von 0 Grad auszuschalten macht energetisch keinen Sinn

[Marcwa19197]

Genau, an der Dämmung sind wir dran :-).. anderes Thema...

Wir verwechseln hier die Parameter, es gibt nämlich insgesamt drei:

• "hcx no reduce below temperature" --> Durchheizen auf Tagestemperatur "absenkbetrieb unterbrechen" (vor allem wenn es zu kalt wird)
• "hcx off/reduce switch temperature" --> Ab unter X °C reduzierter Betrieb
• "Absenkschwelle" --> Der Parameter fehlt aktuell im EMS-ESP. Er wird benötigt um im Zeitprogramm bei "frei einstellbarere Temperatur" zu sagen ab welcher Uhrzeit der reduzierte Betrieb erfolgen kann. Da man im frei einstellbaren Zeitprogramm nur eine Temperatur oder "Aus" im Programm einstellen kann. Stelle ich nun den fehlenden Parameter "Absenkschwelle" auf z.b. 19 °C und im Zeitprogramm dann ab 23:30 Uhr auf "unter 19 °C" weiss das RC310 dass es ab dieser Zeit in den "reduzierten / Nachtbetrieb" laufen soll... Ist etwas schwierig zu erklären, vor allem noch auf englisch. Aber schaue es dir gerne mal bei Gelegenheit an.

Die Absenkschwelle, die ich meine, wird nämlich im Bedienermenü Heizung -> Absenkschwelle eingestellt und ist nur sichtbar, wenn auf "frei einstellbare Temperatur" gestellt wurde. Bei dem 2-Temperatur-Niveau wird diese nicht benötigt, da ich da im Zeitprogramm einfach nur sage wann "Tagbetrieb" und wann "Nacht/reduzierter" Betrieb.

In der Print-Variante des Handbuchs steht folgendes (in der Online-Anleitung wurde der Absatz leider anders beschrieben):
"Temperatureinstellungen über das Zeitprogramm anpassen.
Wenn für einen Zeitabschnitt die Temperatur unterhalb der eingestellten Absenkschwelle liegt, ist in diesem Zeitabschnitt der Absenkbetrieb aktiv (z. B. eingeschränkter Heizbetrieb oder Heizung aus)."

Sorry for writing in german... complicated topic :D

[tp1de]

I added a new GH issue for the missing entity: #2288