Patched webCoRE for Hubitat (2018/09/09)

I guess it depends on people's setup. I don't have any variable events in my location event history since all my globals are static. I also can't find where poll events are sent out from the source code so not seeing where those connect.

all globals are shared between pistons and saved in the webcore main app. so not sure what you mean by globals are static?

while i have around 100 pistons on ST … havent looked at the webcore code itself recently … will need to refresh myself on the flow a bit.

Just that the first event subscription you showed "@@webCore" listens to variable changes and send out events. The way I use them (and I'm probably in the minority) is that I set them once a long time ago to group things like inside and outside lights into variables so I don't have to change them all over the place, so they are static in that they aren't changing for me and those events aren't sent out in my setup.

ahh ok.

if i remember correctly the webcore app itself saves global variables and piston data in webcore app every time a piston executes.

if you turn on logging in webcore there is a lot interesting data you will see.

anyways i am going to drop from this topic now. i use webcore and i love webcore. thats the wrap up.

Of course it is. All apps and drivers are sharing common resources: cpu, flash, database, os, etc.

to add to what @bravenel said above … everything is executing locally. HE doesnt depend on the luxury of cloud horsepower. that is by design.

that means your apps get to respond to events without any WAN trip latency. also means all your apps only have a fixed resource bandwidth to live in.

this is not necessarily a pro or a con. what makes it a pro or a con is whats important to you. :slight_smile:

1 Like

@jp0550

I'm having issues with the device selection page on the webCoRE settings. I just updates to the latest code tonight and I noticed devices I had selected disappeared from some of the attributes since I noticed I was getting device null errors on several pistons. Once I add a device on an attribute, on this settings page, it's not displaying what I selected until I hit done and go back into the Devices page again. I completely updated all 5 apps again to be sure with github on the hubitat-patches branch and still seeing this issue.

I was also curious, can a select all option be added when you click on an attribute so all devices are selected when checking this option? I noticed this is an option on IFTTT and Sharptools apps:
image

You might have come across a bug while migrating off the webcore storage app in the latest code. It's not needed in Hubitat and actually looks like it makes things slower from having to spin up the parent and then the child storage app to get the settings.

Do you remember if you updated your webcore app before the storage app? It might have tried to migrate you off before having the code to do so. I've added a setting that should prevent that in the future, and added that setting you asked for above for being able to toggle all devices. It's the first category now: "Which devices"

Please let me know if things seem quicker all around, the latest changes have some performance improvements. The fastest piston times I was seeing are now around 250ms (for a very simple piston) vs 350-400ms. I was even seeing some faster times in Hubitat than in ST while testing a Wake on Lan piston :open_mouth:

@bfara83 I see what you mean about the device attribute. I'll see what I can do about getting it fixed.

1 Like

Another thing i noticed when migrating all my ST pistons over to HE. The 'time' attribute for variables, for a lack of in depth understanding, is not working like how it should.

I'm pulling some information from IFTTT - the time field. Over on ST, the time comes up correctly, but on HE it doesn't seem so. Here is what i have on ST. The time is supposed to be 4pm - which is correct:-

Over on HE, it's a little messed up and it keeps changing:-

In my very rudimentary understanding of all this, i believe on ST, it is able to understand a time in text format, where as on HE's version it doesn't.

The original entry for {iftttTime} is "August 28, 2018 at 04:00PM" and is set as a 'string'.

Is there a possible fix?

I did update the storage app after the WebCoRE app . I'll check out the new update tomorrow and let you know how everything is working and check the speed of pistons executing.

I'm seeing this in my pistons.
I do what the statement says but it makes no difference.
Any ideas?

1 Like

Open your Piston from the Hubitat UI, then click "Done". After next execution, this should stop.

2 Likes

I've already done that on a number of pistons but it doesn't seem to have any effect.
EDIT:Having said that one I installed last night is not getting the error. Hmmm. Will delve further.
EDIT:OK I see what's happening. I open up in UI and devs are not populated. Click done go back to piston and the error code appears again. Go to UI and devs are now populated. No error.
Should have investigated further first.
Thanks for the response.

1 Like

Good catch!

timeToday in Smartthings is a little more forgiving with the input, and it was erroring out in Webcore causing it just to return the current time.

If you're already at latest you can pull in webcore-piston.groovy and it should be fixed now.

I'm cleaning up the input a little bit now before sending it down to the api method:

private safeTimeToday(dateOrTimeOrString, tz = null){
    if(isHubitat()){
        dateOrTimeOrString = dateOrTimeOrString?.trim() ?: ""
        if(dateOrTimeOrString.toLowerCase().endsWith('am') || dateOrTimeOrString.toLowerCase().endsWith('pm')){
         	dateOrTimeOrString = dateOrTimeOrString[0..-3].trim() 
        }
    }
    return timeToday(dateOrTimeOrString, tz)
}
1 Like

The device selection page for the attributes seems to be working great and the Toggle All On/Off works perfects where it'll select all devices. This was something I always wanted to see on webCoRE since it's so time consuming picking devices on each attribute. So far everything is running quick for me, I haven't noticed any performance issues at all.

1 Like

Did a fix for the issue with global variable values makes its way to the code on github yet?

After the recent issues I decided to move everything back to HE and run the majority of things using around 90 pistons.
Before doing this I had most things running on HE RM.
I have noticed that things run significantly slower on webCoRE than the native HE apps.
I have been through every piston on the HE hub and clicked DONE but this doesn't seem to make much difference for me.
Anyone else seeing noticeable delays when using webCoRE on HE?
PS. I am at the latest version for all the webCoRE apps.

(My guide for timings is a cupboard door opening and a light coming on/off when contact sensor opens/closes).

How are people finding webCoRE vs RM? Is it worth the effort of setting up RPI and installing this?

Can you turn your logging on to full for that piston and post a sample? Having the green snapshot would help as well. It could be the piston itself, or there might be multiple subscriptions to that event slowing it down. If it's simple enough, it might be worth moving over to the simple lighting app as there isn't a lot of overhead for getting it to run there if speed is what you want.

These are my timings with around 50 other pistons running:

+0ms ╔Received event [Closet Contact Sensor].contact = closed with a delay of 85ms
+191ms ║RunTime Analysis CS > 116ms > PS > 56ms > PE > 20ms > CE
+208ms ║Runtime (48681 bytes) successfully initialized in 56ms (v0.3.107.20180806) (207ms)
+210ms ║╔Execution stage started
+215ms ║║Comparison (string) :816f38e28cdd1fd8454ef8a81aaf909f: is_not (string) :80ff8adc87cc6d0d790b1bb31708f282: = true (1ms)
+217ms ║║Condition #8 evaluated true (4ms)
+219ms ║║Condition group #1 evaluated true (state did not change) (6ms)
+222ms ║║Comparison (enum) closed changes = true (1ms)
+224ms ║║Condition #2 evaluated true (3ms)
+228ms ║║Comparison (enum) closed is (string) open = false (1ms)
+230ms ║║Cancelling condition #3's schedules...
+231ms ║║Condition #3 evaluated false (6ms)
+233ms ║║Cancelling condition #1's schedules...
+235ms ║║Condition group #1 evaluated false (state changed) (14ms)
+237ms ║║Cancelling statement #6's schedules...
+256ms ║║Executed physical command [Closet].off() (15ms)
+258ms ║║Executed [Closet].off (17ms)
+261ms ║╚Execution stage complete. (50ms)
+276ms ╚Event processed successfully (275ms)

OK. Here is the piston.
image
And the logs for the door closing. With HE the light is off before the door is fully closed. With webCoRE it is sometimes after the door is closed.
image