I've used both. With local hosting, the Dashboard/IDE loads faster, and I have no problems with a bunch of devices authorized (not sure if it's still a problem, but I had issues with the public Dashboard with lots of devices, plus it just took a while to load in general). But it doesn't affect piston execution at all: on Hubitat, they are just child apps of the webCoRE app, and all execute locally. The dashboard is just used for editing, and there is no difference when they are run.
Which brings us to...:
It sounds like @jp0550 was talking about Hubitat having to recompile the "main" webCoRE app after the hub is rebooted--Groovy is an interpreted language but is ultimately compiled to Java bytecode, and I'm not familiar with the inner workings of Hubitat to know when does that (at runtime, or as much as it can at boot for all installed apps?). But I don't think he meant webCoRE pistons being "compiled"--they are (child) apps, but they themselves have to be interpreted through the parent webCoRE app/runtime.
You do have a neat idea, though--it would be nice to have the ability to convert a piston to "native" Groovy to skip one layer of interpretation and make it faster, an idea Bruce also mentioned above. But I imagine the resulting Groovy would border on unreadable, nice as it may be to have a starting point for converting pistons to native apps (not that it's much harder except the interpreted nature of Groovy and the lack of useful tools like breakpoints, inspectors, or an easy way to unit test make it much harder than writing a webCoRE piston that won't let you write invalid syntax in the first place).
To go back to the first question: webCoRE pistons are locally executed on Hubitat, but generally (just slightly) slower than "native" apps due to the above. In any case, where the Dashboard is hosted won't affect this.
Nice post. I thought I heard that the WebCoRE pistons run locally but I wasn't sure. Glad to hear the Pi hosted dashboard only improves development speed too.
Clarifies a lot that maybe I could gather elsewhere but a newer post helps. I think after reading this I'm going to keep all of my pistons instead of trying to learn Rule Machine...
I was thinking the same as you but decided to move my simpler pistons onto the native HE apps.
I must say that they do run quicker than my webCoRE pistons.
Personally I would recommend moving over your simpler pistons and you will probably find that even the more complex pistons can be moved over.
Just my observations but at the end of the day it's what the user is happiest with that matters.
I'm just happy I have everything working locally.
I find my automation's are a little all over the place right now. Some in RM, some in Simple Lighting, and then also Motion Lighting. The thing about webCoRE I love is that I can keep them all in one place, but then in doing so can create issues, as most have experienced
Yes. Start with simple lighting or motion lighting. I know what you mean about RM but once you start to get your head round it, it's not to bad. I do agree though that once your into webCoRE it does pretty much everything you can think of.
The automations I do have in RM, do run well. I have 4 speakers dotted around rooms, and control them via Dashboard and panels for each station I want to listen to. In webCoRE, 4 pistons covered the config I needed.
In RM, I've had to create 9 custom commands, and then 27 different routines (will be 36 by the time I've finished) to cover what I had in 4 pistons. That's some overhead.
I don't think anyone would argue that WebCoRE's "Containerizing" of many Rules into one Piston is a wonderful thing. But like many here, I've found that the Native tools provide a solid "bang for buck."
The first week or month of Hubitat may not be the ideal week/month to learn RM. But eventually, predictably, the "equation" changes and it becomes worth it. And suddenly you'll find yourself looking for more pistons to convert
Hey everyone, I've updated my repo with the latest changes from @ipaterson. You can read about them below. The main feature is the ability to restore backup pistons from a file and a few bug fixes.
No idea what's wrong, checked the app info and it is using the https://cloud.hubitat.com/api/... endpoint. Have already tried completely removing and reinstalling it, but no luck fixing it yet.
Edit:
Here's what I see in chrome developer tools when attempting to register and sign in to my hubitat's webcore instance:
Everything in your logs looks normal until the 502 error from the cloud hubitat link. Are you able to access other apps from the Hubitat cloud like dashboards?
I've seen other users where their connection to the cloud had disconnected requiring a reboot.
I just spun up a new instance clicking both the dashboard link and the register link, and it popped up for both.
I was getting 502s until I updated all of the webcore apps. I tried rebooting the hub - it didn't do anything. I updated to your latest release and it started working again.
I have been using the WebCoRE Presence Driver since WebCoRE was working on HE. It has worked well for me. With some of the posts regarding hub slowness, I moved WebCoRE back to my ST hub and then I use the HE Hub Link to create a virtual presence sensor in HE. It's been working great for me.
