Boot-Time Notification?

[johnmsch]

Got this all setup and ran a test.  Works like a charm.

 

 

Just noticed something very strange.  For the past 8 days, the email notification I get is stuck on "The ISY has been operating for 345 hours since last reboot".  I haven't touched anything having to do with this functionality in months, and I can't see what the problem is.  Any ideas why its stuck?

 

Oh wait, just remembered, I replaced the PLM about a month ago, but up until last week, this was working fine.

[JBanaszak]

Your runtime counter might have stopped during the DST transition. Mine did.

 

 

Sent from my iPhone using Tapatalk

[Teken]

Just noticed something very strange.  For the past 8 days, the email notification I get is stuck on "The ISY has been operating for 345 hours since last reboot".  I haven't touched anything having to do with this functionality in months, and I can't see what the problem is.  Any ideas why its stuck?

 

Oh wait, just remembered, I replaced the PLM about a month ago, but up until last week, this was working fine.

 

 

Your runtime counter might have stopped during the DST transition. Mine did.

 

 

Sent from my iPhone using Tapatalk

 

I think because of the DST issue its best to have an external device to hard reboot the ISY Series Controller during those events. Sometimes I really wish there was a option to schedule a soft reboot in the ISY Series Controller. It would really help solve these unique conditions that come up once in awhile.

 

Moving forward I am going to deploy a hard reset process for all the controllers.

[johnmsch]

Yep jimmyban, that must be it.  Just checked the console and my ISY Uptime program is not running.  I based this program on the example earlier in this thread.  From what I can remember, it always showed in the console as Running 'Else'.  Its now showing as Idle.  Also the Last Run Time, Last Finish Time, and Next Scheduled Run columns are all blank.

 

Anyone know what happened?  Why did the DST change kill that program?

[Teken]

Yep jimmyban, that must be it.  Just checked the console and my ISY Uptime program is not running.  I based this program on the example earlier in this thread.  From what I can remember, it always showed in the console as Running 'Else'.  Its now showing as Idle.  Also the Last Run Time, Last Finish Time, and Next Scheduled Run columns are all blank.

 

Anyone know what happened?  Why did the DST change kill that program?

 

https://forum.universal-devices.com/topic/22830-programs-failed/

[JBanaszak]

For the record, I’m on 4.6.2. Teken, I like your idea. How are you planning to implement the hard reboot?

 

 

Sent from my iPhone using Tapatalk

[Teken]

For the record, I’m on 4.6.2. Teken, I like your idea. How are you planning to implement the hard reboot?

 

 

Sent from my iPhone using Tapatalk

I have a few ideas, a couple are pretty simple but requires a outlay of finances. Assuming you don't already have such devices on hand. The other is something I've toyed with in another small project before as a similar need arose.

 

So the first idea is to use one of eight web enabled remote power switches to cycle power to the ISY Series Controller after DST happens.

 

In my head I'm not sure should we hard reboot X seconds after DST? Or wait much longer like X minutes?

 

Would love the communities feed back of the pros and cons of doing either. On the surface it would seem simple enough to say hard boot X seconds vs X minutes.

 

But these controllers perform lots of important things for me in the home so need to be sure what ever time interval is sound in implementation.

 

The other solution is having a 24.7.365 dedicated computer system that doesn't use DST and always runs that old / new time. It would then run the command to hard reset the ISY Series Controller via the remote web switch.

 

This could be via a cheap $5.00 Pi Zero / $35.00 RPi etc. I have many of these computers running now so it's a matter of creating a script and a schedule to complete that hard reboot sequence.

 

All of the 24.7.365 computer systems already run multiple NTP servers to ensure the time is accurate. I'll need to confirm the two computers that are up and running now are still respecting the new / old time.

 

EDIT: Just confirmed there are two systems I had deployed on purpose to ignore DST are in fact displaying the pre DST time. So this will work perfectly!

 

Some may be wounding what is the difference between the two solutions?

 

Both solutions require a piece of hardware to cycle power. But one solutions assumes the controlling system will change its system time based on DST correctly. The other system doesn't use DST so there is no reliance on it flipping time correctly but still uses NTP servers to ensure accurate time keeping.

 

The latter has one less moving part because it always uses the pre DST time!

 

Now to deploy, test, validate.

 

 

Sent from my iPhone using Tapatalk

[johnmsch]

https://forum.universal-devices.com/topic/22830-programs-failed/

 

Thanks for the link sir.  However, after reading through that thread, I feel like I need to take a shower.

[johnmsch]

I have a few ideas, a couple are pretty simple but requires a outlay of finances. Assuming you don't already have such devices on hand. The other is something I've toyed with in another small project before as a similar need arose.

 

So the first idea is to use one of eight web enabled remote power switches to cycle power to the ISY Series Controller after DST happens.

 

In my head I'm not sure should we hard reboot X seconds after DST? Or wait much longer like X minutes?

 

Would love the communities feed back of the pros and cons of doing either. On the surface it would seem simple enough to say hard boot X seconds vs X minutes.

 

But these controllers perform lots of important things for me in the home so need to be sure what ever time interval is sound in implementation.

 

The other solution is having a 24.7.365 dedicated computer system that doesn't use DST and always runs that old / new time. It would then run the command to hard reset the ISY Series Controller via the remote web switch.

 

This could be via a cheap $5.00 Pi Zero / $35.00 RPi etc. I have many of these computers running now so it's a matter of creating a script and a schedule to complete that hard reboot sequence.

 

All of the 24.7.365 computer systems already run multiple NTP servers to ensure the time is accurate. I'll need to confirm the two computers that are up and running now are still respecting the new / old time.

 

EDIT: Just confirmed there are two systems I had deployed on purpose to ignore DST are in fact displaying the pre DST time. So this will work perfectly!

 

Some may be wounding what is the difference between the two solutions?

 

Both solutions require a piece of hardware to cycle power. But one solutions assumes the controlling system will change its system time based on DST correctly. The other system doesn't use DST so there is no reliance on it flipping time correctly but still uses NTP servers to ensure accurate time keeping.

 

The latter has one less moving part because it always uses the pre DST time!

 

Now to deploy, test, validate.

 

 

Sent from my iPhone using Tapatalk

 

Please keep us posted on your testing!  I'm just going low tech and set a reminder on my iPhone to reboot the ISY when I wake up on Sunday morning after a DST change.

[Teken]

May all you testing not hurt anything!

Matter of fact, I just hope your test tickles.

 

LOL . . .

[Teken]

Please keep us posted on your testing!  I'm just going low tech and set a reminder on my iPhone to reboot the ISY when I wake up on Sunday morning after a DST change.

 

Nothing wrong with low tech at all. 

 

Honestly if I could find a cheap and reliable timer that could just cycle power during that DST roll back that is exactly what I would use. Since these computers are running 24.7.365 already its not costing me anymore money in terms of energy consumption. 

 

I truly envy those who don't respect the whole DST cycle in their region . . .

[MWareman]

I truly envy those who don't respect the whole DST cycle in their region . . .

Just set the timezone of the ISY to UTC and you too can benefit from no daylight savings....

[larryllix]

Nothing wrong with low tech at all. 

 

Honestly if I could find a cheap and reliable timer that could just cycle power during that DST roll back that is exactly what I would use. Since these computers are running 24.7.365 already its not costing me anymore money in terms of energy consumption. 

 

I truly envy those who don't respect the whole DST cycle in their region . . .

Saskatchewan!

 

Yeah, I have often though there must be a cheap plug-in device that can remotely be turned off and then it self times back on without any power. They could be used in many places.

I have an Insteon OnOff module on my router with an ISY algorithm to cycle it, but what could do that for an ISY and PLM? ISY could turn itself off but not back on again.

[G W]

Saskatchewan!

 

Yeah, I have often though there must be a cheap plug-in device that can remotely be turned off and then it self times back on without any power. They could be used in many places.

I have an Insteon OnOff module on my router with an ISY algorithm to cycle it, but what could do that for an ISY and PLM? ISY could turn itself off but not back on again.

Look at https://www.digital-loggers.com/

 

Sent from my SM-G955U1 using Tapatalk

[Teken]

Just set the timezone of the ISY to UTC and you too can benefit from no daylight savings....

 

LOL ~ Tell me more of this idea you have?

[MWareman]

UTC does not have daylight savings, so no arbitrary clock shift twice a year.

 

However, you do mental gymnastics each time you look at times in the admin console....

 

In all reality, ISY should really use UTC internally (so it does not have to mess with any daylight savings change at all) and ‘simply’ render the time to the local timezone for display and triggering events.

[Teken]

UTC does not have daylight savings, so no arbitrary clock shift twice a year.

 

However, you do mental gymnastics each time you look at times in the admin console....

 

In all reality, ISY should really use UTC internally (so it does not have to mess with any daylight savings change at all) and ‘simply’ render the time to the local timezone for display and triggering events.

I was hoping you were going to say something totally different than what I envisioned in my head when I read your initial reply. ☹️

 

As noted in my past reply I've taken a simpler approach and that is to leave two dedicated computer systems that don't use or respect DST.

 

They do however have more than five NTP server & pools being checked to ensure the time is correct. I've never been a fan of trying to convert UTC to local time.

 

If there was a reasonably cheap egg timer of sorts that could be programmed for DST which could cycle power for under $40.00 I'd be all over that!

 

At the moment it looks like a dedicated computer which sends a command to the remote web switch is the expansive solution.

 

EDIT: Does the ISY Series Controller support a soft reboot command? I would think having access to that portion of the API would remove that expensive remote web switch!

 

 

Sent from my iPhone using Tapatalk

[Teken]

After thinking about this for a moment upon reflection a hard boot should be done over a soft boot.

 

There have been too many instances in my environment where a soft boot didn't take or was respected. This was confirmed by the fact a program that monitors and tracks the up time counter never reset along with other variables not going back to its init values.

 

So if there is a soft boot API that's an option for some. But personal experience tells me a hard reboot is the only sure way to start from scratch.

 

 

Sent from my iPhone using Tapatalk

[johnmsch]

In all reality, ISY should really use UTC internally (so it does not have to mess with any daylight savings change at all) and ‘simply’ render the time to the local timezone for display and triggering events.

 

That would indeed be the perfect solution.  Having worked with a few systems over the years that did time-critical things over multiple time zones, that's exactly how they functioned.

 

I'd add that to the list of things that will happen, right after the first flights of a swine air force.

[johnmsch]

Just got bit again by the DST change and my program referenced above sending the same hour count in an email every night at midnight.  Since I suffer from a severe case of CRS, I had to come back to this forum, as I knew I was subscribed to a post about that counter getting stuck.  And yes, here it is.  Time to reboot the ISY.  Problem solved again until the fall.

After scanning through this thread again, I wanted to touch base with you guys to see if anyone came up with a way to get around this problem, or at least found a way to automatically reboot the ISY each time we have DST change.

 

[larryllix]

3 hours ago, johnmsch said:

Just got bit again by the DST change and my program referenced above sending the same hour count in an email every night at midnight.  Since I suffer from a severe case of CRS, I had to come back to this forum, as I knew I was subscribed to a post about that counter getting stuck.  And yes, here it is.  Time to reboot the ISY.  Problem solved again until the fall.

After scanning through this thread again, I wanted to touch base with you guys to see if anyone came up with a way to get around this problem, or at least found a way to automatically reboot the ISY each time we have DST change.

 

No. Please join into Apostolakisl's current thread regarding this.

[johnmsch]

Would someone please point me to that thread?  I can't seem to find it.

 

[larryllix]

3 hours ago, johnmsch said:

Would someone please point me to that thread?  I can't seem to find it.

 

Here you go. Looks like UDI is starting to investigate. Further input may help.

 

[johnmsch]

Thank you sir!