webCoRE built-in on Hubitat - Do I need to transition and how?

⚙️ Custom Apps and Drivers webCore
21

@eaton.blumenstein You can install webcore on a local server in your network. Then go there to edit the pistons

2 Likes
22

Yes it has a static IP.
All Unifi networking equipment, no special rules to prevent it from getting out.

It's a pity the update page doesn't say "can't connect to hubitat cloud" :frowning:

23

The issue isn't with your hub having access to the internet. It is unable to resolve the name of the AWS server(s) that Hubitat use.

So make sure it accesses (and can access) reliable domain name servers - 1.1.1.1 and 8.8.8.8 are usually recommended.

24

@SirDale What @aaiyar said. Even if it looks like it has DNS, put the entry in anyway and hit save.

25

Even though it had those DNS, it still didn't work.

I put in the ones from my ISP first (so now there are 6 in the list!) and it finally worked, so thanks for that.

It's a pity you can't see the current network settings without switching to DHCP settings (and of course then you have to switch back).

26

You can with the latest platform release. There's an option to "Override Current DNS Settings".

27

Added them to the Hub Information Driver the other day...

28

I had to sign out of the dashboard and back in again once you have removed the old instance of WebCoRE from the apps code.

29

Updated first note in thread with some more information. Net recommendation does not change, if you already have webCoRE installed, waiting to convert is likely easiest.

4 Likes
30

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

31

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
32

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
33

none yet, I'll chat with Victor more on this, he has been busy with release stuff.

2 Likes
34

Thanks for the update.

2 Likes
35

Likewise

1 Like
36

I second this.

37

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

38

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?

39

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.

40

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.