Shell Command vs RESTful Command

Configuration
1

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:

shell_command:
  lamp1_on: curl http://192.168.1.222/relay/0?turn=on
  lamp2_on: curl http://192.168.1.224/relay/0?turn=on

-vs-

rest_command:
  lamp1_on:
    url: "http://192.168.1.222/relay/0?turn=on"
  lamp2_on:
    url: "http://192.168.1.224/relay/0?turn=on"
2

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.

3

What extra is required for Shell? Whatever it is, is apparently already there. :slight_smile:

And results are unimportant, these are fire and forget.

4

In an automation why not use the light.turn_on service?

5

I made my original post as short as possible. In reality, I’m trying to hit URLs like

http://192.168.1.233/color/0?turn=on&red=255&green=80&blue=0&white=1&gain=10

“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.

6

Ha can do that without rest.

7

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…

8

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.

9

I don’t think there is any important difference.

What are these bulbs by the way?

10

Shelly DUO GU10. Terrible color fidelity.

11

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.

12

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.

13

I am curious, and I know you have solved your issue, so if you get sick of me, just say :).

So are you saying that if you put those RGBW values into the light.turn_on service you get a different lighting level than using DDD?

By the way, I didn’t suggest the colour wheel.

14

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. :slight_smile: Great tip, thank you for the pointer!

15

OK, if this helps, take a look at your Home Assistant UI and on the left hand choose Developer Tools and then select the Services Tab.

In the top element choose the service light.turn_on.

If there is a button that says “Go to UI mode” click on that.

As the target click on “choose entity” and choose the light.whatever (your shelly bulb).

In the RGBW field tick the box to the left and type in the box [255,80,0,1]

Click on the button that says “call service”. See if it looks like you want.

If I click on YAML mode, it shows that this has created a service call like this

service: light.turn_on
data:
  rgbw_color:
    - 255
    - 80
    - 0
    - 1
target:
  entity_id: light.hue_lamp_1

(Obviously I am using a hue bulb as I don’t have a shelly one to play with, but the principle should be exactly the same.)

You can use call service as the action in any script or automation.

16

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. :wink:

17

Holey sheets, that works SO WELL!

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.”

18

Shell will use bash of underlying operating system, that is the external dependency.

Rest will use internal software packages of home assistant to call remote URL.

1 Like
19

It is still an external context, that needs to be created for bash, curl and required libraries.

But - use whatever works best for you …

20

The shell command has to create a sub process. This can be orders of magnitude slower depending on the host platform/OS. Use rest if you can.