I am looking to re-engineer how my Hue integration is organized. Presently, all groups, lights, and the hub device are child devices of the hue integration app.
In implementing the V2 API, and to plan for future support of Hue streaming devices, like the Hue Play, or multi-hub scenarios, I want to separate the hub communications and manage from the auto-discovery component, such that each Hue hub has its own app, all of which are child apps of the hub discovery app.
To make this as seamless as possible, I would like to programmatically create the hub integration child app, and move all devices to the new integration app so that users with very large configurations do not have to re-write all their rules, and can migrate automatically when they are ready to do so, in a single step.
Thinking if you have access to the old device, store the DNI, change the old DNI to some other value, create the new device with the stored DNI, delete the old device, but I’d run a small test prior to commiting to it.
I don’t believe that will work. The DNI is not what is actually used by Apps when referring to a device. There is a “Device ID” as well, which is unique for every device, and it is used by apps as a reference into the database. This is why one can easily change the name of a device, or it’s label, or even its DNI without breaking the linkages to apps.
You’re right, for some reason I was thinking that the DNI was the ID, but looking at the properties it’s obvious that it isn’t. Not sure if you can change the ID though.
The DNI (Device Network ID) is not used by the rules. They use the device number, which we cannot declare, nor change. Technically, I could change the DNI of the child app, so that the parent app would know the DNI of the device, but I believe the parent (and child) device references are still hard bound to the device/app numbers used at time of creation, so getParent() and getChildDevices() calls wouldn't change. I could be wrong, and will play with this, but I don't see any relationship between the DNI and the device hierarchy. And most notably, in rules, the subscriptions processes are done via node numbers, not DNI.
I too thought of this, but realized otherwise.
Agreed. This is how I came to the same conclusion.
It's a shame. It would be nice to be able to make changes like this. There is no reason to create a new hierarchy of my apps if it means breaking every user's integrations. But it is frustrating as the current process means having to install multiple instances of the same app, which is not desirable.
Maybe I will device some way to create a hybrid version of my code, where the parent app will maintain just wrapper code for devices that are not migrated, and leave it to the users to migrate devices on their own schedule with the caveat that only one hub can be defined as the default hub, for the wrappers, and all other hubs must be defined in the new methodology.
Maybe one of the HE developers can make this possible in the future.
Wouldn’t there be a security issue if apps could move devices around? Seems to me I recall one of the Hubitat staff saying that manual user selection of devices and drivers was required for this reason.
I don't see why. As an app, I can only access child devices and child apps of my app. There is an ownership hierarchy in place, so getParent() returns null if there is no parent, or the actual parent. And get child devices() is the same for children. If I have 50 devices, and none were created by my app, the get child devices call would not return any devices.
As such, the only changes that could be made are within the realm of the ownership hierarchy already in place.
Agreed. In the hierarchy of apps/devices, we are simply referring to moving a node from one branch to another branch of the same tree.
The limitations would be that a device may be moved to another device or app within the tree, and an app may not be moved to a new app, since apps are typically only 1 parent with multiple child app relationships...
