Feature request: adding driver automatically or detecting the missing ones

I did a search - not so deep, I confess - trying to find any topic related to automatically adding a driver, and I had no success.

Sometimes when I've installed an app and not the necessary drivers, I've got an error - obviously. And I saw in many users incurring in the same error and asking for support. Since I've got my share of this kind of errors, for me now is easy to identify what's going on.

The user can be alerted about the probable missing drivers by intercepting the errors in code when trying to install a device. I stress probable, since I could not find a way to pinpoint exactly the error related to the missing driver.

What I'd like to suggest is, when using an "integration" type app, to have these options:

a) Test if a specific driver is already installed on the HE hub
This way we could tell the user to install the proper driver before continuing

b) Automatically install a driver

What the developers community think about this?

Peace and health for everybody.

1 Like

I think the ability to define a driver inside an app would be an even neater solution, providing a self contained application. The same could be said for the parent - child app structure, i.e. defining a child app inside the parent app code.

1 Like

You mean like this in my apps?

5 Likes

This is also coming...

3 Likes

It does look exciting, even if I read the first dozen or so posts and then skipped to the end :slight_smile: Sounds like it has really progressed a lot. Great work by all involved.

1 Like

It does!
Unfortunately, it exposes the download URL on GitHub so I won't be using it as I don't allow that, and don't have my code on any public URLs

Can you expand a bit on your preference to not put your code on public urls?

That may be true for now, but once proved for openly available code on Git Hub, there may still be potential to introduce a level of security that would allow access into your web site / repository of drivers and apps for authorised users.

1 Like

Phew!
Where do I start??

1 Like

Gotcha. Thanks for the links. Best of luck with your commercial ventures, it’s a fun world!

Since you have the login system, you could probably generate tokenized, user unique urls where the repo and manifest files could be found. The package manager would have to be extended to allow for local overrides to the package repo list, but that’s probably a good idea anyway. Anyway, I digress. No need to hijack the thread more!

3 Likes

I think that it would be a straightforward solution - clean, I like it.

Yes! Could you post the code segment where you got the error properly? It would be nice.

It will be great! It would reduce substantially the questions posted just because of apps/drivers installation problems, not to mention to make the installation process less cumbersome.

It is possible to create a 'combined' parent child app
Then detect if it is installed as a parent then install as a child

There are some SmartThings custom apps that do this.
I experimented with it some time ago but it just made the apps a little cumbersome.

Was the concept that the same parent app was also used for the child app?

Yes, that's right.
You can detect if an app is installed easily enough.
So, you basically detect if the app is installed already, (as a parent) if it is, then present the child code

I don't remember exactly how it was coded (it was a couple of years ago that I looked at it) but you will probably find it on the ST forum

1 Like

That does sound like a good feature. I think we might be talking about different things though .. My idea, which I was simply brainstorming off the back of the original post, was to have some coding construct where you could define the child app and the parent app in the same "file". So rather than having to install two or more pieces of code it could be all tied up in a single file. I'm guessing this may not even be possible and HE would be bound by what is possible in groovy, was just throwing it out there.

My apps are not open source.
I spend a lot of time working out ideas and how to do things so don't release my code in any open forum.

I posted that screenshot just to show that it could be done.

If creating child devices, or wanting to know if they already exist you can just use specific DNIs for the device and then check using getChildDevice(DNI) .. does that help ? The user can still rename the device to whatever they want or there can be a name entry field as in the screenshot above.

I use that to create a child device MQTT driver and then ensure one remains available. Of course you must check that addChildDevice() succeeds initially I.e. the device driver code is present, And warn otherwise, again as in the screenshot above.

I think this is a good idea, but I'm not aware of any easy way to do this. I don't know of any built-in methods available in apps that can check for the existence of a driver with the specified name in the specified namespace (without hitting up the hub via unofficial HTTP methods like the package manager app mentioned above does). The only thing I can think of that would work would be putting a addChildDevice() command inside a try block, catching the specific exception it might throw if the driver code doesn't exist (and using that to inform your check that it doesn't exist), and finally deleting the test device (if created). This seems like a bad way to do this (at the very least, creating another record, even temporarily, in the hub's device table, every time your app runs this check seems like a recipe for eventual disaster if you do it enough times), but HTTP directly to the hub doesn't seem much better.

If anyone is aware of any documented, not-clearly-a-bad-idea-way to do this, open way to do this, I would welcome suggestions. :slight_smile: Otherwise, I'm hoping to put at least my more complicated app/driver sets into the package manager if that idea works out, so hopefully this will be easier in at least those cases. In the meantime, it's easy for me to log a specific error if adding a device fails because a driver doesn't exist, so that is what I'd recommend that users check if it fails (and something I'd recommend devs at least try if they aren't doing anything at all for this right now).

Yes, it’s easy for a child device but not for other devices that may have not been enabled yet within your app. Perversely if it was enabled the driver is available.

Your suggestion of trying to create a child seems the only way due to the security issues.

You can’t create an input for a device type and get a .count returned on the number of all elements there can you ? Including unselected elements that haven’t been enabled ? hideWhenEmpty knows there are none.

But neither of these address the driver code being present but no devices yet created.

That's understandable - no worries.

That's what I'm doing so far on my integration app: catching the exception when I try to add the desired device and telling the user that the problem "likely is" the absence of driver. That's why I said in this:

So far I've been not able to pinpoint the exact exception and give the user a solid information about the error, instead of a "likely" missing driver.

If possible, I'd be happy to at least catch the exact exception not a generic one - anyone has an idea on how to accomplish this?