Of course there's a reason, it is by design. Under specific circumstances, yes, it could "know".
Could being the operative word. Could isn't acceptable. The only way to make it foolproof is the way it is done. If you wanted to do it the opposite way, the system would have to be designed to always work that way and have drivers and apps paired, severely limiting their applicability. It's not as simple as you make it out to sound.
1 Like
Ok, in the very specific case of my app, it is not a could, it is a certainty.
I do see the need for developers to be more aware of the consequences of their code if full access is available without user selection. The current design does provide limits to at least partially protect against laziness and lack of knowledge. I'm starting to have more understanding for the design, even though I don't agree. My agreement is irrelevant anyway.
It depends on the developer...
Your app. But not every app. The system is designed for everyone.
Not in the current model it doesn't. And that's why the current model is the current model. How do I know what kind of developer you are? I don't. And therefore the system is designed to prevent developers from making the type of mistake you say you have prevented in your app. You realize that if done incorrectly, an app could just wipe out all the devices on your system, right? Forcing you back to square one? Granting access to control devices means not only turning them on and off but removing them as well.
Apps can't delete arbitrary devices, including ones the user has selected for that app; they can only delete devices they've created as child devices. (There isn't a way to see child devices of an app from the UI, but it's a thing apps can do.)
Back to the original request: do you have a specific use in mind? This is normally something staff would want to see before blindly agreeing to a feature request. I'd say it's unlikely to happen, anyway, but you might get other ideas for what you could do. Built-in apps intentionally have access to a bit more "magic" than user apps, but there is really nothing a user app can't do one way or another. You've seen several examples above. In nearly every case, this is quite intuitive (e.g., select a motion sensor, and select lights you want to control with it). Apps like HSM do have some options like "use all contact sensors," but again, the workaround in a user app is quite simple: just let the user select contact sensors. You need to specify somehow what the app should do with what devices; in Hubitat, that happens to be point-and-click or touch to select devices (I suppose you might be comparing it to Home Assistant or similar where you can type an arbitrary entity name into, say, AppDaemon? that's basically doing the same thing but by hand).
That being said, Hubitat staff have hinted in the past that they are open to reworking the app UI model. I'm not sure that the way they are able to interact with devices would be changed as part of these (still hypothetical) changes, but it may make building UIs for users to choose devices easier. Most of Hubitat's current model was inherited from ST, presumably to make it easier for users (and developers) to come to this platform, so some of these questions really could be directed back to why ST made those design decisions in the first place. 
1 Like
It still does, with the difference that it can't be done by ignorance or by mistake. On purpose is another matter.
I do believe it to be more than that behind it, but it could be one of the reasons.
By personally reading and understanding my code would be a reliable way. If you don't like what you see, don't use it.
Prevent, no, make it so that it is not done by mistake, sure. Prevent implies that it is secure, it is not. It is just a moderate obstacle keeping developers on the set path as long as they don't purposefully make sure to leave it.
I do, it is the app I talked about above. I wouldn't expect a change to allow this, if this is what they wanted, it would have been done or will be done anyway. All this is more to try to understand the why's.
Yes, they're in a different sandbox with full (or at least partial) device access, so are other devices. There may be no restrictions at all as far as we will ever know. There's a thread about the routing table command in the driver for the Ikea Zigbee devices that clearly shows this.
In general this makes sense, probably in most cases, just not in this, admittedly, corner case.
I do appreciate and understand this, though not all has to be 100% the same to be compatible. There are many examples of that.
Thank you for taking the time to answer!
The reason for these safeguards is that the vast majority of users cannot just read and understand code. You are basically advocating "trust me" (trust my code). It's one thing for a user to trust HSM or Groups and Scenes, it's another thing to trust third party code. @Ryan780 has explained pretty well why a generic trust-my-code doesn't work well. The "but I'm an exception" argument is pretty thin.
2 Likes
Thank you for taking the time to answer.
I do understand that, though users trust closed source aps and devices without even having the choice. Not a debate for here. Reasoning understood.
I wasn't even trying to make that argument, the real argument I'm making is that the "safe guards" currently in place have plenty of ways to be circumvented. The protection is against certain mistakes made by a developer, not against a developer who wants to get around it. With that said, just because it is possible, I have not implemented such workarounds since I see them as "hackish" and it is not what is expected by the user.
Again, I appreciate the feedback. If I would ask for anything related to this it would be for a "select all" button for capability masks other than "*".
What are you talking about? What restriction?
That devices can't be accessed without having been selected in user input.
OK, and how do you get around that?
JS is one simple but unclean way
Are you embedding JS in an app and using that to access a device that wasn't selected?
I'm saying it is possible, not that I am or would do it. But yes, that is one way.
I don't know what you're talking about, and not sure that you can actually get a device wrapper that way for use in an app. That would be news to me. The device wrapper is returned by the input statement. I don't think it's available through JS (but what do I know).
In the case I'm talking about JS would be used to submit the "user selection" as if it was done by the user. Since it is not common knowledge how to do this or that it even can be done I don't like talking about the details in an open forum. I'm sure there are those that know, but then they usually know what to do and not to do. Those that don't know probably shouldn't get a step by step guide. I'd be glad to discuss this in a PM.
LOL. There are many things "hidden" in plain sight.
But, also, there are system calls that are not available in user apps. These aren't documented, and we have no intention of changing their availability. The reason for this may become more apparent over time. Two things to bear in mind: it's not a top platform priority to support a development environment, and it's not an open platform (i.e., it's not open source). There are actual business reasons for most of what we do.
2 Likes
Of course, there usually is.
This is clear from the difference in what is available and what is done.
Hopefully not in a negative (from the perspective of a developer) way 
These things have been made clear. I do hope you appreciate the fact that my users rely on things implemented by 3rd party developers as well as being able to write their own code. Without it, I certainly wouldn't be here, neither would many others, I'm sure.
You do use a lot of open source in the platform, and most user code is provided as open source. But if course, you have your closed source. People use your hub for many different reasons, mine is that it in general us stable and I don't have to bother keeping the platform running. I can do the fun things I want. You deal with the platform. If full open source was the goal for me, I'd be elsewhere.
I sure would hope so, I run my business based on business reasons as well. To do well and thrive as a business, these things needs to be done right. I'm sure you've got your goals and hope you get there while not taking away anything current users like and use.
Thank you again for taking the time for this discussion, it was informative.
