Starting with development of WebCoRE

#1

Hey!
I’m wondering if there is any sort of documentation out there for a developrr to start contributing to WebCoRE.

Things that would be good to know:

  • How to run the dashboard locally: any server specifics, any docker images that allows that?
  • Seems like the url we access on dashboard.webcore.co is a multi-tenant app. How does that communicate with my installation? How can we update for the private deployed server for testing (aka integrate with the above to allow for development)?
  • Any particular tips on how to develop and test the other smartapps? Any particular workflow that simplifies coding + deployment to ST + running?

Thank you!

#2

I use superstatic to run webCoRE locally, there is a superstatic.json config file in the repo so once installed just run superstatic in the webCoRE repo directory. Files are served up from the dashboard directory, and any edits you make there should show up on refresh. There is almost zero setup to run it on a real server, you just have to map all paths (e.g. /piston/:abc123:) back to the index.html file.

The various webCoRE APIs are private and may be restricted to access from specific referral hosts, but I’m not sure. I believe that only the APIs used directly by pistons (e.g. emailing, fuel streams, $nfl) are restricted and those restrictions would apply to the SmartThings endpoint rather than where you host the dashboard. A local install will still connect to the shared webCoRE API endpoints (backup bins and initial dashboard registration).

SmartThings provides a token for communicating with your SmartApps and the “Register a browser” process is how the token gets from the webCoRE SmartApp to your browser. The dashboard host is irrelevant in that exchange, so you can host it anywhere without making any changes. The dashboard server has zero state or storage, it just serves up static files. All of the connection details remain in the browser’s local storage.

I always edit in VS Code then paste into the IDE, any text editor will work. You will quickly notice looking at the code that it is a horrible mess of space and tab indentation since it was primarily developed at the whim of the ST IDE. There is no linting or .editorconfig or any of the typical resources to aid contribution.

A few other relevant notes

  • Always check out the dev branch for local development and submit any pull requests to that branch to avoid conflicting with other work in development.
  • There is no package manager; third party dependencies are just copied into the repo and many of those dependencies seem to have been edited. Best not to upgrade or otherwise mess with them.
  • The code in dist/dashboard is generated by a private build script on the dashboard server and should not be edited. You would either have to set up a minification and upload pipeline for your host or just serve the raw files.
  • There is a beta group of a few dozen people with a private category in this forum, but it is still difficult to get changes tested.
  • With every release there are at least a handful of people that are certain the update broke something so each release is a time commitment. Often I get unlucky and a release coincides with SmartThings outages, a recipe for a ruined weekend. There is a release nearly ready to go out, but the world is just too crazy right now to push out a mandatory update.

If you are interested in future webCoRE development (i.e. for the inevitable but still distant Groovy platform shutdown), please PM me with some details on your experience. There exists some new code following better practices but I have been waiting on some milestones from ST before moving forward.

#3

@ipaterson that was a great introduction! Thank you very much!
I clone the project locally and was able to get started with dashboard tests. I’m look more into the SmartApps after, but this was enough to get started.

:sweat_smile: that’s how you know you are doing IT right.

I’ll PM you for more information, thanks!

#4

Please excuse me for interrupting, but this topic is so rarely discussed, it would really be beneficial to other devs if it was a public conversation, instead of private.

#5

@tyron did you get WebCoRE running on a Raspberry Pi? How was it?

#6

@Alwas no, I don’t even have a Raspeberry Pi. I’m just using my computer to run it.

#7

You have a dedicated 24/7 pc then, any guides on install process? Is it noticeably faster? Which parts run truly local without the ST cloud?

#8

Oh, now I see where you are going. Sorry, maybe the purpose of the thread wasn’t entirely clear. I am not trying to run webCoRE locally for the sake of having it privately or faster. I guess technically you could, but I’m really not sure what would happen when a piston runs for example. Would they be run twice or is that take care by the child smartapp directly on your ST? I don’t know yet.

My goal here is simply running the apps locally for help on developing webCoRE itself.

#9

I think the only option to run webCoRE locally is with a Hubitat Elevation hub. The dashboard can be run anywhere but that doesn’t serve much of a purpose unless you’re developing the frontend dashboard code. The slow part of webCoRE and the dashboard is mostly communicating with and waiting on the ST Groovy platform.

Good point, anyone interested in contributing code is welcome to share their qualifications and interests publicly but a PM is fine, too. Either way, once there is something to work on it will be invaluable to have some devs willing to help.

#10

I’ve been playing with webCoRE UI development for a bit lately and I switched from the previous setup I followed from @ipaterson on using superstatic. That was my initial approach and it is clearly the easiest! But I couldn’t get debugging to integrate with my IDE (I’m using VS Code) so I went for another solution.

I ended up installing Live Server and Debugger for Chrome extensions, configuring .vscode/settings.json with the code below, which tells the Live Server to serve files from /dashboard subfolder and redirect all 404 to index.html for proper handling of rewrites:

{
   "liveServer.settings.root": "/dashboard",
   "liveServer.settings.file": "index.html",
   "liveServer.settings.NoBrowser": true
}

And a Launch Configuration (.vscode/launch.json) with the code below, which starts Chrome connected to VS Code on default Live Server port (5500), also mapping all files from subfolder /dashboard to the root of the server:

{
    "type": "chrome",
    "request": "launch",
    "name": "Launch Chrome against localhost",
    "url": "http://localhost:5500",
    "webRoot": "${workspaceFolder}/dashboard"
}

It’s working pretty well, I can define my breakpoints on VS Code and work from there :slight_smile: