Hot water temps occasionally fail to come back

[freeranger]

Hi

I am seeing a problem sometimes where the evohome API does not return the DHW temp for some reason. This will happen a few times and then go back to normal. evohome client craps out when this happens: 2022-01-20 12:56:44	stdout	KeyError: 'temperature'
2022-01-20 12:56:44	stdout	"temp": self.hotwater.temperatureStatus["temperature"],
2022-01-20 12:56:44	stdout	File "/usr/local/lib/python3.9/site-packages/evohomeclient2/controlsystem.py", line 111, in temperatures

For DHW you do this: "temp": self.hotwater.temperatureStatus["temperature"], which barfs because "temperature" does not exist.

whereas for the CH zones you set temp to None and then:

if zone.temperatureStatus["isAvailable"]:
    zone_info["temp"] = zone.temperatureStatus["temperature"]

I don't know if that would work for DHW since I don't know if there is an isAvailable property for that? I'm wondering if you could do something similar to what you do with zones (or maybe it is necessary to check if temperatureStatus is None too?

I turned on debug logging in the hope of finding out more and whilst that did report on the http headers etc to the request and the response status, it did not show me the response body so I could see what actually comes back when this error happens.

Unfortunately the problem is quite intermittent - it happened a few times on only 2 out of the last 7 days but happened most days the week before that :/

thanks

[freeranger]

Just to add to this, I did a bit of hackery to go poll the API again via a hand crafted call (vs going through evoclient because I can't get to the data that way) and this is an example of what comes back for DHW:

"dhw": {
    "dhwId": "1572162",
    "temperatureStatus": {
        "isAvailable": false
    },
    "stateStatus": {
        "state": "Off",
        "mode": "PermanentOverride"
    },
    "activeFaults": [
        {
            "faultType": "DHWSensorCommunicationLost",
             "since": "2022-02-20T03:25:03"
        }
     ]
}

Now on this occasion it was permanently set off so the status is fine - perhaps in general it is hitting intermittent communication faults and that is when these failures happen. Confirmed in the above is the presence of the "isAvailable" property for dhw so perhaps the solution is simply to check for that the same as is done foe zones?