With the latest update, has anyone noticed big delays in the dashboard?
Have the reported sunrise/sunset issues been fixed in the latest version?
There is a small update today
HPM repair to get it, not forced on everyone.
1 Like
So updating via HPM will now work properly?
Doesn't for me...
1 Like
If I use Update it errors out, but if I do a Repair it finishes without any errors.
My hubs use webCoRE exclusively and my practice is to Disable all pistons in webCoRE settings beforehand removing as much load from my hub as possible. It might work for you, might not
1 Like
I have no idea. I thought HPM does the same thing, they would have to comment...
1 Like
Can't speak for anyone else, but it doesn't matter if I use update or repair. They both fail (times out) on webCoRE Piston. For the past several months, I have had to do all updates/repairs for Piston manually.
3 Likes
Same with me 
. Has any progress been made in fixing Hubtiat + HPM + webCoRE Updates? Does anyone have any insights or updates on when this will be addressed?
It's my understanding (which could be totally wrong) is that HPM fails on webCoRE Piston updates, installs and repairs because of the huge amount of code causing the operation to time out. This is due to a Hubitat platform timeout setting that isn't easily adjusted and may take a lot of effort by the Hubitat team to correct.
In the meantime, although I'd love to have this fixed because using HPM is obviously more convenient, it's not a huge deal to manually accomplish the updates and fixes while the permenant fix is investigated and eventually completed. Of course, this is just my opinion 
Also, you can install the built in version and gradually copy your pistons across from the HPM installed version to the built in version.
The only downside is WC updates are dependant on an HE update and for me, that's OK.
Just another option.
The only problem with that is the people, me for one, have had many bugs found, quickly fixed and tested by the us and the team.
My pistons/Web UI have been fixed but if I go to the buitt-in version it lags behind so they remain broken until HE catches up.
Using staging.webcore.co helps keep some of the fixes.
2 Likes
Yep, everyone's use case is different.
Personally I've never had any issues that needed a 'quick' fix and using built in saves me from having to do any interaction with the app, apart from fine tuning the pistons that are working superbly but I just cannot help myself.
I wholeheartedly echo @dnickel’s sentiments.
While I acknowledge that this perspective might not be backed by scientific data, it’s evident that webCoRE updates have been somewhat infrequent within the Habitat ecosystem. In contrast, the community-installed version has seen a fair share of improvements and fixes.
Let’s remain optimistic and hope for more timely updates from the Habitat team! 
3 Likes
Using the built-in version of webCoRE has frequently been on my mind, but I haven't acted on it because the conversion seems tedious. Right after Hubitat added webCore to the platform, there was discussion regarding a more automated method, but I haven't heard anything since then.
I was waiting to hear about this as well. I only use the graphing capability of webcore, is there any way to pull over graphs with out having to just build them back from scratch?
@nh.schottfam After having been away for a bit, I was finally able to perform a manual update to bring my webCoRE installation up to date. An issue arose immediately with variations of the following construction that I've used without issue for years while traveling.
The scheduler is now ignoring the date and setting the piston to run at the next time the clock hits 5:00 PM. Curiously, it appears to run only once ... not every day at 5 PM. I've tried setting the date & time both manually and with a variable with no success. Thoughts?
