When I run the app and it prompts me for the device EM I would supply the device AeonMonitor. If I know this will never change how can I just hardcode the AeonMonitor driver in my custom code so I will not have to supply anything when I run the app. Thanks
Part of the way the platform works is that a user always has to select any pre-existing devices to be used in an app, the app cannot take control of a device on it's own. The only exception to this is any devices the app creates, those it can control without human intervention, although typically that is required in some form or another, if only to install the app.
Thinking out aloud.... If the apps you are writing are somehow related... could you write a parent app where you would select the AeonMonitor device, then configure child apps to do the specific tasks?
It depends on what you are ultimately trying to achieve with the apps, it may be worth explaining that in a bit more detail so people may be able to suggest alternative options.
I think I like you Thinking Out Aloud. I will give it some thought and perhaps I can cheat my way out of this. Thanks and if you get bored and want to show an example I would not mind at all!
I haven't written any parent/child apps, at least that I remember.... But there are likely plenty around, but whether they tackle this exact scenario, I can't think of one off the top of my head.
You will ultimately have to select the device at some point, any link an app has with an existing device has to come from an input that a user interacts with, unless the app creates the device... So it's more a case of how many times you have to select it... And whether you can construct the app or apps to streamline that process.
It's hard to say how relevant my suggestion may be without knowing a little more about what you are wanting to achieve with your apps.
Adding to the above, the explanation is correct that the user (even if it's you) must select a device, and the suggestion to use a parent app and select the device once for all child apps (if that kind of setup makes sense for you) could work if you wanted to avoid that; otherwise, it's just one-time thing.
But this selector is a bit unusual: it sounds like you're looking for only a specific kind of device, so you could make this list a but shorter by using some capability the driver implements like "capability.switch" (guessing here since I don't know what driver you're actually using...) or even the actual driver name like "device.DriverName" if you're only looking for a specific driver. It won't automatically select anything, but it will make finding it easier -- and make sure the user (even if you) doesn't select something without the attributes and commands your app expects.
What I would like to achieve is to not answer a handful of questions about device drivers that will never change. I would love to just run the app and off I go. Especially around the 12th time of running that app. I think your suggestion will solve my problem in that the device labels created in the parent (And yes I will have to supply them this one time) I can use in the children and have the reward of NOT answering device questions any more. Just have to live with the very minor structing of parent/child. Seems worth it! I think I will give this a try. I appreciate the help.
I suspect, but I could be wrong, that the parent app may need to do the interaction with the device, which may not be ideal in this case. @bertabcd1234 may be able to confirm that.....?
I appreciate that. And instead of a list of 15 things I could get just the one I want... but I would really love to not have to answer any questions. Creating the device label(s) in a parent and then I can code to them in a child makes sense to me. I will give it a try and maybe after doing it I might have a different opinion. Thanks
The parent app can updateSetting() in a child app to set the value of that input (even if not displayed in the UI) to any device the parent has already selected (I think? I know there's a way I've done this...).
This should be something you do once when installing the app (or opening it the first time), not every time it runs...if not, something else is definitely wrong!
Thanks for the thought... I will try making an example and give it a try. I also have not done much with Parent/Child apps so it will be a learning experience. Thanks
When developing an app I end up running the thing SEVERAL times and during that it sure would be nice not to have to answer a series of question that (in my case) never change.
Any App that calls addChildDevice would have this ability. I don't think I've properly released my MobileController App yet, but the code below will hopefully give you an idea. The method at the bottom creates the child device, then the method at the top looks it up based on the Device Id. There are probably different variations of this pattern.
def pageApplyConfiguration(params) {
com.hubitat.app.DeviceWrapper newMobileDevice = getChildDevice(state.deviceId);
if(newMobileDevice != null) {
newMobileDevice.configure();
newMobileDevice.configureBulkPermissions(btMonitor, wifiMonitor, callMonitor, msgMonitor);
}
dynamicPage (name: "pageApplyConfiguration", title: "New Mobile Device", nextPage: "mainPage", install: false, uninstall: false) {
section("") {
paragraph "Your mobile device has been configured. Please click Next to return to the Main Manu"
}
}
}
// Device Methods
String createMobileDevice() {
def dni = UUID.randomUUID().toString();
def newMobileDevice = addChildDevice("simnet", "Mobile Device", dni, 1234, ["name": "${newMobileName}", isComponent: false]);
newMobileDevice.updateSetting("DeviceIPAddress",[value: "${newMobileIPAddress}", type: 'string']);
state.deviceId = newMobileDevice.getDeviceNetworkId();
return newMobileDevice.getDeviceNetworkId();
}
in my preferences section it will return in a variable EM a Device Wrapper... correct?
Then later in my app I have
subscribe(EM, "dryerState", dryerHandler)
in my updated() routine.
So if I said the above correctly I can find from my list of devices the one that is named EM and create a Device Wrapper for it and use it in my subscribe without having to have the "input" for EM above. Am I even close?
Mostly, but not quite.... I'm a little new to the App side of things.... So apologies if I get one or two details wrong along the way here...
Yes, if you configure an input like that, you can reference the input as EM in later pages or methods, as you describe here:
But...
This last bit is what you can't do, if I am understanding your description correctly. If the EM device is pre-existing on your HE hub, you still have to use an Input, you can't create an association or assume control of an existing device in an app without the user selecting it in an Input. If your App creates the device, like I posted about earlier, then you can find the device using the getChildDevice method (this may also work for pre-existing devices, I'm not sure...).
Oh, hang on, maybe I did interpret that wrong.... If you are intending to use an Input, you can just reference EM... you don't necessarily need to find it again, I don't believe.
My whole intent is to not use the input and instead go thru the process I outlined above to get and "EM" programmatically and then I can use it in my subscribe(). Is that possible?
I don't believe it is, it is only possible to do it without an Input if the App creates the device.
From what you were mentioning earlier to Robert, it might be worth explaining a little more about why you are needing to continually select the device, is it that you are re-installing or creating copies / variations of the App multiple times? What I had in mind some time back when we were chatting was that you could have the device selection occur in a parent App that may or may not be relatively basic, then child Apps do the work, so you could install, remove and re-install the child apps as often as you like, but the parent could remain in place and linked to the device and managing communications and subscriptions to events. It really depends on what end-goal the Apps are trying to achieve as to whether that setup could work.
Ya... I made a Parent/Child environment and tried to do just that. It executed without any syntax problems but did not do anything. I am SURE I did not do something correctly. I will work on that some more. But I thought I would ask about creating the Device Wrapper programmatically and get what I want that way.
I keep having to select the device and input it because I often change things while I develop a custom app and change things that cannot be added without uninstalling and installing again. Such as when I change global variables or add things in a preferences, installed(), or updated(). I do realize that code type changes do not require me uninstalling and installing again. I wouldn't mind it so much if I have 1, 2, or 3 inputs but sometimes I deal with switches or plugs that I have lots of.
I haven't written any parent/child apps, at least that I remember.... But there are likely plenty around, but whether they tackle this exact scenario, I can't think of one off the top of my head.
