Open benwainwright opened 1 year ago
Would it make sense for something like this to be run as a Github Action on the repo, rather than for everyone's copy to run it? (It could then hook into tests, etc, before output was committed.)
So that's definitely one option. Here is the pros and cons as I see it:
Options one and two would mean no intervention from the maintainer is required at all if the GH team introduce changes. Since I also suspect the main purpose of this package is to support the genius hub 'Home Assistant' integration, option three is going to mean the maintainer would also then need to handle changes to the home assistant core when those updates are made.
Also worth noting: My solution here isn't perfect. The GH team could refactor their code in ways that break my script - for example, I'm looking for a declaration called 'devicesModel' - all it would take would be for the GH team to rename that symbol for the above to stop working.
FYI: Because the v3 API was undocumented, there was a conscious decision to fail for unknown device types.
I do admit that perhaps a better exception would have been appropriate.
I am seeing the the following:
Source: components/geniushub/__init__.py:124
First occurred: 03:38:00 (1 occurrences)
Last logged: 03:38:00
Error during setup of component geniushub
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 288, in _async_setup_component
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/geniushub/__init__.py", line 124, in async_setup
await client.update()
File "/usr/local/lib/python3.11/site-packages/geniushubclient/__init__.py", line 260, in update
super().update() # now parse all the JSON
^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/geniushubclient/__init__.py", line 201, in update
self.issues = [convert_issue(raw_json) for raw_json in self._issues]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/geniushubclient/__init__.py", line 201, in <listcomp>
self.issues = [convert_issue(raw_json) for raw_json in self._issues]
^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/geniushubclient/__init__.py", line 161, in convert_issue
device_type = self.device_by_id[raw_json["data"]["nodeID"]].data["type"]
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: '59'
From debugging I see the cause of the problem is the nodeID
as invalid. That is, in the list of devices this address no longer exist.
To make the code more resilient, the issue is only an issue if the device actually exist. This aligns with what is the display in the Genius App.
I'll create a PR for this.
HI all, sorry for the delay in responding.
My inclination is to go more down the route of #79, where the code doesn't blow up when it encounters something it doesn't know about. For Issues, that means outputting Unknown Device rather than failing.
For the rest, I'm thinking that if we identify the areas of code that would break with unknown types or ids, and then create issues logging that, rather than breaking.
How does that sound as a potential solution?
Travelling at the moment so not a full answer.
Either works for me. Handling exceptions that are throw is all that's needed for situations that are unforeseen.
On Sat, 30 Sept 2023, 12:03 Paul Manzotti, @.***> wrote:
HI all, sorry for the delay in responding.
My inclination is to go more down the route of #79 https://github.com/manzanotti/geniushub-client/pull/79, where the code doesn't blow up when it encounters something it doesn't know about. For Issues, that means outputting Unknown Device rather than failing.
For the rest, I'm thinking that if we identify the areas of code that would break with unknown types or ids, and then create issues logging that, rather than breaking.
How does that sound as a potential solution?
— Reply to this email directly, view it on GitHub https://github.com/manzanotti/geniushub-client/issues/76#issuecomment-1741741236, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVW2WGRHIOGTHH6BCACQHTX474ATANCNFSM6AAAAAAVTARX4Y . You are receiving this because you commented.Message ID: @.***>
I prefer non-break changes of reporting 'unknown device' rather than failing is an improvement and should not introduce other breaking changes.
Hi there!
I have been getting a very similar failure to the one found here: https://github.com/manzanotti/geniushub-client/issues/74 only my issue complains because it can't find 'type' in the dict its found. The stack trace fails in exactly the same place however.
With a bit of investigation, I established your library gets 'friendly device names' and so forth from data that is hardcoded in
const.py
- this of course means that if Genius Hub release new devices, or even update the firmware in such a way that device ids change, things break.With a bit more investigation, I've established that you are getting your mapping data structures from the Genius Hub frontend client. A data object that appears to be completely identical in shape to the one that is causing the problem for me can be found in
https://www.geniushub.co.uk/app/js/bower.js
.To make your library more resilient, I think you need to find some way of automatically fetching that data, otherwise as the maintainer you are faced with the task of continually updating the package to match any updates the GH team do. To do it at runtime would be slow, but it might not be a bad idea to do this either at install or publish time. With that in mind, I've written a python script this evening that essentially does just this: downloads the
bower.js
file, parses it, locates the dict containing the AST for the 'devicesModel', generates a python AST from it, then writes that to disk as a python source file.It's not perfect (and parsing that JS file is particularly slow), but I'd like to work this into something that you can use in your package to make sure that its always up to date. If this works, would you accept it as a PR? Script is as follows: