Patched webCoRE for Hubitat (2018/09/09)

You can ignore it if you'd like, or you can go to the apps page, click the Piston it's talking about and hit done on the settings page. It's to bring awareness that the settings couldn't be created through the child app which can slow down pistons. There is some discussion above about some of these changes in the new firmware.

1 Like

I found one way. As you say hitting the done, but that doesn't seem to be enough. I then edited the piston reporting it, then it stopped. Odd?

Hitting done creates the setting, but the Piston has to run one more time to update it. Hitting save on the Piston speeds that process up but shouldn't be necessary.

1 Like

Great, gotcha! :+1: Thanks.

1 Like

I hit done on the child apps then went back to the piston and ran the test mode and that fixed that error.

1 Like

Hot fix 1.1.3.116 has been released and is reported to fix webcore

I've been working with @chuck.schwer on my theory that the slowdowns were caused by the 120 timeout limit, even though webcore wasn't necessarily hitting those timeout limits in normal operation. I verified that the changes made to webcore around the time of the update and the removal of the blacklisted methods were not causing the slowdowns. On my second hub I was seeing the same slowdowns especially on startup where the dashboard wouldn't load, and events would take 20-30 seconds to process instead of the subsecond range

He sent me a build of 1.1.3 today that had the timeouts disabled and everything worked great! Webcore and the hub stablized within 3 minutes of bootup with no slowdows or errors, and the dashboard loaded correctly. I'm not sure what the next steps are from their side, but in the meantime, until they announce them, the last version of 1.1.2 (right before the time limits were introduced) should run webcore correctly.

2 Likes
1 Like

Whew.

Latest FW seems to be running great... fingers crossed

@jp0550
I know its trivial but getSHMModeName is still not syncing to HE correctly and is showing my house is armed when its not.

All my sensors are working good -- in fact even faster then 1.1.2

I have no pistons that take less then 1 second to complete as I tested the response times. So I have no ideas why a 120 second timeout would even bother webcore.... logically is doesn't fit but maybe it does for some strange reason.

this limit was impacting the webcore app because webcore itself is continuously running?

I never thought of that.... that could very well be the reason as this has never been mentioned.

No, this has nothing to do with it. Webcore is not continuously running in that sense.

Is it possible for a third party app to negatively affect latency for native apps? (Ie: can a webCoRE instance slow down Simple Lighting?)

This is an interesting question. I'm trying to convert most pistons to RM, but there are a couple that I don't expect to ever bring over. So, does the mere existence of webCoRE on the HE slow other HE apps?

Webcore and other apps only run as needed with the same or very similar architecture to smartapps on Smartthings described here.

  • Callbacks like installed, uninstalled, updated
  • Events from other apps, devices, or location
  • At a scheduled time
  • Web service calls like when loading the webcore dashboard.

It's why it's better in hubitat if you want to listen to the same event like a motion sensor, it's better to put them all in one piston so only one of the child apps (the piston) has to run in response.

Webcore is slowest when the hub is rebooted and it has to recompile the app code before running and responding to the event, but at that point it's cached until reboot or recompiled by updating it on the app code page. After that point though it will sit dormant until one of the events above causes it to "wake up"

As far as I've seen, apps will only slow down other apps when they are running at the same time in response to the "wake up" reasons above where they have to complete for finite resources such cpu and disk io. If your pistons aren't responding to events or schedules at the same time as native or other user apps, they shouldn't have an effect.

I'm currently working on streamlining pistons to run faster. A very simple one will take around 350-400ms to run. A lot of that comes from spinning up itself, and then the parent to grab the runtime data, and using things like atomic state. By reducing the size of the piston I'm seeing times around 250ms, so I'll probably update them in the future to not store things like statistics and logs by default so they run quicker.

3 Likes

is it possible that … depending on the number of pistons and devices … while webcore is architecturally meant to run on demand effectively its running always though not continuously? :slight_smile:

def app(){
    log.debug "Start"
    while(true){
       log.debug "Never!"
     }
     log.debug "Please stop..."
}

ha … thats extreme. this two takes its toll:

Event Subscriptions

Name Handler Filter Source
@@webCoRE webCoREHandler true Home (Location)
webCoRE.poll webCoREHandler true Home (Location)