FOREACH, collections,

Please give us some kind of collections (arrays, lists) and a possibility to loop (e.g. for each) through all the elements.

I have noticed that I often write the same code for many devices (e.g. "for all devices of type x do y"). And with e.g. 10 Chromecast devices it's a lot of clicking (and don't forget, that there is no cut'n'paste in the rule editor to copy lines).

Example (set all silent devices to 50%):
Set cc_devices to (CollectDevices type:Chromecast Audio)
FOREACH dev IN cc_devices
....IF (dev.Volume < 50) Set Volume on dev to 50
END FOR

Thanx in advance!

Has anyone an idea how I can accomplish such tasks (e,g. check a list of devices for a specific status and act dependent of the status' value)?

@bravenel, what do you think?

I think it's time for you to learn/use Groovy. This is easy in a custom app. Further extending Rule Machine is not appealing. There's a line there somewhere; this is across the line, imo.

input "cc_devices", "capability.musicPlayer", title: "Select Chromecast players", multiple: are
...
cc_devices.each {if(it.volume < 50) it.setVolume(50)}
3 Likes

I am a professional Java and Groovy developer. :point_left:

But the lack of a full documation for App Building "binds me" to Rule Machine. :wink:
And no, examples unfortunately are not an equivalent substitute...

Therefor the recently discussed idea of some kind of Groovy integration in Rule Machine...

But maybe there exists an example app which shows, how you can access all devices (without defining them before using), subscribe to device events, etc. pp.? :thinking:

also maybe setup a group and use that if you want to set settings on similiar devices easy in rule machine.

It's not possible in user apps to access devices that are not selected through an input. In the example you had above, that input was shown. As for subscribe to device events, there are examples in the public Github repo (HubitatPublic/example-apps at master Ā· hubitat/HubitatPublic Ā· GitHub), and in all of the various community apps.

This isn't in our plans... As above, beyond the scope of RM. There are ways to integrate with RM from custom apps, see Rule Machine API (forum post available), and through Connectors. Embedding Groovy somehow in a rule is a non-starter.

1 Like

Why not? :thinking:
Or is there at least a mechanism to auto update the list of used devices?

That's a pity. Some kind of injection (similar to Set Variable to Math) would be very powerful:
E.g. filling a string field sGroovy and execute it's content via Eval.me(sGroovy)...

Security. Would give 3rd party apps access to devices behind user's back.

Security. Groovy is compiled in a sandbox.

2 Likes

To be honest, in this case I don't understand the "security" argument... :thinking:

Wouldn't it be the same person who enters the Groovy code as the one who alread now installs drivers, apps, selects devices for the apps, write rules, connects new devices, ...?

So the question is:
How much would I have to pay to get a Build-In App "Groovy Machine" :wink: with all the rights Rule Machine owns?

Yes, but it doesn't mean they understand what the code is doing, nefarious or not...

2 Likes

case in point - me.

3 Likes

Isn't the same valid already now for custom apps and custom drivers? :thinking:
How can a Groovy view expose more data?

There are a large number of 3rd party apps published, and installed by users who are not capable of understanding what the code does. The security risk is to other users, not to yourself. You will have to take my word for it that there are bad actors and that these are not imaginary risks.

This is not available, nor planned to ever be available. There are always going to be restricted methods, sandbox restrictions, etc.

1 Like

I could write Groovy code on my Hubitat only (same as writing rules in Rule Machine), this code would be saved locally on my Hubitat, it can not connect to other users' Hubitat.
=> The security risk is only to myself and never to other users.

Still remains the question: Why not?
Hint: "Security" is not the reason.

So I know itā€™s not the answer you want and youā€™re certainly welcome to your opinions, but youā€™ve already gotten your answer from the powers that be and their answer isnā€™t going to change. Your replies are not going to be so persuasive to change their stated facts and will more likely just inflame the conversation further.

So my unsolicited advice is to proceed and to write your own apps to do some of the more advanced things you are hoping to do. As you mentioned being a groovy developer, thereā€™s plenty of example code out in the community that should set you down the right path.

That's really not my intention! :face_with_hand_over_mouth:

I just want to understand the reasons - to get to a solution after all.

You're right, but alas examples are not a specification or - let alone - a full technical documentation.

If you get stuck, just post in the Developers section of the forum.

Thanx, but Groups are only for bulbs, dimmers, and switches. :cry:
https://docs.hubitat.com/index.php?title=Groups

It seems as though if they were to add a feature like what youā€™re requesting, even if youā€™re only a threat to yourself, it would still open up the possibility of extreme risk to other users.

The problem from their perspective extends well beyond how you personally would use the feature.

Or am I misunderstanding?

1 Like

How? :thinking:

It would be a completely local thing. :point_left:
With such a feature no one would get the possibility to influence other Hubitats.