The State of WebCore on Hubitat

#21

Congrats on the successful move :slight_smile:

#22

Did you ran webCore on HE or you re-write Rules with RM ?

#23

All automation is done using webCoRE. There are a few things I did in RM but that was before I understood the differences between the dashboard.webcore.co and staging.webcore.co.

Right now I am more than please with how webCoRE is functioning. I know RM is powerful but it can’t handle the more complex mathematical / number operations. Unless webCoRE and RM can communicate variables between them, I will develop on the one platform. Besides, it was much easier converting pistons over from SmartThings. All piston run local so I am good with that.

#24

@an39511, What’ s differences between dashboard.webcore.co and staging.webcore.co ? I try to use webCoRe on HE but not stable ! ? !

#25

I don’t know the difference. When I first started I was using dashboard.webcore.co for both SmartThings and HE. It was a pain because I either had to use two computers or logout of the account and log back in under another account. My problem using dashboard.webcore.co was the inability to call pistons from external URLs. Someone suggested I use staging.webcore.co which gave me that ability. I use both now. dashboard.webcore.co for the SmartThings hub and staging.webcore.co for Hubitat. Maybe someone with a better understand can explain the differences.

#26

I don’t experience any stability problems. The only issue I have are occasional devices falling off the network. It was the same situation on SmartThings. Of course that has nothing to do with webCoRE. All I can say is make sure you are running the latest release for both the HE hub and webCore. I have experienced slow UI response from the HE hub but don’t know what causes it, other than I was doing a heck of a lot of device adding and piston conversions during that time. A reboot of the HE hub resolved the problem and now that things are humming along there have been no more hub bog downs

#27

You can access multiple instances of webcore from https://dashboard.webcore.co . Simply select Register Instance from the menu and you enter the register code from the instance of webcore you want to set up and your password. Select Register Instance again for any additional instances you want to use. After that, you can switch from one instance to another from the pull-down menu in the upper left of the screen.

There is also a mobile browser app that is available if you don’t want to use your browser on your desktop or laptop.

I believe https://staging.webcore.co was just a preview/test site set up when they were updating the menu last year.

#28

Staging.webcore.co has some HE specific changes in it.

I hope to finalize a pull request to get this moving toward dashboard.

Some of the ST / HE differences is

  • fuel streams are local on HE (but the dashboard displays them, so the dashboard needs to know about this)
  • external web requests are formatted differently for calling pistons from the outside - this is both the URL formats and how security is maintained.
  • webcore on HE can execute rules, so there are some changes on staging to be able to edit / call rules (IDE changes)

Other than these differences, they are very similar as far as dashboard.

#29

Because of cloud vs local processing capabilities I am planning as well to move from ST to HE and actually I have about 80 pistons in WebCore in ST. Two questions:

  1. Is there a specific version from WebCore to be used in HE?
  2. Have anyone found a way to transfer all cuerrent pistons from WebCore ST to WebCore HE? (Rewriting my 80 pistons would be painful)
#30

Yes, there is a is a webCoRE version for hubitat.found here;
(https://community.hubitat.com/t/webcore-for-hubitat-updates/11967)

I have a little over sixty pistons. What I did was back them all up into a file and then imported them into the new platform however, each piston has to be edited with the names of all the new devices on the new platform. It may sound bad but it took me less than a day to get them all converted. Depending on the complexity of your piston you may want to take snapshots of all your pistons before converting, that way you can see which devices were used. For the most part you probably won’t need them for reference but its a nice thing to have when you need it.

#31

This is great, it looks like there is bo reason to stay in ST now that WebCore works well in HE. I will definitely migrate. Do you know who is maintaining WebCore? I heard that the guy who originally developed it is now and ST employee and not touching anymore WebCore

#32

I assume it is the person who made the post in my previous link, but I am not totally sure. I also don’t know about the original webCoRE developer now working for SmartThings. If that is true it would be very good for them. If it wasn’t for webCoRE SmartThings wouldn’t be very smart. LOL!

It was stated that the webCoRE project would always be open source so the code is open for anyone that wants to work with it. The current version of webCoRE on Hubitat has a few bugs but I haven’t run into a situation where there isn’t a workaround so even if development stops I still have access to one of the greatest automation tools ever created.

#33

So a year down the line how is WebCore working out for everyone on HE? I’ve read some bad things about HE refusing to support people who use WebCore unless they uninstall it etc as they say it causes critical issues with HE. Has this view now been softened?

It also sounded like the hub was not powerful enough to deal with the more complex WC logic, and this caused huge slow downs to the point where people have bought extra hubs just to host webCoRE. Is this still the case? What was causing these issues?

Many thanks in advance :+1:t2:

#34

After being a year on HE, webCoRE has been fantastic. I run a little over 90 pistons with some pretty complex automations and have no problem whatsoever. Hands down, it runs faster than the SmartThings version.There is a slowdown problem with the HE hub but it is NOT due to webCoRE as the vast majority having slowdowns or hub crashes never installed webCoRE in the first place. To my knowledge nobody has bought extra hubs because webCoRE was causing too much of a load. There are plenty of people running more than one hub but not because of webCoRE.

On the downside, there is no support for webCoRE from the HE staff, which is to be expected. But, I have made at least a dozen support tickets for other problems and the staff does not just point the blame finger at webCoRE. But for the few times HE platform updates caused some issue to webCoRE they do work with nh.schottfam to resolve the problem so there is support, just not to the end user. In fact just a month ago HE did a platform update which caused problems with webCoRE and the HE staff worked with nh.schottfam to resolve the problem quickly (within a day). So I would say the staff’s opposition has dramatically sofend.

nh.schottfam has done so much to improve webCoRE that I tip my hat for all they have done.

#35

I am running two HE hubs and have webcore installed on both. I don’t have many pistons as I ported most to RM. Everything seemed to run fine on webcore, but I thought things might run a bit faster on RM and I wanted the practice of writing RM actions.

I saw no difference in my system by moving my pistons to RM. There is really no downside to using webcore that I see. All my pistons moved from my ST to HE instance with no issues. Once over you can get them running and then take your time and move them in to RM if you need to. It is a tedious process using RM. Too bad they just didn’t embrace webcore it is IMO, a hands down better rule engine.

#36

I do wonder what the future holds for webCoRE once SmartThings has ported to it’s new platform. With the removal of Groovy does that also signal the end of webCoRE on SmartThings? Plus, its been over 8 months since the last release of webCoRE on SmartThings.

It was SmartThings statement more than a year ago about retiring the classic app and Groovy that caused me move move over to Hubitat. A move that I don’t regret. But I am concerned about webCoRE’s webcore.co UI based in the cloud and what happens after the SmartThings transsion. Does webcore.co carry on as normal, servicing Hubitat users only? Are there enough users on Hubitat to warrant it’s continuation? I’ve become so accustom to the visual structure of webCoRE that looking at Rule Machine’s UI gives me the willies. Even non-webCoRE users can’t seem to grasp the RM UI.

I realize it is possible to run webCoRE’s UI locally but I am not looking forward to another layer of complexity especially with duplicating all the interconnectivity the current platform provides.

#37

I would like to know the future of webCoRE, also.

I’m planning to jump ship with SmartThings, as well. The stability and support for SmartThings has taken a dive. I’m just waiting on ActionTiles to complete their integration with Hubitat, and then I’m jumping.

#38

webCoRE runs great on Hubitat. Probably a few bugs to still work out, but the community is good at helping. It is MUCH faster in HE on the C7 platform.

I am still a ActionTile supporter, but this next release of SharpTools in beta really is bringing a lot of the UI shine to that product - and it already supports both ST and HE seamlessly. The yearly subscription has a lot of people turned away, but a least the support forum is active with real conversation unlike the ‘we don’t do that’ that was present on the AT forum.

One curious and surprising thing with SharpTools. I really don’t have need virtual switches to make attribute changes on things like I did with ActionTiles. The rules engine with SharpTools allows you todo that directly in the platform.

IMHO.