After you install the WebCoRE apps on your HE, Go to:
apps -> [name you gave your webcore instance]
click the "use custom endpoints" slider
Under "Custom webcore instance url different from dashboard.webcore.co:" https://[local webcore dashboard URL]
Save
Just to be clear, the webcore pistons actually run on the HE box, its only the "dashboard" UI that runs in the docker container.
Oh, OK so what really is the sense of putting it in the unraid docker? I thought that webcore was running in the cloud and this made it run on my Unraid server.
No. Like Bill said, your pistons are stored and execute on your hub. No in the cloud. When you say "run" you need to be more specific. The point of this is so the dashboard runs locally and not in the cloud.
Ryan780 is correct.
Running the dashboard locally does a couple of things for you.
its marginally quicker than running it in the cloud, given that you're not contending with other users for resources.
You're not trusting the security of the webcore cloud, such that, should they ever get hacked or something, the details of your house programming are visible to an attacker.
Should the webcore cloud go away for some reason, your house won't be orphaned with pistons that you can no longer edit.
you have control over when the webcore dashboard code gets upgraded. Nothing changes out from under you.
OK, that sounds great! However, when I pull up the Webcore dashboard it is giving me this message. And even when I do a Hard Reset in Firefox it doesn't do anything.
@ajayjohnm im getting this error on one of my pistons that i have moved from ST. any idea what it might be
28/10/2018, 22:00:00 +559ms
+227ms ║An error occurred while executing the event: java.lang.NullPointerException: Cannot get property 'v' on null object
28/10/2018, 19:00:00 +515ms
+375ms ║An error occurred while executing the event: java.lang.NullPointerException: Cannot get property 'v' on null object
Have you gone through and made sure that each of the drivers for the devices you're trying to set are capable of what you are setting them to?
You have a global variable in there, have you set that in your dashboard as well.
Also, you are using the On command and then a set level command. Why is that?
@pcgirl you can safely ignore that error. I think it has something to do with using the patched hubitat version of webcore which is lagging behind the master branch.
For me the error kind of comes and goes. I'm not sure whats up with that, but it effects nothing. Pistons and editing work just fine.
I see a lot of this too:
Unable to update setting 'dev' from child app. Open child app 'Foo' on the Hubitat apps page and click 'Done' for faster operation
AFAICT this can also be safely ignored. Doesn't seem to bother anything. Pistons still work. It just logs this error now and then.
My ZigBee devices don't adjust unless they are turned on. Although I haven't tried it on HE, it may be different.
They worked on ST and the capabilities are there as a opinion on HE.
Ding ding ding we have a winner 
can't believe I missed that 
haven't tested yet but I'm guessing that was it.
One little gotcha I keep running into with hubitat/webcore is when you add new devices. Just as in ST/webcore you have to make them available to webcore. In Hubiatat:
Apps -> [your webcore instance] -> Settings -> Available Devices -> Which Devices. There's a handy "Toggle All On/Off" here.
Where I run into the gotcha is I'll toggle all on and hit save, then go back to webcore and still no device. You have to hit "save", then when it returns you to the previous screen, hit the "done" button there as well or your device won't be available in webcore.
Just putting this here by way of community documentation.
do while loops work in HE? I can't get this one to run and it worked fine in ST. The rest of the piston works great.
Well I can tell you one thing, repeat loops work. I had one setup that ran out of control every 300ms such that it totally wedged the hub. I managed to delete it, but rebooting the hub was the only way to make it responsive again. This is the kind of thing that didn't sink you under ST. You just wasted a lot of their resources, you didn't saturate your hubs processing ability.
I've also run into things that were working in ST but are not working under WebCoRE hubitat. I have a piston that updates a global variable and that seems to be working intermittently. I have another piston that saves state to a global store then restores. That one seems to save fine but the restore fails. Again, was working under ST.
It's making me wonder how we can make this more stable, and also incorporate upstream changes on a more regular basis.
Is there an official maintainer of this project?
A process for applying the patches in a nightly build or something?
I can help with that if anybody is interested.
Yeah I dunno man. This isn't as stable as I was hoping it would be.
It sure looks to me like I can't trust setting a global variable. The logs say it was set, but when I check it sometimes it isn't.
Something is suddenly making it so my dashboard can't load any of my pistons. Scary sh*t. Can't back them up either.
I've given up on webcore. I have one automation using HTTP calls and data being parsed on the return that doesn't work at all in Hubitat. I'm running that still in ST. I have had to build like 15 virtual switchs and 50 RM, motion and simple lighting rules to get done what I did in webCoRE but I finally got most of my pistons migrated. Had to just give up on some functionality (like using "stays" since HE Rule Machine doesnt offer it). Very, VERY disappointed as it was presented as a working integration and it is FAR from it. Didn't plan on having a to spend a week rebuilding everything from scratch. I will most likely be able to remove webcore from HE soon.
You can backup your pistons now. The backup restore from file is working.
I can't even get into the hub. I rebooted it hoping that would clear up my issues now it just spins.... nothing loads. Still pingable but the hubitat interface is dead. This is after a fresh reboot? Damn.
Yeah i was thinking this was a working integration. I had that impression anyway, but maybe it was just wishful thinking.
This is horrifying. Multiple reboots and the hubitat interface freezes instantly. Devices Apps Settings... nothing works.
Well... ok I still can't tell what happened but I was able to get into hubitat enough to disable al the pistons.
I still can't back them up however. There seems to be some issue between the dashboard and the running webcore instance on hubitat.
I get: "An error has occurred while retrieving backup..."
It seems to have stabilized. Maybe I didn't wait long enough after rebooting to give the hubitat enough time to start all of my pistons. I was able to get into the apps section and stop all the pistons. Everything seems to have stabilized a bit after that.
I still don't quite understand the interaction between hubitat and the webcore dashboard. It keeps throwing up a banner that there was a problem loading dashboard data but then it goes ahead and loads, though everything seems slow. I thought maybe I was running out of memory or something but a look at the webcore app in the app list shows its only using 12%.
Phew... ok well, I was finally able to back all of my pistons up in batches of less than 10. This is still frightening in that I don't know what caused it, and I don't know what solved it either, but everything seems to be back running and snappy.
Download the Hubitat app
