Thanks for the example 
I thought about trying an expression but didn't know the correct syntax.
I would still prefer to see Offset added to the UI like it is in other actions (and also have it display as an offset in the piston viewer). But its nice to have a temporary work-around until the UI can be updated
Hello,
Has anyone else seen Webcore not update the time for daylight savings time? My HE seems to have the correct time in hub information, but Webcore still shows pistons scheduled to fire with their countdown timer to a time each day an hour behind.
Any ideas on if there’s a clock setting I missed?
Thanks,
Jonathan
It would be good to see your piston / settings (likely in a private message).
WebCoRE gathers current time, sunrise, sunset from HE, and printing out current times is also handled by HE/JVM.
In the private message, please share your HE versions, webcore versions, and a description/screen shots of where you are seeing incorrect behavior. It would also be good to show the hub settings of HE for time/location (settings -> hub details, and settings -> location and modes)
I'm also having timing issues. I've checked and double checked all my settings. There has got to be something I'm missing.
Same here, 7:50am job is just now executing at 8:50am.
I did a Cleanup and Rebuild Cache, but no change to the scheduling.
I had to Edit and Save my piston to kickstart the time change. But I can't do that on all pistons, wondering what else to do.
I'll share my details in a PM too.
pause / resume should be the same effect. it can be done from the webcore dashboard with a mouse on the three vertical dots on the piston list view of the piston in question (far right side) of the piston in question
It would be good to see in private messages more of what is happening
Something to keep in mind:
If you have multiple 'Every' blocks in a piston, they all do not execute when a single block fires
So if you use multiple Every blocks you might need something to run the entire piston
Two ways to fix this:
The 'then portion of the if' statement can be empty, but it will cause the piston to run start to finish (vs only within one of the every blocks) and would update all every block timers
An easier way to fix this is use if statements instead of 'every' blocks (ie no every blocks)
Only have seen it on pistons that set their next execution time prior to the DST change (i.e. weekday executions set Friday morning for Monday). After they run again they’re correct again.
Seems to be exactly right. One weekday morning in and they’ve all set themselves correctly.
Thanks everyone,
Jonathan
Hi @nh.schottfam
Just a quick question.
When I open up the dashboard I receive this warning in the HE logs every 10 seconds.
Is this expected and therefore nothing to worry about or is there something going on that is not right. I can't say I've noticed it before.
[app:4](http://192.168.0.25/logs#app4)2021-03-20 18:06:09.560 [debug](http://192.168.0.25/installedapp/configure/4)Check size found 20KB response requireDb: (false) caller: dashLoad
[app:4](http://192.168.0.25/logs#app4)2021-03-20 18:05:58.572 [debug](http://192.168.0.25/installedapp/configure/4)Check size found 20KB response requireDb: (false) caller: dashLoad
[app:4](http://192.168.0.25/logs#app4)2021-03-20 18:05:47.554 [debug](http://192.168.0.25/installedapp/configure/4)Check size found 20KB response requireDb: (false) caller: dashLoadSounds like you have debug messages enabled for the main webcore app
That's that sorted then.
Didn't realise it was set to full. Cannot remember activating it but I obviously did.
Thanks and sorry for wasting your time. 
May have come across a typo in the code, possibly someone can confirm:
In the list of triggers for a device, there is a trigger called "changes and stays unchanged" which I believe should be just "stays unchanged".
@nh.schottfam
It appears that a webCoRE update after that change was made has reverted back to the old code not showing the transition value. Its back to looking like this (transition value not displayed)
I haven't been watching the code updates closely, so I don't know exactly when this reverted back, but I see in the current code the line number changed from my previous post back in Feb.
On Line 3479 where it has this:
"Set level to {0}%{1}"
it needs to be this:
"Set level to {0}%{2}{1}"
Can we get this update pushed into the master copy on github so it sticks on future updates? Thanks 
This will be adjusted in next push. I did not see it revert going thru the logs. webcore only recently added the transition time argument HE has.
Today noticed that none of my pistons did not run when I arrived home (mode changed to DAY). Hubitat was running normally and location mode changed when I arrived. So it seems like just wc pistons did not run. There is 3 pistons which usually does their things when mode changes. Is there any known reason for this to happen or anything special I need to check.
There has been some minor updates for Hubitat lately and I have installed all of them. Actually latest update was installed right after wc issue.
Logs, and info from webcore dashboard are the first place to gather data.
There have not been much changes to webcore that might affect this.
What HE FW version are you on?
Hi,
There was nothing special in hubitat logs or in webcore dashboard. At the morning pistons did run normally so it was that specific moment later that nothing happened.
I'm running v0.3.113.
So what is the HE version?
Oh..sorry. HE version is 2.2.6.137.
I suggest you reboot your hub again, and let's watch logs. You may turn on minimum logging on one or more of those pistons that gave trouble so we see what they say.
I'm on 2.2.6.130, but I have not seen lost events.
Download the Hubitat app
