waterpump and hot water state

[marcelveldt]

Hi guys, great work with this so far!

While testing I discovered these issues/wishes:

• hvac action attribute of climate entity is always idle. Should be of state heating, cooling or idle.

• no separate sensor for hot water state (domestic hot water in api)

• the water_heater entity has state "heating" if my heatpump is cooling.

• device for the boiler is named after the entity (boiler temperature) which should just be "boiler"

My setup:

Anna thermostat Intergas Xtreme CV-ketel Techneco Elga warmtepomp/heatpump

So, in fact my heatpump can be of state idle, heating or cooling at the same time the traditional boiler could be providing hot water. Worst case scenario if the heatpump is having a hard time, the traditional boiler can also be hating (with or without the heatpump).

For starters it would be great to have a sensor to tell me the state of the heatpump/boiler (idle, cooling, heating) and a sensor if my heater is providing hot water.

If I see some spare time left I can take a look at the code myself next week(end) or so.

[bouwew]

Hi Marcel, thanks for contacting us, I remember we worked before on the cooling state for the anna-ha component.

What is the firmware version on your Anna? Already 4.0 or still 3.1?

Also, please share your xml-data with us as described here: https://github.com/plugwise/Plugwise-Smile/tree/master/tests (scroll at little down). Attach a zip-file to a message in this topic please.

Let's start with one set of xml-files showing the heat-pump in cooling mode. We are curious to see how both cv-ketel and heat-pump are represented in the xml-data.

[marcelveldt]

Hi @bouwew true, we worked together in the previous component for the cooling stuff. I can help out again but a bit busy atm so filed this report mostly as an observation. Offcourse I'm happy to help out to fix stuff myself if you want.

Anna's firmware is already at 4.0. I'll collect the xml data and get back to you

[marcelveldt]

here's the export of the xml api raw data

[bouwew]

Thanks!

I've had a quick look, I see the known '..._state'-keys: cooling_state, central_heating_state and domestic_hot_water_state. I also see these: slave_boiler_state and compressor_state.

Now the question is, what do these all show in certain scenario's. Can you please collect xml-data when:

• the system is cooling
• the system is heating from the Elga
• the system is heating and hot water is being tapped
• and, if possible, the system is heating from the boiler, with the Elga not active.

Also FYI, the climate-entity is providing the heating- and cooling-demand state of the thermostat(s). At the moment heating-demand is working, via a simple comparison of the set-temperature and the measured temperature, cooling-demand is not. The reason for this is that there are more thermostats in systems with an Adam. By using the heat-demand-status as hvac_action-info it is clear which thermostat is causing the heater-device to become active.

The water_heater now represents the heater(to add: cooler)-device state in the form of the states: idle, heating and hot_water. These 3 states should be extended to show the various operation-modes of your combi-system is my idea.

[marcelveldt]

Good thing is that there is a simple test function on the Elga which let me reproduce the various states ;-)

Just an idea: why not add a seperate sensor or water_heater entity to represent the 3 states:

heatpump state (idle, heating, cooling) heater state: (idle, heating) domestic hot water (idle, heating)

Offcourse this can also be combined in just 2 heater objects, one for the heatpump (supporting heating, idle and cooling) and the traditional water_heater (supporting idle, heating and hot_water)

[marcelveldt]

The slave boiler is the traditional "CV-ketel" btw, connected to the master heater (the elga). The Elga redirects hot water requests to the slave boiler as well as requests for temperature changes the elga can not efficiently handle itself

[CoMPaTech]

Initial data return (JSON) from the testrun looks good, it picks up both setpoints (see below). @bouwew slave_boiler_state and compressor_state can easily be added I guess.

Device 015ae9ea3f964e668e490fa39da3870b
{
   "name":"Smile (Anna)",
   "types":{
      "home",
      "temperature",
      "thermostat"
   },
   "class":"heater_central",
   "location":"a57efe5f145f498c9be62a9b63626fbf"
}"data":{
   "outdoor_temperature":20.2,
   "domestic_hot_water_state":False,
   "boiler_temperature":29.09,
   "central_heating_state":True,
   "central_heater_water_pressure":1.57,
   "cooling_state":False,
   "slave_boiler_state": False, 
   "compressor_state": True
}

Device 3cb70739631c4d17a86b8b12e8a5161b
{
   "name":"Anna",
   "types":{
      "thermostat"
   },
   "class":"thermostat",
   "location":"c784ee9fdab44e1395b8dee7d7a497d5"
}"data":{
   "thermostat":21.0,
   "temperature":23.3,
   "active_preset":"home",
   "presets":{
      "no_frost":[
         10.0,
         30.0
      ],
      "home":[
         21.0,
         22.0
      ],
      "away":[
         20.0,
         25.0
      ],
      "asleep":[
         20.5,
         24.0
      ],
      "vacation":[
         17.0,
         28.0
      ]
   },
   "available_schedules":[
      "standaard"
   ],
   "selected_schedule":"standaard",
   "last_used":"standaard",
   "illuminance":86.0
}

[bouwew]

Thanks for your ideas!

It should not be sensors as these are supposed to provide a number. I will ask the HA-experts how I am supposed to implement a representation of your system.

One more question: is there a setting on the Plugwise app that you have to set to indicate that there is a cooling function present? And/or, are there 2 set-points on the Anna or on the App? A heating-setpoint and a cooling-setpoint?

[bouwew]

I see cooling_activation_outdoor_temperature set to 21 degrees C. Is this setpoint used to determine whether the heating- or cooling-function must be active?

[CoMPaTech]

Wow, lots of sensors on your setup :) Not sure if it helps, but I also spotted thermostat_supports_cooling and elga_status_code (which is 14)

[marcelveldt]

Thanks for your ideas!

It should not be sensors as these are supposed to provide a number. I will ask the HA-experts how I am supposed to implement a representation of your system.

One more question: is there a setting on the Plugwise app that you have to set to indicate that there is a cooling function present? And/or, are there 2 set-points on the Anna or on the App? A heating-setpoint and a cooling-setpoint?

With sensors I mean both binary sensors and numeric (or text) sensors. I can give you some hints as I'm also working on the new z-wave implementation for hass, together with some of the core devs. A lot is similar. Bottomline it's good to split up stuff into seperate entities as much as you can. As long as you're providing a unique_id for each entity, the user will be able to hide and/or rename the entity.

So to translate the above json output into some hass states and entities:

outdoor_temperature: should be a numeric sensor with it's own entity

domestic_hot_water_state: This is either a binary_sensor (best choice) AND/OR this is the state of the slave water_heater entity (CV ketel).

boiler_temperature: separate sensor, may also be added to the water_heater entity for the heatpump.

central_heating_state: This means the heatpump (master boiler) is heating. Should be the state of the water_heater entity for the heatpump (maybe also as binary_sensor for the sake of completeness).

central_heater_water_pressure: separate sensor

cooling_state": This means the heatpump (master boiler) is cooling. Should be the state of the primary water_heater entity (heatpump) - maybe also as binary_sensor for the sake of completeness.

slave_boiler_state: slave_heater is heating - this can happen with either the main heater also heating or idle.

compressor_state: Binary sensor only or ignore ?

[marcelveldt]

Wow, lots of sensors on your setup :) Not sure if it helps, but I also spotted thermostat_supports_cooling and elga_status_code (which is 14)

You ignore those. These come from the low level Elga api.

[CoMPaTech]

With sensors I mean both binary sensors and numeric (or text) sensors. I can give you some hints as I'm also working on the new z-wave implementation for hass, together with some of the core devs. A lot is similar. Bottomline it's good to split up stuff into seperate entities as much as you can. As long as you're providing a unique_id for each entity, the user will be able to hide and/or rename the entity.

We can definitely use your help getting this into logic, our current PR is climate only on request of core but as you've seen from the custom_component we are already splitting a lot. The approach is to have multiple PRs following up so we have the bases covered. So we should keep working on the custom_component and get cooling in, but not sure if we can also push that through (just thinking time-wise).

As far as boilers/water_heaters go I'm mostly drawing a blank as (un!)fortunately I'm on city heating :( Bouwe is on discord#devs trying to see if and how things should work in generic terms. Also, what happens if someone has an Adam and couple of Lisa's - how would the setpoints (both hot and cold) then work. Initial suggestion was some custom automations if I read #devs right.

You ignore those. These come from the low level Elga api.

OK, kind of hoped the first one was an indication for what Bouwe was looking for but makes sense since it was in the 'boiler' department of the XML, not the Anna.

(Sidenote, I'm very keen to keep tabs on the zwave stuff and proceedings!)

[bouwew]

Great, thanks for your feedback!

The sensors for the various temperatures are already there, that was easy :)

Let's focus our discussion on the various states. To be honest, I have not yet considered using binary sensors as I haven't really been noticing these very much.

Yesterday, I was thinking about an alternative: using the operation_mode and operation_list parameters of the water_heater entity. We could name the various states that your system can be in. And use the applicable names also for less complex systems. The drawback of this solution, I think: there is no card to properly show the operation_mode in Lovelace? So then a combination of both is probably the most practical solution: a water_heater (showing the states idle, heating and cooling, plus a number of attributes) and two binary_sensors to represent the dhw_state and the slave_boiler_state. And maybe a third binary_sensor showing the compressor_state if there is any use for it.

Then about the climate-component, is there a setting on the Plugwise app that you have to set to indicate that there is a cooling function present? And/or, are there 2 setpoints on the Anna or on the App? A heating-setpoint and a cooling-setpoint? The xml-data shows 2 setpoints for each preset. I see cooling_activation_outdoor_temperature set to 21 degrees C in the xml-data. Is this setpoint maybe used to determine whether the heating- or cooling-function must be active?

[bouwew]

NOT WORKING: 0.1.15b1 There will be a working release soon.

[bouwew]

@marcelveldt please try version 0.1.15b4 (in HACS-settings select show-beta). This update implements what I have described in my post above: the water_heater showing idle, heating or cooling, and the 2 binary_sensors.

[marcelveldt]

Hi guys, sorry for the late reply, was enjoying the nice weather outside. I will do some testing next days with the new version and report back. I did some quick testing today and it wasn't working as expected but I need to look more carefully.

Please note that:

HVAC_ACTION on the climate component should represent the ACTUAL action the device is performing: idle, cooling or heating while the HVAC_MODE is the mode the device is is set to (read: allowed to), like auto, cool/heat, cool, heat.

The api will have some specific states about the state, so if it's cooling or heating. In no circumstance you should "calculate" that in your code as it will not be the same as the real world. Just my 2 cents regarding that.

That said, I did not yet take a close look at the xml output to give some sensible feedback. What I do know is that the plugwise app itself will correctly show the state, it will show an icon for heating, cooling and hot water, same applies for the actual Anna physical thermostat on the wall.

[marcelveldt]

OK, here the first test results:

binary sensor for domestic hot water: works well (only updates a bit slow), it's on when hot water is being tapped (provided by the slave boiler). binary sensor for slave boiler state: works well, it's on when the slave boiler kicks in.

The water_heater entity and the climate entity is another story however. These are not showing the correct states. hvac_action on the climate object is always idle and the water_heater state is heating when it's cooling but I did not have a REAL good test case for that as today the outside temperature is too low. Will take a look later this week when temperatures rise.

I'm using the special test feature in the Elga settings of Anna btw:

[marcelveldt]

BTW: the devices are still very strange... The devices should be the physical devices, containing entities for all states/functionality. So REAL WORLD devices, not made up ones as that will confuse users.

In my case this is what I get:

• device: anna_boiler_temperature I believe this should be a sensor/entity below the physical device for the smile gateway

• device: anna_illuminance this should be below the anna thermostat (physical device!)

• device: anna_outdoor_temperature this should be an entity below the smile gateway ?

• device: Smile ( Anna) gateway very good except it's empty ;-) this one should be the placeholder for all those sensors and the water_heater.

If you ask me, I'd expect two physical devices under the integration: one for the gateway and one for each physical thermostat (in my case Anna)

[CoMPaTech]

The api will have some specific states about the state, so if it's cooling or heating. In no circumstance you should "calculate" that in your code as it will not be the same as the real world. Just my 2 cents regarding that. That said, I did not yet take a close look at the xml output to give some sensible feedback. What I do know is that the plugwise app itself will correctly show the state, it will show an icon for heating, cooling and hot water, same applies for the actual Anna physical thermostat on the wall.

And as you probably are aware we are more bound by what HA requires than what the app allows. So there might be inconsistencies towards the App but core is apprehensive in the good way that all HA thermostats should act the same (regardless if that makes a difference towards the original or a 3rd party app).

device: anna_boiler_temperature I believe this should be a sensor/entity below the physical device for the smile gateway

If you know a better way to handle this in config_entry I'd love to improve it. This actually is your heater device, but HA slams the first sensor found to it. @bouwew we probably should diversify wrt to this - this is confusing as it should be 'heater(_central)' - I'll have another go at it.

If you ask me, I'd expect two physical devices under the integration: one for the gateway and one for each physical thermostat (in my case Anna)

I guess you would expect 3 I guess - the gateway (with outdoor_temp), the heater(_central) and the thermostat.

Update speed

We've decided upon feedback from others involved to update immediately on actions, but back off on the devices. (too much data/too fast) Currently we async update at minimum every 60 seconds, so thats most probably the lag in update speed your are seeing.

[bouwew]

Hi Marcel,

Thanks for getting back to us. Just to be clear, the climate_entity does not support cooling yet, it only supports heating at the moment. I first need input from you, or from somewhere else, on how to determine in what state the Anna has set Elga+CV-ketel combi: in heating- or cooling-mode (ignoring hot water for now). When I know this I will be able to fix the climate entity.

The water_heater should support both heating and cooling, I will check the code, maybe there's a mistake.

Also, I don't want to discuss about the details you mentioned yet, what should be what, let's first get this working, then we can go about setting things straight :)

[CoMPaTech]

Updated my above comment.

As for the device naming/parenting. It doesn't really seem to matter how/what I try. Removing the whatever sensor name after the underscore isn't the issue, but even if I do override that and tell it to put climate/thermostat or sensor it shows up as all sensors on my HA.

I'll have another look tomorrow @marcelveldt - in the meantime if you can get some sets of XMLs we can have a look and see what is possible from the data. Please see @bouwew's request in https://github.com/plugwise/plugwise-beta/issues/29#issuecomment-611510421

[bouwew]

The water_heater state logic is like this:

        if self._cooling_state:
            return CURRENT_HVAC_COOL
        elif self._central_heating_state or self._boiler_state or self._domestic_hot_water_state:
            return CURRENT_HVAC_HEAT
        else:
            return CURRENT_HVAC_IDLE

All looks OK, but if the states in de XML-data do not behave as I have assumed, this is not working. So please provide XML-data for various scenario's.

[marcelveldt]

I can help out myself with the devices stuff. Exact thing implemented in some other integrations too. It's indeed a bit strange to work with.

I will collect the XML data asap and do some more testing. As for the cooling state I think we will have to wait until the outside temperature is above 20 degrees ;-) Looks like the test mode for the cooling function is also not shown on the thermostat itself.

[CoMPaTech]

I can help out myself with the devices stuff. Exact thing implemented in some other integrations too. It's indeed a bit strange to work with.

Cool, I'd love a handy sets of pointers (or a cluestick) :)

[marcelveldt]

The water_heater state logic is like this:

        if self._cooling_state:
            return CURRENT_HVAC_COOL
        elif self._central_heating_state or self._boiler_state or self._domestic_hot_water_state:
            return CURRENT_HVAC_HEAT
        else:
            return CURRENT_HVAC_IDLE

This is OK. Nitty pitty detail is that in my case the central heater isn't providing the hot water (the slave boiler is) and that 2 actions can be enabled at the same time: e.g. the heatpump is cooling while the slave_boiler is providing hot water. But that's the edge case. The binary sensor is the solution for that.

[bouwew]

Understood.

Back to the climate stuff, is there any setting on the Plugwise App, a temperature-setpoint I guess, that you can set to determine when the cooling should become active?

[marcelveldt]

Understood.

Back to the climate stuff, is there any setting on the Plugwise App, a temperature-setpoint I guess, that you can set to determine when the cooling should be active?

Well it's a combination of a few factors:

1) A physical button on the Elga to enable cooling mode on the Elga itself. 2) A upper treshold in the Anna settings for the Elga, once this treshold (outside temp) is reached cooling mode is enabled on the Anna. 3) A below treshold in the Anna settings for the Elga, if cooling is enabled and the outside temp falls below this treshold, cooling mode is disabled on the Anna. 4) If cooling mode is enabled on both the Elga AND the Anna and the temperature falls below the setpoint, the Anna will go into cooling mode (tell Elga to cool). This will not happen directly but there'e some additional logic into play accounting all kind of factors including weather conditions.

So, basically you can determine some stuff from the api calls (I guess):

• is cooling mode allowed (=mode)?
• is the heatpump actually cooling (=state)

[marcelveldt]

[bouwew]

Super, thanks!

[bouwew]

I cannot find the lowest 2 numbers anywhere in the XML-data that you sent before. I probably should try to get this info from Plugwise...

[bouwew]

@marcelveldt we've decided to modify our component like this:

• when there is one master-thermostat: use the climate-hvac_actions to show the status of the heater/cooler-device, and via extra binary_sensors where needed,
• when there are two or more master-thermostats: show the heating-demand per master-thermostat in its climate-hvac_actions, and show the heater-status separately via binary_sensors/water_heater.

The reason for this is that the Adam does not support cooling atm, and the Anna does.

When there's something for you to test, we'll let you know here.

[marcelveldt]

Great to hear, sounds like a solid solution you have in mind, best of both worlds. In the meanwhile I can confirm that cooling is working too!

[marcelveldt]

collected the xml data while cooling was active

[bouwew]

Please test version 0.1.19b1 on HACS. With this version you should no longer have the water_heater. Instead the hvac_actions should be visible in the climate-entity.

[bouwew]

Now I will look at the new xml-data, thanks!

[marcelveldt]

Please test version 0.1.19b1 on HACS. With this version you should no longer have the water_heater. Instead the hvac_actions should be visible in the climate-entity.

Great, I'll give it a shot. Will the sensor still be there ? I need to be able to detect when there's a hot water demand and at the same time I control my floorheating valves with the heating/cooling states. What I mean is that hvac_action should only be heating or cooling (as that is strictly spoken hvac) and a separate binary_sensor for domestic hot water.

[marcelveldt]

In fact, I think it's not a big deal if there's also a water_heater entity when there is only one thermostat if that makes things easier. It's just that hvac_action should represent the current action the device is performing as by hass definitions.

[bouwew]

Yes, everything should be there, except the water_heater.

What is your opinion on the hvac_actions when there are 2 or more thermostats in the home? I have one that covers the livingroom and an extra one in the bathroom upstairs. Some other testers have a total of 5.

[marcelveldt]

Each thermostat has it's own mode, state and action.

So the thermostat itself has a heating demand and thus will have an action of heating. If your CV ketel is actually heating will be a property of the CV ketel itself

[bouwew]

Ok, that is now the present implementation:

• for 1 thermostat the hvac_actions are determined from what the active device in the home is doing, as is shown on the Anna display
• for 2 or more, each thermostat shows it's own heating-demand and the water_heater + binary_sensors show the state of the common active device.

[bouwew]

Is 0.1.19b1 working?

[marcelveldt]

Ok, that is now the present implementation:

• for 1 thermostat the hvac_actions are determined from what the active device in the home is doing, as is shown on the Anna display
• for 2 or more, each thermostat shows it's own heating-demand and the water_heater + binary_sensors show the state of the common active device.

That sounds perfect! I'm about to test 0.1.19b now, first will have to eat my dinner ;-)

[bouwew]

:) My dinner is almost ready!

[marcelveldt]

It's working perfectly fine now. hvac_action property is filled correctly and all other sensors seem to be fine too.

Just one small detail I've noticed is that I now see 2 outside_temperature sensors, not sure what's happening there. Strange thing is that both have a different (but almost similar) value.

[marcelveldt]

[CoMPaTech]

Trying to figure out, but same happened in the testdata I see but with 18.0 and 20.2

[CoMPaTech]

For some reason your Smile reports an outdoor temperature from heater_central - could that be the Elga or something else?

https://github.com/plugwise/Plugwise-Smile/blob/master/tests/anna_heatpump/core.domain_objects.xml has 18.0 on your heater_central and the 20.2 on your Home/building (where the rest of us has it as single).

[marcelveldt]

For some reason your Smile reports an outdoor temperature from heater_central - could that be the Elga or something else?

https://github.com/plugwise/Plugwise-Smile/blob/master/tests/anna_heatpump/core.domain_objects.xml has 18.0 on your heater_central and the 20.2 on your Home/building (where the rest of us has it as single).

That's correct, the Elga has it's own temperature sensor on the outside unit. Anna will prefer that value over the internet data

[CoMPaTech]

Makes sense so it can best accomodate, I'll have a look at how we prefer that over the internet one so it remains a single value. Might need some tweaking, but preferring the Elga would be the best option, agreed?