Ha, I was also about to say that I’ve found if WC can handle a task, so can RM… and vice versa.
It’s pretty cool!
Same reason we have 2 versions of a few other tools/integrations - allows the community effort to continue contributing at rate not directly tied to the HE release strategy. Does mean that the Community addition can be ahead of the integrated version if desired, but it also allows one to stay behind the integrated version if they desire.
Platform is very strong on letting the user determine what is best for their install.
3 Likes
Sure, there are built-in and community drivers, but they have different names. And the community versions are almost always superior to the built-in drivers.
No so with WC. There's no clear distinction between the two, other than one is "built-in" and one is a "user app". That in and of itself conveys no useful information. If the Hubitat folks took WC and optimized it in ways that could not be done by a user app, then that would be one thing, but there's no formally documented difference between the two. I still don't understand why they even bothered.
Thanks for pointing that out, by that statement I just mean in plain language terms people know what those mean, like IF I am hungry, THEN I go to the store, ELSE I just stay home.
I know, I sort-of thought when it became a built-in app they were going to make it their own and actually develop it, not just host the code on the hub. Too bad.
One doesn't update the other, if you install both you get duplicate code files but only one set of them go with the active version of Webcore.
1 Like
WC doesn't do true Functions so it can't return a value.
What you can do is a subroutine with args and set a global/hub variable that you query for the the subroutine output.
1 Like
Same reason I chose Hubitat. Webcore is #1 for me and have not used RM either. I just like the extreme flexibility of WebCoRE and it's the closest to programming (from my old programming days) for me.
2 Likes
That always has bugged me. I always wanted to call a piston and send it parameters and have it return a value.
Hub variable device values get updated immediately and you can get them back as results in the same piston, unlike Webcore globals, so I would just get the variable attribute of the variable device for the result, after waiting a second for the subroutine piston to run the args and set the variable as the result.
A very simple custom driver can be written with some logic that acts on a set of command inputs like a function, and set a result attribute(s) that can be used in the same way from Webcore to get the results
1 Like
Maybe @nh.schottfam has a reason.
He's the one who got me on to subroutines with args and if Functions were possible I'm sure he would have found a way.
You should find the custom commands for the device if you scroll down further in the command list.
webcore has most standard commands built it because you can create variables with lists of of devices and in single command issue commands to all these devices. The IDE does not have code to fully determine what commands you intend in this case.
In general defining a custom command the same name as a standard command is going to cause confusion, and it would be best if devices prepend or append something to distinguish the commands
2 Likes
You can add and remove arguments in the parameters drop-down. If there is an existing parameter, you can remove it. If there are none, you can add as many as you need by type.
This times 10000. Predefined commands in capabilities should not be overloaded by user commands if the structure changes.
2 Likes
