Support Thread for IoX 5.7.0

[Michel Kohanim]

As of right now, everyone with this issue has the correct next schedule time. Do we have anyone that does not? If so, we desperately need access to that system.

With kind regards,
Michel

[oberkc]

My system sunrise/sunset times are off one hour (early), but programs based upon sunrise/sunset are scheduled one hour later (correct time).  Based upon my system, I see no reason to think that this is nothing more than a UI issue.

[GJ Software Products]

@Michel Kohanim  I just reviewed my Next Scheduled times and they all look healthy.

[maxnorth]

I have a slightly different problem.  I have rebooted and all is well.  Datetime on my eISY is correct. But my "DST Reset" program did not run last night (It is intended to restart all the programs that are supposed to run on startup).

That reset program uses, among other things, the system variable "Current Day of Week" to trigger.  (It is supposed to trigger at 1:15 am on a Sunday, which is day 7).  Valid values are 1-7. That variable in my system is currently 0, not 7. The init value is also 0. The program did not trigger.

Other date-related system variables, such as Current Month and Current Day of Month, are correct. But not Day of Week.

This persists even after reboot.  I was going to wait to post until tomorrow, to see if it would change to 1 on Monday, but thought I'd get a head start on it here. I will post an update in the morning.

I don't know if this has been broken for some time, or if it's a DST anomaly.

[ShawnW]

Ok, so I was awake when the time-change happened Saturday night, and was about to go to bed right after. I can confirm that everything was fine Prior to that but at change time I remember seeing the AC have a long window of 'do not unplug,,...etc' but I ignored it. Shortly after I headed to bed but my alarm system would not change status. Went to the door and opened it, nothing happened. Reopened laptop and opened AC and for the FIRST time ever, ALL my programs were disabled!! 

  I thought I had avoided this issue as I did the upgrade to 5.7.0 about 2 days after it came out and after they posted that that problem was fixed. Since I've never had the problem i was very surprised. 

I'm also very surprised to get on the forum and seeing all this talk about 5.7.0.x?? I did not get any notifications that a new firmware was up?? I have a feeling I know why and am not happy about that either (how do you guys plan to go on like this??). 

  Regardless, I have not rebooted in weeks and have been relatively good since installing 5.7.0_1 and not sure how to proceed. Should I upgrade packages NOW or wait for this to happen again? I believe sunrise & sunset time look correct. 
Please advise. THX

Polisy 5.7.0_1
OS V 13.1

[n_sievers]

I have confirmed that although the UI sunrise/sunset times are incorrect, my sunrise/sunset scheduled programs are running at the correct times. 

[Xathros]

Disabled Program still triggering

Hello all.  After the DST issues yesterday and messing around re-enabling all of my normally enabled programs, I've run into a curious situation.  I have a pair of programs that I have disabled and they are still triggering based on the change in state of a state var.  I have enabled/disabled them again and they still trigger.  As a test, I created another simple program that triggers on a state var, disabled it and tested, it does NOT trigger when I change the variable state.

Here is the program that should not be running

Note that it shows as disabled.  I have searched using the find feature for anything that might call this program and everything that references s.DryerRunning and there is nothing else that would trigger this to run. #Washer Notifier-Tracker is also triggering while disabled based on the change in it's state var.  There are no folder conditions present in the Washer-Dryer folder.

Now here is my test program:

This one does not trigger when I set s.test to 1.  This is the behavior I expect from a disabled program.

Here is my version info:

isy-5.7.0_5
Name           : isy
Version        : 5.7.0_5
Installed on   : Mon Nov  6 08:09:02 2023 CST

And to maintain some continuity with the posts above, my Sunrise/Sunset times are correct today!

 

-Xathros

 

[maxnorth]

11 hours ago, maxnorth said:

I have a slightly different problem.  I have rebooted and all is well.  Datetime on my eISY is correct. But my "DST Reset" program did not run last night (It is intended to restart all the programs that are supposed to run on startup).

That reset program uses, among other things, the system variable "Current Day of Week" to trigger.  (It is supposed to trigger at 1:15 am on a Sunday, which is day 7).  Valid values are 1-7. That variable in my system is currently 0, not 7. The init value is also 0. The program did not trigger.

Other date-related system variables, such as Current Month and Current Day of Month, are correct. But not Day of Week.

This persists even after reboot.  I was going to wait to post until tomorrow, to see if it would change to 1 on Monday, but thought I'd get a head start on it here. I will post an update in the morning.

I don't know if this has been broken for some time, or if it's a DST anomaly.

Current Day of Week is 1 this morning, so it is reporting correctly.  Seems like this was just a DST anomaly.  Still seems strange that it would still be at 0 yesterday even after a reboot.

[btreinders]

I can confirm that this morning the sunrise and sunset values are correct.  

One issue I did have was I thought I outsmart it and change to eastern time yesterday.  That did not work out well, it put a a system busy pop up and would never go away.  Had to reboot to get it to eastern and then again to get it back to central time.  

[GSpitale01]

My problem is that the sunrise/sunset times are displayed correctly, but the program schedule run times are off by an hour.

Screenshots attached here - the stated sunset time of 4:52PM is correct, but the program scheduled run time is 6PM.

[Michel Kohanim]

Hello everyone,

We are looking into all these issues:

1. The UI is wrong on the first day after DST end
2. current day of the week is 0 instead of 1
3. Next scheduled run time is 1 hour ahead

@ShawnW,

Please upgrade (Admin Console | Configuration tab | Upgrade Packages).

With kind regards,
Michel

[maxnorth]

10 hours ago, Michel Kohanim said:

Hello everyone,

We are looking into all these issues:

1. The UI is wrong on the first day after DST end
2. current day of the week is 0 instead of 1
3. Next scheduled run time is 1 hour ahead

@ShawnW,

Please upgrade (Admin Console | Configuration tab | Upgrade Packages).

With kind regards,
Michel

Current Day is 0 instead of 7.

[DennisC]

7 hours ago, maxnorth said:

Current Day is 0 instead of 7.

Out of curiosity why 7, Sunday is typically the start of the week and labeled 1?

[johnnyt]

RE: DST change issues

For past several years I've used a web switch to power off ISY at 1:59, wait 2 mins, then power it on. This avoided issues I saw every DST change for years before I implemented that. This year for fun I disabled my web switch call and let things go through. 

1. Programs that are counters, i.e. increment a variable every minute, stop running. This time was no different and is a long standing issue. I suspect it affects all programs that are waiting when the time change occurs but I haven't been awake looking at my AC at 2:00:01 to catch that first hand.

2. I don't remember this from years ago when I would let things run through but this time I ended up with no (i.e. blank) "Last Run Time" and "Last Finish Time" for anything before the time change. This despite IoX having been running for well over a month since last reboot and not seeing any evidence of a restart. There should have still been a ton of programs with last run time going back a month+

Now, full disclosure, I'm still on 5.6.4 but I thought I would mention these issues in case they still exist in 5.7.0 so that maybe they could be fixed too while DST issues are being looked at.

[Illusion]

On 5.7.0_5

Yesterday I replaced a 6 button KPL. Replace of the links worked well, but the PLM had trouble communicating with a distant device to update its links. Process stopped with to be written flags next to that device. Admin console did not close, and programs did not get updated with new device. I had to manually close and reopen AC after some time and then manually edit each program that had any reference to replaced device.

[Illusion]

@johnnyt

5 hours ago, johnnyt said:

For past several years I've used a web switch to power off ISY at 1:59, wait 2 mins, then power it on.

I have had DST time change issues for very nearly my whole time with the ISY (15 years) and your solution is much simpler than my plan of moving to AZ and finding a new job and life. 

[Xathros]

On 11/6/2023 at 9:02 AM, Xathros said:

Disabled Program still triggering

Hello all.  After the DST issues yesterday and messing around re-enabling all of my normally enabled programs, I've run into a curious situation.  I have a pair of programs that I have disabled and they are still triggering based on the change in state of a state var.  I have enabled/disabled them again and they still trigger.  As a test, I created another simple program that triggers on a state var, disabled it and tested, it does NOT trigger when I change the variable state.

Here is the program that should not be running

Note that it shows as disabled.  I have searched using the find feature for anything that might call this program and everything that references s.DryerRunning and there is nothing else that would trigger this to run. #Washer Notifier-Tracker is also triggering while disabled based on the change in it's state var.  There are no folder conditions present in the Washer-Dryer folder.

Now here is my test program:

This one does not trigger when I set s.test to 1.  This is the behavior I expect from a disabled program.

Here is my version info:

isy-5.7.0_5
Name           : isy
Version        : 5.7.0_5
Installed on   : Mon Nov  6 08:09:02 2023 CST

And to maintain some continuity with the posts above, my Sunrise/Sunset times are correct today!

 

-Xathros

 

Hello all,

Please disregard my post (above) about disabled programs running.  After messing with this for a while I finally realized that I had some Alexa routines set up that followed my state variables for the washer and dryer running states.  Life was so much simpler when everything was done on the ISY...  Now with automations set up in ISY, Alexa, Kasa, Smartthings, HomeKit etc it's getting harder to figure out exactly where the point of failure lies when there's a problem.  I should have known it wasn't the ISY/IoX!

🤨

-Xathros

 

 

Edited November 7, 2023 by Xathros

[maxnorth]

12 hours ago, DennisC said:

Out of curiosity why 7, Sunday is typically the start of the week and labeled 1?

Well, what does your system show right now?  It is Tuesday, and mine shows 2.

[DennisC]

1 hour ago, maxnorth said:

Well, what does your system show right now?  It is Tuesday, and mine shows 2.

Correct, with Sunday currently at 0, Monday at 1, Tuesday at 2.

The issue being looked at is why Sunday is 0 instead of 1. I didn't understand why you wanted Sunday to be 7?

[maxnorth]

2 hours ago, DennisC said:

Correct, with Sunday currently at 0, Monday at 1, Tuesday at 2.

The issue being looked at is why Sunday is 0 instead of 1. I didn't understand why you wanted Sunday to be 7?

Because the wiki (https://wiki.universal-devices.com/index.php?title=ISY-99i_Generic_Calendar_Using_Programs_and_Variables) suggests that Sunday is 7 and there is no zero value. But perhaps I am misreading something: 

• "iDay.of.Week starts with 1 on Monday and counts through to 7 on Sunday. This variable is used to cross check the status of the variables against ISY’s internal day of week function so as to alert you if it gets out of sync. You do not need this variable since ISY has this function built-in but you can choose to use it instead of the ISY’s built-in day function and get the same result"