There comes a time when you either accept that the answer is no, or you take it offline with the person who gave you the answer. To do otherwise is counter productive as you end up pushing people into a corner....
4 Likes
Someone (third party) creates insidious groovy code for RM and tells the world it will make all apps run faster.
Iām the dumbass who downloads/installs it and borks my Hubitat.
I go running to Hubitat support for help, who tell me the situation canāt be fixed.
Thatās how.
5 Likes
@marktheknife touched on this in his reply, but youāre missing the point of what theyāre saying. If Hubitat allowed custom apps to interact with devices they hadnāt been explicitly authorized to interact with, it would be possible for a bad actor to publish an app that other users would install (because it had documented features which were desirable to that end-user), but which also had undocumented, malicious features which could compromise the userās security.
1 Like
Requiring the explicit selection of devices is no different from iOS or Android making you explicitly grant permissions...
So, it's the same situation as already now with any custom driver and custom app...
And don't forget:
Something like the "Groovy Machine" 
would be a totally local thing - nothing to be shared.
No, it's not, because I have to add every new device again - even if I've already given the permission to deal with e.g. Motion Sensors.
=> At least something like "Permission to use every Motion Sensor" (also of the future) is necessary.
Youāre accusing Hubitat management of lying to you. Thatās not a productive approach.
4 Likes
Looks like it's time to mute this conversation as it isn't going anywhere productive...
2 Likes
No, I don't! Where did you get that from?
I've proofed that the security of others is not concerned by such a feature.
I think you would run into the same issue even if you received the groovy executor in RM you are requesting. It too would have a learning curve.
Developers always complain about documentation. I do it too. However, in this case, I found the provided examples, documentation, and community apps sufficient to help me learn to do groovy apps.
1 Like
No - I don't think so. I believe they (custom apps/drivers) execute in a sandbox. I'll bet that Rule Machine does not.
A) You have proven no such thing.
B) @bravenel said that the functionality you want will never be available, and that the reason it will not be available is security. You then said that:
How else would this be interpreted then as accusing him of lying about the reason?
With respect to what you are considering as you write this, this is true. But, you're essentially asking for a big "trust me" with respect to other users. "I will only use these features locally". But, you could publish an app, and that app would not have these protections wrt using devices behind a users back. Or more to the point, by opening these features for you, they are opened also for others. Perhaps you have benign intents; do all?
4 Likes
But yes:
It seems clear enough to me even as a non-developer that this is the risk that Hubitat would take on by adding what OP is requesting. And itās equally clear the request wonāt be granted. Why keep arguing the point?
Perhaps, but why add to the number of ways a bad actor could compromise someone elseās system?
2 Likes
IMHO if Mr.X want to use an app that needs access to others devices, Mr.X don't wait a second, to fill the list (e.g. by hitting "all devices"). Mr.X is at least 95% of users...
Don't you think so too?
BTW: Everything that will be imported (apps, devices) are still sandboxed - no change in security is necessary.
I include in security things that put the closed nature of the hub at risk. We don't allow ssh, root access, etc. Groovy is constrained to a sandbox environment. Allowing injected groovy would present a huge security hole, one that a truck could be driven through.
This is a weird discussion. Rule Machine is 99.9% just a Groovy app that anyone could implement. It started out as a community app in SmartThings, and has grown from there. I will have to see what very limited things is does that you couldn't do in your own apps -- it is not very much.
All of the Hubitat built-in apps and drivers are implemented in Groovy developed on the hub, just like you can do yourself. There is only a very narrow set of things that are in any way restricted. Most apps and drivers use no restricted methods at all.
4 Likes
I understand this very well - so why not allow e.g. a Groovy script executed in this sandbox?
Effort vs reward vs competing demands for resources combined with support implications for adding another way for people to blow themselves up. Anything is possible; but that's hardly a persuasive argument as to why it should be done. Hubitat Elevation was not developed to be a development environment/platform. Its intent is to provide a means for people to implement home automation.
You have the tools to write apps and drivers. You personally have the skills and knowledge to do so. So have at it to solve the automations that are not otherwise available to you.
6 Likes
Thank you very much for your openness (and patience)! 
OK, i can live with that - of course! 
Just one little wish:
Could the "Toggle All On/Off" toggle have an additional option "All On - even those who are yet to come"? 
1 Like
