Update to neohubapi version no longer detects thermostats

[gerrowadat]

Hi -- I've been using this integration via hacs for a number of months successfully. I have a neohub with 3 room thermostats (neostat) and a fourth that's acting as a hot water switch.

Earlier today, when I updated the integration, my thermostats were no longer detected. It did, however, detect the hot water switch (which I'm not sure was detected before). I'm happy to do any debugging suggested. The debug logs from the integration are unremarkable:

2021-01-18 21:00:35 INFO (MainThread) [custom_components.heatmiserneo] Adding Switches: [<Entity Hot Water: off>] 
2021-01-18 21:00:35 DEBUG (MainThread) [custom_components.heatmiserneo] Entered update(self)
2021-01-18 21:01:05 DEBUG (MainThread) [custom_components.heatmiserneo] Entered update(self)

I'll try to get youmore debugging info and add to this issue.

[gerrowadat]

More on this: I appear to be able to read from the neohub just fine:

doc@hedwig:~/git/shite/neohub$ cat query.py 
import asyncio
import neohubapi.neohub as neohub

async def run():
  hub = neohub.NeoHub(host='heatmiser-hub')
  hub_data, devices = await hub.get_live_data()
  for device in devices['thermostats']:
    print(f"Temperature in zone {device.name}: {device.temperature}")
    await device.identify()

asyncio.run(run())

doc@hedwig:~/git/shite/neohub$ python3 query.py
Temperature in zone Living Room: 20.7
Temperature in zone Underfloor: 21.0
Temperature in zone Bedroom: 19.7

However, calling get_system() appears to be failing, this looks like a bug in neohubapi.

My raw response from get_system() is:

{"ALT_TIMER_FORMAT":null,"CORF":"C","DEVICE_ID":"NeoHub","DST_AUTO":true,"DST_ON":false,"EXTENDED_HISTORY":"off","FORMAT":2,"GDEVLIST":[1,2,3,4],"GLOBAL_HC_MODE":"heating","GLOBAL_SYSTEM_TYPE":"HeatOnly","HEATING_LEVELS":4,"HUB_TYPE":2,"HUB_VERSION":2142,"NTP_ON":"Stopped","PARTITION":"4","TIMESTAMP":0,"TIMEZONESTR":"UK","TIME_ZONE":0.0,"UTC":1610880192}

neohubapi appears not to like ALT_TIMER_FORMAT being null. This is called in async_setup_entry in climate.py

@stikonas FYI

[gerrowadat]

(Happy to submit a patch btw, but I don't have a copy of the heatmiser developer docs so I'm not sure what the right behaviour is when this case happens).

[stikonas]

I'll take a look. Unfortunately Heatmiser docs is not very clear about reply from get get_system, so I had to guess some stuff.

Hopefully with more users/data points we can make it more reliable.

[gerrowadat]

Happy to help. I am waiting from heatmiser support for my copy of the docs. From my reading, it sounds like we can have ALT_TIMER_FORMAT default to the same thing as FORMAT if it is null, but I can't be sure.

[stikonas]

ok, my reply was

{"ALT_TIMER_FORMAT":2,"CORF":"C","DEVICE_ID":"NeoHub","DST_AUTO":true,"DST_ON":false,"EXTENDED_HISTORY":"off","FORMAT":2,"GDEVLIST":[2,3,4,1],"GLOBAL_HC_MODE":"heating","GLOBAL_SYSTEM_TYPE":"HeatOnly","HEATING_LEVELS":4,"HUB_TYPE":2,"HUB_VERSION":2135,"NTP_ON":"Running","PARTITION":"4","TIMESTAMP":0,"TIMEZONESTR":"UK","TIME_ZONE":0.0,"UTC":1611007259}

so I guess I assumed that it's int.

[stikonas]

By the way, older docs are here https://gitlab.com/virchow-personal/neohubby/-/blob/master/docs/Neohub_Api_For_Systems_Developers.pdf (and there aren't many changes in new version)

And it doesn't mention anything about ALT_TIMER_FORMAT being null. I guess we just need to add another enum value then

[stikonas]

Happy to help. I am waiting from heatmiser support for my copy of the docs. From my reading, it sounds like we can have ALT_TIMER_FORMAT default to the same thing as FORMAT if it is null, but I can't be sure.

Can you try the following patch to neohubapi?

diff --git a/neohubapi/enums.py b/neohubapi/enums.py
index 6e88b49..0ea4f1c 100644
--- a/neohubapi/enums.py
+++ b/neohubapi/enums.py
@@ -23,6 +23,8 @@ class ScheduleFormat(enum.Enum):
 
 
 def schedule_format_int_to_enum(int_format):
+    if int_format is None:
+        return None
     if int_format == 0:
         return ScheduleFormat.ZERO
     elif int_format == 1:

[gerrowadat]

That works. I've also sent you a merge request with something similar. Let me know your preference.

[DrTree]

Ah no, I spotted this when doing the proof of concept and patched locally!
Sorry, we've got a new arrival in the house so not had any chance to contribute recently.

[stikonas]

@gerrowadat I briefly looked at your PR, I think adding these two lines is a bit better. Your change will make it work, but I think it's better to return more accurate information about the state of neohub. If it's none, then let's say it's none.

[gerrowadat]

@stikonas You're right, I will send an updated PR today.

@DrTree No worries, and congrats! I think we can close this actually, as the bug seems to be in neohubapi - although maybe consider rolling back until it's fixed upstream? Up to you.

[stikonas]

Ok, 0.4 is on PyPI but HA did not autoupdate my old installation. (But it installed latest version when I removed config/bdeps folder. So I guess we need to update the manifest.

[DrTree]

Works on my setup after #63

[gerrowadat]

Same, just updated via hacs and all is well. Thanks!