Coding Parent and Child in the Same Driver

You can code both parent and children in the same container driver. It all hinges around the fact that (obviously) the parent driver has:

!parent

In my other Ecowitt Wi-Fi Gateway driver development, this will simplify maintenance and user installation process tremendously.

UPDATE (05/01/2020): This practice is not officially supported, and not recommended by Hubitat.

Word of caution... This used to be supported in apps but a change in one of the firmware updates made it so links from apps to child apps created from the same container code stopped working. It's why the Hive App and integration stopped working. If you do it in drivers you run the same risk of it breaking later if they make a change since this is not the norm.

Is this practice discouraged? Would Hubitat purposely disable it for any reason?

For some specific application, like when children hold mostly data/states, it seems to me like there are no drawbacks. Only advantages.

I think Bruce commented that it wasn't intended to work but worked for a while because it wasn't prevented. You can ask them if you want. I was just giving you the warning because of my experience doing the same with apps.

It may be advantageous to developers but it may cause some problem on the platform for thread management or Singleton instances or something. Who knows.

1 Like

@bravenel, any official word on this?

Not sure what your looking for officially.
This type of implementation isn't something that we officially support, and honestly while it may work, you end up with a driver that's not optimized for its specific function.
So if you're looking for an official stance, that would be it.

That's exactly what I was looking for officially.

For what it's worth, if you just need a device to hold states then there are already composite devices. These are recommended for devices as children. You can composite devices to avoid having to create a separate driver to hold states in some cases (as long as the states you are holding fit the mold of the composite devices' capabilities).

Is this what you are referring to? Because that's exactly what I'm using right now.
I was just trying to code these composite devices in a single driver/file to hide the children and prevent the end-user from creating new child devices (which are automatically created by the parent).

No, I should have said component devices. Look in the Driver Type drop down list, you’ll see “Generic Component xxx” drivers. Those are Hubitat’s built-in “child drivers”. They do nothing but hold states. You can create instances of those instead of writing your own.

1 Like

Yes, I thought of using those. Unfortunately I'm writing a driver for a weather station with lots of child sensors, and a lot of states I'd need (humidity, UV, Illuminance, pressure etc.) are missing.

I think the odds of HE adding a component device to support what you want is fairly good if it follows one of the existing capabilities.

Where does this dialog stand? I don't see a decision for a definite direction forward such that we can be assured that these drivers won't stop working after a future platform update.

@sam.bowden, the parent-child architecture is obviously endorsed and fully supported by the Hubitat platform.

What I was asking here is slightly different: is it OK to code both parent and child in the same driver (as in same groovy file)? And @mike.maxwell (an Hubitat software engineer) pointed out that although working, it's not officially supported and discouraged.

Because of all its many child sensors, I started developing my Ecowitt GW1000 Wi-Fi Gateway driver using a parent-child architecture and I thought that coding both in the same driver/file would eliminate the problem (as explained above) of users potentially forgetting to install the child driver or, even worse, manually creating child sensor devices.

@mircolino I have thought all along your idea of coding both in the same driver was an excellent innovation. I guess what I'm concerned about is that one day I'll do a platform update and my Ecowitt GW1000 devices will stop working, as apparently happened with some apps in the past. Is there a valid reason for not supporting this approach with drivers on the platform? Should we submit a formal request to support your approach?

This type of coding, as well as implementing this in apps creates by nessicity sections of code that go unused depending on the context.
This isn't ever going to be officially supported, and therefore we can't gaurentee it wont break in the future.
We don't have any plans to prohibit this, but should it break due to some other platform change we're not likely to spend much time fixing it.

Don't know if you are using my driver or not. But since Mike said it was not going to be supported, I decided not to implement it.
Right now I'm just using a standard (and fully supported) parent/child architecture which is what @mike.maxwell himself implemented in some of his drivers (like the multichannel Shelly Wi-Fi switches).

I think the proper way to solve the following problems:

  1. populating the list of supported devices with drivers that cannot and should not be manually instantiated by the end-user
  2. making sure the end user doesn't forget ancillary files during installation

would be if Hubitat came up with some sort of "driver package", a .zip or a .jar containing all the necessary files and some sort of manifest where to specify which driver should be hidden from the end-user.

@mircolino @mike.maxwell Thanks for the additional clarification.

1 Like