Add EMS+ holidayModes from RC310 to ems-esp

[tp1de]

The RC310 Thermostat maintains 5 holidayModes hm1 ... hm5.
telegram-types:
hm1: 0x0169
hm2: 0x016A
hm3: 0x016B
hm4: 0x016C
hm5: 0x016D

startStop 6 bytes offset 00 yy mm dd yy mm dd (from to - year = 2000 + decimal (yy))
hcMode 1 byte offset 06 1:AUTO_SAT;2:FIX_TEMP;3:OFF;4:ECO
dhwMode 1 byte offset 08 2:OFF; 3:TD_OFF
assignedTo 4 byte offset 09 FF or 00 FF: active e.g. FF FF 00 00 -> hc1,hc2
2 byte offset 11 FF or 00 for dhw1, dhw2
AUTO_SAT: like Saturdays
TD_OFF: Off with thermal disinfection

Each holidayMode represented in web api of km200 as 4 fields within km1 to km5.:
Values have to be read by read request.

Is there any chance to get the holidayModes within ems-esp?

[tp1de]

5 months old and now I would like to start to work on it by myself.
Since I now learned how to add new entities, I would now like to continue with RC310 holiday modes.

@MichaelDvP @proddy I need your advice / help on the best way to implement:

The RC310 has 5 holiday modes hm1 to hm5 and each hm is linked to a separate telegram type.
For each hmx there are a couple of entities: startStop(char), hcMode(enum), dhwMode(enum), asignedTo (JSON)

When implementing all 5 hm's this will result in 20 new entities. I thought it my be best to use the typeids logic for the 5 telegram types and for displaying with a structure like for hc's.

What do you think? And please help how to implement the code.

[tp1de]

@proddy @MichaelDvP I am a bit astonished not to get any reply from you both.
Nevertheless I implemented the first version for RC310 holiday modes by myself:

I have done it in the following way:

1. holiday modes (hm) are within device thermostat (not per hc). On km200 hm's they are within "system".
2. The hm parameters hcmode, dhwmode and the assigned to switches (hc's / dhw) I implemented for hm1 (0x269) and any changes are then copied to hm2-hm5. Not separate parameters per hm to avoid too many field entries.
3. Working assumption is: only one dhw (dhw1) even if RC310 supports 2
4. hm1-hm5 then have individual Start-Stop Dates (code logic similar to existing set_holiday() but not hc depending.
5. reset to RC310 inactive Start-Stop 01.01.2009-01.01.2009 is done by entering less then 11 characters within Change Value popup.

Observation: Changing Start-Stop:

Gives erratic results on the dashboard screen:

1. The entry disappears from the dashboard and comes back after a minute (fetch from read request)
2. or shows hieroglyphs on the screen: (for one minute)
   

Please tell me if should issue a PR with this functionality.

[proddy]

@proddy @MichaelDvP I am a bit astonished not to get any reply from you both

probably because we both have full-time jobs, work 70hr weeks and spend most of that traveling :-) . I did see your message but thermostats is not my thing; I only own an old RC20. Michael is the expert here.

[tp1de]

probably because we both have full-time jobs, work 70hr weeks and spend most of that traveling :-)

Until 3 years ago this was my situation as well - I know what's it about.
Since this thread is from last year I was unsecure if you want me working on it - or not.

What about the erratic behavior of the "Change Value" and Dashboard screen? Shall I open a separate GH issue?

[proddy]

What about the erratic behavior of the "Change Value" and Dashboard screen? Shall I open a separate GH issue?

yes that's a bug. Please create a new issue for this. Also after changing the value, does it show correctly in the Console (show) or the API (http://ems-esp.local/api/thermostat) as this would help us pinpoint where the bug is.

[MichaelDvP]

I have only RC35, RC300 is in many aspects similar, but in others completley different. I can't tell how this works, and can not test. Also ems+ splits in much more different telegrams.

If i count right we have 5 holiday fields, each with date, hc-mode, dhw-mode, and assigments to hc1-hc4, dhw1 and dhw2.
Thats 45 entitiies for setting holiday, i fear this floods the json. Isn't there a way to display this more compact.
If really create an entity for each hc-assigned imo this should mapped to the hc, so only the active hc-assignments show up (and need storage space).

The dashboard after write is normaly from verify value and shows the updated telegram, do you have manipulated the value on write?

[tp1de]

If i count right we have 5 holiday fields, each with date, hc-mode, dhw-mode, and assigments to hc1-hc4, dhw1 and dhw2.
Thats 45 entitiies for setting holiday, i fear this floods the json. Isn't there a way to display this more compact.
If really create an entity for each hc-assigned imo this should mapped to the hc, so only the active hc-assignments show up (and need storage space).

This was my concern and conclusion as well.
So I I just implemented the 2 modes, assignments to active hc's and 1 dhw for the first hm1 and then copy the values to the other 4 hm's. So for me with 2 hc's and one dhw I get 5 parameter fields and the 5 hm's with Start Stop - so in total 10 fields. Please have a look at the first screenshot. I believe that this is acceptable.

The dashboard after write is normaly from verify value and shows the updated telegram, do you have manipulated the value on write?

I found the reason: Since I update to 5 telegrams (0x269 to 0x26D) I need to secure that type 0x269 ist the last one send.
Type 0x269 is linked to the parameter fields in dashboard display and "Change Value" popup.
And there is a filter on the has_update() to process partial telegrams. I had a coding error there. So has_update() was not always processed after the updates and just by next fetch. Funny enough that the result is dashboard display as shown.
Now with these changes the dashboard display is fine and updates are shown as expected.

For the final code I have only one open question:

Is there any possibility to get the telegram type while processing the set_ function?
Since I haven't found anything I have implemented 5 code blocks: set_hm1() to set_hm5() with same code just different telegram type.

[tp1de]

This is the http://ems-esp/api/thermostat view:

[MichaelDvP]

and then copy the values to the other 4 hm's.

Is this usefull? RC35 have only 2 modes per hc, one for vaccations (away from home, set to low temp) , one for holidays (at home, set to high temp). By copiing the heating modes you can't differ? But you are user of RC300, you know better what to set.

Is there any possibility to get the telegram type while processing the set_ function?

No, you can use the way like temperatures or like switchtime. We have set_switchtime1, set_switchtime2, set_dhwswitchtime and set_dhwCircSwitchtime for the different commands, but all calls the same parser to read the string in set_switchtime with type_id as parameter..

[tp1de]

Is this usefull? RC35 have only 2 modes per hc, one for vaccations (away from home, set to low temp) , one for holidays (at home, set to high temp). By copiing the heating modes you can't differ? But you are user of RC300, you know better what to set.

It's not so much a RC310 topic, rather a question if different settings per holiday period make sense and why are 5 holiday periods needed?

I believe that while defining more then 1 holiday period, normally you will choose same parameters (which hc is involved, ww off / or just thermal disinfection off and hc on eco or off etc). Otherwise parameters can be changed before next period starts.

For those who would like it more complex, they should use the RC310 or the MyBuderus App if system has an internet gateway installed. Parameters are only copied when set by ems-esp and are not overwritten when set otherwise.

[tp1de]

I tested the different scenarios of updating the holiday modes and parameters by dashboard, web-API, km200 API , RC310 and Buderus APP.

Is there any way within the void void Thermostat::process_RC300HM() function to get to know if the update was initiated by web-api, mqtt or by dashboard (so by ems-esp itself), or by changes from external sources (km200 API / RC310 / APPs) ?

I would like to use the copy function of parameters only for ems-esp initiated changes and not for those which come from external sources? Any chance to implement this?

[MichaelDvP]

Api/mqtt/web changes parameters via command and set_ function. process_ is triggered by the incoming telegram, you can check if it is a reply to emsesp-read by if (telegram->dest == EMSESP::txservice_.ems_bus_id()) {, but this happens every minute from fetching and in verfying writes.

[tp1de]

@proddy @MichaelDvP
I made a PR for implementing the 5 holiday modes hm1 to hm5. After testing different ways of implementing I have done it in the following way:

When ems-esp ist starting and on first read of telegram 0x269 the parameters are initialized from 0x269 = hm1 (only once) and only for active hc's:

While changing one of the parameters no write command is written to any telegram. Parameters are just kept when updating one of the 5 hm's.

When updating any of the 5 hm's these parameters are used next to the holiday-period entered. This allows the hm's to have different parameters.
To visualize the assigned parameters they are shown next to the Start-Stop date:

Only changes within the Start-Stop dates are used. Parameters are taken as described above.
To initialize (delete) the holiday period the Change Value content should be less than 10 characters. Period will be 01.01.2009-01.01.2009. (hm not active)

[tp1de]

close since you will not support this function