This is one piston where i had to ‘adjust’ the time so that it would trigger correctly. This is taken from the same piston. This is what is says’s on ‘Quick Facts’ on when it will next trigger.
The condition to trigger it that i needed to adjust to get it to actually trigger at the correct time, which is 9:30am, Mondays through to Friday.
Another example where is doesn’t work:
$time should have returned 10:24am - which is the correct time.
Also the use of $time and $time24 in expressions returns the wrong data. $now seems to be ok.
I’ll ask again… What time is the code in WebCore using? The system clock or the localized time? Robin is off by 1 hour and @kayvint is off by 10. Both are off by their difference from UTC currently. That seems like more than a coincidence to me.
From what i’m seeing, the time error is only happening on certain conditions and it’s not across the board. For example, if you create a statement for ‘Add Timer’ - that doesn’t work. But if you create a IF block statement, and use time as a virtual device condition, that seems to work. Also referencing time using $now and $time returns very different results.
The issue is that in smartthings the system timezone for the server is UTC and for hubitat, it’s your local timezone. There’s a few places in the code that he compensates for that by creating a date object (which uses the system timezone) with the offset to make it appear to be the right time. But like @kayvint says it’s not used in all places. I know it is in a issue when you use time restrictions, but I’ll need more time to fully understand the logic as it still works in other places like sunrise and sunset or by scheduling at a certain time without restrictions. I don’t want to screw anything up around that as I know it’s caused some issues in the past with things like DST.
@kayvint @Robin I believe I fixed the issue. Can you update your piston app with this code and let me know if it resolves your offset problems?
That was awesome! Looks like it’s fixed. Checked on my end and now the system variables are showing correctly, $time and $time24 is working correctly as well for timer conditions.
Great Stuff!!
4th of July sale - 10% off - promo code JULY410C
https://community.hubitat.com/t/fourth-of-july-sale-10-off/2478/2
Any more beta updates? Webcore itself just updated again and now I am seeing warnings again. 
I’m unable to gain any access to the page yet my single piston is running fine. 
Need to look at the local install and use my Linux server, but having issues cloning, just get 443 errors. Dammit.
Edit:
Access now sorted. Added devices, but changed the DTH and webCoRE didn’t like that change. So removed them from the available devices.
Has anyone figured out how to import a bin code to a local running webcore ? I try it and it gives a error.
Also has anyone figured out how to get the SHM status working for HE and webcore ?
I have SmartTiles 5.3.3 but haven’t been able to port it over, always many issues given. Has anyone been successful ?
I’m late to the party. Can I get an ELI5? Does it means we can keep all of webcore magic while discarding ST entirety and run everything locally?
Might come handy when/if Samsung pushes Smartthings to become less community/dev friendly and more mainstream.
Yes, webcore is essentially the same on both platforms.
Difference comes with the Hubitat app being very basic, the platform is aimed fully at automation and isn’t intended for app control, no device tiles etc.
It’s also missing key things ActionTiles, but may users are using an old version of SmartTiles (but only those that happen to have the old source code, it can’t be shared)
It actually does come with a native dashboard to create your own tiles. Local too, so very low latency between clicking a tile and response. You can also load the dashboard via a cloud link when away from home, so it can serve as a remote app that way.
For those who installed a local webcore dashboard on a pi, is the apache server still usable for other purposes or does the webcore install hog it?
Edit: After some reading I think I will install the wc dashboard on another apache server instance listening on a different port just in case I might need the web server on port 80 in the future.
My attempt at a new instance on a different port failed and I’m too lazy now that it’s the weekend to try it again.
Solution: get another pi when the need arises for a web server 
The good news is I have 4 leak sensors paired now… I think I will give their version of SHM a try for some local goodness.
The requirements for serving up the dashboard should be incredibly minimal because it is just one html page and a few scripts and stylesheets. Once you’ve loaded those once they will stay cached so you’re barely hitting the server at all. It’s a single page app, so despite the browser URL changing, navigating between pistons does not load anything new from your web server. The vast majority of the “work” that happens while you’re browsing the dashboard is communicating with the smart apps.
The only “magic” that apache or any web server provide over just loading the index.html file is path rewriting so that when you refresh the page and load /piston/:8223897348734: directly it serves up the root index.html file (i.e. there is no actual /piston/ path in your web server).
I wouldn’t be surprised if it’s a Hubitat issue. They don’t seem to like webCoRE very much and aren’t doing very much to make it easier to use. They like their god-awful rules machine.
