Time expressions evaluate differently in HE WebCoRe?

#1

Greetings. I’ve just moved from ST to HE, and except for a few inconveniences, everything is going great. About 90% of my WebCoRe automations are moved to simple or 5.1 rules, but a few seem more difficult to convert. Of the remaining WebCoRe pistons, all are working, except one.

I have a certain blind that needs to be closed for a certain amount of time during certain months of the year when the sun’s angle is problematic, during a fixed schedule (that does not change with DST).

On ST, this expression worked perfectly:

image

On HE, the expression: evaluates to:

(expression) time(“00:01”)+time($localNow-$utc) »»» (long) 60000,

reporting (long) - whatever that means, and returning time value of just “00:01”, so it just opens at 1 minute after midnight local time. It fails to calculate:

(expression) time($localNow-$utc) »»» (time) 0,

incorrectly returning (time) 0, instead of time difference between local and utc, which calculates correctly in WebCoRe for ST:

(expression) time($localNow-$utc) »»» (time) -25200002

I thought it might just be that HE version doesn’t like negative time value, but

(expression) time($utc-$localNow) »»» (time) -1

also calculates incorrectly.

I know there are other ways to do this, but hoping someone can educate me on why this expression not working the same on HE as it does on ST. Please help.

(Already learned $twc doesn’t exist on HE and had to set up Openweather to set my “it’s cloudy” virtual switch in another rule).

#2

Tagging @E_Sch, maybe he can look at it closer.

#3

There is a variable in HE $tzOffset which will give you the offset from UTC in msecs

You can also use times in UTC if you want an absolute time.

Are you really just trying ($now+60000). (ie adding 1 minute (in msecs) to now?)

or do you want a time like 10:00 AM local time every day? You don’t need these gyrations if you just want 10:00 AM every day…

webcore on HE does not have many of the DST bugs ST has.

the functions addMinutes, hours, seconds, etc will do proper DST adjustments for 24, 23, 25 hour days.

#4

Thank you. I am using it in an expression to trigger an event at one minute past midnight GMT. At my local time, this is when I want it to always trigger regardless of local DST status. It just so happens to be about midnight GMT.

In HE post someone correctly notified me that $localNow incorrectly reports $utc!

It seems time functions in HE all use GMT for numeric values, but formatDateTime() uses timezone information to convert text to string corrected for local $tzOffset.

So, whenever I want to use a calculated time in an expression in HE do I always have to subtract $tzOffset to execute at correct local time instead of GMT?

#5

everything in is in local time zone.

so if you want to do something at 00:01 you could just say

time. happens at 00:01

this will give you 12:01 AM every day

#6

Comparing output of time() and formatdatetime() in ST and HE versions, it seems HE version always expecting local time as input text and always converting to UTC in numeric format, than converting back to local time in output text string. This is different than ST version, but explains why $localNow numeric value is = $utc value. It is quite confusing, but explains how difficulties with DST are avoided in HE version.

I understand how to simply execute at the same local time everyday. That is not my objective. I am controlling a blind to close in the evening just before the sun shines through it, and then to open 1:15 later, after the sun becomes blocked again. The sun doesn’t care about DST, so I was just using this expression to avoid adding additional logic for daylight/standard time.

I think I can use just use $tzOffset in the expression, instead of $localnow-$utc, assuming $tzOffset changes appropriately when DST ends.

Thank you for all your help.

#7

ok, ensure you are on latest webcore on HE via HPM repair.

The changes is offset is getOffset vs. raw as this will do as you want.

#8

Thank you. I ran the repair in HPM.

Maybe stupid question, but why does “cast iron” and web dashboard report ver. as:

$versionv 0.3.114.20220203
$versionHv 0.3.114.20220928_HE

and HPM reports version as:

  • webCoRE
    • webCoRE v1.0.61 (app)
    • webCoRE Fuel Stream v1.0.61 (app)
    • webCoRE Piston v1.0.61 (app)
    • webCoRE Storage v1.0.61 (app)
    • webCoRE Graphs Tile Device v1.0.61 (driver)
    • webCoRE Presence Sensor v1.0.61 (driver)
    • webCoRE Weather v1.0.61 (driver)

Is it normal?

I don’t understand how to use getOffset vs. raw. Any docs or examples you can point me to on this?

Thank you again for helping out a noob.

#9

It seems to work with $tzOffset. Just need to verify after DST ends in Nov.

image
image.png1178×1237 58.1 KB