Device Handlers - need the ability to select other input device


#1

I have gone through this discussion and people replied that devices don’t need to call other devices, as this is done through apps and that this is a SmartThings design decision.
Well I maintain that this is a bad design decision… and let me say why.

Why is it a security issue, as what is the difference between selecting an input capability.switch in a App or a device handler? Both have been actively selected by a user.

Why do I need this?

Two scenarios:

  1. Virtual Device Handlers - the ability to control multiple real devices from one virtual device is something I already need to do and have hit this problem twice already. For example the BMW ConnectedDrive will only open a GarageDoor device, so I had to create a virtual door opener to control the door, but then I can’t control the door relay from the virtual door opener… I have to create an App to monitor the opener and then control the relay. This just shouldn’t be necessary…

  2. Z-Wave Device Handler with associated device - I just created a handler for my SRT321 thermostat and this needs to be able to control another Z-Wave device via its ID in an association. Only I have to set a number in preferences / create a helper app to select the z-wave switch and then pass in the ID to the thermostat device handler. Again if device handlers can select other devices then this horrible hack would not be required…

So SmartThings - please look at your device handler architecture and add other devices.
This isn’t some esoteric issue - it is a real problem that I have hit three times in under a month…


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #2

The isolation of Devices from each other is a very foundational piece of the SmartThings architecture, so it takes a lot of careful consideration before changing it… Especially when it is also fundamentally working just fine as is.

I honestly believe that the entire concept of “Virtual Devices” (except for in the IDE Simulator) was never considered when the architecture was defined. They are a clever utility, but the functionality they provide might be implemented much differently if the architecture is revised.


#3

Well I have to disagree on your statement that it’s working “fine”'as it is. I’m having to do hacks to work round a broken design!

Smarththings need to fix their design, as devices do not work in isolation, as I’ve just demonstrated with my ZWave thermostat…


(Mike Nestor) #4

If you have the app create the virtual device, and associate with the other devices, then the virtual device could always call back to the parent app to make changes to other devices. This would preserve, at least at the code level, the separation of devices but still allow you to handle your case 1. It’s kind of kludgy but might work to get you closer to what you need right away.


#5

Mmm I didn’t realise an app could create a virtual device, but that sounds interesting, as a kludgy workaround :wink:


(Mike Nestor) #6

Fair warning on that though. The logging is way off so your device will log but any log statements in your app when the device calls back to parent won’t show. I had a huge amount of trouble figuring this out when I first did it.