Child devices can only be accessed via their direct link. The rest of the table row will go to the parent device.
In a future release (probably not the next one) child devices will be their own row.
3 Likes
@stephack
Stephan thank you so much for this!
I was getting a bit bogged down by all the virtual devices I have.
I added a few of my own device drivers to your code and now I have the joy of organisation 
Brilliant!
Thank you again.
Andy
5 Likes
I'm glad folks are finding it useful. In ST it was a lot more complicated with a bunch of quirks that made it work for my various scenarios. That's the main reason why I never shared it over there. For HE I just really simplified the driver and set it to use the the built in drivers to make it even simpler.
I never thought that anyone would add their own custom drivers to this. That's the beauty of these communities...imagination can run wild.
3 Likes
@bravenel is there some way we can add global user variables? Using virtual devices to pass data between apps etc, works, but adding some variables would clean up my code, and rules immensely. Just a thought. Of course, I can also see how triggering off of bool changes, etc could be an issue in the architecture...
There is a way for apps to pass data to each other: use Location Events.
Example:
sendLocationEvent(name: "hsmSetArm", value: value, descriptionText: "Setting HSM arm state")
Another app can subscribe to such events like this:
subscribe(location, "hsmSetArm", armHandler)
Also, you can send data in a map as part of the event, which the handler on the other side could retrieve as JSON data.
Or, if you are referring to within Rule Machine, supporting "variables" is on the wish list, and may or may not be supported in the future.
2 Likes
Update: 10/14/18
- added method customDevices() to act as a template to add up to 10 more custom device drivers
- ValidDeviceTypes state variable created so that all valid types are displayed on container device page for reference
1 Like
Can you explain how to use the new customDevices() feature a little more in detail? Sorry not sure I understand it completely. Thanks!
You would need to manually edit that section.
Say you want to be able to easily create a custom driver you created called "My Driver" to be included in a Container. You would uncomment the first line and edit accordingly.
def custom1 = [ namespace: "halfrican", driver: "My Driver", ref: "MD"]
Now you can create an instance of your driver in the virtual container. Under the Create Virtual Device button....The NAME would be whatever you wish to call the device. The TYPE would be "MD" because that's what you chose to reference your device type in the custom1 above.
Make sense?
1 Like
Got ya, thanks
I just have to chime in that this is brilliant. Thank you @stephack
Making it easy to add in our own drivers was very kind....
1 Like
Yeah. I see @stephack had added custom device types. With my recent discovery with triggering Alexa to speak without a raspberry pi I'll be needing to make a bunch of virtual motion sensors.
2 Likes
Please elaborate.
2 Likes
Haha I'm going to make a clean post about it when I have it working 100% in practice but I've proved it out to work.
Basically taking advantage of SmartThings updated Alexa skill that allows motion sensors to be used as triggers of routines. Also using Other Hub SmartThings Integration:
Basically the flow will be:
Life360 Presence home-> Hubitat rule switches custom motion sensor with switch capability (reset somehow) -> Other SmartThings Hub Integration changes mirrored motion sensor to activated -> Alexa fires pre-configured routine -> routine has Alexa says function.
That simple! lol
1 Like
OMG @stephack I think you undersold how easy it is to include custom drivers and how automagically you do it!
I was expecting your instructions to tell me to make a new section in the Virtual Container code with the driver that I wanted to instantiate, but you literally only have to have that driver in your Driver Code library and fill in 3 pieces of information in the Virtual Container code...
Now that's smart... Thanks a lot!
2 Likes
Is something like this possible with apps?
Yes, it was the app parent/child structure that inspired me to create the virtual container.
This is how RM and most apps that create many "children" work already.
2 Likes
Hmm I will have to see if I can figure out how to make this work I suppose. There are few apps I am running that I would like to see grouped together like this. Eventghost, your boot me up scotty app and likely a few others.
One more question. How do you have so much space in the name column in your list it in the OP? Mine seems teeny and makes the device names wrap.
Screen resolution maybe...not sure.
Wow...didn't realize anyone was using that. I never made it parent/child because I only have 2 devices that use it. It can be easily converted but would then require you to install 2 separate apps (1 parent and 1 child) in the IDE. I'll try to slap it together for you this afternoon. You can then look at the existing code and compare it to the new one and that should help clarify how easy it is to change the app type.
1 Like
Dead easy!
You just need to create a new master āparentā app and make the parents of your apps children of the master app.
I am about to release āCobra Appsā which will be a master parent containing my parent/child apps like Message Central, Presence Central etc.
It will look like this...
Andy
1 Like
I'm having a really stupid day it seems (no change there). But I just don't get how I can create one device and have my others kind of linked. I've tried and tried, but this stupidity seems to be lasting longer than normal. Any steps for stupids like me? Thx.
