I’d like to fire off some Shelly DDD URLs via an automation, and have gotten both Shell and Rest to work. They seem to be exactly the same in this particular case, why would I use one over the other for this simple task?
For example, these two entries appear to provide exactly the same functionality:
The first (shell) is more general, but requires the existence of additional software on the HA host, while the second is more specific and (probably) uses „native“ functions from the HA software stack. Also, it has advantages on handling the results.
“turn=on” was just a simplified example, what I used to see if these Command types would even function. Turns out that they both do, so now I’m wondering which way to go.
I’ve tried it, HA doesn’t seem to have the ability to accurately set the color to these specs, only to something close to it. The bulbs are awful, need to be replaced, but for now this is the only way to switch them between two desired color states.
At any rate, back to the original “which is better” question…
I’ve found that the Shell command can hit these URLs in parallel, separated by &. Maybe Rest can too, but at this point I might just go with Shell if there’s no compelling reason not to.
Interesting, given the overall quality of shelly products.
Are you saying the DDD url gives a better colour rendition than the HA light.turn_on service? If so you should post your findings to github so the HA devs can do something about it.
Oh, far more granularity. The DDD URL provides 765 color combinations, and 100 brightness steps. The color wheel in the HA UI can’t come close.
A few firmwares ago, one could control R G B and W at the same time via DDD, 1020 combinations, and the colors were quite nice. But now the W channel is disabled when in Color Mode, so the colors are all too rich, muddy, dirty, harsh without that little touch of W to soften them. Other parts of the firmware have been updated since then as well (like the WiFi stack I think?) so downgrading will brick them. I and others have asked quite a few times why Shelly did this, no answer. And White Mode is no help, as there’s only the options of “Too-Cool Warm” and “WAY-Too-Cool Cool.”
Maybe color rendition via HA is a workable feature with other bulbs, but with the GU10s, the only way to make them usable is with the finer control of DDD.
Not sick of you, but definitely embarrassed to say that I’ve never seen the docs, nor the values available, for light before now. [sheepish]
While DDD will do what I need for now, I obviously have some studying to do if I want to transition to the correct way of doing things. Great tip, thank you for the pointer!
Initially I was going to add a new Light card to the dashboard, Call Service, and fill out the fields you mention above. Heading downstairs to fiddle with it. Kind of excited.
Back when I got these bulbs, I genuinely don’t think HA had such a robust color control. Could be wrong, could be that I just didn’t see it before now.
And get this; HA can even set the “disabled” white channel, the bulbs have been saved. Even though the ability is featured in Shelly’s own DDD documentation, the white= value in the URL no longer does anything. But HA can do it!
@nickrout, thank you SO MUCH for sending me down this path. Now when I turn on/off the projector, the room is set to exactly the lighting I want. No more “ew, god that color is grotesque.”