You are great. Thank you 
@zxdavb For some reason after the 0.81.2 upgrade (I had skipped a few) The DHW entity no longer shows the current temperature nor does it allow graphing through more-info on an entity card. I can see that the climate.dhw entity has the information, how would you access that attribute value? (states.climate.dhw.attribites[“temperature”] doesn’t go deep enough into the nested attribute value to retrieve it.
I had used this to determine whether to stick the boost on the how water but can’t easily see the info now, any ideas?
Is the problem in 0.80.x too?
In any case, I am in the middle of exposing the DHW as a ‘water_heater’ component, a new component introduced in 0.81.x.
I am almost finished with it, but oddly, I have the same symptoms as you describe.
…so it makes sense for me to fix that, rather than to address your issue.
OK - try the latest verison on https://github.com/zxdavb/evohome, YMMV.
It has a hack:
def target_temperature(self):
"""Should return None, as there is no target temp exposed via the api."""
return self.current_temperature
Everything is exposed via device_state_attributes:
2018-11-02 21:08:00 DEBUG (MainThread) [custom_components.evohome] device_state_attributes(999) = {'status': {'dhwId': '999', 'temperatureStatus': {'temperature': 54.0, 'isAvailable': True}, 'stateStatus': {'state': 'On', 'mode': 'FollowSchedule'}, 'activeFaults': []}, 'switchpoints': {'current': {'DhwState': 'On', 'TimeOfDay': '16:30:00', 'DateAndTime': '2018/11/02 16:30:00'}, 'next': {'DhwState': 'Off', 'TimeOfDay': '23:00:00', 'DateAndTime': '2018/11/02 23:00:00'}}}
… or, formatted:
{
'status': {
'dhwId': '999',
'temperatureStatus': {
'temperature': 54.0,
'isAvailable': True
},
'stateStatus': {
'state': 'On',
'mode': 'FollowSchedule'
},
'activeFaults': []
},
'switchpoints': {
'current': {
'DhwState': 'On',
'TimeOfDay': '16:30:00',
'DateAndTime': '2018/11/02 16:30:00'
},
'next': {
'DhwState': 'Off',
'TimeOfDay': '23:00:00',
'DateAndTime': '2018/11/02 23:00:00'
}
}
}
So now I think you use:
states.water_heater.dhw.attributes["temperature"]
or
states.water_heater.dhw.attributes.temperature
You really need to get inside the JSON (here, temperature is the target temp, not the current temp - that’s the ‘hack’ I refer to), but TBH, I do not know how to do that - If you get an answer, please post here.
@zxdavb ok, so I implemented the updated .py file last night. Initially I got some weird results. On reboot I got a warning that there was no hot water storage device (can’t remember the exact message). The display of the entity (climate.dhw) however was perfect i.e. it shows state i.e. on/off and the current temperature of the how water cylinder. When I clicked through to see the state of the history graph however initially it showed a graph of on/off states, but then changed (not re-clicked or anything, it just updated) to display the history graph of a completely unrelated entity (broadband download speed). Didn’t understand this so I left it overnight.
This morning the click through graph is showing what I had expected (and hoped)
The entity card is showing what it did last night;
which is perfect.
The reason I wanted to be able to read the temperature to a sensor was to enable its display on a floorplan. So, I used a sensor definition of;
hot_water_temp:
value_template: '{{ states.climate.dhw.attributes["temperature"] | float }}'
unit_of_measurement: '°C'
friendly_name: "Hot Water Temp"
This works. You’ll notice the device ‘water_heater’ has been substituted by climate. That is because there is no water_heater device, I checked the entity states list However the climate.dhw attribute defintion has changed to more closely (but not exactly) match that of the thermostat. The fact that the water_heater device hasn’t been created I think was part of the initial error message (which only showed once).
The climate.dhw attribute definition now looks like this;
min_temp: 30
max_temp: 85
temperature: 60.6
operation_mode: FollowSchedule
operation_list: FollowSchedule,TemporaryOverride,PermanentOverride
status: {
"dhwId": "1659230",
"temperatureStatus": {
"temperature": 60,
"isAvailable": true
},
"stateStatus": {
"state": "Off",
"mode": "FollowSchedule"
},
"activeFaults": [],
"apiV1Status": {
"temp": 60.56
}
}
switchpoints: {}
friendly_name: ~DHW
icon: mdi:thermometer-lines
supported_features: 4098
Hope this helps, let me know if you need any more info.
Further info:
following the last reboot (to get the sensor definition recognised), I now have an error message for the water_heater.
@Isablend, that doesn’t sound at all right!
Can I first check you’ve got three (3) .py files under the custom components folder? They are:
evohome.py
climate/evohome.py
water_heater/evohome.py
@zxdavb There’s the issue, I don’t have the water_heater/evohome.py file. I’ll go look for it and put it in now.
@zxdavb Ok, so have now added the water_heater/evohome.py and re-booted the system.
climate.dhw still exists as an entity
there are no water_heater entities created
the error message previously reported has gone
Attached the full log files (saved as a .yaml) following the re-boot for the first 5 mins in case you can see if anything else is wrong.system.yaml (2.7 MB)
@isablend Please double check you have the latest version of all three files - this is not clear from your posts.
And I will then look at your (rather lengthy) log file!
The logic for enumerating the evohome devices moved from /climate/evohome.py (where DHW was a climate device) to /evohome.py (where DHW is a water_heater device).
If you update one of these (/evohome.py), but not the other (/climate/evohome.py) you’ll get the behavior that you describe.
If you execute: cat home-assistant.log | grep "Found DHW"", you’ll get:
2018-11-03 10:54:32 INFO (SyncWorker_7) [custom_components.evohome] setup_platform(): Found DHW device, id: 1659230, type: domesticHotWater
2018-11-03 10:54:40 INFO (SyncWorker_19) [custom_components.climate.evohome] setup_platform(): Found DHW device, id: 1659230, type: domesticHotWater
Which confirms the diagnosis (i.e. the second line shouldn’t be there) - you haven’t updated climate/evohome.py!
Someone could help me by letting me know the min/max permissible DHW target temps?
@Isablend I just pushed a fix in the last few seconds that may have caused an issue at you end - don’t forget to update all 3 files!
I don’t use DHW but I use evohome.
I updated from your github. It works but a lot of " _connect(4231727): packet[‘to’] & self._type = True" message. (Hassbian, HA 0.81.4)
Highest is 85 degrees, lowest is 35 degrees. Should be set at 60 degrees or higher to avoid legionnaires.
@zxdavb
have ensured that all three files have been updated to the latest version and done a re-start. Attached the log file with only the evohome loggin turned on (except critical).
system.yaml (64.9 KB)
There are reported errors about there not being ‘current_temperature’ attribute for the thermostat’s, but when I inspect the element after the re-boot it seems to exist. Interestingly enough the rendering of the entity water_heater.dhw now does not show the current temperature as it did earlier, but click through for more-info and a) it is show and b) it is graphed.
The dhw temperature attribute is available for rendering in a sensor.
The graph is constructed using historical data from the SQL database (home-assistant_v2.db). If there is data there, with the same entity ID, then you may get these sort of glitches. In your case, it only has data for the last 20 mins, max (rather than the last 24h).
I set mine to 61C for minimum of 2 hours, once a week, and 58C otherwise (to save money).
These have just been removed, and an update has been pushed.