pywizlight: Throw exceptions while creating the instance

Hey,

I would love to have an connection exception to be thrown right after creating the instance.

def api_factory(ip : str) -> Any:
	api = None

	try:
		from pywizlight import wizlight
		from pywizlight.exceptions import WizLightError

		try:
			api = wizlight(ip)

			# hack start
			loop = get_loop() # instance of the loop
			builder = get_builder() # instace of pilot builder
			loop.run_until_complete(api.turn_on(builder()))
			# hack end

		except WizLightError:
			exit(wording.get('connection_no').format('WIZ LIGHT') + wording.get('exclamation_mark'))
		return api
	except ImportError:
		exit(wording.get('package_no').format('WIZ LIGHT') + wording.get('exclamation_mark'))

At the moment I need to turn the bulb on just to test the connection. See the hack start and hack end flags - that would be nice to be removable.

I integrated pywizlight to Chroma Feedback that let’s you use your bulbs as a traffic light for CI builds. Still working on it but release of version 8.0.0 is planned this week.

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (15 by maintainers)

Commits related to this issue

Auto feature mapping and connect_on_init was added for Throw exceptions while creating the instance #35 — committed to sbidy/pywizlight by sbidy 3 years ago

Most upvoted comments

@redaxmedia I have added the connect_on_init property for init. But this is really rudimentary! So there are no high sophisticated retries etc, There will be only one UDP package send to the bulb which can be result in an false-positive because UDP is “fire and forget”.

sbidy on Feb 8, 2021

Could this behavior (throwing an exception if the bulb is not found) be controlled by a parameter? For instance:

api = wizlight(ip, test_connection=True)

As @sbidy mentioned, my lightbulbs are behind a switch but I’d rather catch connection errors when I can’t reach the lightbulb than having to recreate the instance every time the lightbulb is turned on.

Having that parameter would allow both use cases.

eibanez on Jan 29, 2021

@sbidy Good… just ping me and I can update my integration 😃

henryruhs on Jan 6, 2021

Okay,

so what are you plans? I see that you tagged this issue for 0.4.2 and therefore will add my suggestion?

I mean both point of views are valid somehow. Having a false positive instance that can be used later once a bulb is online or the other way around of having only valid instances of online bulbs. In my opinion there is no big difference of a bulb being switched on and not being accessible or a bulb switched off - both are connected that are not working.

Beyond that, I can tell you that a couple of other libraries instantly throw execptions:

https://github.com/redaxmedia/chroma-feedback/blob/master/chroma_feedback/consumer/magic_hue/api.py#L21-L25 https://github.com/redaxmedia/chroma-feedback/blob/master/chroma_feedback/consumer/philips_hue/api.py#L21-L24 https://github.com/redaxmedia/chroma-feedback/blob/master/chroma_feedback/consumer/thingm_blink/api.py#L21-L24 https://github.com/redaxmedia/chroma-feedback/blob/master/chroma_feedback/consumer/xiaomi_yeelight/api.py#L21-L24

Whatsoever, thanks for the library and the fast release circles.

henryruhs on Jan 6, 2021