webCoRE for Hubitat Updates

I've seen it before very briefly and I do believe it's an ad like you mentioned.

1 Like

I seem to remember in the dim and distant past, ST days, that the server that hosts webCoRE was paid for by Adrian.
He paid for the server space by hosting adverts.
I have adblock running on my PC and have webCoRE loading almost instantly but having said that I only have 6 pistons.

Hello,

I instinctively went to say no but then I wanted to take it a few steps further and I found something interesting.

Am I running pihole or any other known blockers? No and I confirmed that.

Then I thought, I haven't been seeing ads in webcore on my phone. I validated, I am not receiving ads in webcore on my phone. I went to check on a PC via chrome and I wasn't seeing ads either. Do I have something setup running a blocker in the background that I forgot about? Possibly but that would have to be Chrome specific (which is linked to my phone). My laptop is brand new so I know I've not added anything for that specifically.

Then I thought maybe the ads were my imagination because they're on the webcore forum. Regardless, I wanted a control to test.

I pulled up my microsoft edge browser for the very first time. Went to my hub. Went into webcore by entering the dashboard AND I did it by entering the HE UI. In both circumstances, the piston opened immediately (< 4 seconds). I tried this multiple times and I couldn't believe how fast it was entering my heaviest piston. I don't think I've ever witnessed piston load times that fast and I've been on webcore for years.

So what has this taught me? it's something with chrome. Either chrome itself or a setting I've made, or a blocker. There's definitely something in chrome that webcore doesn't like on my phone and laptop but a brand new installation of microsoft edge runs it better than I realized was possible.

So now that I've come this far, I don't know what's the next thing I can look at to narrow it down (aside from avoiding chrome). I'd like to figure out if this is a setting or something that's causing this problem.

I work for a software company and I pull in obscene amounts of data and I've not noticed delays like this in any of my other workings. My smart home is over 200 devices and is very responsive. It's just webcore in chrome that seems to be having the trouble.

same. Can you try it in edge, please? I just did and I had a completely different experience (better).

Chrome is good for me on my laptop and phone.
Laptop is running 'Adblock' and pistons load within 5 seconds.
Not sure what this tells us apart from your experience is different from mine. :thinking:

I'm running Version 96.0.4664.110 (Official Build) (64-bit)

1 Like

Yeah, that's what I remember also.

Hello,

I've noticed this since I migrated from ST to HE webcore and I've always thought it was wrong but I didn't realize there was somebody actively engaged in maintaining this code so I never reported it.

Here is what I've noticed and has often confused me:

There's a selection for 'is not and stays not' and one directly below it that says 'is now and stays'.

I am suspicious that this is just a typo and the second one should be "is not and stays" either would be a reflection of the word used, hence my confusion.

Can somebody clarify the functionality behind these two and confirm/deny whether it's a typo or if I'm just not understanding these triggers?

1 Like

Edge - perfect.

1 Like

The strings are correct

one is stays_not comparison, and the other is stays comparison.

Because it is a trigger, it has to trigger 'true' to the comparison, and then stay 'true'
for the stated duration

dateTime (time, date) and deltas are Longs (ie an integer).

I bet if you assign one of them to a decimal, you may get the answer you are looking for.

I need to create a simpler test case to see exactly what is going on, above is my hypothesis

1 Like

Thanks for the help earlier today. I changed all of the datetime variables to dynamic and made a new "now" dynamic variable to see what the current date and time are and it's preforming the correct calculations.

1 Like

Sorry I wasn't clear on where my confusion was:
Option 1: is NOT and stays NOT
Option 2: is NOW and stays

Is the word "now" correct?

Great! What do we do now?
awkward pulp fiction GIF

1 Like

No idea.

But for me, using the staging is fine via chrome, my preferred choice.

I've just used and accepted the standard webcore addy through chrome gives a 40 sec delay. Thought nothing of it, until I read this thread.

For now, I'll just stick to chrome/staging. Not sure what's causing the delays, but it's been that way for me from probably day1.

1 Like

The best person I know if they have time would be @ipaterson

2 Likes

lol same here until I stumbled on this thread. But now that I know it can be faster, I want that.

I converted a few pistons to use HE groups and now I get "Device missing from piston" on all the converted pistons. Read the old posts but I didn't really see an answer. I try to substitute the devMasterSwitch with a real device and not a virtual one but I get the same thing now.
Piston seems to work but it shouldn't be trying to subscribe to a device that I am not testing in the code (?)
I did an HPM repair with no change.
I have edited other pistons and saved them and they don't have this error.
Any suggestions?

image
30/12/2021, 11:30:56 +556ms
+60ms ╔Subscribing to devices...
+315ms ║Device missing from piston. Loading all from parent (252ms)
+317ms ║Using Attribute subscription
+323ms ║Using Attribute subscription
+327ms ║Subscribing to Staircase Motion.motion...
+355ms ║Piston utilizes Lux Master...
+356ms ║Piston utilizes Staircase Group...
+366ms ╚Finished subscribing (334ms)

Guessing here, but are all devices in the group also defined to webCoRE?

1 Like

Yes, the devices and the group are shared.

I can’t keep track of this mega thread so I don’t know what I was summoned for here but it looks like maybe something that appears when the dashboard is loading? Might be able to help if someone can get a screen recording to show what you’re describing.