Ems-esp: Add modes (summer / winter switch) from thermostat CW400

[lsw271]

Is your feature request related to a problem? Please describe.
In thermostat I've got 3 modes (in thermostat it calls summer / winter switch) 1. always summer, 2. summer from X degrees 3. always winter.

Describe the solution you'd like
I would like to control this settings from telnet > mqtt > HA

Describe alternatives you've considered
EMS-ESP sends data to mqtt, commands to change the mode maybe in the future

Setup:
Boiler: Junkers GBx72/Trendline/Cerapur/Greenstar Si/27i (DeviceID:0x08 ProductID:123, Version:06.02)
mine is Junkers CerapurAcu Smart
Thermostat: RC300/RC310/Moduline 3000/CW400/Sense II (DeviceID:0x10, ProductID:158, Version:33.04) Clock: 21:25:08 25/09/2020 and CW400

Additional context
setting to 1. Always summer (i dont know which telegram did this but I tried to catch it :) )

setting to 2. Summer from X degrees:

change temp in mode 2 from 15 to 13 degrees:

setting to 3. Always winter:

[MichaelDvP]

Yes, good catch, it's in telegram 0x2AF, pos6 for the temperature threshold, pos 7 for the mode. This telegram is on Norberts list, but i never know what WDC means. I'll add it to the beta.

@lsw271 OT: Can you also try to catch the telegrams for wWMode and wWCircMode as described in #518

[MichaelDvP]

@lsw271 i've added summermode and summertemp to the dev build, Please check if it works as expected.

[lsw271]

@MichaelDvP could you tell me how I can download dev version? i need to go to dev branch and then what? where i can find the .bin file to upload in EMS-ESP UI?

[lsw271]

@MichaelDvP could you tell me how I can download dev version? i need to go to dev branch and then what? where i can find the .bin file to upload in EMS-ESP UI?

I found this :) https://github.com/proddy/EMS-ESP/blob/firmware/firmware/EMS-ESP-2_1_0b2-esp8266.bin

[lsw271]

@MichaelDvP I am after some testing
Change comforttemp: from telnet and thermostat OK
Change ecotemp: from telnet and thermostat OK
change manualtemp: from telnet and thermostat OK
change temp: from telnet OK, thermostat i think it will be OK but i dont see it in the mqtt (see hc1 below)? it will be added?

Change summertemp:
Many times after sending: "call thermostat summertemp 11" session in telnet goes broken
Temperature is setting double, when I call 11 in thermostat I saw 22, when I call 15 I saw 30. Maybe because the scale is between 10 and 30 degrees?
Change summermode:
also session in telnet goes broken after "call thermostat summermode 0, 1 or 2" but summermode goes changed! ;)
I didnt see summertemp in mqtt?
{
"hc1": {
"seltemp": 0,
"currtemp": 21.3,
"comforttemp": 18.5,
"ecotemp": 16.5,
"manualtemp": 7,
"targetflowtemp": 0,
"mode": "auto",
"modetype": "eco"
}
}

Could we change mode names?
modetype: It will be great to tell apart summer modes. Maybe "asummer" (like always summer) and "xsummer" (like summer from x degrees?), Eco could change name to winter?
mode: auto is ok, but in my CW400 mode heat means "manual". Of course I could also do a template sensor, but I would like to ask first :)

When I changed summermode in thermostat from summer (always summer) to summer from X degrees and the temperature outside was lower than X summermode changed to ECO. Its ok because summer would be upper than X degrees. But I think we should add one more entity calls setModetype which inform us about set mode type (summer, summer from X degrees, ECO), modetype will still be but only to inform us of actual mode (temperature dependent). We will be setting command to setModetype. What do you think?

You have changed temperature names? or it is only in dev build because we have also old topic and it will back to daytemp/ nighttemp later?

When I watched on telegrams in telnet and sends commands i didn't see yellow font with changes, its ok? or it will be added?

[MichaelDvP]

I've fixed summertemp factor and summermode setting should be shown now on console an mqtt.
What do you mean with "telnet goes broken"?

The modetype reports not the setting, but the current state of the thermostat. If summermode is set to x degree and temperature is higher, the modetype changes to summer, (i.e. heating is off).
Mode can be manual/auto and modetype in auto-mode gives comfort/eco for the two automatic switched levels.
In older thermostats like my RC35 these levels called day/night, but in times with more singles one use the lower level over the day when at work, so bosch now calls it "eco". Since the temeratur is related to the mode we have to use consistent names:
modes day/night => daytemp/nighttemp
modes comfort/eco => comforttemp/ecotemp

You have to set log info (or higher) in telnet to see the yellow confirmation messages.

[lsw271]

I understand that modetype inform us about current mode but it will be good to see which mode we setted up. In that case another entity would be helpful. Modetype will be to inform about actual mode, setModetype would be for setting / changing.

"telnet goes broken" means the session in putty went closed with error, i dont remmember error message but putty session went inactive (I can check error message tonight)

[proddy]

@lsw271 the telnet session will automatically close after 2mins of in-activity (timeout)

[lsw271]

Ok, but the session became inactive after sending the command. I will check it tonight and let you know what this message is

[LineF]

I have the same problem (using 2.1.0b2).
ESP seems to crash. Uptime gets resetted to 0.

Uptime: 000+00:02:45.067
Chip ID: 0x008bef69
SDK version: 2.2.2-dev(38a443e)
Core version: 2_7_4
Full version: SDK:2.2.2-dev(38a443e)/Core:2.7.3-3-g2843a5ac=20703003/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-30-g92add50/BearSSL:5c771be
Boot version: 31
Boot mode: 1
CPU frequency: 160 MHz
Flash chip: 0x001640E0 (4194304 bytes)
Reset reason: Exception
Reset info: Fatal exception:28 flag:2 (Exception) epc1:0x40256bec epc2:0x00000000 epc3:0x00000000 excvaddr:0x0000000d depc:0x00000000
Free heap: 11448 bytes
Free mem: 43 %
Maximum free block size: 10888 bytes
Heap fragmentation: 5 %
Free continuations stack: 1248 bytes
Sketch size: 930656 bytes (2211840 bytes free)
Free heap: 11216 bytes
Free mem: 42 %

[proddy]

@LineF that's not good. Can you retrace the steps that cause the crash? Is it idle or during an operation?

[LineF]

I just tried latest version (commit 1043052) but this one is completely broken.
Crashes every view seconds -trying ota update, but I think I have to flash by usb...

With commit 2d2e9398 I only had to give the command "call thermostat summermode 0" (or any other text instead of the "0") and this immediately crashed the software...
...
ok, I'm back on commit 2d2e9398 - gateway is working again

[proddy]

ok, should be easy to find the bug

[lsw271]

ok, so I will waiting for fix before update;)

[proddy]

@MichaelDvP I'm unable to track down the root cause of the problem. I don't have an RC300 and running the standalone test simulation seems to show normal behavior (make run; test km; call thermostat summermode 0). Can you take a look?

[MichaelDvP]

Cause was the new telegrams were not proper checked for hc-number when reading from ems.
I also have no RC300 for testing, but i think it's fixed now.

[LineF]

commit 545ff35 seems to be working now. No reboots any more.
Summermode and summertemp are now shown with the "show" command.
BTW: V2 is a very good piece of work!
Thanks!
Martin

[lsw271]

@MichaelDvP great job! big progress! :)
Telnet session its ok now. But I think I found somethiing to fix (sorry :)). As usual below some screenshots ;)

1. It is normal that summermode once is in hc1, another time (summermode: off) outside the hc1?
   
   
   It will be working ok in HA? I think about right payload

2. When I tried to change ecotemp from 16 degrees to 15 I saw temperature looks like has been changed manual by rotary control. Screenshots are chronologically.

without changes screen

changed to 15

looks ok...

but look here

It should be like below

So I think seltemp should be 0. It will cause temperature and modetype set to _turned off_

[MichaelDvP]

It is normal that summermode once is in hc1, another time (summermode: off) outside the hc1?

Fixed, but the second picture shows modetype: summer and summermode: off. Was this a intermediate display, short after changing the summermode, or a stable display? summermode is a setting to the thermostat, modetype shows the active status of the thermostat, When changing summertemp it can take some 10 seconds until modetype also changes, but than the modes should be consistent.

For the temperatures check what you have set, i'm not sure if it is right or wrong behaviour.

For my thermostat the auto mode switches between two temperatures (night/day or eco/comfort) at given times, When changing the actual setpoint with the wheel or temp-cmd, this becomes temporary active until next switchtime. When changing ecotemp it only effects the actual setpoint if the thermostat is actually on unchanged ecotemp, otherwise it becomes active when the thermostat program next time acitvates the ecotemp.

[lsw271]

Fixed, but the second picture shows modetype: summer and summermode: off. Was this a intermediate display, short after changing the summermode, or a stable display? summermode is a setting to the thermostat, modetype shows the active status of the thermostat, When changing summertemp it can take some 10 seconds until modetype also changes, but than the modes should be consistent.

Yes, you were right it was short after changing.

For the temperatures check what you have set, i'm not sure if it is right or wrong behaviour.

First: I've got summermode set to auto(2), modetype summer. I am changing ecotemp and comforttemp and everything its ok.
Next: I've got summermode set to on (1), modetype summer. I am changing ecotemp and comforttemp and... everything its ok now ;)

Look at the screenshot, I done the same, now the seltemp doesnt change :) did you changed something in code? :)

For my thermostat the auto mode switches between two temperatures (night/day or eco/comfort) at given times, When changing the actual setpoint with the wheel or temp-cmd, this becomes temporary active until next switchtime. When changing ecotemp it only effects the actual setpoint if the thermostat is actually on unchanged ecotemp, otherwise it becomes active when the thermostat program next time acitvates the ecotemp.

Mine has got the same behaviour

[lsw271]

@proddy in HA autodiscovery we will can change those values? Or I need to do some switches, thermostats on my own?

Summary report ;)
I think we've got main useful configuration to set heating circuit temperature on CW400.
We've got:

1. Set manualtemp to working with heat mode. In mine thermostat (CW400) its called just "manual"
2. Set ecotemp / comforttemp to working with mode auto. In mine thermostat (CW400) its called "two levels of temperature"
3. Set summermode
   
   
   
   • 0 = off = always winter
   
   
   • 1 = on = always summer
   
   
   • 2 = auto = summer from X degrees
   
   

We havent got "any temperature setting" mode which means in schedule you need to set any temperature in hours (i don't remember exactly how many but maybe we can set there 6 temperatures). In "two levels of temperature" we've got only two temperatures.

@proddy @MichaelDvP What do you think guys? We shoud finish in this case to set heating circuit temperature on CW400? Or we try to add mode "any temperature setting"? I dont use that mode but I can try to catch telegrams for Michael and later test it. Maybe it will be usefull for someone else? :)

[proddy]

The HA native climate component only understands the 3 modes, heat, off and auto. So can't add them. What you'll need to do is build the trigger yourself to send the MQTT command to EMS-ESP. It's not too difficult though. Create a new input sensor and attach an automation trigger to it. in pseudo code, from the top of my head, something like

input_select:

thermostat_mode:
  name: CW400 mode
  options:
    - mode1
    - mode2
    - mode3
  initial: mode1

automation:

- id: send_cw400_mode
  alias: Send CW400 mode
  initial_state: true
  trigger:
    platform: state
    entity_id: input_select.cw400_mode
  action:
  - service: mqtt.publish
    data_template:
      topic: ems-esp/thermostat
      payload: '{{ cmd:"mode", data:states.input_select.cw400_mode.state }}'

[MichaelDvP]

What do you think guys? We shoud finish in this case to set heating circuit temperature on CW400? Or we try to add mode "any temperature setting"? I dont use that mode but I can try to catch telegrams for Michael and later test it. Maybe it will be usefull for someone else? :)

It would be interresting to see what telegram is used for the scheduls on ems+. For ems it is documented, but for ems+ i also did not find it in Norberts bible. It you can catch some of these telegrams i'll have a look.
But i dont think it will be added to ems-esp. It's a lot of data and the goal of smarthome is to react dynamically to events like coming home. A schedule program is good for 9to5 workers and will never be changed. So don't spend to much time with this.

[lsw271]

Thanks @proddy
I have done something like this, maybe someone will want to use it ;)

of course firt we need to add helpers

- id: send_cw400_heatmode
  alias: Send CW400 heat mode
  initial_state: true
  trigger:
  - platform: state
    entity_id: input_select.tryb_co_termostatu
  action:
  - service: mqtt.publish
    data_template:
      topic: 'ems-esp/thermostat'
      payload_template: >-
       {% if states.input_select.tryb_co_termostatu.state =='auto' %} {"cmd":"mode", "data": "auto"}
                                   {% elif states.input_select.tryb_co_termostatu.state =='ręczny' %} {"cmd":"mode", "data": "heat"}
                                   {% endif %} 
      #payload_template: '{"cmd":"mode", "data": {{states.input_select.tryb_co_termostatu.state}} '

- id: send_cw400_summermode
  alias: Send CW400 summermode
  initial_state: true
  trigger:
  - platform: state
    entity_id: input_select.przelacznik_lato_zima
  action:
  - service: mqtt.publish
    data_template:
      topic: 'ems-esp/thermostat'
      payload_template: >-
       {% if states.input_select.przelacznik_lato_zima.state =='zima' %} {"cmd":"summermode", "data": "0"}
                                   {% elif states.input_select.przelacznik_lato_zima.state =='lato' %} {"cmd":"summermode", "data": "1"}
                                   {% elif states.input_select.przelacznik_lato_zima.state =='lato od X stopni' %} {"cmd":"summermode", "data": "2"}
                                   {% endif %} 
      #payload_template: '{"cmd":"mode", "data": {{states.input_select.tryb_co_termostatu.state}} '

- id: send_cw400_summertemp
  alias: Send CW400 summertemp
  initial_state: true
  trigger:
  - platform: state
    entity_id: input_number.temperatura_tryb_letni
  action:
  - service: mqtt.publish
    data_template:
      topic: 'ems-esp/thermostat'
      payload_template: '{"cmd":"summertemp", "data": {{(states.input_number.temperatura_tryb_letni.state)| round (0)}} }'

[proddy]

I'll add those examples to the MQTT section of the documentation. Closing this.

[lsw271]

@MichaelDvP @proddy i've got now 2.1.0b5 and when i'm trying to change summermode i've got another values than in version 2.1.0b3

summermode in b3(bold mqtt explorer) b3 was a good configuration
0 = summermode off = always winter
1 = summermode on = always summer
2 = summermode auto = summer from X degrees

summermode in b5(bold mqtt explorer)
0 = summermode off = always summer
1 = summermode auto = summer from X degrees
2 = summermode on = always winter

could you fix that?

[MichaelDvP]

Sure, i'm waiting until proddy makes his larger change and than fix it. The last time we are making changes to the same file, the automatic merge kicks the wwtemp/wwtemplow, better to do it one by one.
Would you mind if i call the settings summer, auto, winter? Most setting on ems are 0/1/2 for off/on/auto, only this summermode counts on/auto/off. If we use on/off for 0/2 i'm afraid it will not survive the next larger change.

[lsw271]

Summer / auto / winter will be ok

[proddy]

@lsw271 any chance to check this?

[lsw271]

Tonight ;)

[lsw271]

@proddy @MichaelDvP thanks :) now its great

we've got:
0 = summer
1 = auto
2 = winter