@Isablend Woops! Your log is not from the latest version of the custom component (my fault).
I have now pushed the latest change to github.com/zxdavb/evohome/master/evohome.py.
Would you mind trying again? Or would @bc1871 have a go if you’ve still got one unavailable zone?
@matthewcky2k You’ll recall you kindly gave me access to your location so I could do some DHW work? 
This is what I see, attached. If you are using the latest custom_component (last updated about an hour ago), maybe you could send me an extract of your logs: grep 'available' home-assistant.log | head -n 20 and grep 'self._status' home-assistant.log | head -n 20
Maybe check your groups.yaml?
I did wonder when I saw the time on the file was uploaded 14 hours earlier. Anyhoo, below is the latest log from the new code. log.yaml (189.1 KB)
Sorry I’ve just provided the full content for speed of response.
The data I want is in there - will have a look, but I have to get the kids from school now.
I’m using the latest custom component does this have a cache or somthing that’s maybe causing the issue?
My groups.yaml is correct and it’s shows the same in the states in HA
I’ll get the logs for you.
@Isablend The good news is that the data is coming back from Honeywell’s website - so the issue must be with my code…
Let me have a look at it.
Oh. That’s a bad news for me.
Not unless you’ve use_hueristics turned on.
Anyway, I’ve found something odd with @Isablend’s latest log file. so…
On line 301 of custom_components/evohome.py the line of code looks like this:
# _LOGGER.debug("setup(): domain_data['config']: %s", tmp)
Could you replace the # with a space (make sure you keep the indents lined up), and send me another copy?
_LOGGER.debug("setup(): domain_data['config']: %s", tmp)
Code adjusted as described. Attached the updated logs following a restart this morning. log.yaml (187.4 KB)
@Isablend Could you try turning off high_precision & see what happens?
[IGNORE]: I am also pushing out another commit later today with even more logging!
[EDIT]: Found the bug, will commit a fix very soon. Thanks @Isablend (provided logs) and @matthewcky2k (provided access to DHW) - I wouldn’t have found it without your help.
Until then, turning off higher precision temperatures is a work-around.
@zxdavb You got there before I could provide more logs When I switch high precision off the unreported room started providing status. Awesome, really impressed with how this works. I’ve come from the Vera environment so gradually moving across all my components, so this is another which I’m mightily happy with.
OK, a fix has been committed.
The good news is that DHW is now reported with higher precision (same as the zones: 0.1 displayed, 0.01 logged).
Please download & test for me (don’t forget to turn high_precision back on).
@zxdavb Yep that seems to be working, now reporting the decimal place. Will keep an eye out for anything different over the next 244 hours, but seems to have worked. Thanks.
Guys, what’s the lowest/highest temp you can set for DHW?
Lowest is 30 c highest is 85
OK, new version commied 5 mins ago…
Guys,
I’m adding ‘inheritance’ to state (a bit like heuristics, but much safer/sensible).
For example, if a zone in in FollowSchedule mode, and the controller is in Away mode, the state will show Away. However, if the controller is in Away mode, and the zone is in TemporaryOverride, it will show TemporaryOverride.
The current_operation mode will be unaffected & will still be visible in the UI.
So…
DHW doesn’t behave the same as heating zones. For example, DHW is completely unaffected by AutoWithEco, and HeatingOff.
If you go to Away mode, what happens to your DHW if it was in FollowSchedule mode at the time? Does it turn Off?
And does DHW go back to FollowSchedule (from either/both of TemporaryOverride/PermanentOverride) if you use AutoWithReset?
This is post 100 - Oh yeah!