You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked into this and there are a few issues. Firstly I think this probably only makes sense when we can get rid of the SmartRequests helper entirely, otherwise it's quite a bit of duplication. To do this we would need to implement more modules or at least have some kind of placeholder for modules we're not planning on implementing anytime soon, i.e. HomeKit.
Secondly not all the queries would necessarily be returned by the query() method on the module. For example get_wireless_scan_info which (if it was moved into a module) would probably not scan unless a consumer tried to join a network (or it would massively slow down the first device update). These extra calls would need to be exposed somehow by the modules with a function that only dump_devinfo calls which could be considered wrong, although maybe not.
Finally I don't see an immediate gap whereby a query could potentially be added to a Module but not to the SmartRequests helper because as long as we're covered by tests someone would have to generate the fixture with the data for the tests to pass. Unless they add it to the FIXTURE_MISSING_MODULES list in the FakeSmartTransport which I guess we should be careful to avoid.
Anyway, for future reference this is the method I used in dump_devinfo to try to get the requests from the modules if we ever want to use it in the future. One advantage of this was that if the module does an extra check to see if something is supported beyond the ver_code we can re-use the logic to avoid making a request that will fail:
classDummyDevice:
"""Dummy device to initialize a module and get the queries."""def__init__(self, component_id, component_version, device_info):
self._components= {component_id: component_version}
self.sys_info=device_infodefget_smart_component_requests(component_id, component_version, device_info):
"""Get the list of components from the modules."""requests= []
formod_classinSmartModule.REGISTERED_MODULES.values():
ifcomponent_id==mod_class.REQUIRED_COMPONENT:
module=mod_class(DummyDevice(component_id, component_version, device_info), mod_class.__name__ )
ifqueries:=module.query():
formethod, paramsinqueries.items():
requests.append(SmartRequest(method, params))
returnrequests
Here's a list of queries from the helper not currently coming from the modules for a L530. There could be some others for different devices:
get_fw_download_state
qs_component_nego
get_inherit_info
get_wireless_scan_info
get_schedule_rules
get_next_event
get_countdown_rules
get_antitheft_rules
get_preset_rules
get_auto_light_info
get_dynamic_light_effect_rules
The text was updated successfully, but these errors were encountered:
Broken out from #813.
I looked into this and there are a few issues. Firstly I think this probably only makes sense when we can get rid of the
SmartRequests
helper entirely, otherwise it's quite a bit of duplication. To do this we would need to implement more modules or at least have some kind of placeholder for modules we're not planning on implementing anytime soon, i.e.HomeKit
.Secondly not all the queries would necessarily be returned by the
query()
method on the module. For exampleget_wireless_scan_info
which (if it was moved into a module) would probably not scan unless a consumer tried to join a network (or it would massively slow down the first device update). Theseextra
calls would need to be exposed somehow by the modules with a function that onlydump_devinfo
calls which could be considered wrong, although maybe not.Finally I don't see an immediate gap whereby a query could potentially be added to a Module but not to the
SmartRequests
helper because as long as we're covered by tests someone would have to generate the fixture with the data for the tests to pass. Unless they add it to theFIXTURE_MISSING_MODULES
list in theFakeSmartTransport
which I guess we should be careful to avoid.Anyway, for future reference this is the method I used in
dump_devinfo
to try to get the requests from the modules if we ever want to use it in the future. One advantage of this was that if the module does an extra check to see if something is supported beyond thever_code
we can re-use the logic to avoid making a request that will fail:Here's a list of queries from the helper not currently coming from the modules for a L530. There could be some others for different devices:
The text was updated successfully, but these errors were encountered: