obviate.io issueshttps://gitlab.com/groups/obviate.io/-/issues2019-12-30T23:10:14Zhttps://gitlab.com/obviate.io/pyleglight/-/issues/5Proper exceptions2019-12-30T23:10:14ZJon DavisProper exceptionsThrow proper exceptions for the known issues. Known invalid values. Also exception when the changes don't apply, perhaps the lights went away or a firmware has changed functionality.Throw proper exceptions for the known issues. Known invalid values. Also exception when the changes don't apply, perhaps the lights went away or a firmware has changed functionality.0.3.0Jon DavisJon Davishttps://gitlab.com/obviate.io/pyleglight/-/issues/6Real testing2020-01-03T23:40:27ZJon DavisReal testingImplement pytest or similar.
* Unsure if discovery is possible to test? Maybe possible running a copy of zeroconf in registration mode. https://github.com/jstasiak/python-zeroconf/blob/master/examples/registration.py
* Will need to mocku...Implement pytest or similar.
* Unsure if discovery is possible to test? Maybe possible running a copy of zeroconf in registration mode. https://github.com/jstasiak/python-zeroconf/blob/master/examples/registration.py
* Will need to mockup the API response of the lights. ex https://requests-mock.readthedocs.io/en/latest/pytest.html or build our own tiny simulated light in flask?1.0.0Jon DavisJon Davishttps://gitlab.com/obviate.io/pyleglight/-/issues/7Add tests for 0.2.0 features2020-01-03T05:12:27ZJon DavisAdd tests for 0.2.0 featuresDidn't add testing for for Issues #1 #2 and #3, add that.Didn't add testing for for Issues #1 #2 and #3, add that.0.3.0Jon DavisJon Davishttps://gitlab.com/obviate.io/pyleglight/-/issues/9Discovery doesn’t seem to work2021-02-13T03:16:50ZAndy PiperDiscovery doesn’t seem to workI am having no issues using pyleglight when I provide an IP address, but I’m fighting with the discovery piece. Even at a long timeout, it never seems to populate the response data on a call to `discover()`.
I’ve been trying to walk it ...I am having no issues using pyleglight when I provide an IP address, but I’m fighting with the discovery piece. Even at a long timeout, it never seems to populate the response data on a call to `discover()`.
I’ve been trying to walk it through in the Python REPL using the zeroconf module, and it seems a bit tricky - I only get a response after a second command is issued. I’m trying to narrow this down. Have you seen anything similar?https://gitlab.com/obviate.io/pyleglight/-/issues/10Seems to work with Ring Light as well2021-02-13T03:12:03ZVictor EcheverriaSeems to work with Ring Light as wellDug up this library when I found out that Elgato's Control Center can't discover my light because my network is peculiar. I'm able to manually add my Ring Light and turn it on/off, change brightness and color temperature as described in ...Dug up this library when I found out that Elgato's Control Center can't discover my light because my network is peculiar. I'm able to manually add my Ring Light and turn it on/off, change brightness and color temperature as described in the examples.https://gitlab.com/obviate.io/pyleglight/-/issues/11Test with new RGB Strip2021-04-07T00:22:08ZJon DavisTest with new RGB StripNew RGB strip introduces....colors! Gotta figure out how this one works.
http://10.23.22.94:9123/elgato/accessory-info
`{"productName":"Elgato Light Strip","hardwareBoardType":70,"firmwareBuildNumber":211,"firmwareVersion":"1.0.4","ser...New RGB strip introduces....colors! Gotta figure out how this one works.
http://10.23.22.94:9123/elgato/accessory-info
`{"productName":"Elgato Light Strip","hardwareBoardType":70,"firmwareBuildNumber":211,"firmwareVersion":"1.0.4","serialNumber":"ASDF1234","displayName":"Elgato Light Strip 9615","features":["lights"]}`
http://10.23.22.108:9123/elgato/accessory-info
`{"productName":"Elgato Key Light","hardwareBoardType":53,"firmwareBuildNumber":200,"firmwareVersion":"1.0.3","serialNumber":"ASDF1266","displayName":"Key Light Right","features":["lights"]}`
See #12 for crash on detection/info output.
Trying to differentiate the two... The "features" is the same. Can't rely on the name. We could try and guess based on hardwareBoardType but without a lot more data on that we have no idea if that actually makes a different. Same with SN's. Best we can do is wait until we fetch the info. If we see on/brightness/temperature combo, we know it's a regular light and if we see on/brightness/hue/saturation treat is as RGB mode.Jon DavisJon Davishttps://gitlab.com/obviate.io/pyleglight/-/issues/12Discovery crashes with RGB lightstrips on the network2021-04-07T00:22:08ZJon DavisDiscovery crashes with RGB lightstrips on the network```
>>> allL = leglight.discover(2)
Exception in thread zeroconf-ServiceBrowser__elg._tcp.local._1699607:
Traceback (most recent call last):
File "/usr/local/Cellar/python@3.9/3.9.2_2/Frameworks/Python.framework/Versions/3.9/lib/python...```
>>> allL = leglight.discover(2)
Exception in thread zeroconf-ServiceBrowser__elg._tcp.local._1699607:
Traceback (most recent call last):
File "/usr/local/Cellar/python@3.9/3.9.2_2/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run()
File "/usr/local/lib/python3.9/site-packages/zeroconf/__init__.py", line 1755, in run
self._service_state_changed.fire(
File "/usr/local/lib/python3.9/site-packages/zeroconf/__init__.py", line 1513, in fire
h(**kwargs)
File "/usr/local/lib/python3.9/site-packages/zeroconf/__init__.py", line 1611, in on_change
listener.add_service(*args)
File "/usr/local/lib/python3.9/site-packages/leglight/discovery.py", line 25, in add_service
lights.append(LegLight(address=ip, port=port, name=lname, server=server))
File "/usr/local/lib/python3.9/site-packages/leglight/leglight.py", line 29, in __init__
self.info()
File "/usr/local/lib/python3.9/site-packages/leglight/leglight.py", line 95, in info
self.isTemperature = self.postFit(status['temperature'])
KeyError: 'temperature'
```
At the end of discovery https://gitlab.com/obviate.io/pyleglight/-/blob/master/leglight/leglight.py#L29 we call info, which assumes the on/brightness/temperature k/v. Those don't exist.
Regular Light: http://10.23.22.108:9123/elgato/lights
`{"numberOfLights":1,"lights":[{"on":0,"brightness":10,"temperature":160}]}`
RGB Strip: http://10.23.22.94:9123/elgato/lights
`{"numberOfLights":1,"lights":[{"on":0,"hue":245.000000,"saturation":100.000000,"brightness":100}]}`Jon DavisJon Davishttps://gitlab.com/obviate.io/pyleglight/-/issues/13Future warning emitted from zeroconf, missing update_service method2021-10-14T16:47:55ZTom CharlesworthFuture warning emitted from zeroconf, missing update_service methodMinimal test code:
import leglight
lights = leglight.discover(5)
Diagnostic:
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/zeroconf/_services/browser.py:169: FutureWarning: <leglight.disco...Minimal test code:
import leglight
lights = leglight.discover(5)
Diagnostic:
/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/zeroconf/_services/browser.py:169: FutureWarning: <leglight.discovery.discover.<locals>.thelistener object at 0x105e6c130> has no update_service method. Provide one (it can be empty if you don't care about the updates), it'll become mandatory.
Versions:
Darwin matsu.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:20 PDT 2021; root:xnu-7195.141.6~3/RELEASE_ARM64_T8101 arm64
pyleglight git commit: 96e89334801d068c631f2a1fe39824fa1532f211
Python 3.10.0:b494f5935c
zeroconf versions: 0.36.7
Proposed patch:
diff --git a/leglight/discovery.py b/leglight/discovery.py
index 3308c35..a7b3106 100644
--- a/leglight/discovery.py
+++ b/leglight/discovery.py
@@ -34,6 +34,9 @@ def discover(timeout: int = 5) -> list:
logging.debug("Found light @ {}:{}".format(ip, port))
lights.append(LegLight(address=ip, port=port, name=lname, server=server))
+ def update_Service(self, zeroconf):https://gitlab.com/obviate.io/pyleglight/-/issues/14Add customizable timeout to request in LegLight constructor2022-08-24T19:16:33ZStuart ColvilleAdd customizable timeout to request in LegLight constructorSince a specified keylight address might not always be available (e.g. if you move network), it would be nice to have a default timeout for the request in the LegLight Constructor, with the possibly of this being overridden.
[By defaul...Since a specified keylight address might not always be available (e.g. if you move network), it would be nice to have a default timeout for the request in the LegLight Constructor, with the possibly of this being overridden.
[By default (without a timeout specified) requests will indefinitely wait for a response](https://requests.readthedocs.io/en/latest/user/advanced/#timeouts).