Bug: HTTP Cycle API ignores zones

There appears to be a bug with selectors and the Cycle API.

I’m POSTing to https://api.lifx.com/v1/lights/id:d073d5xxxxxx|0-7/cycle but the state is being set across the entire Z instead of just the first 8 zones.

Also, there is no (documented) fast option for the cycle API which would be handy. As well as bumping the states limit to 6 (but that’s just a personal request).

Hi,

We’ve started work on adding zone support to this handler :slight_smile:

Unfortunately we won’t be able to add a fast option to this endpoint because it relies on getting the current state of the device to know which state to go to next (the fast option in the state endpoint essentially bypasses getting the current state of the device).

When we’ve got the change ready we’ll also change the limit to be a bit higher.

I’ll post here when the changes are done (probably next week sometime)

Stephen

1 Like

Hello,

You can now use zone selectors with cycle!

Also, you may now specify up to 10 different states to cycle between.

Stephen

1 Like

Sweet. I’m looking forward to playing with this once I’m back in Melbourne in August. :slight_smile:

Hey Stephen,

If I specify any zones, I get a timed_out error. Sending the identical cycle to just the selector works fine, though:

id:d073d5XXXXXX => works fine
id:d073d5XXXXXX|0|1|2|3 => returns "status": "timed_out"
id:d073d5XXXXXX|0-3 => returns "status": "timed_out"

Also, it doesn’t recognize the all zones option, i.e. id:d073d5XXXXXX|all returns "error": "Unknown zone identifier: 'all'".

Only three zones certainly shouldn’t time out, that’s a bit weird. Do those zones at least change on the strip? I just tried it against my strip at home and it seems to work for my strip.

As for all, that’s not a valid zone specifier. If you want the whole device, don’t specify any zone specifiers.

Nope. The only time the strip changes is if I don’t specify a zone at all. Even trying to target a single zone gives me a timeout response with no change occurring.

Whoops, my bad. I misread/misinterpreted the selector docs.

hmm, that’s super bizarre.

Are you able to try sending one of these https://lan.developer.lifx.com/docs/multizone-messages#section-setcolorzones-501 over your local lan?

For example, if you have python3.6 or later installed:

# I recommend doing this in a virtualenv
pip3 install lifx-photons-core

# make the whole strip red and turned on
lifx lan:transform d073d5000001 -- '{"power": "on", "color": "red", "brightness": 0.1}'

# Make the first few zones green
lifx lan:set_zones d073d5000001 -- '{"start_index": 0, "end_index": 3, "hue": 100, "saturation": 1, "brightness": 1}'

# Also, might be helpful knowing what type of strip and firmware you have on it
lifx lan:get_attr d073d5000001 version --silent
lifx lan:get_attr d073d5000001 host_firmware --silent

Both the lan:transform and lan:set_zones commands work fine.

Output from the strip/firmware commands:

$ bin/lifx lan:get_attr d073d52716ae version --silent
d073d5000001: {"product": 32, "vendor": 1, "version": 512}

$ bin/lifx lan:get_attr d073d52716ae host_firmware --silent
d073d5000001: {"build": 1529627232000000000, "reserved": 1529627232000000000, "version": "2.76"}

The strip I’m testing with has 48 zones, btw. It’s 6 strips with a 10cm official LIFX Z connector between each strip.

Ok, so the bug is on our end!

Seems when I tested it on my strip at home I was using the state endpoint instead of the cycle endpoint which is why it worked for me.

I’ll let you know once we’ve resolved the issue.

No problem. In the meantime, I’ll continue to poke and prod Photons Interactor which seems intriguing. :wink:

hehehehe, yeap, I have grand plans for photons interactor, but still very early days :slight_smile:

Easy to get running though,

pip3 install venvstarter
./interact serve
# press enter to make a configuration file
# go to http://localhost:6100

Oh, I’ve had it running since Saturday. :sunglasses: If I’m not mistaken, this feels like something that could ultimately become a local LAN implementation of the HTTP API (amongst other things). And certainly better developed than the really crappy one I half-built in Node.js, as a learning exercise for Node.

Oh nice :slight_smile:

Yeah, the idea is a local http api like thing. For example, once you’ve got it running you can run

./command transform '{"transform": {"power": "on", "brightness": 0.5, "color": "red"}, "matcher": "cap=multizone"}'

The command helper is just a few lines of bash that curls localhost:6100.
And you can get help on the commands with something like ./command help '{"command": "transform"}')

This project is also a chance to make photons used for something useful.
And lets me opensource some things that didn’t make sense to include in photons itself.

The command helper is just a few lines of bash that curls localhost:6100.

Yes, I’d worked that out too. :smiley: I got to the point of sending some fairly basic but really fast state changes to my strip as a pseudo-animation.

1 Like

Ok,

So we fixed a couple bugs and cycle works most of the time now.

The more zones you request the longer it takes to get the current state of the strip and this can cause it to time out before it gets to the part where it actually changes the strip. We’re investigating how to make this better.

For now, if you’re just cycling the first three zones it should work all the time.

I’ll test tomorrow, but my goal is to change all 48 zones all the time, so I’ll keep diving into Photons more as well.

Good news: it can change all 48 zones in a single update.

Bad news: it’s way too slow to use for my intended purposes, but I understand why. However, this may not be as big of a problem now that I’ve discovered Photons Interactor. :grin:

Fair enough.

The good news is we have firmware plans to make this a lot faster, but yes, for now it’s very slow.

Though if you don’t care about specific zones, then don’t have a zone specifier at all and it won’t spend time trying to work out the current state of all the zones.