webCoRE for Hubitat Updates

@nh.schottfam : I upgraded webCoRE to v0.3.114.20220203_HE today via HPM and my comparisons from http POST requests started failing.

This did work before and is now failing:

Moved from a value comparison to an expression comparison and it works as expected as shown:

updated. needed to log in / out a few times, but eventually statements are working again.


This is fixed in the latest bits.


Just updated my instance from HPM about 20 minutes ago. All seems fine on my end. Did need to logout and back in after the install completed, using chrome. After it logged back in it has been performing well, seems a little snappier even when navigating. Using staging.webcore.co and it has been good. Was able to modify pistons without problems, and even was able to backup all of my pistons too.

1 Like

Sorry but I'm still confused how to update my local installation of webCoRE. I'm still new to all of that but got it working fine (webCoRE on hubitat and locally dashborad on my RPi). Yesterday I updated webCoRE via HPM. If I start the dashboard I now get the following banner on the top

I was happy to get webCoRE running locally but now I struggle how to update the local installation on my RPi.
Is it the right way to update the local installation which @Tony is describing in his post?

You do want to update the files for html/css/js to the latest from the repo for the HE builds (which the early post shows a method of doing this if the cloned the proper repo).

You then want to logout of the webCoRE UI, and login in again.

Also see:

I also run a local server, and I'm having a different problem after doing all of that.

I updated my repo, restarted Apache, logged out, logged back in, and it works on my desktop but not on my phone. When I open a piston from my phone, none of the conditions show any devices, but from my computer, it works fine.

For example, if I have a condition "If Device1's battery changes then...", that shows up fine on my computer, but on my mobile device, it shows as "If then...".

On your mobile device;
logout of webCoRE
clear the cache of whatever browser you are using.
log back on to webCoRE

Thanks @nh.schottfam, I tried it our and it's working now. Such a great work.....

That's exactly what I did. Didn't work.

I just got an update. I did the clear piston caches and I still have the old global variables. Is it normal ?

Same here on my phone.

Now I cleared the cache of the app again and now it seems to work

What do you mean by this?

First I cleared the data with the Android Chrome app. Then I cleared the entire cache of the Chrome app. Which worked for me. Long press the Chrome icon and go to "Storage & cache" and "Clear cache". That helped in combination with logout and re-login.

Hope that helps

1 Like

That worked, thanks.

There is a bug fix update pushed out, to address a NP issue, and a variable access issue (both are intermittent, but have hit a few people).

There is no additional UI changes in this bug fix.

HPM should notify of the update.


Hi @nh.schottfam , hope you are great.

Now I am seeing on the UI a message no my nested IFs. THinking on how I write my pistons, I ask the following:

I have a switch and an IF statement (IF SwitchX is on then) and this switch represent "automation". So I put my entire routine inside that IF and if I want to "disable" the routine I just need to turn OFF that switch and to anable, I turn it ON. What would be a good way of doing this? Am I doing it the right way?

I hit a bug this morning where a while loop that used to end properly ran infinitely. Sample piston below. Does this update fix that issue?

Try changing the outermost "if" statement to an "only when" filter.

you might want to look try:

  • adding the switch is on to each nested if statement (and un-nest the the if statements with 'changes' in them. That would move the trigger comparisons to out level (left to right) vs. nested.
  • extra credit for keeping the trigger comparison first in the ifs that are 'AND'.

You want the if statements with 'changes' in them to be crossed on each execution (so that 'changes' can be tracked). What is currently happening is 'changes' is only tracked when the switch is on, which may sound right, but on first runs after switch becomes on may be wrong...