Webcore on Hubitat or Rasberry pi

[nrus2222]

You won't regret it, @user3509!

I jumped over from ST a few months ago and zero regrets. Everything on HE and webcore working perfectly and more quickly, after correcting small issue with HE/ST versions handling date/time for timezones differently, and twc weather not supported on HE. Started converting several of my pistons to HE's rule machine, but have not noticed any difference in performance. All way better than ST's laggy web interface.

No need to wait til Jan...just do it! Just took me a couple hours to move 90% of my physical devices over, the rest of the day to deal with a few z-wave pairing issues (f-ing i-Blinds!), and the rest of the weekend to recreate virtual devices and webore/rules automatons I had before. My setup has around 80 physical plus virtual devices and around 30 automations, and integrations with Rachio, Flume, EcoBee, Actiontiles and data logging to google sheets. I was afraid converting all this would result in more bugs that were going to take longer to fix, but with this community's help, most of it up and running after a weekend, and just a few weeks to tie up some loose ends and move on to building the system out further (including Emporia Energy monitor, and some new rules using Emporia and Flume triggers/conditions that weren't possible on ST). I think all the best Groovy developers that helped make ST what it was, are on HE now. Some key pieces here from my ST setup were @sandood's ecobee suite and @krlaframboise simple event logger, but many more cool things I've found in built-in and community drivers I'm using now (+1 for HPM package manager, if it's not built in, chances are you can find what you need there - only a few items I've had to copy/paste code or Github URLs.).

As @Equis mentions, only painful part for webcore is going through each piston and selecting all the new devices on HE hub. When you restore backup pistons from ST version, all the devices show up with a unique, but not user-friendly code, My only tip to my former self would be to print each of my more complicated pistons with the ST device names I recognize to ease this step. I didn't make any mistakes, but there were a few cases I really had to work through the logic again to make sure I was picking the right physical and virtual devices.

I am not an "everything needs to be local" guy, and zero issue with editing on the web, but love the faster local piston execution on HE. It is definitely noticeable. IMHO if you want to host webcore on Pi, it can wait if you are happy with how it worked on ST.

Welcome to HE community, and hope your conversion goes as smoothly as mine.

[dnickel]

I just the hub a year ago and WC is amust setup. Do the HPM as suggested earlier and possibly BPT's bundle manger as well (he has a lot of code).
The one thing that made my jump easier was setting up the ST hub as part of hub mesh with HE.

[RELEASE] HubConnect - Share Devices across Multiple Hubs (no longer SmartThings!)

Current Release: 1.6.4 - December 29, 2019 HubConnect 1.x End of Life Notice With version 2.0 about to be released, there will be no further updates to the 1.x codebase and all official support will end on 4-30-2020. HubConnect - A new and improved way to connect and share devices across multiple Hubitat and SmartThings hubs to a central Hubitat hub. HubConnect replaces HubLink/Link to Hub and supports true bi-directional device linkages no matter where the device is physically located; …

This allowed me to have all my ST devices available for pistons. I then migrated devices and their associated pistons a few at a time until I had nothing left on ST.
I had 2 older Fibaro Z-Wave devices with temp probes that would not play with any drivers on HE so the ST hung around for a while until I found a suitable replacement.

[ogiewon]

@dnickel

The one thing that made my jump easier was setting up the ST hub as part of hub mesh with HE.

These days, it is no longer possible to install any new Groovy Apps/DTHs to one's ST account's Groovy IDE. ST has basically made the Groovy IDE Read-Only with respect to code. Soon, they will shut it down completely (target date is 12/31/2022.)

[nrus2222]

I unpaired everything from ST and never looked back!

That brick has already sucked enough of my life away.

[user3509]

Thanks Guys for the info. I cant change over until the new year. As for backing up pistons. Ive read that some use the backup feature in WebCore and back all pistons up at once. I have read other posts that use the Green snapshot of the piston and use the individual code to restore that piston
What is the best way to restore after WebCore is shut down in smartthings

[Equis]

I backed them up and downloaded the .zip file. The ST pistons will still be accessible in your webCoRE dashboard, so I didn't feel the need to write down all the codes. You can upload the zip file, but I found it just as easy to copy the pistons over from ST and change them as I went. Again, you can have the ST piston open in another tab to reference the devices that you need to update in the Hubitat one.

Some pistons did require a little rethinking. I had a ST piston that turned my landscape lights off, but I had to add a loop and wait to ensure that they all got switched off. ST didn't like to turn them all off if I just sent one command. That loop and pause got eliminated on Hubitat.

There was something else that I had to use a wait command to accommodate the cloud-based lag. That just wasn't necessary on Hubitat when things get executed so fast locally.

I had good intentions to move stuff over from ST in groups to minimize, but found that everything was so intertwined that I just decided to go for it. I still tried to prioritize for WAF but I had about 95% of everything paired and pistons running in about 2 days. I have just under 100 devices and 50 active pistons.

[nrus2222]

If I remember right, once you unpair each device from ST it shows up as random coded name on the ST piston too. It is not so useful if you don't remember which device is which in the code.

If you have some more complex pistons, I would recommend saving screenshots/un-anonymized of everything that might be confused before unpairing devices. Restoring from backups worked perfectly. If you have one backup file for all, it will still let you pick one-by-one each piston you want to restore. Just need to remember which device goes where.

[mattias]

@user3509

I cant change over until the new year.

I would also recommend you hold off until the new year. Hubitat just announced that there will be some great news for Webcore users on December 31. Maybe Webcore will become a built-in app. Maybe the dashboard will be hosted on HE. We don’t know yet, but if I were you I would definitely wait until the new year just to avoid the possibility of having to migrate or redo things once the news have been announced.

Edit: From Facebook:

[ogiewon]

@mattias

Hubitat just announced that there will be some great news for Webcore users on December 31. Maybe Webcore will become a built-in app. Maybe the dashboard will be hosted on HE. We don’t know yet, but if I were you I would definitely wait until the new year just to avoid the possibility of having to migrate or redo things once the news have been announced.

I am pretty sure that this is the news (see below.) It is an optional way for existing SmartThings users to use a Hubitat hub to run webCoRE. SmartThings has announced that Groovy SmartApps will stop working on December 31st. Thus, the news from @bobby mentioning that the 31st is not the end.

[RELEASE] HubiThings Replica

A Hubitat application to allow real-time bi-direction updates between Hubitat and SmartThings devices, modes, scenes, weather and push notifications utilizing the SmartThings OAuth Cloud API. Includes the ability to have multiple ST locations with multiple ST hubs replicated to a single Hubitat hub. It is not a requirement to have a ST hub to operate mirror functions to cloud native ST devices. This solution requires a reasonable degree of understanding of both Hubitat and SmartThings. The orig…

[Hatallica]

I guess that I will wait to see. A webCoRE announcement is exciting to me. An ST announcement, not so much. I only have an old Samsung vacuum robot still tied to that system.
On the flip side, I appreciate that it is savvy business for HE to reach ST users and reduce barriers.

[bthrock]

@ogiewon

I am pretty sure that this is the news (see below.) It is an optional way for existing SmartThings users to use a Hubitat hub to run webCoRE.

To be clear, the post you linked to regarding HubiThings Replica is wholly unrelated to that pending announcement. HubiThings Replica is intended for those who need or prefer to use SmartThings in one capacity or another, but want the many additional benefits of using Hubitat—webCoRE and Rule Machine amongst them. Replica simplifies making that connection, so that people no longer have to bend over backwards to make it happen.

It is exciting to hear that something is happening with webCoRE. I’ve always been a big fan, but have occasionally been frustrated with its unresolved quirks.

[ogiewon]

@Hatallica

I guess that I will wait to see.

Didn’t have to wait too long! Here is the official announcement. This is great news for all webCoRE users!

webCoRE: A beautiful story continues beyond December 31st 2022

Born as a community effort on the SmartThings platform in 2016, CoRE was a rule engine that filled the void left behind by Rule Machine. A year later, Adrian Caramaliu, the principal developer of CoRE, added a web interface to the original app maximizing the power of its rules engine. While webCoRE was never allowed to take advantage of the local processing on the SmartThings platform, members of Hubitat community adapted its code to execute locally, on the Hubitat Elevation. The result was tho…

[CAL.hub]

Forgive this OT walk down memory lane. It was interesting, back in the day, to see how Adrian was first scoffed at by the ST community, then revered.

I recall even the eminent @JDRoberts being a skeptic.

[ogiewon]

@CAL.hub

Forgive this OT walk down memory lane. It was interesting, back in the day, to see how Adrian was first scoffed at by the ST community, then revered.

Well, you appear to have taken things completely out of context with the above post. At this particular point in time (2016), Adrian was simply suggesting an enhancement to Rule Machine. Bruce appeared to be genuinely curious to see what Adrian would come up with.

Here is a link to the full discussion between Adrian and Bruce back in 2016, regarding Rule Machine back in the SmartThings days.

Rule machine - as per the app developer, this app is no longer available for...

[CAL.hub]

I wasn't saying Bruce was a skeptic. AFAIK, Bruce and Adrian have always exhibited mutual respect for each other and their projects. But, when Adrian was throwing out ideas for CoRE, there were a lot of skeptics who didn't think he could live up to his boasts.

[bobbyD]

@CAL.hub

see how Adrian was first scoffed at by the ST community

That's because he still hates Mondays...

[bobbyD]

It was awesome seeing both Bruce and Adrian roll up their sleeves and get cracking at making home automation smarter. Their speed of slinging code was fun to watch. I personally learned a lot from both of them.

[marktheknife]

@CAL.hub

I wasn't saying Bruce was a skeptic.

True, your post called out JD specifically as a skeptic.

But you did say Adrian was scoffed at by the ST community followed immediately by a screenshot of an old post from Bruce. In a thread about WebCoRE.

Without Dan’s clarification explaining the context, the post reads as so grossly misleading that it seems deliberate, IMHO, though I acknowledge it apparently was not.

[Hal3]