On last fix for the scheduler issue is available. Dated today, and HPM has been updated.
Thx to all for help with reproducing/debugging.
2 Likes
@nh.schottfam- When modifying a name of a piston that is referred to in a webcore script, shouldn’t the modified name be automatically changed in that webcore script?
It should - webCoRE uses hashes of app id's internally.
Ok, that's not happening after this last update for me. I've also noticed that I've got multiple "instances" I've included a screenshot to better explain...
so I suggest
- logout in the webCoRE console
- in HE console(s) go to Apps -> webCoRE -> Settings -> Security -> Clear All security tokens
- done your way out
- clear your browser cache
- login again to webCoRE console
This should not happen again, one time change in this release.
1 Like
It would be good to see some logs (perhaps a private message for privacy).
enable logging on the webcore application (done your way out)
Ensure your password is set in the webcore application
1 Like
Hi @nh.schottfam I can confirm that the latest update has stopped the 'paused' display issue and also new rules are now not displaying 'The piston does not subscribe............ etc..' any more.
Good work and thanks. 
PSA: Updated to Version: 2.2.1.113 So far, no issues with webCoRE...
I just noticed that all of my external URL endpoints are no longer working. When executed I get the normal response "{"result":"OK","timestamp":1591615581628}" but the piston doesn't fire.
The only thing I have changed in the last few days is installed MAKER API but I don't think it is causing a problem because my test hub doesn't have MAKER API installed and I can't get any piston to fire using it's web endpoint either.
Question: Are custom webCoRE endpoints working for you?
Edited: It appears that Hubitat version 2.2.1.113 breaks the endpoints.
Release 2.2.0.132 makes calling the endpoints work again.
Because webCoRE is not an approved app I haven't reached out to support yet.
Thanks - I do suggest contact support, my guess is this was not intentional
This is likely to impact a lot of things global events, etc.
@chuck.schwer It appears location events were broken in the latest firmware update?
Can you tell me more about what is broken?
I see the sendLocation event, and it does show up the the System Events portion of log,
But the subscribed event handler never gets called in the child application based on the event.
I did as you suggested and bobby said that I should reach out to you, which I had already done. Basically they washed there hand of me and leaving the problem up to you to diagnose and report it to the engineers. Can't say that I am surprised. Guess I will stop updating till they fix it. Thanks for all you do, which is a lot!
can you downgrade to the previous firmware version that does not have this problem?
I have provided information to Chuck on how to see the issue. The event is not being delivered in my tests on the newer firmware.
Yes, downgrading to version 2.2.0.132 corrects the problem. The issue comes about on 2.2.1.115
This should be fixed in latest release posted today. Thx to @chuck.schwer for looking into this with me.
4 Likes
Is anyone having issues with seeing "history" within the tiles in "dashboards?" It seems really flaky- some have history and others don't.
New release posted:
Further optimizations to help improve JVM performance on HE.
- Primarily reduction in heap variables and further code optimizations
- change to support decode64 for binary data returned on an http call due to HE api changes
- Added further time parsing based on common webCoRE issue(s)
- periods in meridians
- Unix time in seconds (vs ms).
- updated to support much larger pistons > 20 chunks
2 Likes
Updated just now from February version - couldn't open any of the pistons - getting "Sorry, an error occurred while retrieving the piston data." error. Glad that I've made dump before upgrading!
