I’ve just had a message when I’ve gone in to the WC dashboard asking if I want all my pistons backing up as my account id has changed.
Is this anything todo with the built in WC? I’ve not used it, and am still using the version initially installed via HPM
This is part of the transition effort (in progress)
webCoRE is checking if automatic backups have been done, and tracking the the account ID settings have changed.
It is ok to let things backup again to ensure there are accessible with the current settings.
2 Likes
I'm curious to know if there have been any developments regarding the migration application for transitioning, HE Webcore from the user version to the integrated version.
5 Likes
none yet, I'll chat with Victor more on this, he has been busy with release stuff.
2 Likes
Thanks for the update.
2 Likes
Likewise
1 Like
I second this.
Hello All,
I was having issues with HPM completing the Update of Webcore (specifically... it would time-out upgrading the Webcore Piston App). This has been happening for about a year and I was always able to get it to complete on the 2nd or 3rd try. I tried all the tricks of rebooting the the hub, using repair of App within HPM, etc.
I decided to take the leap and switch to the Built-In version.
This works well but it does take alot of time and steps to get it right and functioning. Below is a summary of advice to do this using the steps discussed above.
-
Don't delete your User version of WebCore until this process is complete and confirmed to be working.
-
I copied all of my Global Variables for the Dashboard using simple copy and paste into a text editor. They will come over all as one long string. I just inserted a return between the semi colon and the @ so that I could have essentially a list of all the Global Variables.
-
When setting up the Built -n Webcore App, be sure to give the App a simple same difference. I called mine WebCore Built-In
-
During the app install, be sure to add all of the devices that you use in all of your User Webcore App. I honestly just added them all with exception of the special devices that are not listed in Actuators, Sensors, or Devices. For the special devices, I only had about 10, so I just made sure those were selected as well.
-
Once the app is installed and it's time to add Pistons, the first step should be to add all of your Global Variables. You will just need the string portion after the @ symbol which is the name of the variable. The app will place the @symbol at the start of the string. Obviously, you will need to select the correct type of Variable. It is very important to get the Global Variables input exactly as they are used in your piston or you will have to track down the differences later.
-
As stated above, when restoring the Pistons into the New App, it will need to be done Piston by Piston. They will come in "Paused". For me, I added all the pistons one by one and completed the next steps below.
-
I had two windows of the Dashboard open in my browser. One was from the User Version of Webcore, and the other from the Built-in version.
-
Piston by Piston, I paused the piston in the User Version, Resumed the piston in the Built-In Version, edited the Built-In Version, and then saved again. The Edit and Save was just to get the App to recognize the Triggers.
-
I did this for all 81 of my Pistons until complete. During the process, I was placing each Piston into the correct user category and allowing the Back-Up feature.
Total time was about 4 hours but worked perfectly.
Hope this helps.
John
Thanks for sharing, I’ve been wondering about doing this myself, although I’ve had no issues with WC through HPM so far.
It reminds. me of the migration I took from smartthings to HE. A couple of points
- Can you not import all pistons in one go? I’m sure I did when I migrated, although the process did seem as though it was working. You had to wait a long time and it wasn’t too clear they were importing.
- Did you have to edit your pistons to reselect all devices? On the ST to HE migration, all devices showed up with placeholder names and the pistons had to be edited to select the correct devices. I took a screen shot of all pistons to ensure I added the correct devices back in.
Have you noticed any differences between the two versions?
Hi @Paul1964
Yes...the import or backed-up pistons is essentially one big task that forces you Piston by Piston once the restore starts.... review the piston when it comes over, then save it if it looks good....then it moves on to the next piston and so on...
As long as you do the part above that I mentioned about adding your devices on the Built-In App initial set-up, the recovered piston (newly installed in the new app) recognizes the devices and it is flawless. Same thing is true for the Global Variables.
I've noticed no differences so far in the User App versus the Built-In. Deleting the User App did result in about 1 MB of less file size when looking at the Hub back-up files.
I think my issue with HPM was the number and complexity of the Pistons I had. It was just too much for the HMP app to update it all and there must be a timer that times out and causes a fatal error.
same issue with the fatal error, looking at the code, it seems like all of the methods (ie: update()) have 300 seconds timeout timers. I updated one on my hubs by obtaining the WebCore piston code from the URL listed in the app code file ( line 67 ish) and it took 435 seconds to update and most importantly, it did save. i have had to do this on all 4 of my hubs for a while now. worst case is 117 pistons on a hub, the case I just measured time to save was only 39 pistons. they are fairly complex pistons. I have often wondered if disabling the pistons might help but it did not.
@user1974 .... Outstanding information. I wonder if we could ask the Programmer of HPM to update the code an allow something like 600 seconds? This does not matter to me anymore as I have made the switch to the Built In Code.
But it could save some headaches for others.
@csteele
Would it be possible to extend the time-out on HPM from 300 to 500-600 seconds? See the last two posts above this one.
Thanks,
John
Yes, it just doesn't 'take' 
@nh.schottfam and I both tried this and got a timeout at 300 seconds. Seems the platform limits the value.
1 Like
i have attempted to alter the timeouts, at first the one seen in the update() to 500 seconds. it did not help. then I altered all of the timeouts (maybe 6 or more) to 500 seconds and had similar WebCore update results (fatal error). a direct update (copy and paste files from github) was able to save the updated files on all 4 of my hubs. one must update all of them (webCore, Piston, Storage etc) or webCore pistons will issue a warning that the child and parent app are of different versions. To me, as i can update and save the github files directly implies that it may not be an obvious platform timeout issue but a package manager issue. i am sure they will resolve this but for now there is a way to accomplish the updates.
Time it out, from when you begin manually importing "webcore_piston.groovy" to after it finishes saving. The first time (no pre-existing code) is faster than an update. I'm not a WebCoRE user but I added it via HPM once and it worked. It was the Update that took too long and failed. I guess deleting 14,000 lines isn't quick
The point is, the platform works fine for the target audience: humans, and the automated function via HPM is stuck with the timeouts allowed. I have not heard back about an increase in the Platform's limit.
Thanks for that, Understood, good explanation. That explains why adding time to the existing HPM timeouts provided no remedy to the fatal error.
Apologies for being uneducated on this. What is meant by “the platform limit”? Is this a Hubitat restriction on an app automated update? Does Hubitat have any limits for the manual method of replacing the code and saving? Or, is the limit related to Groovy apps?
One last question….. to whom should I address a request for a change?
Thanks in advance!
Believe it may be more of a transaction time limit which would have system wide implications. As for your second question, it is being looked at.
Theres an HPM update, that’s changed the timeout to 7 mins, however WC will still not upgrade for me having upgraded HPM & rebooting.
1 Like
