I have a device driver that has a preference. I need to read the value of that preference from an app. Is there any way to do that?
No, but you can store the result in data, which is readable...
Would a child driver function work? Thinking a function in the child driver could return the value of the preference and be called from the parent app.
Hmm that might work. In the meantime I used Mike's suggestion and it's working. I was helping add some new functionality to alarmdecoder to work with other sensor types beyond contacts. So far so good!
Is there a way to read a child device's preferences, such as txtEnable, from a parent device instead of from an App? I know they can be changed with updateSettings() but there doesn't seem to be a getSettings()
I haven't tried this myself but I believe it should return a map of all the input settings.
I have tried that on a Virtual Contact Device which I know has txtEnable because I can turn it to true or false and see it on the device page. Unfortunately, myDevice.settings is returning null.
You should be able to simply add a function (e.g. getSetting()) to the child device that returns whatever setting you'd like. Then, call that function from the parent device via childDevice.getSetting(). Not sure if there is a better way or not. @mike.maxwell would probably be able to answer the best method for retrieving a Child Device's Settings from its Parent Device's code.
I saw that @ritchierich suggested that. I was really hoping to get this to work with existing virtual devices instead of having to write my own driver just so I can access its preferences/settings. Besides, why would they include them in the virtual devices if you can't access them?
Because the Virtual Device driver code is what uses those settings. I always write my own Child Drivers as I like to have complete control over their behavior. I have never needed to access the value of a child device's settings in my parent drivers.
@ogiewon Oh! That's interesting. Would you please explain that more? I have not witnessed the virtual drivers doing anything with that specific setting so I figured their purpose was for us to wire rules and our code to it.
txtEnable should enable more verbose logging that generally would not be needed but might be useful for troubleshooting specific issues.
@stephack I've seen code in the user created drivers to do log.info if that was turned on. In the stock Virtual Contact Sensor driver (for example), I do not see any additional logging happening so I assumed the driver itself doesn't do anything with it.
I can't speak for the Virtual Contact Sensor as Idon't use it but with the Virtual Switch:
When descriptionText (which is txtEnable) is enabled, I see all on/off switch events in my logs. With it disabled I do not see these events. With a contact sensor, I assume it would be open/closed events instead of switch events.
Yes... txtEnable should replicate device events in the logs - and not much more than that.
It is debatable whether it should also log repeat events that are filtered out of the event table or not - various drivers handle that situation different ways.
@stephack @JasonJoel Then sounds like we aren't meant to access that setting externally and the driver is supposed to handle it internally. If that's the case, perhaps the Virtual Contact Sensor Driver is missing that piece.
Not sure what you mean by that.
It is a user settable option - some users don't want that data in the log at all. What that option does when turned ON is obviously up to the driver coding, although there are some general norms on what that user settable option should do inside of the driver.
@JasonJoel Sorry if I wasn't clear. I was accepting your response.
If the driver is the intended handler of txtEnable, and never something outside the driver, then it makes sense that I wouldn't be able to access the setting outside the driver such as in a parent driver or app. Assuming that is the case then it seems like the stock Virtual Contact Driver is missing the code to write to the log when that setting is on. In other words, it has a setting that it doesn't use and I can't use it either.
Gotcha!! I get it now. I'm slow, sometimes it takes me a while.
Nope, txtEnable controls the logging of the description text when you click open or close on the virtual conact sensor: