SmartThings virtual devices using CLI

Hi, @georgeh
The devices that you mention you’re having issues with are those that you created using the “local” flag?

1 Like

Yes. I tried both the CLI command-line mode as well as the “interactive” mode, both with similar results… each time with the local flag (shown in one of my snippets above).

Hi @nayelyz ,
Just wanted to check whether you were looking into the issue I’m having creating virtual devices (to confirm my assumption). It is not urgent, since the recent fix to migrated virtual devices repaired my existing ones, but I would still like to be able to create devices in the future using “stock” methods.

thanks!

Yes, we already created a ticket because we saw other issues in the CLI when we try to create “local” virtual devices and this one where commands to them also fail. Sadly, we haven’t got any feedback yet.

1 Like

Hi, @georgeh
The team mentioned there shouldn’t be an issue with the local virtual device created with the command

smartthings virtualdevices:create-standard --name=nameAssigned --local

I created one and had no issues sending a command to it the same way you did.
So, this might be due to something else.
I see you used the flag “–token=xxx” in the command for the creation of the device.
Is that different from the one that the CLI gets automatically? Because that could explain the “403” error code

1 Like

Tried that command again, no luck. Log below. It does create a device, but the device is broken as it shows a greyed out button in the app that doesn’t allow turn on/off.

The token was one I created for access, which I believe maybe different from the CLI standard use. But this time (as originally) I just used the CLI login and interactive mode, so the token is not relevant to this failure.

C:\Users\grhay>smartthings virtualdevices:create-standard --name=ST-GRH-vs4 --local
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 #   Name                   Room Id                               Location   Location Id
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 1   Bedroom                978be6b6-9c22-4172-1cx  HayekHome  8d34ec44-1nothingtoseehere
 2   Den                    7f870f7a-d4eb-43c8-926c-c1xx8  HayekHome  8d34ec44-1nothingtoseehere
 3   Energy Meters          1be2dcf9-30c6-44e4-96x  HayekHome  8d34ec44-1nothingtoseehere
 4   Family Room            ccb87439-2359-4f34-87ax  HayekHome  8d34ec44-1nothingtoseehere
 5   Garage                 2a465863-7229-4c52-92d2-x  HayekHome  8d34ec44-1nothingtoseehere
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 6   Media Room             5d244e80-55c9-4d88x  HayekHome  8d34ec44-1nothingtoseehere
 7   Not in Use Stuff       faddac13-d956-47bb-b21x  HayekHome  8d34ec44-1nothingtoseehere
 8   Outside                8375557a-adfc-4194-9x  HayekHome  8d34ec44-1nothingtoseehere
 9   Presence Devices       ce371040-f8fd-4x HayekHome  8d34ec44-1nothingtoseehere
 10  System Infrastructure  ef7597d0-7343-45x  HayekHome  8d34ec44-1nothingtoseehere
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 11  Upstairs               9fe84080-de9b-447b-x  HayekHome  8d34ec44-1nothingtoseehere
 12  Wine Cellar            36fb0ad6-19e3-4f5b-x  HayekHome  8d34ec44-1nothingtoseehere
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
? Select a room. 10
─────────────────────────────────────────
 #  Name           Id
─────────────────────────────────────────
 1  Switch         VIRTUAL_SWITCH
 2  Dimmer Switch  VIRTUAL_DIMMER_SWITCH
─────────────────────────────────────────
? Select a device prototype. 1
    AxiosError: Request failed with status code 403: {"requestId":"2779494418826588550","error":{"code":"A resource
    could not be found.","message":"ForbiddenError","details":[]}}
    Code: ERR_BAD_REQUEST

Hi, @georgeh
Thank you for the info, this is super helpful. The team is already aware of your issue and is investigating more details about it. We’ll keep you updated.

2 Likes

Any visibility into when this might get fixed? I see there’s a method to create a virtual device using the advanced web app, however that seems to only support a cloud based device (not local). (I now have need to create one, and would prefer a local standard (vs. community) solution.)

1 Like

Hi, @georgeh
Sorry for the delay, have you recently done the following?

  1. Send another command to the pre-existing standard virtual local device
  2. Created a new device and send commands to it

The team made a change on August 1st, that’s why I need to check if the issue remains and where, please.

1 Like
  1. The pre-existing device (switch) that I had around is still broken.
  2. A new device I just created works fine.

So things seem good now. Thanks for getting back on this.

1 Like

@AlejandroPadilla any update on this?

I have been using the Local Virtual Switches for more than half a year now.
The Virtual Switches have worked flawlessly all time.

The Virtual Switch Driver is simple and its memory requirement is small.
The driver is only suitable for virtual switches.

If the need for use is only the virtual switches,
then the use of this Virtual Switch Driver leaves memory space in the hub to use other drivers.

The only drawback in these Virtual Switches is that they have to be done using the CLI.

These are not the same as created using the API +Browser?
I’ve never used the CLI but have several of these local virtual switches and they’ve run perfectly.

EDIT Confirmed that this is the same Virtual Switch, created both by CLI with the --local flag or using the API +Browser, in that case checking the ‘local’ selection box. Should be noted that the browser has the option for several device types but only the switch can be local at present.

1 Like

Maybe someone else can answer this. I’m not using API +Browser. I started using CLI before API +Browser existed.

I think they are the same virtual switches.

Virtual Switch Driver ID from AWA is 572a2641-2af8-47e4-bfe5-ad83748fd7a1.

I don’t know about the API +Browser but the Advanced Users app also lets you create virtual devices, the difference is that they run in the Cloud.
The ones @TapioX created were using the flag --local which uses a driver to run in the Hub.
So, in that regard, I’ll see if we can request an option in the Advanced Users tool to use the “local version” of the virtual device.

4 Likes

This would be a good improvement.

1 Like

@TAustin 's excellent API + Browser I always understood to be based on the CLI. If we go to Devices/Virtual Devices/Create (the vEdge virtual devices are NOT here) we can create a local switch (ONLY switch) from a list of virtual devices.
On the Advanced ST UI this lists as local, although no driver is seen in my case :man_shrugging:

Interesting, I see the same, I’ll report that as well.

1 Like

I think that real reason is that it’s not possible change virtual device’s driver.

It would be nice to see the driver (read only) even if you can’t change it.

The CLI uses the Core SDK which in turn accesses the public SmartThings API. I believe there are a few bits and bobs like Edge invites that are handled internally because they are a bit weird. It has its own security scope when used with default authentication that lets it do a few things that a PAT can’t do.

The API Browser+ accesses the public SmartThings API directly using a PAT, and picks up a choice morsel or two from elsewhere.

I am pretty sure the driver did appear once but I suspect it probably now hides the driver deliberately to avoid it getting tangled up with the functionality to change drivers. I’d imagine that could get a bit messy.

You will probably see it if you look at the details of a virtual device using the API Browser+. It certainly shows the drivers for my virtual devices.

5 Likes