Fix posted for issue with $args.
Please update if you installed the Jan 6th kit.
2 Likes
Just updated and checked it out. Working without any issues as of yet.
Edit: Since I'm checking on all the logging levels of my pistons in an effort to reduce any overhead, is there overhead involved if the Trace option is enabled in a piston? Or is that only taking effect if one is viewing the traced piston on the dashboard?
Trace is really a UI display thing. The piston is gathering these records, and storing them (it is the maxStats or timing stats). This is not that big in state. So I would not worry. The 'big' item now in state is if you have logging enabled, and when you go into a piston in the webcore dashboard, you see a lot of logs.
Also going back to October... I saw that there was an option to set up DarkSky as a weather provider. I've gone through the settings in the Hubitat side of webCoRE to select DarkSky and entered my API key, and had installed the webCoRE Storage app as well, but the $weather variable is still showing null. Is there anything else I'm supposed to do with this? Or am I accessing it incorrectly?
So with latest update - could I start logging some of my piston runs without significant performance implications?
I would not recommend leaving logging on when not actively debugging. Just for comparison, the built-in hubitat drivers all turn debug logging off after 30 minutes. If you'r not going to be looking at them, why waste the resources generating them.
1 Like
It is your call in the end to leave some logging on or not. As mentioned, it is fastest to have logging turned off after you have completed debugging. Note that webcore does maintain trace information even if logging is off for the last execution and history of executions.
Here are some simple performance comparison for a very simple piston:
[38, 15, 14, 20, 14, 23, 17] = ave 20ms. no logging (7 runs)
[37, 35, 20, 25, 22, 28] = 28 ms. logging set to 'minimal' logging (6 runs)
This is right after a reboot, so jvm/JIT has not done much of anything yet, and the system may be settling.
The overhead is state accesses, which are slow in HE (db).
If you ran the above tests longer, they continue to get faster because JVM/JIT does its work, but as state size grows, the db accesses can get longer (or if there are a lot of other apps beating on the db, they compete at the db). The db accesses also show a lot of variability both over short and longer timeframes.
The first access to a newly saved piston (or newly rebooted hub), is a bit longer as there is some initialization that happens, that will not be repeated.
The execution times are actually shorter than listed above, as a piston gets state, runs, then saves state.
A lot of the improvements in webCoRE HE have been dramatic reductions in state size and accesses.
As a comparison, ST typically cannot start piston in these times (much less finish).
- Typical times I see from my account are over 150ms average
- that said, ST generally has faster CPUs, so putting a piston compute bound, ST can go much faster. In general this is not the home automation workload.
- ST can run many more in parallel (they have throttles). HE can run 4 in parallel.
1 Like
I just installed webcore for HE and when I go to the dashboard I see the following:
" There was a problem loading the dashboard data. The data shown below may be outdated; please log out if this problem persists."
I when I click on "New Piston" nothing happens; actually none of the tabs except "register instance" do anything.
The only thing in HE logs are:
2020-01-10 01:46:11.618 pm [debug](http://192.168.1.20/installedapp/configure/129)register resp: 200 using api-us-b.webcore.co:9247
[app:129](http://192.168.1.20/logs#app129)2020-01-10 01:46:11.100 pm [info](http://192.168.1.20/installedapp/configure/129)Updated ran webCoRE v0.3.110.20191009 HE: v0.3.110.20200107_HE
[app:129](http://192.168.1.20/logs#app129)2020-01-10 01:18:52.218 pm [debug](http://192.168.1.20/installedapp/configure/129)register resp: 200 using api-us-b.webcore.co:9247
[app:129](http://192.168.1.20/logs#app129)2020-01-10 01:18:51.688 pm [info](http://192.168.1.20/installedapp/configure/129)Updated ran webCoRE v0.3.110.20191009 HE: v0.3.110.20200107_HE
Some information:
I used to have webcore onfigured with smartthings but my hub died. When I first went to the dashboard I saw my old pistons. I ran the cache clear in webcore HE and I no longer see those pistons (which is not a problem, just trying to provide information).
I have reinstalled webcore a couple of times rebooting the hub each time
Any idea what the problem is?
Thanks
Did you register your new hubitat webcore with your browser? Try giving a distinctive name to your new webcore installation and check if you see it in your browser.
also check that you installed webcore correctly (ie both he webcore.groovy and webcore-piston.groovy and saved them).
Have you recently rebooted your hub? If not, try that. (HE console -> settings -> reboot hub); if so, be sure to give it a few mins to settle after a reboot (it is really busy after a reboot for a few mins).
Thank you for the quick replies. I have rebooted a couple of times. I uninstalled it and gave it a different name. I then went to "Register a Browser" followed the steps. I then got a prompt for the password; which I was not getting earlier. But ultimately the same thing. I even rebooted again and waited a couple of minutes. Attached an screenshot. The top left just says "loading..."
Did you connect your Hubitat to the cloud?
No sure. Are there specific steps I need to take?
Do you see your hub if you go to Hubitat Portal ? If no - follow the instructions to add it to the cloud. My understanding is that webcore UI server will be using hubitat cloud to proxy HTTP requests to your local hub. Otherwise it just won't be able to access hub somewhere in your LAN
Thanks. I do see it there. On the recommendation of @nh.schottfamI tried a different browser and that worked. THanks for all the help.
I had to login as a different user since my other userid reached a limit of posts 
. Wanted to leave a response instead of waiting 20 hours for the limit to be reset.
I have put in the darksky key but I keep getting this error. I do the webcore storage enabled.
2020-02-13 07:01:53.374 pm errorDarkSky http Response Status: 400 error Message: Bad Request
Over and over again.
We resolved this issue by adjusting the location settings for darksky in the webcore app settings.
New Release Feb 24, 2020
- more optimizations and performance improvements
- fixes for flash command
- code reduction
See post 1 in this thread
6 Likes
