Hi @Bloodtick_Jones let me sometime to check it, but how does it changes the values? Are you using automation?
I can change by both the deviceEvents API as shown here and the published command device api, but the actual UI on iOS does not allow for updates via the +/- buttons as throws the demonstrated error.
Hi @Bloodtick_Jones thanks for the information, we can reproduce the issue we already create a report about it, and as soon as I have news I will inform you.
2 Likes
@orangebucket has new information about virtual devices created using CLI
The new web IDE still exhibits the virtual thermostat anomalies. Awesome ST is improving the interface.
1 Like
You can create local virtual switch using CLI command
smartthings virtualdevices:create-standard --name=Name --location=LocationID --room=RoomID --local --prototype=VIRTUAL_SWITCH
or you can use also CLI command (interactive mode)
smartthings virtualdevices:create-standard --local
and CLI interactively ask name, location, room and type (prototype)
The Virtual Switch driver will be automatically loaded into the hub.
You have to use CLI version 1.4.1
You can check CLI version using command
smartthings --version
Edit May 2024:
My first attempt using CLI for virtual device creation. After upgrading to v1.4.1, I tried both the interactive mode and the full CLI mode and in both cases I get the following error message… any suggestions?
? Select a device prototype. 1
AxiosError: Request failed with status code 403: {"requestId":"97227980340846756","error":{"code":"A resource
could not be found.","message":"ForbiddenError","details":[]}}
Code: ERR_BAD_REQUEST
Hopefully this is relevant …
- The API returns that error if you try to create a local virtual device without specifying the
channelIdfor the Edge driver. - The CLI doesn’t specify the
channelId. - If you have already installed the driver on the hub it will usually successfully create the device (I found if I did a batch in quick succession the first one sometimes failed).
- If you use the CLI in debug mode you don’t see the response at all so you don’t realise there is an error, you just wonder why the CLI isn’t saying anything.
.
Relevant yes. I see that the virtual devices were actually created and appear in the app, but they seem broken - their power button is greyed out and can’t be toggled. I also get the common “device hasn’t updated all of its info…” warning but suspect that’s unrelated.
The driver appears to have been successfully created on the hub, assuming it is the one named “Virtual Devices V2”. Checking one of the devices I created using the new web account interface (screenshot attached), it seems odd that the manufacturer is not ST (vs. community) and there is no driver listed. If I try to change the driver to the “Virtual Devices V2” one it fails and gives an error message suggesting I check the fingerprints.
Not sure where to go next from here.
The driver should be Virtual Switch which is in the default channel that you don’t need to enrol in, so you probably won’t see it listed.
I don’t see any synthetic events in the driver to initialise the attribute. They were temporarily disabled in stock drivers but that doesn’t seem to have had one at all. You could try sending an on/off command to the device via the CLI or some other API based means as that should make the app behave.
It has been a very long time since I toyed with the Virtual Switch and I don’t have access to the CLI for a while.
1 Like
Your device in the picture looks exactly the same as mine.
Virtual Switch driver is
Driver Id 572a2641-2af8-47e4-bfe5-ad83748fd7a1
You can see driver in your hub driver list.
The driver cannot be read from the device.
Do you have for CLI a token that has all permissions?
This driver is T Austin’s vEdge driver
That one is not shown on my hub, so it must not’ve been automatically loaded into the hub when I ran the CLI virtual switch install.
I don’t believe so. I use the CLI authentication method of logging into my ST account. Do I need to setup a token to use the virtual switch install feature of CLI? (I have loaded drivers and done other CLI tasks without the token option method previously).
I use PAT token that has all permissions.
Personal Access Tokens (PAT)
More information: Authorization and Permissions | SmartThings Developers
Add to CLI command –token=PAT
the auth token (PAT) to use
I tried again, after creating the full permission PAT, adding it to the command line… same result with the ERR_BAD_REQUEST response. This time, however, the device created was assigned the correct VIRTUAL SWITCH driver, and I’ve confirmed that driver is now on my hub.
However the virtual device shown in the app is still broken - the button is greyed out and won’t toggle on or off. (Timer knob on that page is also greyed out)
Can you try again and before trying set CLI to debug mode using command (Windows)
set SMARTTHINGS_DEBUG=true
Then can you share the smartthings virtualdevices command log.
( Delete all personal information from the log)
Result was same as last time - created a non-working device with greyed out button. I’ve also included the view of the device from the webpage.
C:\Users\grhay>smartthings virtualdevices:create-standard --name=vSwitch3-ST-GRH --location=xxx
3ce212b8 --room=xxx --local --prototype=VIRTUAL_SWITCH --token=xxx
[2023-07-11T08:09:10.663] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/locations/xxx","method":"get","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/json","User-Agent":"@smartthings/cli/1.4.1 win32-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer xxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"params":{"allowed":"false"}}
[2023-07-11T08:09:11.275] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/locations/xxx/rooms","method":"get","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/json","User-Agent":"@smartthings/cli/1.4.1 win32-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer xxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}}
[2023-07-11T08:09:11.682] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/devices","method":"get","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/vnd.smartthings+json;v=20170916","User-Agent":"@smartthings/cli/1.4.1 win32-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer xxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"params":{"locationId":"xxx","type":"HUB"}}
[2023-07-11T08:09:12.209] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/virtualdevices/prototypes","method":"post","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/json","User-Agent":"@smartthings/cli/1.4.1 win32-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer xxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"data":{"name":"vSwitch3-ST-GRH","roomId":"xxx","prototype":"VIRTUAL_SWITCH","hubId":"xxx","executionTarget":"LOCAL","owner":{"ownerType":"LOCATION","ownerId":"xxx"}}}
I checked SmartThings API calls and all were the same in my log.
Did your CLI log continue like this?
Main Info
─────────────────────────────────────────────────────────
Label vSwitchStd
Name vSwitchStd
Id xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
Type VIRTUAL
Manufacturer Code
Location Id xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
Room Id xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
Profile Id 71ed0734-123f-330f-886c-174466bbfe76
Capabilities switch
refresh
Child Devices
─────────────────────────────────────────────────────────
Device Integration Info (from virtual)
─────────────────────────────────────────────────
Name vSwitchStd
Hub Id xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx
Driver Id 572a2641-2af8-47e4-bfe5-ad83748fd7a1
─────────────────────────────────────────────────
Do you have in your hub this setting?
I also added to another location (second SmartThings V3 hub) first local virtual switch.
My local virtual switch operates normally.
Have you tried using the CLI to turn the device on or off?
1 Like
or
“https://my.smartthings.com/advanced/devices”
You can also see virtual switch value
www page needs to be refreshed to update the value
CLI log did not continue beyond the text I posted above.
I tried turning the device off via both CLI and the web page. CLI did not reply with any error, but the ICON state of the switch did not change in the app.
C:\Users\grhay>smartthings devices:commands a3f61250-dxxx9433db9 switch:off
[2023-07-11T13:29:32.264] [DEBUG] login-authenticator - authentication - enter
[2023-07-11T13:29:32.267] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/devices/a3f612x3db9/commands","method":"post","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/json","User-Agent":"@smartthings/cli/1.4.1 win32-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer fbcd5b88-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"data":{"commands":[{"component":"main","capability":"switch","command":"off","arguments":[]}]}}
When I try to change the state on the web-page, I get the following error message:
Error running command "off". 500 unsuccessful-http-call status=403
My hub settings show localVirtualDeviceAvailability as “available”