Returning nil for a boolean?!? As a recovering developer myself, 
2 Likes
Taking a quick look, it appears that a local virtual switch, as created by the AWA, is using a profile without the new preference in.
It doesn’t really matter what the implicit profiles in the driver package say as they aren’t used in VIRTUAL devices. There has to be one for the Edge package to build, and if you are using custom capabilities I found you had to mention them in a profile otherwise they weren’t cached on the hub filesystem as they needed to be at the time. Although the implicit profiles in the package may, or may not, end up mapped into ‘real’ profiles (I’m not sure of the exact flow) you would still need to know the ID of those profiles when building the virtual devices.
So no, existing virtual switches wouldn’t be updated, and new ones need to be created with a profile with preferences in (which probably has to be done on the backend for the stock prototypes).
The driver code is back to front unless changing the behaviour of existing devices was a deliberate decision.
1 Like
They should also check if there are preferences at all.
local function force_state_change(device)
return device.preferences and device.preferences["certifiedpreferences.forceStateChange"] and {state_change = true} or nil
end
1 Like
I’ve been having a play with my own VIRTUAL device driver. I can get the preference to appear in the mobile app for a virtual device and I can see the setting being changed in the device object in the API. However in the driver device.preferences is empty.
2 Likes
Following up my own message …
Something was familiar about this. It seems I tried similar tests with other preferences back in April and I noticed the same thing then. Also there was no sign of the infoChanged lifecycle occurring. @TapioX wasn’t having any success back then either and I don’t know if that has changed.
1 Like
I made some tests again. There was no sign of the infoChanged lifecycle occurring.
The virtual devices themselves work.
@nayelyz informed me in May about the state of the virtual devices:
- Support for virtual devices is limited to the official one (“virtual_switch”)
- We suggest you create a LAN driver to create those “virtual devices”
After May, I’ve switched to making LAN-type drivers.
The only new feature for virtual devices is that temperature measurements’ unit in ST App’s detail view is now Fahrenheit. ST App’s dashboard tile is still using Celsius. It works like this even if the commands are used Celsius as a unit.
1 Like
Hi, thanks for the tag. I’ll ask the team about that option in preferences to know the expected behavior.
1 Like
This should mean the old behaviour will return while the device preferences are being sorted out.