Create virtual drivers from text file?

jamesxheath · September 21, 2022, 3:07pm

Hi,

I'm looking for a way to create multiple virtual devices - possibly by importing a text file, or maybe using code (though that may be beyond me....).
I've created something that requires me to create 48 virtual devices - 12 locations, for 4 users (see here if you're interested [RELEASE] OwnTracks Presence - #231 by jamesxheath)

I'm guessing I just have to knuckle down & do it manually, but if there's a different way, that would be great!

Thanks,

James

jamesxheath · September 21, 2022, 3:20pm

LibraSun, this is a very fair question - I realise that creating a huge number of virtual devices is really clunky, and is a bit of a dirty hack. If I can do it with variables / buttons I will, but this is part of an OwnTracks location setup, and the way that seems to be engineered is that I have to have a virtual device for each user, for each location. This makes the setup easy to use, but a bit painful to configure for me atleast (most users will probably only be setting up a couple of users and a couple of locations I guess).
I'll post in the OwnTracks thread to see if there's any other approach.... but suspecting there isn't, my question stands!!

csteele · September 21, 2022, 3:53pm

Wimps

I was involved in the design of HubConnect and one of the major pieces within is generating Virtual Devices. In other words, I feel your pain. HubMesh has the same chore, although I hope they had an easier time.

Every 'mirrored device' needs a virtual at the other end. With a specific set of Capabilities, Attributes and Commands. In HubConnect's case, the "Library of virtual drivers" had to be explicit, while HubMesh has them hidden internally.

I'm simply offering this comment as: possibly an outside of the box idea. (But starting with some humor )

jamesxheath · September 21, 2022, 3:54pm

LibraSun - you've hit the nail on the head - to set up the Mobile app Owntracks side of things I've created custom JSON files in a sheet which I can then import.

ogiewon · September 21, 2022, 5:46pm

Hubitat "Apps" and "Drivers" can easily create virtual 'child' devices. The nice thing about this design, is that you could actually dynamically create the child devices when new data is received by the parent app or parent driver. That is exactly how I wrote HubDuino to behave. An Arduino-style microcontroller sends data to the hub, which is then parsed by the parent who attempts to find an existing child device that matches the incoming data. If not found, it creates a child device.

Perhaps the author of the OwnTracks community app could look at enhancing it such that it automatically creates the child devices? I have not looked at the code/architecture, thus I cannot say for certain how feasible this would be.

FriedCheese2006 · September 21, 2022, 5:48pm

How fast do you need this? Is there a specific device type that you need?

I ask because I have a desire to create virtuals in bulk for app testing. I'd planned to write an app to do that, but I'm not sure when exactly I'll get to it. Maybe I could toss it together in the next day or two. My use-case is to just use the omnisensor virtual device.

ogiewon · September 21, 2022, 5:55pm

Just be aware that if you use a Hubitat App to create child devices, the app must stay installed on the hub. Removing the parent app will remove all of the child devices.

I guess one could write an app that runs on your computer, that essentially emulates a human being sitting in front of a web browser creating virtual devices...

FriedCheese2006 · September 21, 2022, 6:04pm

I think this is because most devs write in a function to remove the device when the app is removed.

ogiewon · September 21, 2022, 6:30pm

Actually, the Hubitat Platform does this, even if the developer does not explicitly remove its children when it is removed. I know Parent "Devices" do this automatically, as I have a ton of experience with those. This is to prevent the hub having 'orphaned' child devices. I am not 100% certain about Parent "Apps", but I believe it applies there as well.

pfmiller · September 21, 2022, 6:34pm

The AverageTemp example app in the Hubitat github doesn't automatically remove child devices when the app is removed. You have to add a cleanup function if you want it to do that.

FriedCheese2006 · September 21, 2022, 6:40pm

Funny enough...I went and tested in my app by removing the function that removes the child device. The platform still gave a popup saying that the child would be removed...but it left it in place.

jamesxheath · September 21, 2022, 6:42pm

@FriedCheese2006 - I'm not in a huge rush - I can wait a week or so! The virtual devices I'm wanting to create are Owntracks Location virtual devices that need 2 preferences:

Location/Region to Track
User to Track

@ogiewon I use Hubduino for a different part of this creation, so I suppose that I might be able to investigate your code and modify the Owntracks App to autocreate the devices (there is already an app for each of the 4 users). I'm just not sure my coding skills are that good!

ogiewon · September 21, 2022, 6:46pm

Be aware that HubDuino only contains Driver code, not App code. Thus, the process for adding child devices might be slightly different. I would actually recommend you look at the Hubitat Public GitHub repo for a simple example of a Parent/Child set of driver code. This example from Hubitat is what I have modeled my more recent development after. HubDuino is really a port of my old SmartThings ST_Anything groovy code. The example below is much simpler, IMHO.

github.com

hubitat/HubitatPublic/blob/master/examples/drivers/genericComponentParentDemo.groovy

/*
    Generic Component Parent Demo
    Copyright 2019 Hubitat Inc.  All Rights Reserved
    2019-09-07 (public repo only) maxwell
        -initial pub

*/

metadata {
    definition (name: "Generic Component Parent Demo", namespace: "hubitat", author: "Mike Maxwell") {
        capability "Configuration"
        
        //demo commands, these will create the appropriate component device if it doesn't already exist...
        command "childSwitchOn"
        command "childSwitchOff"
        command "childDimmerOn"
        command "childDimmerOff"
        command "childDimmerSetLevel", ["number"]
        command "setTemperature", ["number"]

This file has been truncated. show original

FriedCheese2006 · September 21, 2022, 7:06pm

Ah...that might be a little more specific than what I had planned or could turn around in a decent amount of time...I think anyways. My initial thought would be to just have an input for number of devices and a second input for a generic name. I would just prepend the name with the device number.

FriedCheese2006 · September 21, 2022, 7:11pm

Maybe, but who wants to do that 47 times

jamesxheath · September 21, 2022, 7:50pm

@ogiewon - I've just realised there's a flaw for me in the auto creating of the devices - they don't get created until the data for that device is sent in. That works perfectly for Hubduino, where data is sent periodically, and relatively quickly, but for the location service, this would require all users to visit all locations (or for me to set each phone in to location spoofing), my fault for not thinking that through!
@FriedCheese2006 Something that created all 48 for me to then edit up will be a good bit quicker than creating them all.
@LibraSun the backup/restore could work really well for me - I could create the set of 12 locations for one user and then replicate and edit for the other 3 - where is this "backup/restore devices" tool, and can you use it on a subset?

thebearmay · September 21, 2022, 8:07pm

IIRC if you set isComponent: true when you create the child device from an app, and then remove the app, the child devices are removed with it; if you set isComponent: false and delete the app, I believe that the devices remain and must be manually removed unless the app cleans up after itself - usually in the uninstalled method.

thebearmay · September 21, 2022, 8:46pm

So, back to the original question - does such an animal exist now, it didn't but it does now. It uses a very simple method and requests the driver name, the namespace that the driver runs in, a base device name and the number of iterations. Child devices get created with the isComponent:false, and are named using the pattern [base device name][iteration]

https://raw.githubusercontent.com/thebearmay/hubitat/main/apps/deviceGen.groovy

You will get the warning that the devices will be deleted when you delete the app, but they'll stick around.

FriedCheese2006 · September 21, 2022, 9:03pm

Well then...alright.

I was trying to make things complicated on myself by seeing if there's a way to pull the "device type" menu. Much simpler approach.

jamesxheath · September 21, 2022, 9:29pm

@thebearmay - fabulous! I'm trying it now, but I'm clearly missing something...
I've got the driver name & namespace from the driver code:

		name: OwnTracks Virtual Mobile Presence Driver,
		namespace: brianwilson-hubitat,

And put these in:

but when I hit "Add Devices" and "Done" no devices are added to my setup (the total count stays the same)

I don't understand "isComponent:false" - are they hidden in some way?

Thanks! James