Bst, gmt?

Has anyone found a way to see when the hub changes from GMT to BST and vice versa ideally in webcore but will happily deal with any way so i can add it to automations.

reason is my Electric supply is on Eco7 and that doesn't keep the same time from GMT to BST so would be easier if i could automate it.

@thebearmay 's Hub Info driver includes a timezone attribute, you could try using that....

1 Like

This stymied me a bit when I converted from ST. WebCoRE on HE basically reports everything in local time whenever converted from raw numeric datetime format - regardless of offset in raw value. I think it is useful in avoiding untriggered/double-triggered events during DST transitions, but was confusing to me. This community pointed me to WebCoRE variable $tzOffset, which does report correct offset to GMT, so can be used to trigger appropriately when local time changes +/- 1 hr seasonally.

ive read what you have said but still abit confused how do you use $tzOffset?

It's a built-in variable in webCoRE that keeps track of the offset between your local time and GMT in coded time format. So during your standard time (GMT) it will be 0, and during your summer time (BST) it will be some number.

I'm in US PST time zone, and if I enter "formatDuration($tzOffset)" into a webCoRE evaluation console below the piston, I get: "ยปยปยป (string) -08:00:00", I am currently 8 hrs behind your GMT here. During my summer time (PDT), I jump forward an hr (closer to GMT), and this expression should give me -07:00:00 (7 hrs behind GMT).

I think yours should change from 0 to +1 hr when you change from GMT to BST. It should give you 3600000 (integer ~ milliseconds) during BST and 0 during GMT in datetime format, if you don't use a function to convert it to a more readable time.

In any webCoRE condition you can select expression, and enter formatDuration($tzOffset) as part of your expression to get the text string time version, or just select variable and get the integer version. You can always play around with your expressions in evaluation console to see what works.

Hope it helps. Cheers!

BTW, might get more eyes on this specific type of query regarding webCoRE at:

(at least until HE fully assimilates it into this forum).

1 Like

that does help i think ive change my piston to what i think is right, as they say The proof is in the pudding.

Yes, it should work. I use a very similar statement to have a particular blind tilt closed and open at the same "solar" times - when the suns angle's glare is annoying through this window:

image

It has the effect of always executing at the same time relative to GMT, regardless of local DST change. I assume that is also what you are doing.

I didn't realize at the time I wrote it, but I think it should also work with just "time("##:##")+$tzOffset", because $tzOffset is already in msec, so doesn't need the time() function to convert it, but fortunately the function is smart enough to recognize it and act appropriately.

1 Like

Download the Hubitat app