Virtual Devices Using New Official Web Interface

[orangebucket (Graham)]

@AlejandroPadilla

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

It is 1.4.1 which is the first version to handle local virtual devices.

[TapioX]

@orangebucket

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.

I started experimenting again with VIRTUAL type virtual devices.
I’ve had a break from testing these for over a year.

I wanted to test whether I could still make more of these VIRTUAL type virtual devices.

ST has made some improvements to the operation of these virtual devices, although no new information has been added to the documentation.

Adding virtual devices seems to work.

---

There is a strange initial value setting in virtual devices. ST randomly assigns initial values ​​to capabilities’ attributes.

I have now added these Range definitions to my drivers’ added lifecycle.
These Range definitions make the initial values ​​of the ranges reasonable.

Example Lua code:

local max = 100
local min = 0
device:emit_event(capabilities.switchLevel.levelRange({ value = { minimum = min, step = 1, maximum = max }, unit = ‘%’ }))

[orangebucket (Graham)]

@TapioX

There is a strange initial value setting in virtual devices. ST randomly assigns initial values ​​to capabilities’ attributes.

Yes, and in a number of cases they are such seriously bonkers values that they are pointless as you can’t use the mobile app to set them to something useful and have to do it manually anyway. So they might just as well have left it to the user.

I was particularly annoyed by them when they first appeared as I was already emitting synthetic events in the added handler and they were getting splatted. I did get the impression that things had improved and already initialised values were being left alone but I may be imagining things.

It should be noted that when you do a hub replace or a hub backup the added handler gets called for each device on the new hub. This is one of the reasons I stopped using automatic failover in hub groups as my virtual devices were changing status because of it. I’m not yet sure exactly what data structures are preserved to allow me to logic gate the synthetic events.

I closed an issue I raised about this as it seemed an inappropriate place for it, but I am pleased to see this situation being raised in the context of Zigbee devices in a pull request and the proposed fix being the same one I had implemented.