Your webCoRE global @variables in your pistons should work just fine as they are. The only reason to use hub @@variables would be if you'd like to expose or set variables from other hub apps outside of webCoRE.
I've noticed that alot of my pistons are not firing or only part firing on having a look I've found this same error on quite a few of them.
Ive just cleared it from about 45 pistons so far and they now seem to be working again, just wondering if there's a quick way to clear the error from all pistons I have about 150 left to go through???
If you are clearing logs,
there is webcore main command to do this
HE console -> apps -> webcore (main app) ->
this will clear all piston logs (and will reset logging to defaults (ie max logs)
It can take a bit to run, so let it go.
I was getting this today with pistons that were using global variables.
These pistons were failing.
Did an HPM repair and this resolved the issue.
1 Like
Doesn't this option only show when the debug flag in the main app is set? I don't have the option you describe but I vaguely remember seeing it at one point.
1 Like
that is correct, main webcore 'Full' has to be on to see that option.
after you do what you want you can turn it back to your desired level.
3 Likes
Thank you I've just spent the past 30 odd mins going round in circles trying to find it....
1 Like
I'm seeing same issue as @garyburchell .
Yesterday cleared logs and today I'm seeing:
So clearing seems to fix issue at the moment but it doesn't fix the main issue which causes a lot of pistons to not run correctly.
Is there anything that I should do about it and why is that error showing. It seems to occur in pistons with modes or smart home monitor.
My errors have not reappeared, but my pistons are not working properly.
Either not firing or massive delays.
Any way to roll back to before the update?
Not sure if you saw this but I was getting the same.
HPM repair on WC fixed the issue and pistons now firing ok.
I did a repair last night after reading your post, hasn't seemed to help.
You could load a HE backup prior to the update.
I'm getting the "null object on line 6784" errors with the Feb 8 piston release
Rolled back one version to the Feb 7 piston and the error is gone.
So I did a repair with HPM earlier and have been out for a few hours come home and all is good.
I'm not so sure that I did a repair lastnight now I think I did modify.
1 Like
I have noticed a few issues with the last few updates with WebCoRE.
This position has worked for years. In fact, I have brought this over from ST. So, the last week or so this has been intermittent.
I'm getting the following errors.
I'm Currently on
I will try doing a repair; I'm not sure why this started happening.
I also noticed I started getting this error too.
I am also having the same error logs as you and I had done a repair and a pause/resume on that small piston. I am having this error for all pistons.
"Time happens daily at" seems wonky over the past two updates. Below is from one log and I can a provide more info as needed. I have logged out of webCoRE (app and browser), cleared the browser cookies/cache, cleared the HE app data.
+122ms ║║Comparison (time) 26700000 happens_daily_at (time) 82800000 = true (0ms)
I have not observed any other issues with the latest versions.
So a couple of things:
-
first apologies for the issues recently...
-
second, I'm seeing really weird things with GitHub lately.
For example I push a fix, and in the main GitHub page it shows it live
but the raw page, shows an older version of the file.
Of course HPM and any folks updating use the raw file.
I expect this is some caching / timing issue, but I find when I fix something for someone and say try it, they say it does not work....(when either we don't know or it does work but the HPM update did not get it even though it is up)....
This also makes it hard on HPM as if HPM does update with a new config file, it assumes it got the right underlying file (and does not offer future updates), when in fact it may not have gotten to latest file.
6 Likes
I get that Nested Trigger warning now too but I "assumed" it was a new feature trying to help coders from making trigger/condition errors.
I believe that is true,
