Future Date Email Time Stamp

[Teken]

A few weeks ago I was Alpha testing some new firmware for my energy monitoring system. During the testing stage it was found high REST calls were impacting the ISY Series Controller. Regardless of that fact what happen next really surprised me.

Systematically, all of the Insteon leak sensors declared a value of 2 no other battery operated device had any faults.

This happen several times over the course of a week and rebooting the ISY Series Controller did not solve that issue as noted above. The strange part is the fact the controller was sending out emails listed into the future?!?!

As seen in the image captures here they are dated for 7.6.2021 ~ 5.6.2022 

[KSchex]

Hi Teken, I would really like to know what UDI has to say.  Every computer has it's Achilles' heal.  In this case it maybe the inability to handle the added successive Ethernet interrupts in a short time period.  Just a guess.

[Teken]

30 minutes ago, KSchex said:

Hi Teken, I would really like to know what UDI has to say.  Every computer has it's Achilles' heal.  In this case it maybe the inability to handle the added successive Ethernet interrupts in a short time period.  Just a guess.

Eager to know also considering it defeats the purpose of having a on board RTC which also connects to a NTP Server!

[Michel Kohanim]

Teken, thank you for the report. 

Not sure what you had in mind. i.e. would you like us to speculate or would you like to actually find the root cause? If the latter, please provide a log of all your traffic to ISY and especially those that coincide with these events. Without this information, I can pretty much say "your ISY flew to the future and came back" and there's no proof to the contrary. 

You may also want to check the log and see if the dates are changed in the logs.

With kind regards,
Michel

[Teken]

1 hour ago, Michel Kohanim said:

Teken, thank you for the report. 

Not sure what you had in mind. i.e. would you like us to speculate or would you like to actually find the root cause? If the latter, please provide a log of all your traffic to ISY and especially those that coincide with these events. Without this information, I can pretty much say "your ISY flew to the future and came back" and there's no proof to the contrary. 

You may also want to check the log and see if the dates are changed in the logs.

With kind regards,
Michel

Hi Michel,

I will review the logs but don't suspect they will prove very helpful as my system fills up quite fast due to the energy / weather modules. Even having expanded the logs via Telnet it doesn't seem to offer enough capacity to store those logs if and when needed. The primary reason for this post was to let the team know such an event did happen. Next, was to inquire how and why the system let the time become corrupted.

In my mind it defeats the whole purpose for a on board RTC and NTP if the ISY firmware can just circumvent it. 

Some of the systems I work on have independent and separate clocks which act as watch dogs. Their only role in life is to ensure time keeping is accurate and to compare it to other clocks in the system. If there is ever a discrepancy a flag is thrown and alerts sent out for user review / inspection. I would hope this might be something the team may consider in the future as the ISY Series Controller essentially is a very smart clock that crunches numbers very well.

Just my thoughts on that point . . .

 

[Michel Kohanim]

Thanks Teken.

1. You can increase the log size to whatever you like through telnet (there's a limit based on the size of your SD Card)

2. Something "happened" is meaningless and unactionable. It's even more suspect when it's combined with such conclusions as "defeats the purpose"

3. Your other system that's bombarding ISY must have logs

In short, please give us something we can act on. 

 

With kind regards,

Michel