Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump geniushub client, handle dead devices, handle raise_for_status #25687

Merged
merged 9 commits into from Aug 4, 2019

Conversation

@zxdavb
Copy link
Contributor

commented Aug 4, 2019

Breaking Change:

None

Description:

Bump geniushub client (less logging, improved device typing, better handling of edge cases)
handle more edge cases, such as dead devices,
handle raise_for_status exceptions correction

Related issue (if applicable): None

Pull request with documentation for home-assistant.io (if applicable): None

Example entry for configuration.yaml (if applicable):

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
  • Untested files have been added to .coveragerc.

If the code does not interact with devices:

  • Tests have been added to verify that the new code works.
zxdavb added 3 commits Aug 4, 2019

@project-bot project-bot bot added this to Needs review in Dev Aug 4, 2019

@ghost ghost assigned zxdavb Aug 4, 2019

@zxdavb zxdavb requested a review from MartinHjelmare Aug 4, 2019

@zxdavb zxdavb marked this pull request as ready for review Aug 4, 2019

zxdavb added 2 commits Aug 4, 2019
try:
if device.type[:21] in GH_IS_SWITCH:
switches.append(GeniusBinarySensor(client, device))
except (AttributeError, TypeError):

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Aug 4, 2019

Member

Why would there be these errors?

This comment has been minimized.

Copy link
@zxdavb

zxdavb Aug 4, 2019

Author Contributor

By design, the client library returns 100% the same JSON as the vendor would via a cURL request.

For some edge cases, device['type'] == None, and for others 'type' in device == False. At some stage I do a self.__dict__.update(obj_dict) and so device.type reflects this.

The systems is based upon zwave, and one such edge case is when the devices has not been heard from for a while. Have a look at device 4, below.

(venv) dbonnes@vm-builder:~/client_apis/geniushub-client$ python ghclient.py ${HUB_ADDRESS} -u ${USERNAME} -p ${PASSWORD} devices
WARNING:geniushubclient:Device 4, 'Room Thermostat': has no fingerprint, so has no type.
[{"id": "2", "type": "Dual Channel Receiver"}, {"id": "2-1", "type": "Dual Channel Receiver - Channel 1"}, {"id": "2-2", "type": "Dual Channel Receiver - Channel 2"}, {"id": "4"}, {"id": "6", "type": "Smart Plug"}, {"id": "8", "type": "Genius Valve"}, {"id": "9", "type": "Genius Valve"}, {"id": "10", "type": "Genius Valve"}, {"id": "11", "type": "Genius Valve"}, {"id": "13", "type": "Room Sensor"}, {"id": "14", "type": "Room Sensor"}, {"id": "15", "type": "Room Sensor"}, {"id": "16", "type": "Room Sensor"}, {"id": "17", "type": "Room Sensor"}, {"id": "19", "type": "Radiator Valve"}, {"id": "20", "type": "Radiator Valve"}, {"id": "22", "type": "Radiator Valve"}, {"id": "25", "type": "Radiator Valve"}, {"id": "27", "type": "Genius Valve"}, {"id": "29", "type": "Genius Valve"}, {"id": "30", "type": "Electric Switch"}, {"id": "34", "type": "Genius Valve"}, {"id": "36", "type": "Smart Plug"}, {"id": "38", "type": "Radiator Valve"}]

(venv) dbonnes@vm-builder:~/client_apis/geniushub-client$ curl -X GET https://my.geniushub.co.uk/v1/devices/summary -H "authorization: Bearer ${HUB_TOKEN}"
[{"id":"2","type":"Dual Channel Receiver"},{"id":"2-1","type":"Dual Channel Receiver - Channel 1"},{"id":"2-2","type":"Dual Channel Receiver - Channel 2"},{"id":"4"},{"id":"6","type":"Smart Plug"},{"id":"8","type":"Genius Valve"},{"id":"9","type":"Genius Valve"},{"id":"10","type":"Genius Valve"},{"id":"11","type":"Genius Valve"},{"id":"13","type":"Room Sensor"},{"id":"14","type":"Room Sensor"},{"id":"15","type":"Room Sensor"},{"id":"16","type":"Room Sensor"},{"id":"17","type":"Room Sensor"},{"id":"19","type":"Radiator Valve"},{"id":"20","type":"Radiator Valve"},{"id":"22","type":"Radiator Valve"},{"id":"25","type":"Radiator Valve"},{"id":"27","type":"Genius Valve"},{"id":"29","type":"Genius Valve"},{"id":"30","type":"Electric Switch"},{"id":"34","type":"Genius Valve"},{"id":"36","type":"Smart Plug"},{"id":"38","type":"Radiator Valve"}]

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Aug 4, 2019

Member

All attributes of an instance should always be initialized in init method. After init the instance should be considered complete.

TypeError is also a sign that we should do something different, either here or in the library.

This comment has been minimized.

Copy link
@zxdavb

zxdavb Aug 4, 2019

Author Contributor

Yeah - as I was explaining it to you, I realized it was a bad idea (and a recent change from deeper testing) - was just hoping I could get it past you & fix it later...

Everything is initialized in __init__, though.

Are you happy with if self.type is not None?

This comment has been minimized.

Copy link
@zxdavb

zxdavb Aug 4, 2019

Author Contributor

All attributes of an instance should always be initialized in init method. After init the instance should be considered complete.

How does that fit in with the @property decorator?

This comment has been minimized.

Copy link
@MartinHjelmare

MartinHjelmare Aug 4, 2019

Member

How do you mean?

This comment has been minimized.

Copy link
@zxdavb

zxdavb Aug 4, 2019

Author Contributor

Don't worry, I think I got it

  • self.id is fixed, so is set as an instance attribute in __init__
    self.id = data['id']
  • self.name, self.type are variable, so set via functions with @property decorator:
    @property
    def type(self) -> Optional[str]:
        """Return the type of the device."""
        return self.data.get('type')
homeassistant/components/geniushub/__init__.py Outdated Show resolved Hide resolved
zxdavb added 4 commits Aug 4, 2019

Dev automation moved this from Needs review to Reviewer approved Aug 4, 2019

@MartinHjelmare
Copy link
Member

left a comment

Looks good!

@MartinHjelmare MartinHjelmare merged commit b0c79c2 into home-assistant:dev Aug 4, 2019

11 checks passed

CI Build #20190804.42 succeeded
Details
CI (FullCheck Mypy) FullCheck Mypy succeeded
Details
CI (FullCheck Pylint) FullCheck Pylint succeeded
Details
CI (Overview CheckFormat) Overview CheckFormat succeeded
Details
CI (Overview Lint) Overview Lint succeeded
Details
CI (Overview Validate) Overview Validate succeeded
Details
CI (Tests PyTest Python36) Tests PyTest Python36 succeeded
Details
CI (Tests PyTest Python37) Tests PyTest Python37 succeeded
Details
cla-bot Everyone involved has signed the CLA
codecov/patch Coverage not affected when comparing 73f5575...981b9a8
Details
codecov/project 94.02% (target 90%)
Details

Dev automation moved this from Reviewer approved to Done Aug 4, 2019

@lock lock bot locked and limited conversation to collaborators Aug 5, 2019

@zxdavb zxdavb deleted the zxdavb:tweak_geniushub branch Sep 1, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
3 participants
You can’t perform that action at this time.