Virtual Devices Using New Official Web Interface

Devices & Integrations Connected Things
1

Twelve hours in and the test device is still working.

Just to clarify, what this means is that custom virtual devices of type VIRTUAL powered by custom Edge drivers can be created by API calls instead of masquerading as LAN devices and being managed by a sentinel device. I don’t really like Edge drivers and I feel the developers have lost the plot with capability presentations, but I should be able to roll my own virtual devices now.

The deficiency is arguably in cloud based virtual devices now.

4 Likes
2

@TAustin Does this change your thinking on the vEdge Virtual Devices driver? Would you consider migrating to using this kind of an implementation?

3

As soon as the SmartThings-native virtual devices were available, I said that if they meet their needs, then people should use those instead (and why I included the ability to create them in the API Browser+). I even suggested sunsetting my vEdge driver, but enough folks had balked at that, pointing out that the SmartThings virtual devices are pretty simplistic and may not meet everyone’s needs. For example, if you need a virtual presence or motion sensor - you need a way to actually change the state. Thus the inclusion of secondary controls in the vEdge devices to accomplish that. Last I looked, the SmartThings-native ones didn’t include that, but I could be out of date on that. There are other examples of vEdge devices with additional features (auto-revert, icon selection, etc.) that could still be considered useful. But certainly for something as simple as a virtual switch - you should use the native ones.

The community-developed stuff was often stop-gap solutions while the official SmartThings capabilities were lacking. Now that they are getting caught up in some of these areas (virtual devices, Smartthings for Advanced Users, etc.), it’s certainly true that much of this stuff may no longer be needed. It may be time to take my ball and go home. :slight_smile:

5 Likes
4

Please don’t just take your ball and go home. You’ve done some amazing useful stuff!

5

I was more thinking about the new ability to create true VIRTUAL devices that are powered by Edge drivers as mentioned by @orangebucket which gives the ability to have custom virtual devices that execute locally vs LAN devices mimicking virtual device behaviors.

DESCRIPTION
  create a virtual device from a device profile ID or definition

  The command can be run interactively in question & answer mode, with command line parameters, or with input from a file or standard in. You can also run this command multiple times with the same input file but different command
  line arguments to create multiple devices with different names in different locations and rooms.

EXAMPLES
  $ smartthings virtualdevices:create                            # interactive mode

  $ smartthings virtualdevices:create -i data.yml                # using request body from a YAML file

  $ smartthings virtualdevices:create -N "My Device" -i data.yml # using file request body with "My Device" for the name

  $ smartthings virtualdevices:create \                          # using command line parameters for everything
  >    --name="My Second Device" \ 
  >    --device-profile=7633ef68-6433-47ab-89c3-deb04b8b0d61 \ 
  >    --location=95bdd473-4498-42fc-b932-974d6e5c236e \ 
  >    --room=c7266cb7-7dcc-4958-8bc4-4288f5b50e1b

  $ smartthings virtualdevices:create -f profile.yml             # using a device profile and prompting for the remaining value

The original ST-Native virtual devices I believe are now called “standard” virtual devices in the CLI.

  virtualdevices:create           create a virtual device from a device profile ID or definition
  virtualdevices:create-standard  create a device from one of the standard prototypes.
6

Same answer I would think. If they meet your needs you should use them over a community-developed driver, which takes up room on the hub, counts towards driver limits, and creates devices that counts toward device limits (has someone confirmed that the new ones don’t?).

7

Ah I guess I should have actually looked at these closer. They require a profile to be developed first? That doesn’t sounds like something useful to the masses.

I’ll have to look at this a bit closer.

8

Your virtual devices are better for many reasons. Including the fact that your run local and those created in the Advanced Web App run in the cloud.

2 Likes
9

I think they are saying that these new ones run locally, so different from the original virtual devices I guess??

1 Like
10

That’s what I got from the post by @orangebucket. Perhaps he can give us some more details of how these are meant to be developed and implemented.

11

I just created some virtual switches using the “new” Advanced Web App they run in the cloud.

2 Likes
12

I hope you will not even think about that.
You have provided great solutions when they were needed and I’m sure there are many others, like myself, who are still counting on your creative work. For me things like Rules in API+, Multi trigger, Counter Utility, etc ( just to cite my use) are examples where, even although hopefully ST will continue to improve, the community needs initiatives like these.
Have a great weekend.

7 Likes
13

I don’t know how they are implemented but the cloud executing virtual devices are basically wrappers for the individual capabilities in a device. If a capability has a ‘setter’ command for setting an attribute, or has ‘enum’ commands for the particular values, then the virtual device will set the attributes accordingly. If the commands don’t have any obvious defined behaviour, or there aren’t any, then it seems to be tough luck. You can specify events using the API but that’s not much help if you are writing a Routine. There are some predefined ‘prototypes’ defined, which is where the term ‘standard’ in the CLI comes in, or you can define custom devices using device profiles. There is something called ‘command mapping’ which allows you specify the events that should be emitted for a particular command but my understanding is that the command has to be defined in a capability and only the capability attributes can be used. So something like an ‘Alexa Switch’ seems to be a bit of an issue.

Local virtual devices are implemented using Edge drivers. Only two of the ‘standard’ virtual devices can currently be implemented - the virtual switch and the virtual dimmer switch. They use the ‘Virtual Switch’ Edge driver which has been available for months. This neatly corresponds with the two stock virtual devices implemented as DTHs. Custom virtual devices need Edge drivers to implement the device described in the profile, but if you look at the ‘Virtual Switch’ driver you will see how simple the structure is, and you don’t even need any internal profiles at all (well you might need one as a placeholder to prevent error messages) as the device profile is being set externally. As you are handling the attributes and commands in the Edge driver you aren’t limited in what you can do. If you want the on command for a switch to open a contact that’s fine.

14

@Johnnybegoode @art_333

I shouldn’t have said that; didn’t really mean it!

16 Likes
15

i’ll stick with yours, .
keep up the good work
martin

16

i’ll second that ,
cast web api
edge bridge
mqtt devices
too many to write down
thanks
martin

1 Like
17

@orangebucket
Do you have an example of a device profile?
Can you share an example.

19

Here is a device profile for a virtual contact sensor that also has a switch to act as an actuator. There are a few unnecessary fields because I created it via the CLI (smartthings deviceprofiles:create just walks you through it) and then pulled it out of the API. I added the metadata afterwards because I wanted to tweak the presentation. It is in YAML purely because when I am using the CLI I use YAML.

id: {{profileId}}
name: {{profile name}}
metadata:
  vid: {{presentationId}}
  mnmn: SmartThingsCommunity
migrationStatus: NOT_MIGRATED
status: DEVELOPMENT
preferences: []
components:
  - label: main
    id: main
    capabilities:
      - id: contactSensor
        version: 1
        ephemeral: false
      - id: switch
        version: 1
        ephemeral: false
    categories: []
owner:
  ownerType: USER
  ownerId: {{ownerId}}

I create the device using an input file to the CLI that looks like this.

name: {{device name}}
owner:
  ownerType: LOCATION
  ownerId: {{ownerId}}
deviceProfileId: {{profileId}}
executionTarget: LOCAL
roomId: {{roomId}}
hubId: {{hubId}}
driverId: {{driverId}}

I then use smartthings virtualdevices:create -i {{the above file}.yaml.

You can use smartthings virtualdevices:create --local to be walked through creating the device.

Two points to note:

  1. The CLI will set both the name and the label to the same thing. I recommend you use a generic description for name and then then fix the label up afterwards.
  2. The API always returns a 403 Forbidden error when I create a local device, whether I use the CLI walkthrough, an input file, or hit the API directly. If the CLI is used in debug mode you don’t see the error. However that is because you don’t see any errors in debug mode for some reason. The device is nearly always created though. Update: It seems the API returns this error if the channelId isn’t specified, but if the driver is already installed it creates the device anyway.

@nayelyz and @AlejandroPadilla, could you perhaps flag point 2) up to the relevant team. Something doesn’t seem to be quite right. Thanks.

1 Like
20

Thanks for sharing this.
I’ll have to test this when I have some free time.

21

Hi @orangebucket let me check it, one question, what version of the SmartThings CLI are you using?