Daylight Saving Time - AGAIN!

[TinCan782]

Once again Insteon doesn't get daylight saving time correct!
This morning my Hub advanced one hour, a full week before the time change is scheduled (14 March) to happen. Yes, is still shows the correct location, etc.
Last fall, it was a day early.
This time information is readily available; how complicated can it be to get this right?

[eagle77]

Unless I'm missing it (possible), the new app doesn't even seem to have a way to look at what the Hub time is set to. And yes, looking at my Hub using the old app, it has already sprung ahead one hour. Turning on the use DST switch reverts it back to the right time.

[TinCan782]

I have DST enabled; I just disabled it and the time reverted back to the correct time. I'll have to set a reminder to re-enable DST next Saturday night.
Still, we shouldn't have to do that!
I used the new app (Android) for a couple of weeks and went back to the old app.

[markmongold]

This seems to still be an issue a year later from this first post. We have a series of Schedule events that run a cat feeder and for the past two days it did not seem to be working. After digging around I thought about this and set an even to be an hour earlier than the current EST and it triggered. The new iOS app does not have a setting anywhere about DST. The older app can at least check what time the Hub2 clock is set to, and it showed it to have already sprung ahead a week early. Can some one at insteon look into this and at least acknowledge that there is an issue here? Better yet, fix the change over date for DST to match the current regional laws as to when it happens, or at least allow the iOS app to see the hub setting, or current hub time, or disable or enable the setting manually?

[ricketyca]

Well some users get up earlier than others. I was trying to figure out how to word my issue - was it the fact that DST seemed to start a week early for my hub, or that I discovered no way to see what the hub thought the time was on the new Android app (Vn 1.0.3.203) - saying Me Too here solves my dilemma

Surely the app needs an update to show what the current hub date and time are including the timezone name (like EDT or EST). It would also be good to have an option to disable the DST action.

In addition, it would be nice to know why DST seems to be enabled a week early.

[macguyver6940]

Something is definitely whacked! My hub jumped forward a week ago, had to use the old app (android) to discover that, dst was enabled disabled dst and corrected the time. All was well until this morning (Saturday before dst) when the morning scene triggered, waking my wife and I. Now I'M TRIGGERED!
Is insteon even alive out there? Haven't seen any notable updates on the new app for a veeerrrryyy looooooong time, and have never heard any "news updates" on the site or via email. Only ads trying to sell us stuff which they clearly can't control.

[TinCan782]

Something is definitely whacked! My hub jumped forward a week ago, had to use the old app (android) to discover that, dst was enabled disabled dst and corrected the time. All was well until this morning (Saturday before dst) when the morning scene triggered, waking my wife and I. Now I'M TRIGGERED!
Is insteon even alive out there? Haven't seen any notable updates on the new app for a veeerrrryyy looooooong time, and have never heard any "news updates" on the site or via email. Only ads trying to sell us stuff which they clearly can't control.

Just looked at my HUB time (old app) and indeed, it has advanced an hour.
Observe DST has been OFF since last weekend when I turned it off because the time jumped an hour. I was going to turn it back on tonight/tomorrow AM when DST is actually supposed to occur.

I know this DST issue has been going on for many of the years I have been using Insteon. It also occurs with the fall time change as well.
C'mon Insteon. Is it that difficult to get this right? Wonder what is going to happen if/when the twice a year time change is eliminated.

Just out of curiousity, I turned DST back on (time was still one hour advanced) and then turned DST back off and the HUB time went back an hour to the correct time.

[ricketyca]

After the experience last weekend when the Hub decided that DST should take effect, I was not surprised to discover that today (14th March) when Daylight Savings Time was due to take effect. Throughout my house, smart devices knew and adjusted. The device that controls lighting and other schedules through the house (Insteon Hub V2) does not.

Using the 'new' app, it is impossible to see what time the hub thinks it is, but fortunately the Old App still works and assures me that the time had not been changed to accommodate DST overnight.

Resetting the Location for the Hub does resolve it, but this really, really is a very poor situation for a device that is time driven.

As a further affront, the timestamp on my posting shows pre-DST (08:49) , even though my computer has managed to update itself properly.

[TinCan782]

Continuing....the DST problem also affects sunset/sunrise programming.

My porch lights are programmed sunset on, sunrise off. The app displays the times as sunset 6PM; sunrise 6AM (pre-DST) which matches published times for my location.
Sunset (6PM) comes around and the lights do NOT come on; they actually come on one hour later! The HUB time and location are correct.

Early this morning I re-enable Observe DST, the HUB time advances an hour to DST. Sunset/sunrise times now show 7PM/7AM which is correct for DST. 6 AM rolls around and the porch lights turn off...one hour early! I'm waiting to see what happens this evening at sunset.

In the meantime, I have done two things: 1) I power-cycled the HUB and, 2) I re-set the HUB location and saved it even though it correctly displayed Los Angeles.

Frustrating as searching this forum and the Smarthome forum shows discussions of this problem for at least the past five years. Last year the fall DST change occurred one day early; five years ago the spring time change occurred one day early.

We'll see what happens this evening.

Note: Both the Android app (old version) and Windows 10 desktop app show Hub times as well as sunset/sunrise times and agree with each other.

[ricketyca]

Continuing....the DST problem also affects sunset/sunrise programming.

...

Note: Both the Android app (old version) and Windows 10 desktop app show Hub times as well as sunset/sunrise times and agree with each other.

Thanks for mentioning that, but I cannot see sunrise/sunset on the W10 app nor my old Android app. However, the symptoms are common. My sunrise/sunset also misbehaved last week when the first erroneous DST happened.

So fortunately "Ok Google. It's getting dark" works as I had built a activity for when severe cloud and storms make it dark inside the house. I have not found another way to do that automagically with Insteon. I suppose if I added another motion sensor that turned on the things that are needed on in the evening, set it so that it only turned them on when it is dark enough and never turned them off it would work. It is challenging though. Whilst I am generally happy with the Insteon solution, from time to time it seems that devices are no longer supported (my 8 button mini switch for example) and so one never know whether a sensor bought today won't work with the hub app if it is updated.

The mini switch situation (where the Apple app supported it, but Android did not - 'to be added in a future update') reminds me a lot of software that I dealt with in the UK for a major international computer company (as they were at the time). Their financial package did not support Pounds Shillings and Pence and it was planned to be added for about two years until the UK decimalised. Then the restriction was closed "because it was no longer a requirement"

[TinCan782]

Android app v1.9.8 Viewing Sunset/Sunrise times:
In order to view sunset/sunrise times, you need to have something scheduled using them.
I have a scene called "Porchlights" containing devices "front porch" and "back porch".
The scene is scheduled ON at sunset and OFF at sunrise.
The bottom of the screen displays the time. In this case, the times shown are correct. When the action actually occurs is off an hour (since yesterday)!
The screenshots below show the on time at sunset and off time at sunrise.
Screenshot_20210314-113739_INSTEON.jpg image_3048.jpg

[ricketyca]

Android app v1.9.8 Viewing Sunset/Sunrise times:
In order to view sunset/sunrise times, you need to have something scheduled using them.

Thanks a lot - I thought I recalled seeing them before and I do have schedules using them. It worked for me as you suggested and having reset my Location earlier today, I expect that is why they are showing correctly for me

[TinCan782]

Last evening (Sun 3/14), the sunset event occurred at the correct time. This morning the sunrise event occurred at the correct time.!
Glad that this seems to have "corrected" itself.
The issue still remains as to why the HUB's DST change occurred a week early.

[ricketyca]

Last evening (Sun 3/14), the sunset event occurred at the correct time. This morning the sunrise event occurred at the correct time.!
Glad that this seems to have "corrected" itself.
The issue still remains as to why the HUB's DST change occurred a week early.

Well, my sunset event last evening did not occur at the correct time. I needed to manually turn on the lights. I do not know whether the sunrise worked as I was not awake! I did not make any adjustments to my timers or schedules during the day. i did look at the sunrise/sunset times, but did not re-save the schedules using them. In addition a clock-time event for yesterday morning occured one hour later (on the clock) than it should have been. I will post another message shortly as I have some speculation on why the scheduled items behave the way they do. I was going to wait until the evening to see if my hypothesis is correct, but maybe I will post it anyway and see whether it fits what people have seen.

[ricketyca]

My guess about Hub V2 DST etc - (This does not attempt to explain DST changes on 6/7 March)

At midnight every night, a daily schedule is produced and stored using current times. Offsets of the gaps between the schedules are set. Offsets are a practical way to provide time based actions in a computer system as the program gets woken up after a period of time.

As an example my first scheduled action for the day is ‘Goodnight’ that turns off most house lights at 01:30.
On the night of the DST change, the daily schedule was built and the following effects were observed (or not based on sleeping)!

In my area sunrise had been around 6:30am, so the sunrise schedule (Turn off porch lights) was set for 5.5 hours after Goodnight, and my indoor night light was set to turn off 2 hours later.

At 2am the DST change routine ran and changed the clock to 3am. Offsets were not updated

After ‘sleeping’ for 5.5 hours the sunrise scheduled item ran, however it was actually 7:30am. I did not witness this event (still sleeping myself). After another 2 hours, the indoor night light turned off. Actual time 09:30 - I did witness this.

Investigation using the old version of the app, showed that scheduled sunrise/sunset times were correct (showing 07:30am for sunrise), however that was not the time (nor offset) in the hidden daily schedule. The Dusk scene that turns on most house lights schedule also showed that it was to occur at the correct clock time. It would have been set in the daily schedule for 11 hours after the indoor night light turned off. At 19:30 (7:30pm) it was beginning to get dark, but the ‘dusk’ schedule did not run because 11 hours had not yet passed from the last scheduled event.

I expect that today (Monday) all schedules will work as expected because the daily schedule had been built with the latest times and the offsets between them were established using those.

The advantage of using offsets is that systems can readily provide wake-ups based on an elapsed period time. The risk is that if the device is turned off during power on, the daily schedule needs to be checked and the next scheduled event offset calculated for the next wake-up. In addition, when DST becomes active (or inactive in the Autumn), any scheduled item in there will still happen (though maybe not at the correct clock time) because they are triggered by a timer that has elapsed since the previous scheduled item.

I imagine that when we use the app to change a schedule, it goes through and adjusts the daily schedule, recalculating the offsets between items.

Possible Solutions I realise that any solution will need programming changes to the Hub.

A simple solution would be to calculate the offset to the next scheduled item when a scheduled event runs based on the clock time of the scheduled item. If the elapsed time is <0, run the next scheduled item as well.

An alternative would be to recalculate the daily schedule offsets when changing the clock for DST. Care needs to be taken here too in the Spring, to make sure that scheduled items whose offset is now < 1 hour need to be set to zero to run now.

Of course, this is all completely speculative, but if built in a way similar to that which I have describes, would cause the erroneous scheduled events that I have observed

rick