8000 Overhaul Emulated Hue #28317
Overhaul Emulated Hue #28317
Conversation
| @@ -393,141 +459,66 @@ def __init__(self, config): | |||
| hass.services.async_call(domain, service, data, blocking=True) | |||
There was a problem hiding this comment.
Why is this a create_task with blocking=True. In that case you could also just do async_call with blocking=False.
There was a problem hiding this comment.
Why is this a create_task with blocking=True. In that case you could also just do
async_callwithblocking=False.
Not sure ( I didn't write that :) ). I would ponder it's to give the device time to update before returning a response to Alexa / Google. Will test with blocking=False and report in later with the result.
| } | ||
| return { | ||
| unique_id = hashlib.md5(entity.entity_id.encode()).hexdigest() | ||
| unique_id = "00:%s:%s:%s:%s:%s:%s:%s-%s" % ( |
There was a problem hiding this comment.
Please use f-strings instead of old style string formatting.
There was a problem hiding this comment.
Here I would actually just do a ":".join(("00", val1, val2, …))
8000
There was a problem hiding this comment.
Here I would actually just do a
":".join(("00", val1, val2, …))
While that would work to generate most of the unique_id, there's actually a hyphen before the last two pairs of hex characters which would have to be added post-join(). As such, there's not a "clean" way to represent it with join():
unique_id = ":".join((
"00",
unique_id[0:2],
unique_id[2:4],
unique_id[4:6],
unique_id[6:8],
unique_id[8:10],
unique_id[10:12],
unique_id[12:14],
)) + "-" + unique_id[14:16]
Pro: Much easier to read and modify
Con: Concatenation on top of a join
With f-strings that "problem" goes away, but the string overall is more difficult to read and perhaps could cause confusion for editors in the future:
# "Plain" - don't care about string length
unique_id_fstring = f"00:{unique_id[0:2]}:{unique_id[2:4]}:{unique_id[4:6]}:{unique_id[6:8]}:{unique_id[8:10]}:{unique_id[10:12]}:{unique_id[12:14]}-{unique_id[14:16]}"
# "Tidy" - don't use lines longer than 80 characters results in:
unique_id_fstring2 = f"00:{unique_id[0:2]}:{unique_id[2:4]}:{unique_id[4:6]}:" \
f"{unique_id[6:8]}:{unique_id[8:10]}:{unique_id[10:12]}:" \
f"{unique_id[12:14]}-{unique_id[14:16]}"
Pro: Uses f-strings (ooohhh, shiny)
Con: A bit harder to read
I don't currently have the ability to test with Alexa if changing the hyphen to a colon would cause issues (personally I found issue with Alexa not discovering devices without a leading 00:) and won't have the ability to do so for at least a few days to weeks, but I would think that it actually shouldn't be removed as the hyphen does in fact exist in the Hue API's official documentation, as well as the output from a Hue bridge.
Either of you guys care to chime in? I didn't make any change yet and to be honest, I'm not entirely impressed with either solution. If I had to make a pick, though, I'd go with the join() for code readability. That said, Home Assistant code style would be to use f-strings so with that in mind, I am absolutely fine with following suit and calling it a day. Appreciate your thoughts!
There was a problem hiding this comment.
okay, in that case let's use
| unique_id = "00:%s:%s:%s:%s:%s:%s:%s-%s" % ( | |
| unique_id = "00:%s:%s:%s:%s:%s:%s:%s-%s".format( |
Anything but % :)
There was a problem hiding this comment.
@balloob Done, committed. Thanks!
|
🎉 |
Breaking Change:
entityidwere not Hue compliant,emulated_hue_ids.jsonwill need to be cleared out and devices re-discovered and configured in Alexa / Google Home. This is a necessary growing pain to move the component forward in a Hue-compliant fashion.Description:
Emulated Hue should not support brightness values 0 or 255, as the Hue API states that brightness should range from 1 to 254. This is causing Alexa to produce "Device doesn't support requested value" errors. Clamping brightness, hue, saturation and color temperature to Hue API-compatible values resolves this issue.
Adjusted response codes for errors and unauthorized request responses:
aiohttpimportHTTP_NOT_FOUNDtoHTTP_UNAUTHORIZEDwhere appropriateChanged "uniqueid" to match Hue bridge format:
00:%s:%s:%s:%s:%s:%s:%s-%s00:seems to resolve that issue. A new store-bought Hue bridge also contains MACs beginning with00:so I believe this is the right way to go about this.Added support for all light types:
General code cleanups; examples:
parse_hue_api_put_light_body()as after code refactoring and cleanup, I found thatHueOneLightChangeViewwas the only place that references it. It could always be broken out again if a call is needed elsewhere in the code, but I don't believe that's the case.HueOneLightStateView()- success response creation routineget_entity_state()- clamping routineTo Do:
floor(254/255) * 100 = 99)Related issue (if applicable):
Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
Example entry for
configuration.yaml(if applicable):Checklist:
tox. Your PR cannot be merged unless tests passIf user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
python3 -m script.hassfest.requirements_all.txtby runningpython3 -m script.gen_requirements_all..coveragerc.If the code does not interact with devices: