General Questions

[marshalltech81]

I am sorry to leave this issue but I did not know the best way to contact you with general questions.

First of all, thanks for all of your hard work in the LIFX community. I have been working on a couple of different LIFX concepts that I thought I could use your photons library for and had some general questions about how it worked. I did read all of the documentation I could find and I apologize if what I am asking is covered there.

1. I remember reading somewhere that you should not send more than x number of requests to the LIFX device during a y given amount of time. Does photons respect that?

2. According to https://photons.delfick.com/interacting/packets.html, is seems like ack_required and res_required are true by default but according to https://lan.developer.lifx.com/docs/changing-a-device it seems like for set messages you want the res_required to be set to false as "Note however that if your Set messages changes the visual appearance of the light it is likely you'll get the state of the device before your change."

3. Based on your profile at https://delfick.com/, I believe you mentioned that you had code that allowed you to interact with a "virtual" bulb. Will that ever be folded into this library.

[delfick]

but I did not know the best way to contact you with general questions.

This is the best way cause I no longer look at the community forums

First of all, thanks for all of your hard work in the LIFX community

:)

I did read all of the documentation I could find and I apologize if what I am asking is covered there.

The documentation certainly ain't comprehensive hahah

I remember reading somewhere that you should not send more than x number of requests to the LIFX device during a y given amount of time. Does photons respect that?

It's more that just the device doesn't necessarily keep up than anything bad happening. Photons does have a default limit to how many inflight messages haven't been replied to before it'll send more.

So:

async for _ in sender(Repeater(msg), reference, limit=50):
    ...

With that, once 50 messages have been sent and none of them have been replied to, it won't send anymore till one of them has been replied to (or timed out). It does this by turning that into a semaphore (or you can pass in a semaphore yourself)

https://photons.delfick.com/interacting/sender_interface.html#the-sender-interface

Ends up getting used here https://github.com/delfick/photons/blob/main/modules/photons_transport/targets/item.py#L291

It defaults to 30, which was a very arbitrary choice. There was a point where one of the Android engineers had fixed a bottleneck in the Android app and a phone was able to change more lights than photons more efficiently and the only way for photons to beat that against so many devices at the same time was to remove the inflight limit hahah

According to https://photons.delfick.com/interacting/packets.html, is seems like ack_required and res_required are true by default but according to https://lan.developer.lifx.com/docs/changing-a-device it seems like for set messages you want the res_required to be set to false as "Note however that if your Set messages changes the visual appearance of the light it is likely you'll get the state of the device before your change."

I have an idea that maybe I'll get to one day where photons doesn't even expose those two flags. I made photons before I understood how those two flags work and interact (there are some other private things they do). But the advice I give now is to always set res_required to False, assume Get messages give back a reply and never care about replies from Set messages.

Based on your profile at https://delfick.com/, I believe you mentioned that you had code that allowed you to interact with a "virtual" bulb. Will that ever be folded into this library

It's for the best I don't make it easy to start a virtual device. I'd rather not encourage reverse engineering :p

[delfick]

Also you could say the backoff logic for retrying messages helps with the not flooding a device with messages.

https://github.com/delfick/photons/blob/main/modules/photons_transport/retry_options.py#L28

https://github.com/delfick/photons/blob/main/modules/photons_transport/targets/__init__.py#L20

[marshalltech81]

I have an idea that maybe I'll get to one day where photons doesn't even expose those two flags. I made photons before I understood how those two flags work and interact (there are some other private things they do). But the advice I give now is to always set res_required to False, assume Get messages give back a reply and never care about replies from Set messages.

It is not necessarily reverse engineering. Having a virtual or a proxy bulb would open up all sorts of possibilities of better coordination with various smart hub platforms.

[delfick]

Having a virtual or a proxy bulb would open up all sorts of possibilities of better coordination with various smart hub platforms.

Absolutely.

However I am being careful because of the "not assisting" part of NDA around the non public knowledge I have :)

[marshalltech81]

I understand and my apologies. I was not thinking about that aspect of things.

2 big things I would like to do with the 50+ LIFX bulbs I have is the following:

1. I currently own a Philips Hue Play HDMI Sync Box. I would like to be able to control my LIFX bulbs from a virtual hue hub

2. the virtual bulb would enable management of arbitrary groups of bulbs that could be controlled as various groups within the LIFX app vs relying on a Hubitat, Home Assistant, etc where groups and scenes of bulbs managed by those platforms produces at times a popcorn effect of managing the bulbs.

I will conclude by stating I do think LIFX to be the superior bulb in this space! I want to try to integrate it into as many things as I possibly can and I appreciate you taking the time to put this library together!

[delfick]

I understand and my apologies. I was not thinking about that aspect of things.

All good :)

the virtual bulb would enable management of arbitrary groups of bulbs that could be controlled as various groups within the LIFX app vs relying on a Hubitat, Home Assistant, etc where groups and scenes of bulbs managed by those platforms produces at times a popcorn effect of managing the bulbs.

I'm unsure what this means, but good luck!

and I appreciate you taking the time to put this library together!

You're welcome :)

[delfick]

actually, are you saying you want to make the lifx app see non lifx things as if they were lifx things?

[marshalltech81]

Well there were a couple of use cases I had in mind ...

1. Testing against LIFX clients and integrations
2. Creating better Groups so such other applications can discover the Virtual Bulb and have the Virtual Bulb control and/or orchestrate other LIFX bulbs behind the scenes. Like I have 50+ LIFX bulbs and importing them into a home assistant is kinda a pain where I only care about the group of bulbs to control them as one entity. Like I have 8 living room ceiling bulbs that I only need to expose as 1 ceiling bulb. I will never control the 8 individually

[delfick]

fair enough. I'd say it's probably better to improve home assistant for that requirement. (or wait a decade for everything to be using matter :p)

[marshalltech81]

i understand ... let me ask another salient message. If you send a device message to a device that doesnt support that message, what is the outcome? Does photons attempt to do anything with device type or does it just pass the message?

lastly do you know of anything that will allow LIFX bulbs to be integrated by a Philips Hue bridge. I would love my LIFX bulbs to be triggered by the Philips Hue Play HDMI Sync box

[delfick]

The sender itself doesn't care, it sends whatever bytes you want wherever you tell it. But photons does provide constructs to help make sure you only send messages to devices that support a message. If you send a packet to a device that device doesn't support, the device will see that packet and essentially be all like "what is this?" and ignore it.

https://photons.delfick.com/interacting/gatherer_interface.html

lastly do you know of anything that will allow LIFX bulbs to be integrated by a Philips Hue bridge. I would love my LIFX bulbs to be triggered by the Philips Hue Play HDMI Sync box

nup, I only know LIFX things, and even then I'm not really a fan of IoT in general. @Djelibeybi might have ideas?

[Djelibeybi]

You can do it in a round about way via Razer Chroma Connect. Hue for PC/Mac can send data to Chroma which in turn can connect to LIFX devices.

Might also be possible in a similar way using other RGB software like Hyperion-NG or OpenRGB but I've only done it with Razer.