I will have to get back to you on what the specific use case was, but it had to do with my integration between Alexa / ST / Routines and a Switch not being able to accomplish the same functionality.
I just figured that if an official Virtual Device creator existed it would be comprised of many if not all virtual and simulated device types (Thermostat, Bulb, etc…), but I’m guessing that the Simulated devices aren’t localized either, so they probably don’t fall into the same classification as there are only 2 labeled virtual device types. Just some thoughts out loud.
Yeah, we’re still working on the usefulness of the virtual stuff and so I’m genuinely curious what peoples’ use cases are for these things. Let me know if you think of anything. No promises that it will actually make it in, but we’ll certainly consider it.
I noted in the beta I want virtual locks and contact sensor. I use a virtual lock for a switch that controls a actuator so it shows up in lock manager and easier for my wife to see everything is locked vs on=locked. The contact sensor is one where I assign 10 sensors and if any are open it shows open, while all closed shows closed, once again mak s it easier for the wife to see all doors are closed
Think you are going to see a ton of use cases for all the various virtual device types based on different scenarios and uses. I see value add with 3rd party integrations, multiple device automation, where only having a switch available won’t work. Load up that app with all of them
No, unfortunately, as you note that sensor (targeted at Apple Homekit) requires bluetooth. This change added support for running Fibaro Motion sensors that previously worked with SmartThings in the cloud to run locally (so they work with offline automations, etc.).
As per https://support.smartthings.com/hc/en-us/articles/204075624-Fibaro-Motion-Sensor, the Z-Wave and Z-Wave Plus motion sensors are supported within SmartThings. With this release, support for the Z-Wave (but not the Z-Wave Plus / ZW5) variant will run locally. We’ll look at making this more clear with the release notes when this version goes to production.
bamarayne
(Jason "The Enabler" as deemed so by @Smart)
91
And then add them all as available restrictions in smart lighting
I know this might be a bit off topic, but the hub supports two USB ports…
So if you added a USB bluetooth adapter, would it then be possible to add bluetooth controller to the hub and make it control bluetooth devices also? (including this Fibaro motion sensor FGBHMS-001 V1.0)
having issues with ST and HUE integration lately, not sure if it’s tied to the Beta or something else. Bulbs become unresponsive to routines and/or manual actions in ST. actions as simple as the turning off a light seem to act erratically. Sometimes if I open the light, click save, and retry the action it will work other times not.
And specify as to whether you are using the Hue Bridge or have the bulbs directly integrated with ST, and if you are using the native integration or a specific custom SmartApp (ie: Hue B Smart, etc.). Report that in Centercode.
thanks, I will do as suggested for logs and bug report, I am using the Hug Bridge, 2nd Gen with about 35 lights…was running custom apps but removed all of them and are now using the Native lighting integration.
I have the same setup. I would try rebooting your Bridge, ST hub and then the router and see if the issue goes away.
If the issue continues, they should definitely be able to isolate it a lot easier with you using the native integration and use of the bridge and providing logs of so called behavior.
Perfect solution is having ST on 15 (not controllable by us), 2.4ghz on 11 and Hue on 25. I have had channels sitting on top of each other, and the ST Hub sitting less than a foot away from my router and still never experienced any interference. I think a lot it depends on environment and equipment being used.
