Took a look at a bunch of threads and discussions – distilled the install of WebCore locally into a blog post so I can redo it again later when I blow something up (accidentally or on purpose …)
I’m noticing something weird with local installation of webcore on my Rpi. The system variables for my time seems to be wrong and is 10 hours ahead of my actual time - I’m in sydney.
Cross checked the Timezone on HE and that was correct. Also checked the date and time on my Rpi and that was correct.
Now all my time based pistons won’t wire correctly. Any ideas on how I can fix this? Is anybody else having the same issue?
I’m an hour off GMT in WC on Hubitat, but the HE hub itself is correct.
Not sure why it’s happening but I’ve just added an offset to all my pistons
Just to be sure, so your webcore install is also not showing the correct time right?
@kayvint @RobinWinbourne Can you post the pistons that don’t work without the offsets? I see where the $time variables are out of sync, but when creating pistons based on time schedules (at least on my end) they still execute at the correct time. I’d like to see the cases where this is failing so I can fix them correctly.
Robin you are SUCH a show off!
It sounds like WebCore is using the user time (localized time) rather than the system clock (UTC). Since Robin is off by 1 and the UK is UTC+1 currently (thank you DST) and Sydney is UTC+10 and …
So, it seems that you either need to have your usertime removed and have the RPi stay in UTC or have webcore use the system clock instead of usertime.
It’s actually the only piston I have running on HE… I use it to turn on a smart outlet and ping my phone as a morning alarm.
My current home is dumb… all my tech is in the home I now rent to tenants and that’s still running on ST.
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.
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.
4th of July sale - 10% off - promo code JULY410C