The 408 is a sign the webcore server is returning a register error. Not fatal, but not good. I have reported it the the webcore folks.
I am getting these recently too. The odd part is, they are EXACTLY 3 hours apart.
Two of them are only 3 hours and 3 THOUSANDTHS of a second apart, it is that exact.
Incidentally, that is also the setting I have for my recovery to run.
Coincidence? Hmmm....I'm very suspicious.
The frequency has increased now to every 30 minutes. Something in the recent update must have introduced this because this never happened before.
Update:
It appears the frequency increased last night at this time:
Also, the only place the "register resp" appears in the app appears to be in the section dealing with registering the instance of webcore on the webcore servers.
So, my question is, why is this code even needed? I uncommented the debug logging and this is what appears in the logs as the params that are called.
So, the server at webcore.co is what is timing out on us. There are only two times that this method is called in the app. Once when settings are updated and one when cache is rebuilt. So, why can't these be commented out to eliminate this problem? Why do our instances of webcore need to be registered to the webcore servers? I'm not even using their dashboard for piston editing at this point.
I went ahead and commented out the two calls to that method and the method itself and everything still appears to be working correctly. No 408 message. So, it appears that the webcore servers need to be straightened out.
It might just be anecdotal but webCoRE even feels like it is running faster now too. It feels like clicks through the dashboard and through the app itself feel faster than it did yesterday.
I'm kinda stuck right now... I can get into the dashboard, but cannot view or create any pistons, as it is just spinning.
When looking in the log, I see these messages:
It even comes up when trying to create a new piston, so there's nothing smaller than that, I assume?
I might want to try out that beta version that's out there...
When you first open the dashboard, open the smallest piston you have created. That will get the dashboard synced with Hubitat.
1 Like
Ah, thank you... I figured creating a blank piston would be the same as opening a small piston. Unfortunately I couldn't remember which one was a small piston, so I just had to go down the list and try them until I found one that worked. Looks like I'm back in the pistons again!
1 Like
I think I've perfected my Echo / Alexa volume controller pistons! Using Echo Speaks to make announcements, etc... but it was always really annoying when the volume on each Echo was not set appropriately to the time of day (can't hear it during the day if it's still set to volume 20, blasts at night if it's still set on volume 80, etc.). So here's what I came up with:
Basically it'll change the volume global variable whenever the mode changes, then a second piston picks up that global variable change and compares it to each Echo's volume level. If it's different, it tries to set the volume, then checks again to see if it matches.
If it doesn't match, it marks the run as dirty (i.e. one or more of the Echo's didn't take the volume change for some reason), and moves on to the next one. If it makes it through the loop without needing to make any adjustments (or retries!), then it'll exit the while loop. Otherwise, it'll set a 5 minute timer and repeat the process, until all of the Echo's have the desired volume setting.
2 Likes
In addition to the 408 Error, when trying to use the cloud dashboard (dashboard.webcore.co), i get the following error:
Only option appears to be to use a local dashboard.
New release posted:
-
The webcore servers (if you use dashboard.webcore.co) have been updated with a new procedure to upload devices to the IDE. This should remove some of the issues on HE due to the limited http response limitations on HE to the cloud (ie the needing to open a small piston first).
- it also should allow better processing with large number of devices.
- note that devices do not need to be selected multiple times, (ie once you select a device it is available, and it does not need to be selected multiple times)
-
If you run a local webcore server, the your local webcore server must be updated to the new server modules in order to work with this new groovy code release.
-
Other fixes
-
further performance improvements. This is done by further caching, and minimizing state variables.
-
HSM incidents are reported to $incidents, $hsmTripped
-
when running local webcore server, register commands should not be sent the to external webcore servers
-
$weather can be configured to return DarkSky or apiXU (you will need appropriate keys for the service you select. This was added since apiXU moved to a pay for use model
-
improved handling of global and superGlobal variables - reduction of overhead on HE (note this is webCoRE globals and superGlobal variables. HE globals can be used via the appropriate virtual device in webCoRE.
-
by default webCoRE pistons have reduced their logging to the HE Console -> Logs. This can be re-enabled via the HE Console -> Apps -> select a piston and enable "Piston logs are also displayed in HE console logs?" These logs are available in the webCoRE dashboard when viewing a piston (unchanged).
-
Has there been a new release of the Local Dashboard code with the patches for Hubitat like was produced last year?
WebCoRE has updated their server code twice this year in significant ways for HE.
The code should be up to date in repo (this thread). One of the beta testers ran this way during beta.
1 Like
Just updated to the latest release. Everything loaded and saved okay. I rebooted the hub and now I am having problems with a piston using waits. It seems that even though I have a wait for 300 seconds its only waiting 40-50 seconds instead.
This piston gets called from an endpoint every 2 minutes. Each time its called is't supposed to refresh and wait for another 5 minutes. If the piston fails to be called before the timeout it sets a variable the network is down. Once the network comes back and the endpoint can call it again then it resets back to waiting 5 minutes again.
This piston has been running for months with no issues. It properly does what it sets out to do, So i'm not sure what changed to cause problems with it now.
LOGS;
10/11/2019, 8:31:22 AM +209ms
+6ms +Received event [Home].time = 1570797082948 with a delay of -739ms, canQueue: true, calledMyself: false
+36ms ¦RunTime initialize > 35 LockT > 1ms > rtDataT > 3ms > pistonT > 1ms (first state access 31 7 28)
+38ms ¦Runtime (5384 bytes) successfully initialized in 3ms (v0.3.110.20191009_HE)
+42ms ¦+Execution stage started
+60ms ¦¦Executed virtual command setVariable (2ms)
+65ms ¦¦Executed virtual command setState (0ms)
+73ms ¦+Execution stage complete. (31ms)
+78ms ¦Setting up scheduled job for Fri, Oct 11 2019 @ 8:33:22 AM EDT (in 120s), with 1 more job pending
+118ms +Event processed successfully (116ms)
10/11/2019, 8:30:23 AM +2ms
+5ms +Received event [Home].execute = UNKNOWN with a delay of 200ms, canQueue: true, calledMyself: false
+51ms ¦RunTime initialize > 50 LockT > 1ms > rtDataT > 3ms > pistonT > 1ms (first state access 46 6 44)
+54ms ¦Runtime (5366 bytes) successfully initialized in 3ms (v0.3.110.20191009_HE)
+55ms ¦+Execution stage started
+60ms ¦¦Cancelling statement #1's schedules...
+64ms ¦¦Executed virtual command setState (1ms)
+70ms ¦¦Executed virtual command setVariable (1ms)
+73ms ¦¦Cancelling statement #3's schedules...
+79ms ¦¦Executed virtual command wait (1ms)
+82ms ¦¦Requesting a wake up for Fri, Oct 11 2019 @ 8:35:23 AM EDT (in 300s)
+88ms ¦+Execution stage complete. (33ms)
+92ms ¦Setting up scheduled job for Fri, Oct 11 2019 @ 8:31:22 AM EDT (in 59s), with 2 more jobs pending
+114ms +Event processed successfully (112ms)
I just ran this piston successfully
I notice in your logs it says there are other pending jobs 'with 2 more jobs'
Is there other code I'm not seeing?
Did you edit and save this piston since updating?
I have (other code) a piston on SmartThings that calls the piston I posted earlier . Every 2 minutes. There are no processes calling the original piston except the one that is on the SmartThings platform. I have posted that piston below.
I did edit and save the piston. Also rebooted the hub.
Could it be every time the piston is called that instead of canceling the previous wait that its now stacking them?
Any piston that uses a global variable is called every time any piston that uses a global variable is called. Your HE piston has not conditions, only execution, so it will happen any time a global variable is updated by any piston. I would change the implementation to use a direct link to the HE piston from ST. Instead of using the execute Piston URL, I would use a webcore IFTTT execution URL. From the virtual device list, there is an IFTTT device. The cloud version of the link can be built using this template:
http://cloud.hubitat.com/api/HUB_ID/apps/APP#/ifttt/EVENT_NAME?access_token=TOKEN
The items in all caps would have to be replaced. This will prevent the piston from being run unnecessarily.
I put out an update, please install the new webcore-piston.groovy and let me know.
1 Like
This is not the case in HE. Global changes do not wake a piston unless the piston uses it as a trigger.
How does it know if the piston uses that particular global variable as a trigger? Before it had to wake any piston that used a global variable as a trigger. Does it wake the parent app instead now?
