core 🚀 - Migrate the LIFX component to aiolifx

@amelchio, thank you for creating this issue. Regardless of the final route that is taken to update the LIFX library I want to outline some of what I consider requirements for any solution going forward and outline some of the changes I've made to the existing lifx component and associated library that has made my setup substantially more reliable.

As far as the LIFXLan library provided my @mclarkk it provides a very nice and well written high level API for communicating with the lights, but it doesn't provide the glue code needed work effectively with HA and in my opinion that glue code is substantially more important than the overall library used to format and send messages.

For this glue code to work effectively I feel it needs to provide the following:

Active Monitoring for state messages broadcasted by the lights when they're reset or reconnect to wifi. This will ensure we get real-time discovery of new lights being added to the network.
Callback allows for relaying those messages back to HA similarly to the way it currently works in the liffylights protocol.
Reduction of messages sent to bulbs should be a priority. I.E - HA should not be allowed to spam bulbs and commands should be ignored if the current state matches that of the new state that is attempting to be set.
Retires should occur if acknowledgements are not received, and should report to HA if light has become unreachable. HA should then avoid sending messages to that light until it sees a state message indicating that it has rejoined wifi.

For changes I've made to the current liffylights and lifx component on my own install, they are as follows.

Added a check to prevent set_color from being sent if the on command was the only thing supplied.
Changed the acknowledgement checking code in liffylights.py in line 137 from 3 to 2.
Added the ability for liffylights to see broadcast messages from the bulbs.
Added the ability for liffylights to update HA on power and color state messages.
Removed code in lifx.py that would poll for device state. (this is not needed)
Started using HA as a the sole source for messages to and from LIFX lights.

Overall the changes I made are to ensure that messages to lights are only for the purposes of changing light state and overall this has significantly improved the reliability of my lights and ultimately that is what I feel makes the biggest difference.

keatontaylor on 6 Mar 2017

@keatontaylor, thanks for popping in – I can agree with all of that and I was planning to implement most of the things that you mention, once we have a better base. That should fix a number of bugs. The glue is not HA specific and should be easy to add to another library with an active maintainer.

Is your work on liffylights/HA available, I did not manage to find it in any branch?

About the reduction in messages, did you see any actual problems due to the message frequency or is this more a matter of good taste, i.e. not sending unneeded messages?

I was contacted by @frawau and it turns out that a library based on asyncio and Python 3 already exists: https://github.com/frawau/aiolifx so that may be an even better path to follow. I will give it a try soon!

amelchio on 6 Mar 2017

@amelchio I can upload the liffylights and HA changes I've made to my github tomorrow morning. As for the reduction in messages, I absolutely see a significant decrease in issues as a result of sending fewer messages. My light, 12 in total, have had zero issues in just over two months after I reduced the number of messages to the light to only those that are needed. Especially improving the reliability of the Gen 1 bulbs.

The aiolifx library seems to borrow almost all the messaging code from LIFXLAN as far as I can tell, but has a lot of the code already in place to handle the glue code for HA. So it might be a better starting point. If you do get a codebase somewhere I'd be happy to help, and with my spring break coming up I should also have the time. :)

I'm excited to finally get this fixed and hopefully improve reliability for those of us using LIFX.

keatontaylor on 6 Mar 2017

If I may

@keatontaylor[1], I have 10 gen 1 Lifx and I have been using aiolifx for 2-3 months, I think
I saw 2 problems that quickly went away, with one bulb.
I do suspect that using unicast and keeping the connection up is good for the reliability.
Also, by using aiolifx in my "AutoBuddy" project, I am able to detect when a bulb comes
back online without the need for discovery.

The messaging code is entirely from lifxlan, just modified for Python 3, I did not see the
point of reinventing the wheel. There is just one difference in the API for the
"pulse"command.

Try the test program, just hit return quickly and you'll be able to get a sense as to how fast
it will discover your Lifx.

@amelchio I'll see how I can get it on PyPi.

Cheers,
François

On Monday, 6 March 2017 00:36:15 ICT Keaton Taylor wrote:

@amelchio[2] I can upload the liffylights and HA changes I've made to my github
tomorrow morning. As for the reduction in messages, I absolutely see a significant
decrease in issues as a result of sending fewer messages. My light, 12 in total, have had
zero issues in just over two months after I reduced the number of messages to the light to
only those that are needed. Especially improving the reliability of the Gen 1 bulbs.
The aiolifx library seems to borrow almost all the messaging code from LIFXLAN as far as I
can tell, but has a lot of the code already in place to handle the glue code for HA. So it
might be a better starting point. If you do get a codebase somewhere I'd be happy to help,
and with my spring break coming up I should also have the time. :)
I'm excited to finally get this fixed and hopefully improve reliability for those of us using
LIFX.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[3], or mute the thread[4].[5]

[1] https://github.com/keatontaylor
[2] https://github.com/amelchio
[3] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-284333259
[4] https://github.com/notifications/unsubscribe-auth/
AORvqQAFYqqZgbZ3wHKZPBz4TF3uKfkaks5ri8V_gaJpZM4MTgc8
[5] https://github.com/notifications/beacon/AORvqd1PLMWJ-R1uve1gMmemfki5rO6Pks5ri8V_gaJpZM4MTgc8.gif

frawau on 6 Mar 2017

@frawau, I took a look at your example CLI program and probed around with wireshark a bit to look at the messages being sent. Everything looks good with the exception of the number of messages being sent during initial discovery. Things like wifi info, etc can be retrieved when they're called upon, not during the initial discovery. If the library itself asks for this information on discovery I'd ask it to be removed and only retrieve the bare minimum of what we need from the bulbs.

Ideally, simply GetService as a broadcast and Get (light message) will be sufficient to get the mac address, label, service port, IP, along with the current power, brightness, etc from the bulb.

Also, UDP is stateless, the connection does not remain open as UDP has no concept of an ongoing connection.

Otherwise everything looks very good and is extremely speedy.

keatontaylor on 6 Mar 2017

@keatontaylor It seems we agree that aiolifx is the way to go, that's great. If nothing unexpected turns up (in the code or in my life), I can probably do the conversion this week.

amelchio on 6 Mar 2017

@keatontaylor [1]All those messages are requested by the test program only. Check the
"register" method.

UDP is stateless... silly me I know that, I meant to say that I am using a slow heartbeat....

Cheers,
François

On Monday, 6 March 2017 01:52:24 ICT Keaton Taylor wrote:

@frawau[2], I took a look at your example CLI program and probed around with wireshark
a bit to look at the messages being sent. Everything looks good with the exception of the
number of messages being sent during initial discovery. Things like wifi info, etc can be
retrieved when they're called upon, not during the initial discovery. If the library itself asks
for this information on discovery I'd ask it to be removed and only retrieve the bare
minimum of what we need from the bulbs.
Ideally, simply GetService as a broadcast and Get (light message) will be sufficient to get
the mac address, label, service port, IP, along with the current power, brightness, etc from
the bulb.
Also, UDP is stateless, the connection does not remain open as UDP has no concept of an
ongoing connection.
Otherwise everything looks very good and is extremely speedy.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[3], or mute the thread[4].[5]

[1] https://github.com/keatontaylor
[2] https://github.com/frawau
[3] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-284350272
[4] https://github.com/notifications/unsubscribe-auth/AORvqUnFRjrKbhu_d-_BOjTJb5WxEkOpks5ri9dYgaJpZM4MTgc8
[5] https://github.com/notifications/beacon/AORvqVkDsvg0k2w-Uua8tv6Ejd89tOSBks5ri9dYgaJpZM4MTgc8.gif

frawau on 6 Mar 2017

@amelchio It's on PyPi. Let me know if it works for you.[1]

Regard,
François

On Monday, 6 March 2017 02:01:01 ICT Anders Melchiorsen wrote:

@keatontaylor[2] It seems we agree that aiolifx is the way to go, that's great. If nothing
unexpected turns up (in the code or in my life), I can probably do the conversion this week.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[3], or mute the thread[4].[5]

[1] https://github.com/amelchio
[2] https://github.com/keatontaylor
[3] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-284352312
[4] https://github.com/notifications/unsubscribe-auth/
AORvqWbRByImG5MeYdugY1jZHLKSQYXIks5ri9ldgaJpZM4MTgc8
[5] https://github.com/notifications/beacon/
AORvqaV4loxV5no_8_0I6nri5O6S40rgks5ri9ldgaJpZM4MTgc8.gif

frawau on 6 Mar 2017

@amelchio Looking forward to this 👍

arsaboo on 6 Mar 2017

@frawau It works 👌. To be used with Home Assistant, though, aiolifx must be backported to support Python 3.4, see https://home-assistant.io/developers/asyncio_misc/

@keatontaylor It seems that polling is actually needed in order to catch changes made outside of Home Assistant. This could for example be with the smartphone app, a physical wall switch or the native schedules. Do you agree or did I miss something?

amelchio on 7 Mar 2017

@amelchio[1] Really? It works ;) To support 3.4 I would think that all you have to do is
change any async/await into @asyncio.coroutine/yield from. From the top of my head that
should be it and it only involves 2 methods fire_sending and try_sending, 4 lines in total.
(Ooops I should have followed the link before writting that ;))

Can you check if that works ? ( I don't have python3.4 currently ( I used the strech repos to
get my "Jessies" up to speed ) Then we can find a way to make that "official" in Pypi.

Indeed you need to poll for status every now and then to get other apps induced changes.
I did look a bit (not too hard) and all I could find is the bulb sending a StateInfo message
after booting, that the reason of the
' if "State"' bit in datagram_received and also why it can quickly find (around 15 secs) the
bulbs that were offline without the need for discovery. That should take care of the
physical switch bit.

Cheers,
François

On Tuesday, 7 March 2017 00:59:37 ICT Anders Melchiorsen wrote:

@frawau[2] It works 👌. To be used with Home Assistant, though, aiolifx must be
backported to support Python 3.4, see https://home-assistant.io/developers/asyncio_misc/
[3]
@keatontaylor[4] It seems that polling is actually needed in order to catch changes made
outside of Home Assistant. This could for example be with the smartphone app, a physical
wall switch or the native schedules. Do you agree or did I miss something?
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[5], or mute the thread[6].[7]

[1] https://github.com/amelchio
[2] https://github.com/frawau
[3] https://home-assistant.io/developers/asyncio_misc/
[4] https://github.com/keatontaylor
[5] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-284661122
[6] https://github.com/notifications/unsubscribe-auth/
AORvqdN1oQ_r4u60D_ZrHXGy-0Nt67Biks5rjRx5gaJpZM4MTgc8
[7] https://github.com/notifications/beacon/
AORvqV3asc5s8oWnMg3tKlpEVx_TwRXOks5rjRx5gaJpZM4MTgc8.gif

frawau on 7 Mar 2017

@amelchio, polling is extremely messy for the following example.

I.E - You turn off lights with a transition say 10 seconds, the bulbs respond with an acknowledgement and ideally HA will see the bulbs as immediately off, which I think is the preferred behavior, since ultimately that is the command that was sent to the bulbs. If during that 10 seconds a polling event occurs, HA will be updated with whatever the brightness level, etc the bulb is currently in during the polling. So for example if the polling occurs at second 5 in the 10 second off transition, polling will report to HA that the bulb is at 50% brightness. If say polling occurs every 10 seconds then we will have 5 seconds of HA not knowing what the state of the bulb is.

The solution to this problem is tricky, because we need to decide if we're going to prioritize HA being "more" correct in what the actual state of the bulbs are, or if we're going to allow apps outside HA to muck around with light state.

In my own testing I went the route of only allowing HA to control the lights, this means that HA is always correct in what state the lights are in, after a transition completes.

Overall the best compromise may be to have something within the library that polls lights on a given interval, but pausing polling for particular bulbs that are in a transition, then resume normal polling when it is complete.

A bad solution, in my opinion, would be ignoring acknowledgements all together and polling the lights more frequently, like once a second, but I am almost 100% confident that would result in the lights becoming unresponsive, etc.

In a perfect world, the lights themselves would broadcast changes regardless of the app being used to control them, so that HA could just capture the broadcasts, and in some cases, like updating lights from the web API they do, but from the LIFX app, they do not.

Let me know what your opinions are on this. I feel it is a crucial decision to be made that has the largest impact on lifx light reliability.

keatontaylor on 7 Mar 2017

Okay, I pushed an initial aiolifx version now: https://github.com/amelchio/home-assistant/tree/aiolifx

I am learning Python as I go so the code may have some issues. Especially the asyncio stuff has me kind of confused and googling.

Anyway, everything seems to work much better than before. I think it fixes #3604, #4589, #5158 and #6245.

@frawau I also do not have Python 3.4 handy but if it is just a few lines then we can surely find a way to get that handled. Kudos on aiolifx, it's a pleasure to use.

@keatontaylor I think polling is fine in that situation. Yes, there are some inconsistencies during transitions but the polling will make sure that they are resolved eventually. The smartphone app works the same way and it's rarely an issue. Give it another chance, I believe your bad experiences are mostly due to liffylights, not so much the LIFX bulbs.

amelchio on 8 Mar 2017

👍1

@amelchio, if that is the case we need a somewhat high polling rate. Maybe 5 seconds or something. If the state of the bulb is the same as the last state we should not send callbacks to HA to ensure the core thread isn't being flooded with updates. Also, we may want to reconsider some of the code in the lifx component.

Here is the scenario that will result in a bad experience:

Currently the lifx component will not turn on lights that it thinks are already on. So in the case of some external device like the lifx bulb turns the light off, HA will not be able to turn it back on until the next polling even completes. We can remove the check and send the on command to the bulbs regardless of the known state, but that would mean something like a brightness change would send the 'on' command and the brightness change command each time.

This is compounded by the inability for the YAML code in HA to effectively check some state of the bulb and perform no action if it is in a current state. Like the following code.

  action:
    - service_template: >
        {% if is_state('input_boolean.sleeping', 'off') %}
          homeassistant.turn_on
        {% else %}
          homeassistant.turn_off
        {% endif %}
      entity_id: light.bedroom_lamp
      data:
        transition: 0

In the case above, the service template must provide either on or off, you cannot say neither. So commands like these if the code wasn't in place in the component to ignore state changes when the light was already in that state could flood the light with off or on messages when it is already off/on.

I suppose we could ask for a light state message before we send a command to the lights to ensure that the new state we want is different from the old one, but in networks with high latency that would likely increase the time it takes to turn on/off a bulb beyond what would be reasonable for the user.

keatontaylor on 8 Mar 2017

At bare minimum I would like a configuration option for polling frequency so that it may be turned off it HA is the only thing communicating with the lights.

keatontaylor on 8 Mar 2017

Hi Guys,

For what it's worth, here is how I would handle your "polling" problem... Again I am not at
all familiar with HA, but I think it would work.

Inside the Lifx component, you have a fast heartbeat element (hb), say every 5 secs. Each
light has its own cycle, which is an integer (polling freq/ hb freq) each time the hb is fired,
all the cycles are decreased by 1, when it reaches 0 the polling message is actually sent
and the cycle is reset. Whenever a command with a duration is sent, you set that light
cycle so it it will poll right after the command is done.

I think that that could work and is not too difficult to implement.

Just my 2 cents.

Regards,
François

On Tuesday, 7 March 2017 17:15:23 ICT Keaton Taylor wrote:

At bare minimum I would like a configuration option for polling frequency so that it may
be turned off it HA is the only thing communicating with the lights.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[1], or mute the thread[2].[3]

[1] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-284914755
[2] https://github.com/notifications/unsubscribe-auth/
AORvqdgfJVwbXxA8ZQhR4DBM1uBSUtpCks5rjgErgaJpZM4MTgc8
[3] https://github.com/notifications/beacon/AORvqd-VebgXuaFtmgy6Zb_1JWuh5Lk7ks5rjgErgaJpZM4MTgc8.gif

frawau on 8 Mar 2017

@frawau seems like a reasonable solution.

keatontaylor on 8 Mar 2017

@keatontaylor Why don't you test out my branch. I have tried to address almost all of your concerns so I would be happy to see you actually break it 😃

It is true that HA needs a way to set a color without affecting the power state (and vice versa), for example for Flux. However, that is a generic issue so let us keep that discussion out of this LIFX cleanup.

amelchio on 8 Mar 2017

@amelchio, I already found something I don't like. :)

Your lifx.py code simply sets the HA state of the bulb to the state that is requested without receiving an acknowledgement from the bulb. So there is no verification that the state actually changed to what we want, and instead you seem to be relying solely on polling. This certainly works, but also has its own fair share of issues associated with it.

Also could you explain to me what the block updates code is for?

keatontaylor on 8 Mar 2017

There may be a more elegant way to do this but the most elegant way has the problem of not actually working.

The ACK just says that the packet was received, it does not tell us that the transition has completed or even started. But the ACK is not ignored: if it does not show up, "unregister" is called and the bulb is set as unavailable.

The "block_updates" code is to avoid the UI glitch where the power toggle would temporarily jump back right after being clicked. The bulb is slow to react and setting a state followed by requesting the current state can return the old state, even though it is about to change.

Unfortunately, this "set" followed by "get" is exactly what HA always does. So I assume success for two seconds, allowing potential retransmits to complete and the bulb to handle the set request. At this point the "get" is made, ensuring that the state machine is properly updated.

amelchio on 8 Mar 2017

Hmm, I'll have to give this more thought on what may be best, but in the meantime take a look at how the liffylights code does it.

keatontaylor on 8 Mar 2017

I am just curious.... How often do you see that happening? (No ACK) In my environment I
almost never see that. In any case, you could change DEFAULT_TIMEOUT and
DEFAULT_ATTEMPTS to find a combination that works for you. I did tinker with that a bit
before settling on the current values.

And now for something completely different. Do you have a flic (https://flic.io/) component
in HA? Because I have a aioflic lib you might be interested in. (although I am waiting for
them to update their bit)

Cheers,
François

On Wednesday, 8 March 2017 01:44:14 ICT Anders Melchiorsen wrote:

The ACK just says that the packet was received, it does not tell us that the transition has
completed or even started. But the ACK is not ignored: if it does not show up, "unregister"
is called and the bulb is set as unavailable.

frawau on 8 Mar 2017

@frawau I did not yet run it long enough to tell. Until now I mostly saw missing ACKs when toggling the wall switch on purpose. I do have one bulb that seems to unregister every now and then. I will have to keep an eye on that but it is an outdoor lamp and I suspect that it is actually checking out.

Just to be clear, Home Assistant is not my project. I am just a new user trying to get it working with my lights. So the Flic button is not in my personal area of interest, sorry.

amelchio on 8 Mar 2017

Just an FYI for future projects, lifxlan has been updated to support both Python 2 and Python 3, thanks in large part to @frawau! It was way past due. I just released the newest version on PyPI. Best of luck on the HA project!

mclarkk on 9 Mar 2017

@mclarkk that's great, thanks for your good work on LIFX support.

@frawau I now confirmed that the bulb that is frequently being unregistered by aiolifx cannot be ping'ed during the outage. So it seems to be a problem with my connectivity and not an issue with aiolifx 👍

amelchio on 9 Mar 2017

@keatontaylor @arsaboo @Charliedean @brianjking @petersandersen @issacg

Hi guys. If you feel like it, please test my new LIFX platform. I put instructions at the top of this #6435 issue. (I picked your handles from issues that I think my work fixes.)

amelchio on 10 Mar 2017

@amelchio Thanks....trying it now. It does not start, I see the following in my logs:

Mar 10 20:54:53 raspberrypi hass[1314]: File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 214
Mar 10 20:54:53 raspberrypi hass[1314]: ^
Mar 10 20:54:53 raspberrypi hass[1314]: SyntaxError: only named arguments may follow *expression

arsaboo on 11 Mar 2017

I removed the * on that line and then it works. Will test it out more.

arsaboo on 11 Mar 2017

@arsaboo Thanks, that was a 3.5-ism, so I guess you are running on Python 3.4? I fixed it now.

amelchio on 11 Mar 2017

I'll take a look asap. Probably on Sunday. :)

keatontaylor on 11 Mar 2017

Working well so far. Let me know if there is anything specific that we want to test.

arsaboo on 11 Mar 2017

I did a side-by-set testing of the current lifx component and lifxtest. The difference is day and night. Lifxtest is super responsive - the status updates in less than a second when turning the lights on and in less than 2-3 seconds when turning them off. On the lifx component, it almost takes forever to update (easily more than 30 seconds). Would love to see a PR soon just for the speed alone.

Quick question: Is there any way to add random, color loop, or any other effects?

arsaboo on 11 Mar 2017

Also, see these errors in the logs every time I turn on/off the lights:

17-03-11 11:44:15 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/tasks.py", line 237, in _step
    result = next(coro)
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 1001, in _event_to_service_call
    yield from service_handler.func(service_call)
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/__init__.py", line 249, in async_handle_light_service
    yield from light.async_turn_on(**params)
  File "/usr/lib/python3.4/asyncio/coroutines.py", line 141, in coro
    res = func(*args, **kw)
  File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 225, in async_turn_on
    self.block_updates()
  File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 178, in block_updates
    self.blocker = asyncio.ensure_future(self.update_later())
AttributeError: 'module' object has no attribute 'ensure_future'
17-03-11 11:44:23 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/tasks.py", line 237, in _step
    result = next(coro)
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 1001, in _event_to_service_call
    yield from service_handler.func(service_call)
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/components/light/__init__.py", line 251, in async_handle_light_service
    yield from light.async_turn_off(**params)
  File "/usr/lib/python3.4/asyncio/coroutines.py", line 141, in coro
    res = func(*args, **kw)
  File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 239, in async_turn_off
    self.block_updates()
  File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 178, in block_updates
    self.blocker = asyncio.ensure_future(self.update_later())
AttributeError: 'module' object has no attribute 'ensure_future'

arsaboo on 11 Mar 2017

@arsaboo Thank you, that is very valuable feedback! I have pushed a new version which I think fixes the error in your log. Maybe I should install Python 3.4 myself to better see those things .

There is not anything specific to test. This first step is for bug fixes as well as improved reliability and response times. The only new feature is that lights are set as "unavailable" when turned off at the wall switch.

I want to use LIFX for notifications so I do plan to add at least a flash effect. I don't know about color cycling, it has to run on the server (not the bulb) so it is a bit of work to implement.

amelchio on 11 Mar 2017

@amelchio Cool....those errors are gone with the fix.

Color cycling will be cool to have, but I guess that is not an immediate requirement. Something to work on after we have the basics ready 😉

arsaboo on 11 Mar 2017

Just updated to 0.40 and now I see a few of these in my logs:

17-03-11 18:23:40 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback _SelectorDatagramTransport._read_ready()
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/events.py", line 120, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.4/asyncio/selector_events.py", line 932, in _read_ready
    self._protocol.datagram_received(data, addr)
  File "/home/hass/.homeassistant/deps/aiolifx/aiolifx34.py", line 111, in datagram_received
    callb(self,response)
  File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 90, in ready
    self.hass.async_add_job(self.async_add_devices([entity]))
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 195, in async_add_job
    elif is_callback(target):
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 80, in is_callback
    return '_hass_callback' in func.__dict__
AttributeError: 'NoneType' object has no attribute '__dict__'
17-03-11 18:23:40 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback _SelectorDatagramTransport._read_ready()
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/events.py", line 120, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.4/asyncio/selector_events.py", line 932, in _read_ready
    self._protocol.datagram_received(data, addr)
  File "/home/hass/.homeassistant/deps/aiolifx/aiolifx34.py", line 111, in datagram_received
    callb(self,response)
  File "/home/hass/.homeassistant/custom_components/light/lifxtest.py", line 90, in ready
    self.hass.async_add_job(self.async_add_devices([entity]))
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 195, in async_add_job
    elif is_callback(target):
  File "/srv/hass/hass_venv/lib/python3.4/site-packages/homeassistant/core.py", line 80, in is_callback
    return '_hass_callback' in func.__dict__
AttributeError: 'NoneType' object has no attribute '__dict__'

arsaboo on 12 Mar 2017

@amelchio, color cycling can run on the bulb with the setwaveform command as part of the lifxlan and by proxy the aiolifx library.

keatontaylor on 12 Mar 2017

@arsaboo Thanks again! I pushed another fix.

amelchio on 12 Mar 2017

@keatontaylor that only does one color change (what I called a flash effect). I believe you have to string several of those together to get some nice cycling effects.

amelchio on 12 Mar 2017

Ah, I see. Still we should have pulse/blink implemented via set waveform.

keatontaylor on 12 Mar 2017

This has been working very reliably for me....may not be a bad idea to get the initial implementation in. Simpler the PR, faster it will be approved 😉

arsaboo on 13 Mar 2017

🎉1

@arsaboo very true.

keatontaylor on 13 Mar 2017

@amelchio Regarding the cycling effects, instead of specifying the colors as you suggest in your previous comment, wondering if it will be easier to just use random colors.

arsaboo on 13 Mar 2017

@arsaboo Can you describe the effects you are looking for in more detail? Incidentally, I hope to submit the PR on the initial implementation today but I do expect a fair amount of spanking in review as I am new to Home Assistant as well as Python.

amelchio on 13 Mar 2017

@amelchio All the more reason to submit a simpler code :wink:

I am essentially looking for a random color cycling that can be used in case of parties (something similar to color loop in Hue). The effects that LIFX runs on the phone use lot of battery. It will be nice to have something similar/close that can be run independently.

arsaboo on 13 Mar 2017

@arsaboo It uses a lot of battery because it is a lot of work and that would have to be implemented again in Home Assistant :). I don't know how Hue does things, hence the request to elaborate. I was wondering whether it could be done already today with a (somewhat complicated) HA script.

Personally, I would love an effect that could simulate a TV set to a burglar passing by the house.

amelchio on 13 Mar 2017

@amelchio A script should be fine. As long as we can specify the colors (see example here) and the transition interval, we should be fine.

arsaboo on 13 Mar 2017

Sorry I haven't had a moment to look at this yet, but wanted to add that I'm very grateful for your work regardless 👍

issacg on 15 Mar 2017

Working perfectly over here, I have just replaced the lifx.py until next release.
Loving the responsiveness and smoothness 👍

Charliedean on 15 Mar 2017

Thank you!

I will be testing this tonight. I have been a very angry man since getting over 20 Lifx lights and being tortured by their unreliability.

Hopefully this can bring a little joy back into my life!

mihalski on 19 Mar 2017

I got a lot of this error:

17-03-19 10:57:29 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.4/asyncio/tasks.py", line 237, in _step
result = next(coro)
File "/home/homeassistant/.homeassistant/deps/aiolifx/aiolifx34.py", line 164, in try_sending
self.connection_lost(None)
File "/home/homeassistant/.homeassistant/deps/aiolifx/aiolifx34.py", line 125, in connection_lost
self.parent.unregister(self)
File "/home/homeassistant/.homeassistant/deps/aiolifx/aiolifx34.py", line 612, in unregister
self.parent.unregister(alight)
File "/home/homeassistant/.homeassistant/custom_components/light/lifxtest.py", line 94, in unregister
entity = self.entities[device.mac_addr]
KeyError: 'd0:73:d5:13:e1:6e'

Not sure if it was one per Lifx bulb but it seemed like it.

mihalski on 19 Mar 2017

@mihalski

If your lights are generally unstable (i.e. it also affects the official smartphone app) it is probably due to wifi issues and this change will unfortunately not help. With 20+ lights I must assume that you are covering quite an area and you may need better/more wifi access points.

However, if it is only Home Assistant that is unreliable with the lights, this change could absolutely be an improvement.

As for the error, thank you. I will make a more thorough fix, but for a start could you try changing the requirements near the top to read like this:

REQUIREMENTS = ['aiolifx==0.4.2']

amelchio on 19 Mar 2017

Thank you for your prompt response.

My instability MAINLY affects the LAN, whereas WAN control usually continues to work even when LAN control fails. Interestingly it is still possible to ping the lights in that state.

I believe it has to do with this: https://docs.lightsd.io/known-issues.html

I thought wifi coverage/performance/etc might be my issue too so I purchased a UniFi AP-AC-Pro, which has been outstanding.

All in all I've sunk over $1k into Lifx lights and wifi so I really hope this mitigates many of the problems I've encountered. It certainly seems much more responsive so far.

Do you know if your lifx component will be included in the next update to HA as standard?

mihalski on 19 Mar 2017

The error persists, just referencing different lines in aiolifx:

17-03-19 11:18:01 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/lib/python3.4/asyncio/tasks.py", line 237, in _step
result = next(coro)
File "/home/homeassistant/.homeassistant/deps/aiolifx/aiolifx34.py", line 169, in try_sending
self.connection_lost(None)
File "/home/homeassistant/.homeassistant/deps/aiolifx/aiolifx34.py", line 127, in connection_lost
self.parent.unregister(self)
File "/home/homeassistant/.homeassistant/deps/aiolifx/aiolifx34.py", line 617, in unregister
self.parent.unregister(alight)
File "/home/homeassistant/.homeassistant/custom_components/light/lifxtest.py", line 94, in unregister
entity = self.entities[device.mac_addr]
KeyError: 'd0:73:d5:13:c0:fc'

It does not appear to affect basic functionality.

mihalski on 19 Mar 2017

@mihalski

Thanks for doing the test. I made a fix on my branch now, you can try it out by installing this file instead: https://raw.githubusercontent.com/amelchio/home-assistant/f3d869cdeef8feac445fe59bbcf8691694679a32/homeassistant/components/light/lifx.py

This component was merged to HA, so it should be part of the next release.

amelchio on 19 Mar 2017

@amelchio[1] My best guess regarding the error mentioned by @mihalski [2]is that there
are 2 messages sent to the bulb, the first one times out and unregister the bulb. When the
second times out, it also tries to unregister the bulb and the unregister method chokes on
that.

My 2 cents.

On Saturday, 18 March 2017 18:36:54 ICT Anders Melchiorsen wrote:

_@mihalski_
Thanks for doing the test. I made a fix on my branch now, you can try it out by installing
this file instead: https://raw.githubusercontent.com/amelchio/home-assistant/
f3d869cdeef8feac445fe59bbcf8691694679a32/homeassistant/components/light/lifx.py[3]
This component was merged to HA, so it should be part of the next release.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[4], or mute the thread[5].[6]

[1] https://github.com/amelchio
[2] https://github.com/mihalski
[3] https://raw.githubusercontent.com/amelchio/home-assistant/
f3d869cdeef8feac445fe59bbcf8691694679a32/homeassistant/components/light/lifx.py
[4] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-287587682
[5] https://github.com/notifications/unsubscribe-auth/
AORvqYDub_THyi5kciEI_Vl3psnAr5ijks5rnIa2gaJpZM4MTgc8
[6] https://github.com/notifications/beacon/AORvqUyYf-xB44jtKIMVEoSZsht2w02mks5rnIa2gaJpZM4MTgc8.gif

frawau on 19 Mar 2017

I've come across a problem with detection. This is a specific example of a broader problem:

I have a lamp with two lifx lights in it. Family Room Lamp 1 and Family Room Lamp 2. This component is detecting Family Room Lamp 2 but not Family Room Lamp 1. Meanwhile, over LAN, the LIFX iPhone app happily sees and controls both of these lights.

I haven't yet power cycled the light to see if it appears, and in case there is some sort of debugging I can do to help identify the problem.

mihalski on 19 Mar 2017

Another interesting thing I just encountered.

I built myself a box with five light sockets and Sonoff remote power switch. I currently have three lights in it and I tried powering it off. After a while all the lights became unavailable in HA (which is an awesome feature the old component didn't seem to support). I then turned the box back on and after a while all three light became available, however, for some reason one of the lights read the state incorrectly and showed as off. A simple toggle to on and then off turned the light off.

Is there a way to get view only the lifx component related logging? Would be curious to see what's happening during all these situation.

mihalski on 19 Mar 2017

May be you can try the aiolifx test program... just to check.... You can download it from
https://github.com/frawau/aiolifx/tree/master/examples

Just run it in the console, hit "return" a few times (quickly if you want to get a sense of
how fast/slow the bulbs are discovered) then you can "pay" with the light.

FWIW I have 10 Lifx (Original) and the they work almost flawlessly with aiolifx

Cheers,
François

On Saturday, 18 March 2017 21:42:40 ICT mihalski wrote:

Another interesting thing I just encountered.
I built myself a box with five light sockets and Sonoff remote power switch. I currently
have three lights in it and I tried powering it off. After a while all the lights became
unavailable in HA (which is an awesome feature the old component didn't seem to
support). I then turned the box back on and after a while all three light became available,
however, for some reason one of the lights read the state incorrectly and showed as off. A
simple toggle to on and then off turned the light off.
Is there a way to get view only the lifx component related logging? Would be curious to
see what's happening during all these situation.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[1], or mute the thread[2].[3]

[1] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-287594085
[2] https://github.com/notifications/unsubscribe-auth/
AORvqdgNZOhSPXEIDm7m7nVTuM7CMq6dks5rnLJAgaJpZM4MTgc8
[3] https://github.com/notifications/beacon/
AORvqfwotOdoxFSpD3HqjHhFO6vvotkoks5rnLJAgaJpZM4MTgc8.gif

frawau on 19 Mar 2017

Thanks. That's VERY useful.

You're right. It's VERY fast. But it doesn't detect all the lights. Some are simply off, but others, like Family Room Lamp 1 are on and controllable via the LIFX app. Here's the output I got:

(homeassistant_venv) homeassistant@homepi:~/.homeassistant$ PYTHONPATH=deps python3 lifx-cli.py 
Hit "Enter" to start
Use Ctrl-C to quit
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused

Select Bulb:
    [1] Bedroom Bedside Lamp
    [2] Dining Area Light 1
    [3] Dining Area Light 2
    [4] Family Room Ceiling Light
    [5] Family Room Lamp 2
    [6] Living Room Lamp
    [7] New E27 Light
    [8] Office Ceiling Light
    [9] Office Floor Lamp
    [10]    Spare Light 2
    [11]    TV Area Lamp

Your choice: Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused

Are those connection refused messages from the lights it's failing to detect?

mihalski on 19 Mar 2017

I also noticed that Spare Light 3 became unavailable 13 minutes ago. But in that case it is also unavailable via both LAN and WAN using the LIFX app.

mihalski on 19 Mar 2017

Weirdly Spare Light 3 has now come up in the list, but it remains unavailable in HA and via the LIFX app.

Select Bulb:
    [1] Bedroom Bedside Lamp
    [2] Dining Area Light 1
    [3] Dining Area Light 2
    [4] Family Room Ceiling Light
    [5] Family Room Lamp 2
    [6] Living Room Lamp
    [7] New E27 Light
    [8] Office Ceiling Light
    [9] Office Floor Lamp
    [10]    Spare Light 2
    [11]    Spare Light 3
    [12]    TV Area Lamp

Your choice:

mihalski on 19 Mar 2017

Wow... Never seen that one. Error 111 is an OS level error... Questions

What OS are you using (looks like Linux, but platform, distro, kernel)
   What version of Python 3.4 or 3.5?

From the answer I think 7 lamps are refusing to be contacted... but can you tell me exactly
how many bulbs are powered off.

On Saturday, 18 March 2017 22:10:45 ICT mihalski wrote:

Thanks. That's VERY useful.
You're right. It's VERY fast. But it doesn't detect all the lights. Some are simply off, but
others, like Family Room Lamp 1 are on and controllable via the LIFX app. Here's the
output I got:
(homeassistant_venv) homeassistant@homepi:~/.homeassistant$ PYTHONPATH=deps
python3 lifx-cli.py
Hit "Enter" to start
Use Ctrl-C to quit
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused

Select Bulb:
[1] Bedroom Bedside Lamp
[2] Dining Area Light 1
[3] Dining Area Light 2
[4] Family Room Ceiling Light
[5] Family Room Lamp 2
[6] Living Room Lamp
[7] New E27 Light
[8] Office Ceiling Light
[9] Office Floor Lamp
[10] Spare Light 2
[11] TV Area Lamp

Your choice: Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused
Error received: [Errno 111] Connection refused

Are those connection refused messages from the lights it's failing to detect?
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[1], or mute the thread[2].[3]

[1] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-287595013
[2] https://github.com/notifications/unsubscribe-auth/
AORvqdPuJBwDKcxrIi_bdT8K881SV9PWks5rnLjVgaJpZM4MTgc8
[3] https://github.com/notifications/beacon/AORvqTVxDGG-nT5NOTcZEs4z7XF2PO0Cks5rnLjVgaJpZM4MTgc8.gif

frawau on 19 Mar 2017

Linux homepi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
Running on Raspberry Pi 3 with latest Jessie.

Python 3.4.2

I think the errors might be because HA is running on the same machine and already has the lifx component running?

I'll do more work on this later this evening.. Currently I'm rushing out to an appointment.

mihalski on 19 Mar 2017

If it reappeared without restarting the test program, it is highly likely that it was either
powered off then on, or that for some reason it rebooted.

You can do a check. Take one of the lights you see. Power it off. Send a command to it, it
should disappear ... power it on, after roughly 15 secs it should come back

On Saturday, 18 March 2017 22:18:49 ICT mihalski wrote:

Weirdly Spare Light 3 has now come up in the list, but it remains unavailable in HA and via
the LIFX app.
Select Bulb:
[1] Bedroom Bedside Lamp
[2] Dining Area Light 1
[3] Dining Area Light 2
[4] Family Room Ceiling Light
[5] Family Room Lamp 2
[6] Living Room Lamp
[7] New E27 Light
[8] Office Ceiling Light
[9] Office Floor Lamp
[10] Spare Light 2
[11] Spare Light 3
[12] TV Area Lamp

Your choice:

—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[1], or mute the thread[2].[3]

[1] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-287595263
[2] https://github.com/notifications/unsubscribe-auth/
AORvqZcgyTPf81I6YB0aOrdg7VFgMoXBks5rnLq5gaJpZM4MTgc8
[3] https://github.com/notifications/beacon/
AORvqQnG3srQqqxfW14usk5VAm08oiuJks5rnLq5gaJpZM4MTgc8.gif

frawau on 19 Mar 2017

I am not using HA, but my own stuff, yet I could run the test program an my home
automation system in parallel with no problem. That was on a i7 though. I have found
issues with aiolifx once I started using a RPi3. It might be a good idea to run the test
program from a different host.

FYI I am in GMT+7 so not sure about timely responses.

On Saturday, 18 March 2017 22:26:14 ICT mihalski wrote:

Linux homepi 4.4.50-v7+ #970[1] SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/
LinuxRunning on Raspberry Pi 3 with latest Jessie.
Python 3.4.2
I think the errors might be because HA is running on the same machine and already has
the lifx component running?
I'll do more work on this later this evening.. Currently I'm rushing out to an appointment.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[2], or mute the thread[3].[4]

[1] https://github.com/home-assistant/home-assistant/pull/970
[2] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-287595521
[3] https://github.com/notifications/unsubscribe-auth/AORvqd-vyrphHYkqz6-uZ5qTKrDUWp3Sks5rnLx2gaJpZM4MTgc8
[4] https://github.com/notifications/beacon/
AORvqdd5mgcV4Qm06PEsFf6fmP6hjc3Iks5rnLx2gaJpZM4MTgc8.gif

frawau on 19 Mar 2017

@mihalski This is all very weird but I think it adds up if you have an IP address conflict (that is, multiple devices with the same IP address). Do you know how to check that?

Here is HA configuration to enable mostly lights related logging:

logger:
  default: critical
  logs:
    homeassistant.components.light: debug
    custom_components.light: debug

I expect that the log will show register NEWbut not register READY for the troublesome lights.

@frawau Lots of HA users are on Pis, did you find serious issues with aiolifx?

amelchio on 19 Mar 2017

I'm GMT +10 so it's close.

What happened here? :P

Hit "Enter" to start
Use Ctrl-C to quit

Select Bulb:
    [1] Bedroom Bedside Lamp
    [2] Dining Area Light 1
    [3] Dining Area Light 2
    [4] Dining Area Light 3
    [5] Family Room Ceiling Light
    [6] Family Room Lamp 1
    [7] Family Room Lamp 2
    [8] Living Room Lamp
    [9] Master Bedroom Bedside Lamp Jola
    [10]    Master Bedroom Bedside Lamp Stan
    [11]    New E27 Light
    [12]    Office Ceiling Light
    [13]    Office Floor Lamp
    [14]    Spare Bedroom Lamp
    [15]    Spare Light 2
    [16]    Study Desk Lamp
    [17]    TV Area Lamp
    [18]    d0:73:d5:12:1c:5f

Your choice: 
Select Bulb:
    [1] Bedroom Bedside Lamp
    [2] Dining Area Light 1
    [3] Dining Area Light 2
    [4] Dining Area Light 3
    [5] Family Room Ceiling Light
    [6] Family Room Lamp 1
    [7] Family Room Lamp 2
    [8] Living Room Lamp
    [9] Master Bedroom Bedside Lamp Jola
    [10]    Master Bedroom Bedside Lamp Stan
    [11]    Master Bedroom Desk Lamp
    [12]    New E27 Light
    [13]    Office Ceiling Light
    [14]    Office Floor Lamp
    [15]    Spare Bedroom Lamp
    [16]    Spare Light 2
    [17]    Study Desk Lamp
    [18]    TV Area Lamp

Your choice:

The lack of connection refused messages suggests that the "frozen" and/or "off" lights were refusing connection.

mihalski on 19 Mar 2017

I think this is the list of all the lights I currently have in service:

Your choice: 
Select Bulb:
    [1] Bedroom Bedside Lamp
    [2] Dining Area Light 1
    [3] Dining Area Light 2
    [4] Dining Area Light 3
    [5] Family Room Ceiling Light
    [6] Family Room Lamp 1
    [7] Family Room Lamp 2
    [8] Living Room Lamp
    [9] Master Bedroom Bedside Lamp Jola
    [10]    Master Bedroom Bedside Lamp Stan
    [11]    Master Bedroom Desk Lamp
    [12]    New E27 Light
    [13]    Office Ceiling Light
    [14]    Office Floor Lamp
    [15]    Spare Bedroom Lamp
    [16]    Spare Light 2
    [17]    Spare Light 3
    [18]    Study Desk Lamp
    [19]    TV Area Lamp

Your choice:

There are another 6 or so waiting to be deployed, but I held back after the problems with reliability. I'm certainly having VASTLY more feedback from the new lifx component. Even if only to tell me a light is unavailable.

mihalski on 19 Mar 2017

I does look good.... Test program running on same host as HA?

For checking duplicate addresses, arping would be best.

On Sunday, 19 March 2017 04:23:09 ICT mihalski wrote:

I'm GMT +10 so it's close.
What happened here? :P
Hit "Enter" to start
Use Ctrl-C to quit

Select Bulb:
[1] Bedroom Bedside Lamp
[2] Dining Area Light 1
[3] Dining Area Light 2
[4] Dining Area Light 3
[5] Family Room Ceiling Light
[6] Family Room Lamp 1
[7] Family Room Lamp 2
[8] Living Room Lamp
[9] Master Bedroom Bedside Lamp Jola
[10] Master Bedroom Bedside Lamp Stan
[11] New E27 Light
[12] Office Ceiling Light
[13] Office Floor Lamp
[14] Spare Bedroom Lamp
[15] Spare Light 2
[16] Study Desk Lamp
[17] TV Area Lamp
[18] d0:73:d5:12:1c:5f

Your choice:
Select Bulb:
[1] Bedroom Bedside Lamp
[2] Dining Area Light 1
[3] Dining Area Light 2
[4] Dining Area Light 3
[5] Family Room Ceiling Light
[6] Family Room Lamp 1
[7] Family Room Lamp 2
[8] Living Room Lamp
[9] Master Bedroom Bedside Lamp Jola
[10] Master Bedroom Bedside Lamp Stan
[11] Master Bedroom Desk Lamp
[12] New E27 Light
[13] Office Ceiling Light
[14] Office Floor Lamp
[15] Spare Bedroom Lamp
[16] Spare Light 2
[17] Study Desk Lamp
[18] TV Area Lamp

Your choice:

The lack of connection refused messages suggests that the "frozen" and/or "off" lights
were refusing connection.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[1], or mute the thread[2].[3]

[1] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-287609802
[2] https://github.com/notifications/unsubscribe-auth/AORvqZ_uwSCsG5qafSpn-NVKf0VXJXZ_ks5rnRAdgaJpZM4MTgc8
[3] https://github.com/notifications/beacon/
AORvqSwLuxo6z7J4arRN0jKcSmhLBtVAks5rnRAdgaJpZM4MTgc8.gif

frawau on 19 Mar 2017

Not that this was the result of power cycling any devices that weren't being detected or turning on any that were off.

mihalski on 19 Mar 2017

Spare Light 3 seems to be a problem light as it's unavailable again with no reason.

mihalski on 19 Mar 2017

@mihalski You said that you could ping the bulbs when they go offline. Please try using arping to confirm that it is the right MAC address that answers.

amelchio on 19 Mar 2017

@mihalski Is there any update on your issues?

amelchio on 22 Mar 2017

I have seen a VAST improvement in reliability and performance of the LIFX lights using the new component. Better even than with Lifx's own app.

Some of them do frequently become unavailable, but most are even controllable in that state so I think it has to do that I'm running on a Raspberry Pi 3. Awaiting the release of an updated aiolifx to see if that resolves things.

One in particular keeps becoming unavailable and even though I replaced it with another bulb that had NOT becoming unavailable has also started to become unavailable frequently. I noticed that aiolifx has a lot of trouble handling renaming of lights. Especially if you swap one out and use the same name.

mihalski on 22 Mar 2017

@mihalski I certainly have had issues with unresponsive lights in specific areas of my apartment, but I think that has more to do with weak wifi signals and issues LIFX bulbs have with reconnecting to the network and retrieving DHCP/Static IP addresses when they attempt to reconnect.

For example, my bulb in the entryway seems to have some issues, but replacing it with another bulb was fruitless, eventually I upgraded it to one of the 3rd gen color lights, which I suspect have fewer wifi issues and the reliability has been prefect since.

keatontaylor on 23 Mar 2017

In this situation the bulbs are in close proximity to each other so if anything interference from the other bulbs is a more likely cause.

But the fact that they are reported as unavailable and yet still get switched as part of the group implies that maybe it was the aiolifx bug that was found to affect Raspberry Pi.

Overall the reliability and functionality have improved through the roof. Even the "unavailable" state is SUPER useful as I can track when people turn their light off (for those lights that are reliable).

mihalski on 23 Mar 2017

Hi,

@mihalski[1] Are you using aiolifx >=0.4.2 ? Because with that version, on a RPi3 I have
not seen the problem with my system running uninterrupted for almost 6 days.

By this I cannot state that the problem does not happen, but if it does happen, it is much
less frequently.

I just pushed 0.4.3, the only difference is that the sample application can now be ran by
doing

 python3 -m aiolifx

Regards,
François

On Wednesday, 22 March 2017 13:42:38 ICT mihalski wrote:

Some of them do frequently become unavailable, but most are even controllable in that
state so I think it has to do that I'm running on a Raspberry Pi 3. Awaiting the release of an
updated aiolifx to see if that resolves things.

[1] https://github.com/mihalski

frawau on 23 Mar 2017

I am using 0.4.2 but it wasn't until just now that I realised that this commit:

https://github.com/frawau/aiolifx/commit/6497610db43da4b46a8bede61a2fca60a3418bd3

was included in 0.4.2. Doh!

So I had better figure out what's going on. At least things aren't as frustrating as they used to be.

mihalski on 23 Mar 2017

Hi,

To try to figure out what is going on, you might want to test with AutoBuddy, the soft I
wrote and use. It is much less developed than HA, and I am not suggesting you switch, but
for testing/troubleshooting, it could possibly help.

There is a RPi3 image and "some" instructions can be found under my github account
(frawau)

Cheers,

On Wednesday, 22 March 2017 21:23:30 ICT mihalski wrote:

I am using 0.4.2 but it wasn't until just now that I realised that this commit:
frawau/aiolifx@6497610[1]
was included in 0.4.2. Doh!
So I had better figure out what's going on. At least things aren't as frustrating as they
used to be.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[2], or mute the thread[3].[4]

[1] https://github.com/frawau/aiolifx/commit/
6497610db43da4b46a8bede61a2fca60a3418bd3
[2] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-288613686
[3] https://github.com/notifications/unsubscribe-auth/AORvqZUE-LBxs-tRPl9iw-W03EDX39aaks5rofPCgaJpZM4MTgc8
[4] https://github.com/notifications/beacon/AORvqan4op-_p8RA7yjCc7FIqyQVsKtfks5rofPCgaJpZM4MTgc8.gif

frawau on 23 Mar 2017

@mihalski Thanks for the update. I am sorry for your situation but it does not sound like that should be a reason for upholding the release of the updated LIFX component in the next HA version.

@frawau The release is done this weekend so I hope you are ready for some extra support questions :)

amelchio on 23 Mar 2017

On the contrary. Bring it on!

The updated component is a BILLION times better than the old one!

mihalski on 23 Mar 2017

🎉1

Grand Prix weekend, I should spend some time at home.... not in front of the computer
though ;)

On Thursday, 23 March 2017 00:29:12 ICT Anders Melchiorsen wrote:

@mihalski[1] Thanks for the update. I am sorry for your situation but it does not sound
like that should be a reason for upholding the release of the updated LIFX component in
the next HA version.
@frawau[2] The release is done this weekend so I hope you are ready for some extra
support questions :)
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[3], or mute the thread[4].[5]

[1] https://github.com/mihalski
[2] https://github.com/frawau
[3] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-288638176
[4] https://github.com/notifications/unsubscribe-auth/AORvqQULplpKgWZu2siu-QaVrKu6ptHYks5roh9IgaJpZM4MTgc8
[5] https://github.com/notifications/beacon/
AORvqWF1ntLZEzGVHLHg8dMeihT3FKXiks5roh9IgaJpZM4MTgc8.gif

frawau on 23 Mar 2017

Just thought id comment here because all you guys are knowledgeable with lifx/HA.
Is there a way to set the colour/brightness without turning the lights on with scenes?
I have tried with 'state': 'off', but this simply does not change the colours if the lights are already on.

Running newest HA with aiolifx

Any ideas?
Cheers

Charliedean on 30 Mar 2017

@Charliedean There is currently no way to set the color without affecting the power state but I do hope to work on that soon. (Incidentally, the forum is more appropriate for such questions.)

amelchio on 30 Mar 2017

I've noticed that sometimes (often?) even "unavailable" lights can be controlled by having their brightness changed. It seems like they're not REALLY unavailable.

Has anyone else encountered this? I only noticed due to lights in groups, some of which were unavailable still turned on and off with the group.

mihalski on 30 Mar 2017

@amelchio, just my two cents in the grand scheme of changing color/brightness without affecting power state. @balloob has continually made it clear that this violates his view of the state machine as bulbs that are off should have no color/brightness attributes. What I originally suggested way in August was adding a set_state method that would allow changing the brightness/color/power without the state change being explicitly tied to the current power state. This was somewhat rejected, but I was told to implement a set_brightness attribute instead. So just giving you some fair warning in some of the issues you might encounter.

For now I just override the turn_off method in my own installation to accept those brightness/color values and passes them along to the turn on method with a special flag to ignore current state.

For what it is worth, the library does seem quite stable and I am happy with it so far. :)

keatontaylor on 30 Mar 2017

@keatontaylor Thanks for the heads up. I did read much of your discussion with @balloob and I agree that he is wrong and you are right on this. I am sure that we can find a solution but I want to understand things better (including how Hue works) before pushing the issue.

Great that the library works for you, thanks for sharing!

amelchio on 31 Mar 2017

@mihalski I haven't noticed that but my lights rarely go "unavailable". How long will your lights stay "unavailable" after you notice that they actually do work?

amelchio on 31 Mar 2017

@mihalski, as far as unavailable lights are concerned, that may be due to poor wifi connectivity and the heartbeat that is sent from the library timing out. However, I believe aiolifx is setup to always attempt to send a command to a unavailable bulb regardless if the heartbeat failure has caused it to be flagged as unavailable.

This ensures the highest level of reliability if unavailability is for whatever reason wrong. We've talked a lot about your particular setup and I've mentioned a few times the importance of a strong wifi signal and I too have experiencing some minor issues, especially for bulbs placed in recessed lighting fixtures. I've also with one bulb requested a warranty replacement because it was having wifi issues regardless of placement. So I'd strongly suspect something along those lines and unrelated to the aiolifx are at fault.

keatontaylor on 31 Mar 2017

@keatontaylor [1]Actually aiolifx closes the connection to a bulb it deems unavailable and
recreates the unicast connection once it discovers the bulb or when the bulb broadcasts a
LightState message (as it does 15 secs after booting)

I am not sure how HA is using aiolifx, it could be that is uses "fire_and_forget" not
expecting any ack or response from the bulb with a very long polling cycle but it looks
more like a disconnect between the HA state and aiolifx state (or not using aiolifx when
the bulb is disconnected).

Not sure how many people are seeing this, but @mihalski [2]setup seems to be quite
peculiar ;)

Cheers

On Thursday, 30 March 2017 15:26:53 ICT Keaton Taylor wrote:

_@mihalski_, as far as unavailable lights are concerned, that may be due to poor wifi
connectivity and the heartbeat that is sent from the library timing out. However, I believe
aiolifx is setup to always attempt to send a command to a unavailable bulb regardless if
the heartbeat failure has caused it to be flagged as unavailable.
This ensures the highest level of reliability if unavailability is for whatever reason wrong.
We've talked a lot about your particular setup and I've mentioned a few times the
importance of a strong wifi signal and I too have experiencing some minor issues,
especially for bulbs placed in recessed lighting fixtures. I've also with one bulb requested a
warranty replacement because it was having wifi issues regardless of placement. So I'd
strongly suspect something along those lines and unrelated to the aiolifx are at fault.
—You are receiving this because you were mentioned.Reply to this email directly, view it
on GitHub[3], or mute the thread[4].[5]

[1] https://github.com/keatontaylor
[2] https://github.com/mihalski
[3] https://github.com/home-assistant/home-assistant/issues/
6435#issuecomment-290563125
[4] https://github.com/notifications/unsubscribe-auth/
AORvqd18-6Wkn0BudGm6__tBCLvHwNohks5rrCwtgaJpZM4MTgc8
[5] https://github.com/notifications/beacon/
AORvqU0lpgyxj2iXzOoeIzl3UJJNdHA8ks5rrCwtgaJpZM4MTgc8.gif

frawau on 31 Mar 2017

@keatontaylor It seems that all the lights have between good and very good signal. In my experience since I made upgrades (due to the Lifx lights) my wifi has been bulletproof everywhere inside the house as well as all AROUND the house (as in outside).

It may be that a build itself is at fault but I'm still not seeing anything jump out at me. Going to have to do some querying/visualisation of the influxdb data.

Also, it would be MUCH easier to track all my bulbs if people stopped turning them off. If only there were small reliable wireless buttons available :/ And not stupid garage remote fobs.

mihalski on 31 Mar 2017

@mihalski[1] I feel you pain..... I have the same issue.... and I do have small reliable
wireless (bluetooth) button flic at https://flic.io/. Using the embedded bluetooth in a
Raspberry Pi 3 they have been very reliable for me. They are a bit pricey though

In my case my wife still insist on turning them off with the old switch... grrrr

On Friday, 31 March 2017 01:50:49 ICT mihalski wrote:

Also, it would be MUCH easier to track all my bulbs if people stopped turning them off.
If only there were small reliable wireless buttons available :/ And not stupid garage
remote fobs.

[1] https://github.com/mihalski

frawau on 31 Mar 2017

I'm currently trying to figure out how to make such a switch, but honestly.. The enclosure is the hardest part :/ I think I could manage the electronics if only an enclosure presented itself that was suitable.. I plan on doing a LOT of ordering off AliExpress over the next few months to experiment..

mihalski on 31 Mar 2017

@mihalski Can you try this and see if it is better at keeping your lights available? It allows a few lost packets before marking a light unavailable.

https://github.com/amelchio/home-assistant/blob/lifx-unavailable/homeassistant/components/light/lifx.py

amelchio on 1 Apr 2017

Should I overwrite the existing one or rename it and stick it in custom_components ?

mihalski on 2 Apr 2017

@mihalski Both ways work. I like the custom_components one because it makes it easy to change back.

With this change, I still have lights dropping off but it should help for the cases where you are still able to control an unavailable light.

amelchio on 2 Apr 2017

I've been fighting a major recent problem I've been having with HA that results in "too many open files" errors on a MASSIVE scale.. Still working to figure it out, but this seems relevant.. I'm off to report the Unifi component issue next.

pi@homepi:~ $ sudo lsof | wc -l
21795
pi@homepi:~ $ sudo lsof |grep homeassistant |wc -l
15445
pi@homepi:~ $ sudo lsof |grep homeassistant |grep -i lifx |wc -l
4998
pi@homepi:~ $ sudo lsof |grep homeassistant |grep -i ubnt |wc -l
8942
pi@homepi:~ $ sudo lsof |grep homeassistant |grep -vi ubnt | grep -vi lifx |wc -l
1537

Here's a graph of "sudo lsof | wc -l" and "sudo -u homeassistant | wc -l" :

screen shot 2017-04-07 04 45 30 pm

The large cliffs are restarts of HA. Is anyone else experiencing this?

mihalski on 7 Apr 2017

@mihalski Please create a new issue for that (and please include a few of the lsof entries).

amelchio on 8 Apr 2017

Core: Migrate the LIFX component to aiolifx

All 99 comments

Related issues