Ever since updating to v0.3.113.20210703_HE I have been having sporadic problems with timed events, specifically with "every" statements where a piston fires at time intervals. Since updating there is a condition (not yet known) that causes pistons to fall out of their time loop and they never restart unless manually kicked.
Whatever this problem is, webCoRE's recovery is not catching it either. Perhaps it is suffering from the same condition that cause pistons to fail. I detect no errors that would indicate there is a problem, however I am now getting occasional "Timeout Error httpRequest" errors on calls made to a local http server that I know is operating properly and has so for many years. I don't know if it's related, but just putting that out there. At this point I have nothing to go on other than returning to a known good version of webCoRE
HPM notified me of a fix update so I ran the install but I never seem to get any new version numbers. Are the fixes there but the ver not being changed?
It has been a day and everything appears to be back to normal. Timed pistons remain firing on their schedule and I am no longer getting http timeouts. Another day or so and I will know for certain if the problem has resolved, but so far, so good.
First, it should be noted that the only part of webCoRE that depends on the cloud is the piston editor. Once created, all pistons run locally on Hubitat. So, the outcome is the same either way, and hosting the editor locally might be more work to both set up and maintain than it is worth--your choice, of course.
If you wanted to try, I'm not aware of any newer guides than the ones in a previous thread on this subject:
Towards the bottom of that first post, you will find guides for setting up the editor on either a "bare" Linux server like Raspberry Pi or inside Docker on any supported OS/hardware combination. As noted in these instructions, you will need to point your Hubitat webCoRE installation to use custom URLs when you're done. Otherwise, there is nothing else to do on the Hubitat side, as Hubitat itself is not capable of hosting the editor on its own (which is why you need some external server--whether it's the cloud editor or one you host locally). But again, execution is ultimately local either way.
I assume this is the fault of the driver author and not WC?
All my virtual monetaries have created log entries.
dev:2852021-07-16 10:04:13.811 errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_bloodtick_Virtual_Momentary_Switch_463.refresh() is applicable for argument types: () values: [] Possible solutions: every(), parse(java.lang.String), every(groovy.lang.Closure), push(), grep() (refresh)
dev:2842021-07-16 10:04:13.737 errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_bloodtick_Virtual_Momentary_Switch_463.refresh() is applicable for argument types: () values: [] Possible solutions: every(), parse(java.lang.String), every(groovy.lang.Closure), push(), grep() (refresh)
dev:2832021-07-16 10:04:13.661 errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_bloodtick_Virtual_Momentary_Switch_463.refresh() is applicable for argument types: () values: [] Possible solutions: every(), parse(java.lang.String), every(groovy.lang.Closure), push(), grep() (refresh)
dev:2822021-07-16 10:04:13.580 errororg.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: user_driver_bloodtick_Virtual_Momentary_Switch_463.refresh() is applicable for argument types: () values: [] Possible solutions: every(), parse(java.lang.String), every(groovy.lang.Closure), push(), grep() (refresh)
UI bug - devices with apostrophes have the apostrophes HTML-encoded in the piston display. For example, a device named "Someone's" will show up as "Someone& #39;s" (without the extra space after the &). I don't know if this affects other special characters.
It appears that Webcore identifies devices by their label but not their name. If the label changes, those devices can no longer be referenced by their old labels. It's nice to allow addressing by label, but we should also be able to reference devices by their names.