If this has been covered or is documented, please just point me in the right direction. I’m not getting anything from searches using the terms I can think of. . . .
I’m thinking about an application where it would be nice if a SmartApp could spawn/instantiate a virtual switch. I would code the SmartApp to respond to this switch appropriately (maybe an on-off switch for the app if you wanted to be able to manually disable it without having to uninstall and then re-install, for example)
Ideally, for ease-of-use, the SmartApp would do the following automagically:
Spawn or instantiate the virtual switch with predetermined labeling/naming or, perhaps, even custom graphics. So, when it showed up in the things view, the user would recognize it as part of the SmartApp they just installed.
Subscribe to the events coming from this specific switch without the user having to select it.
Maintain some sort of linkage to the SmartApp so that if the SmartApp is uninstalled, the virtual switch is also deleted automagically
So, is this contemplated and/or supported? If so, is there documentation, samples, threads for me to review on the subject?
From my previous research it is not possible to create a child device that is not of your own name space. I.e, you will not be able to create a virtual switch which is a standard ST virtual switch. However, if you clone the device type and call is something else, you might be able to create your own device with your own Smart App.
I never actually got to try this. I never got a response from ST devs either, but if you achieve something, please let us know.
As stated above, this is a classic “Service Manager” and “Child Device” scenario type setup. If setup correctly, ST will handle the relationship and addition/deletion of devices tied to the Manager. So if you delete the manager (Parent), the devices (children) will be deleted. Also if you delete the last child device, the manager will be deleted (new since latest update).
All kinds of functionality can be created/instantiated with the Service Manager and virtual/real devices. One in particular is creating mutual inclusivity/exclusivity between child devices and/or device their states. Think of something like additive modes. “I’m home”, “it’s dark” and “it’s Monday” so “turn on Football game”. While many are trying to get modes to do that, States of one or more virtual devices can report to the service manager which then brokers that data and can decide when to take some kind of action. What’s really nice is that you can bury a state in a virtual switch and therefore turn it on/off like a switch. I can go on and on, but I think you get the point.
Thanks for these seeds, @notoriousbdg, @625alex, and @wackware . I am more or less familiar with a Service-Manager as a thing required for LAN or cloud-connected devices. What I’m seeing in the docs seems to be having to do with devices discovered on a LAN or cloud and then creating child devices from them. I’m not seeing how this can be applied to a regular SmartApp spawning a child device that is a virtual switch. I don’t see anything in the docs describing methods available to a SmartApp to create child devices. Not that it doesn’t make sense - it does - It’s just not obvious from what is documented how you would actually do it.
Are there examples of SmartApps creating child devices independent of any LAN/cloud discovery process? Reviewing some specific examples may help, however, it may be that this is just a bit beyond my capabilities at the moment . . . I might just have to swing back to this once I get a little further up the learning curve ;-).
Excellent! I can work with this. Much appreciated. I will dig into the examples provided and see if I can sort this out. Seems like what I need should be here. Thanks again!
Seems like addedvt is a new device object being created by the constructor addChildDevice(). "ms_w_vts" is the namespace and "vTile_ms" is a custom device type in that namespace. Correct so far?
I’ve seen documentation for Java constructors. It seems like addChildDevice() must be a ST custom constructor. Right? Is there documentation of this somewhere?
Correct. The vTile_ms device type is also available at the link I sent which makes it easier to see the relationship between the app and device.
The only documentation I have found is what I linked to originally. There are a couple other posts on addChildDevice on the forums that have a little more info…
For a little more explanation the ddni(vt) is actually calling a process to create the Device Network Id (DNI) for the new device - it is its unique identifier within your hub and you can see it when you list your devices. It is considered “good ST practice” to have the first part of the DNI be the “parent app.id” so that the children devices are “related” to their parent. So the particular process ddni(vt) is creating a string with app.id + “/” + newdevice.id for the DNI…
is for which “Hub” the device is being created on. You can lookup up the hub and specify it, however, it auto-populates for the current “Hub” if it is left null I have not found much use for this at this moment, however, it looks to me like this is where you can specify “Virtual” and have a device-type that doesn’t actually show up in “things”…
name is the “hidden” name which is used within ST and for the parent/child relationship to communicate, label is what the user will see as the name and can also be set through preferences and changed by the user, and completedSetup determines whether or not the device will show up with a blue “+” in things and need user interaction prior to use.