frawau / aiolifx Goto Github PK

Pull request: #57.

This is now required for my next update to Home Assistant. Thanks!

All struct.unpack() calls lack endianness and alignment hints. This means that the library will only work correctly on a little-endian machine.

My PR #47 adds in < correctly, but everything else in unpack.py is affected by the issue.

Judging by how each message has multiple struct.unpack() calls, I suspect the original author(s) had an issue where struct.unpack was trying to use native word alignment; eg: LightSetPower:

# Using explicit little-endian with no alignment: returns "6"
print(struct.calcsize('<HI'))

# Using native alignment: returns "8" on x86_64; because it aligns the uint32 (I) to the next 4-byte boundary
print(struct.calcsize('HI'))

The callback function to get_hostfirmware, get_wififirmware and set_power is not called when the reply is received.

At the moment all devices are instantiated as a Light which is a subclass of Device. Given there's now support for the Switch which as some slightly different characteristics I think it makes sense to make a new Switch class.

Benefits:

• Take relays_power out of Light given it only make sense for a Switch: https://github.com/frawau/aiolifx/blob/master/aiolifx/aiolifx.py#L883
• If a Switch is instantiated as a Light the consumer could call methods which aren't supported on a Switch so need to handle a State Unhandled message, see comment
• Device would need to be able to be instantiated without knowing the product ID, see comment

It might also make sense to make other subclasses of Light e.g. ColorLight or HevLight so the class only has properties and methods it supports.

This makes it easier to package this for distributions.

Hi,

I noticed the 0.7.0 release is not tagged in Git, please add the tag.

Thanks!

Please see https://community.home-assistant.io/t/after-lifx-bulb-firmware-update-hass-no-longer-see-this-bulb/18849/12 for lifx-cli.py output.

I have ordered a LIFX + and expect to fix this myself, but maybe you can do it even faster?

It would be good to have a fixed release on PyPI by Saturday (for the next Home Assistant version). Are you available to make that, provided I manage to fix it in time?

Lifx has released a new product line - smart switchs the LAN protocol has been updated to support them

https://lan.developer.lifx.com/docs/switch-messages

Each switch has 4 relays that can either be On or Off - switches dont support dimming.

Hello,

I created a fork of aiolifx that replaces the many callbacks with Python 3.5 style async functions - instead of callback functions, which better suit my needs.

master...brianmay:async_functions

As this means significant incompatible changes to the API, and also drops Python 3.4 support, I suspect you might be reluctant to merge my changes. Hence I plan to continue this fork - possibly under a new - yet-to-be-determined name and will make unrelated changes such as making the code base PEP8 compliant.

I thought I should let you know of my plans.

Feel free to close this issue report.

Regards

Support additional packets defined in LIFX's protocol.yml: LIFX/public-protocol@78fef2d

Maybe generate msgTypes from this?

I just wanted to check-in because usually you're really responsive with reviewing issues and PRs. With one PR hitting almost a month without comment, I'm just a bit concerned.

Hi -

I'm tracking down an issue in Home Assistant's Lifx integration (which uses aiolifx under the hood), and in some circumstances, the resp_set_multizonemultizone in aiolifx/aiolifx.py is getting an index out of bounds error at line 1084:

This, unfortunately, causes Home Assistant to fill the disk with error messages in the log file as fast as it can.

It seems that resp_set_multizonemultizone shouldn't be throwing an error - not sure if it needs to validate incoming data or if there's an off-by-one error or somesuch, and unfortunately my Python isn't strong enough to debug, so I'm creating this issue in the hopes that someone can add some more graceful error handling in resp_set_multizonemultizone.

Here's a stack trace from the call in Home Assistant (note the call to resp_set_multizonemultizone at the bottom.

2022-02-09 17:10:46 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback _SelectorDatagramTransport._read_ready()
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/usr/local/lib/python3.9/asyncio/selector_events.py", line 1029, in _read_ready
    self._protocol.datagram_received(data, addr)
  File "/usr/local/lib/python3.9/site-packages/aiolifx/aiolifx.py", line 180, in datagram_received
    getattr(self, setmethod)(response)
  File "/usr/local/lib/python3.9/site-packages/aiolifx/aiolifx.py", line 1084, in resp_set_multizonemultizone
    self.color_zones[i] = resp.color[i - resp.index]

Thanks!

Grant

If I write a simple script based off your CLI example:

import asyncio
import aiolifx as alifx
from functools import partial

class bulbs():
    def __init__(self):
        pass
    def register(self,bulb):
        print(bulb.get_label())

loop = asyncio.get_event_loop()
MyBulbs = bulbs()
coro = loop.create_datagram_endpoint(partial(alifx.LifxDiscovery,loop,MyBulbs),local_addr=('0.0.0.0',56700))
server = loop.create_task(coro)
loop.run_forever()

The loop prints None a few times.
If I print the bulb object itself, the output looks like

None
  MAC Address: d0:73:xx:xx:xx:xx
  IP Address: 1
  Port: 56700
  Power: Unknown
  Location: None
  Group: None
  Color (HSBK): None
  Host Firmware Build Timestamp: None (None UTC)
  Host Firmware Build Version: None
  Wifi Firmware Build Timestamp: None (None UTC)
  Wifi Firmware Build Version: None
  Vendor: None
  Product: Unknown
  Version: None

The only thing correct is the MAC, which I have redacted.

Hi,

First - I want to admit that there is nothing wrong with your library as it stands. Saying that - I have come from the hass community where Ive upgraded a hass instance to the latest version. Now, the light in my office is no longer picked up.

Looking into it, my light reports itself as a Lifx Carbon Prototype for whatever reason, but it is a Color 1000. The code that checks the bulb checks to see if the reported bulb name is in the features map

return not aiolifx().products.features_map[device.product]["color"]

I was hoping I'd be able to submit a patch for this if you'd be willing to accept it.

Hello!

A recent PR changed a good amount of the product mapping. One of the products Lifx A19 with the product_id: 27 seems like it changed the min_kelvin when it shouldn't have.

Location of the exact change can be found here.

Below is some output from Lifx's http api detailing the capabilities of the light. The light has a min_kelvin val of 2500 but it is currently listed as 1500 in this library.

~ curl "https://api.lifx.com/v1/lights/all" -H "Authorization: Bearer ${LIFX_TOKEN}" | jq .[0].product

{
  "name": "LIFX A19",
  "identifier": "lifx_a19",
  "company": "LIFX",
  "vendor_id": 1,
  "product_id": 27,
  "capabilities": {
    "has_color": true,
    "has_variable_color_temp": true,
    "has_ir": false,
    "has_hev": false,
    "has_chain": false,
    "has_matrix": false,
    "has_multizone": false,
    "min_kelvin": 2500,
    "max_kelvin": 9000
  }
}