So I stayed back at 1.1.1.19 because everything worked. Now, not so much. Huge delays in everything. So, I upgraded to 1.1.3.114 and the same thing. Huge delays in everything. Most of my automations are in webcore. I've updated that. Took forever. Even when trying to reboot this hub. I don't have any other versions to try. I've rebooted ... everything. what else should I try? Feeling a little frustrated.
I have not experienced any of the slowdowns reported in the forums
The only real difference between my systems (I have two) and most people having issues, is that I don’t have webcore installed
Something to think about...
Andy
2 Likes
Contact support@hubitat.com so they can take a look and determine what is bogging your hub down. Personally, I don't use webCoRE as it is a beast of an app. It is essentially an interpreted language on top of an interpreted language (groovy).
2 Likes
I'm only really using webcore for the variables. If we could send variables from webcore to RM, I'd be stoked.
@kilowatts
I'm not sure what you mean.
Which 'variables' are you sending to RM?
Are you talking about custom attributes?
I was having delay problems in Webcore. So I converted all my routines to RM and deleted WC. Everything has been great ever since. I think WC uses too much of HE's memory and processing power. The more devices and routines you have just makes WC slower.
Just remember, everything runs locally on HE. Webcore was running on a big cloud computer in ST.
3 Likes
Well, here's one: andyhawk's circadian lighting piston defines two global variables: @lightLevel, and @colorTemperature. These can be used globally in other pistons to adjust various bulbs.
I'm toying with the idea of sending @lightLevel to a virtual dimmer and somehow being able to capture that state in RM. The colorTemperature isn't a problem, thanks to being able to use it on a timer with the "color pre-staging" option.
@danfox52 - yes, the idea would be to get time-sensitive triggers off WC at the very least, unless something changes. But be aware that webcore automations do NOT process on the cloud. They run locally. It's the dashboard and editing that run in the cloud.
That's what I mean. WC runs on HE. I think it is overwhelming HE. In ST it runs in the cloud.
Ah, didn't realize that. Yes, it's much slower on HE at the moment.
I've been rewriting my webcore pistons into their own apps or converting to RM if possible.
Took a bit of work to really groovy and how to write apps, but now that I'm comfortable doing it, its soooooooo much faster and powerful than webcore.
One more piston to convert and I'll be able to uninstall webcore. Hoping that would ease up on the required resources.
4 Likes
I did the same. Not the apps part but moved everything from webCoRE to RM and everything was great for a while.
Then after an update, could have been 112, everything started to slow down or stop working.
Moved everything back to ST apart from a couple of Simple Lighting rules.
I'm going to leave things on ST for a while to see if people see less issues as time goes on.
I want to use HE as I like the concept but I'm not sure it's quite there yet.
It is still in its infancy as a product so I'm sure they will get things sorted.
1 Like
It's funny that everything ran just fine since the beginning until these past few updates. I'll submit a ticket, but if this is a way to blame it on other apps, which is the reason I came to HE, I'll be less inclined to be a believer. I'm feeling a little frustrated about this whole situation. I didn't mind waiting it out at 19, but now HE has nixed all of my options. Roll backs aren't working any more. Being in IT, I understand that things don't ALWAYS go as planned, but c'mon. Slow down on the hasty updates.
1 Like
I think that is why the Hubitat team are now asking for people to join a beta tester programme
I wasn't particularly blaming webcore - It was just an observation on my part that both my hubs are running fine (even though my test hub gets battered with some really sloppy code sometimes)
I achieve everything I want with a little groovy coding so have not found it necessary to install webcore.
Andy
3 Likes
Personally, I wouldn't want an unsupported app to be the reason they don't develop and improve HE. A lot of people jumped right in with webcore because it was easier than learning RM. I was almost one of them...but in my experience it is always better to do everything natively on a platform and use custom or 3rd party only where absolutely necessary. Frankly, I'm glad I did. Rm takes a bit to wrap your head around, but its powerful (not as powerful as webcore) and I don't have to deal with forcefitting a tool that was not designed to run here.
I hope they find a solution to all your issues but really don't want that to be the focus of the HE staff, who could instead be improving this already powerful system we have.
9 Likes
Second that! I've even resorted to writing my own apps to avoid anything that might cause issues on the hub...assuming my own apps won't! 
I am also trying to stay away from anything cloud-based as much as possible.
I understand the frustration, as I've not yet gone past 1.1.1 until it appears that locks are working fine. But I would rather they get functionality I am interested in going, than wait until they get everything perfectly right.
I wonder why roll-backs aren't working anymore? Would definitely get support involved, as I've always been able to roll back.
2 Likes
It's worth noting there is an influx of ex-ST users here, and ST forums regularly have conversations about Hubitat whenever something goes wrong. webCoRE was written for SmartThings, but now it has an official Hubitat subforum, so clearly there is plenty of desire to make it work for HE from that side. But the creator of webCoRE works for SmartThings now. So put all that in your pipe and smoke it.
Some enterprising software guy should write a translator that translates a Piston into a Groovy app. It's a bit much to be running a high level language interpreter (webCoRE) on top of Groovy. But, the 'code' and 'logic' of a Piston could be directly translated into Groovy. The resulting app would run like lightning compared to running it as a Piston.
So people who like webCoRE as an authoring environment for automations, could write their automation as a Piston, then translate it to a Groovy app, and then install and run the app.
10 Likes
My own 2 cents: I was away on vacation for 10 days while all these updates came out. When I left, I noticed my Life360 presence didn't update, so I had to force Away mode through the dashboard.
Anyway, I returned yesterday and updated to 1.1.3.114. All of a sudden, Life360 is working, my locks are responding better than they ever did in HE, and all seems fine. (I hope I didn't jinx myself here).
2 Likes
You know I defended HE when someone was saying that the developers wanted to force us to use the native apps. The reason I came to HE was because of the versatility and the ability to adapt. If HE isn't going to keep the same ethic then I'm questioning my decision. Welcome 3rd party apps with open arms, but it's obvious that something is not working with the updates, so instead of trying to keep the interface open to
3rd party such as webcore or try to fix what the update broke, you're saying I should completely abandon webcore because it doesn't fit into the plan? People put a lot of time into home automation. They also spend time porting device handlers from ST that HE embraces openly. See the irony here?
3 Likes
