I am submitting a feature request to add another section to the built in Nanoleaf driver. Currently, there is an effect set number field. It works well, but takes a lot of trial and error to get right. It also becomes unreliable as you change effects in the native app.
Honestly, it hadn't become a problem for me until just now. It seems to be the crossover of scenes that are applicable across devices doesn't have a clear rhyme or reason to how they're numbered. I don't even have 46 effects in the app and I don't understand why the one I want is number 46).
Some of these devices share scenes from the native app and it's just an inefficient mess to keep clean when referencing them by number.
There's been a recent addition to the TP Link driver app that allows for the effect name to be entered. As long as you get the case sensitivity right, it works beautifully.
The set effect number, next effect, previous effect all have their applicable place but allowing the effect name on Nanoleaf would provide a cleaner/more future-proofed experience and downstream automations.
Theres a big difference in writing webcore to run effect number 46 when set effect: rainbow is much more concise.
Given that the nanoleaf devices have a state called lightEffects which is a map of the effect number to the name, It probably wouldn't be too tricky for someone to write some app/device that could set the effect by name. Although it'd obviously be a lot easier to do it in the device itself.
It can probably be done already in WebCore - not sure about Rule Machine though.
This information certainly takes some of the guesswork out of the above problems I was having. I think I'm going to do some cleanup and work with this new information......but I'd still like to just do this by effect name
So I've had a little time to play with this and here's my honest feedback: I think the numbering of scenes adds a level of complexity thats not necessary.
For instance:
I knew that this list of scenes is kind of set in stone if I want to automate off of it. I downloaded a bunch of scenes, got them all numbered out, configured them by number in webcore.
Oh no, there's a scene that I need to change in the native app, MAYBE I'm just changing the name. It creates a new scene, I delete the original, now all my scene configs from webcore are off by one.
So now at bedtime, instead of my 54 panel canvas being set to a scene at 3%, it gets set to another scene of a million lumens and every scene I configured is out of whack.
Is this the end of the world? No. But what this means is you are basically locked into whatever scenes you have and any changes that are not add only (as the numbers increment +1) will mess up any configuration you have.
In the TP Link driver, the scenes have name AND number (they are not tied to a singular string). So sure, you can configure by scene number and incrementally change scenes how you want but you can ALSO configure by name only. What this eliminates is the number changes caused by scene deletions in the native app. If I delete 5 scenes in the app, it doesn't push all my configurations by 5. If you change a scene name in the app, sure you're going to have to reconfigure but I think that's the low runner. The ease of which this can get out of whack makes it a non-viable solution (if you ever want to make scene changes ever again).
I think I want to clarify the request. I want to be able to call nanoleaf by scene name WITHOUT the numerical scene number being involved.
Because I'm an absolute glutton for punishment, I purchased yet another nanoleaf device.
I have learned a workaround to this feature request. By strategically naming the scenes in the native app starting with numbers, I can force the app to always keep the scenes in the same order, providing MORE stability with downstream automations.
As long as I always replace a scene with an identical number preceeding it, I can keep them in order/maintain automation integrity; add any new scenes to the end. It appears to accept 25 scenes.
I would STILL prefer a way to call scene/effect by case sensitive name like with the TP link integration, but this is an acceptable workaround in the meantime that offers SOME future-proofing.
Edit: I didn't realize I was grabbing the screenshots with power warnings. That's a whole other issue that I'm working with nanoleaf on. They're sending me a new unit because we suspect the new firmware bricked my canvas.
