Yesterday after the time change I looked in the android mobile app on my phone to see if I could tell what the clock on my EISY was set to. I couldn't seem to find it anywhere. I just wanted to make sure it was updated.

Is there any way to see the internal clock setting on the EISY that way?

Also, as a former programmer, I'm curious how IoX handles times changes like this, and how they affect programs (currently running or otherwise). I remember a long time ago a company I worked for had to stop their batch processing systems for one hour and then restart them to accommodate the backwards shift in time. Otherwise data timestamps got whacked up if I recall.

Thanks!

If you are at the latest level, go to the portal and open the new eisy-ui and you will see the settings eisy-ui

18 hours ago, IndyUDIuser said:

Yesterday after the time change I looked in the android mobile app on my phone to see if I could tell what the clock on my EISY was set to. I couldn't seem to find it anywhere. I just wanted to make sure it was updated.

Is there any way to see the internal clock setting on the EISY that way?

Also, as a former programmer, I'm curious how IoX handles times changes like this, and how they affect programs (currently running or otherwise). I remember a long time ago a company I worked for had to stop their batch processing systems for one hour and then restart them to accommodate the backwards shift in time. Otherwise data timestamps got whacked up if I recall.

Thanks!

It has not been implemented in UDM, exists in eisy-ui which has remote access: https://forum.universal-devices.com/topic/47042-eisy-ui-is-getting-there-heres-where-we-stand/

I found an indirect way to verify the time. I have a program that sets several variables based on the system date and time, and updates them all day long. I was able to view those variables in UDM and confirm they were set correctly.

Thanks, and good luck with EISY-UI. I have peeked at it but still rely on Admin Console until the forum posts indicate EISY-UI is more ready for prime time.

Using a program that writes the system date and time into variables and then reading those in UDM is a sensible workaround, though it only confirms the hour and minute whenever the program last ran, not the exact clock. Given that eisy-ui exposes the setting and UDM doesn't yet, staying on Admin Console for things like this seems reasonable until the new interface matures. On the DST question, IoX scheduling concerns like programs that fire during the repeated hour are worth checking directly in the program summary, since behavior there matters more than the displayed time.

16 hours ago, IndyUDIuser said:

Thanks, and good luck with EISY-UI. I have peeked at it but still rely on Admin Console until the forum posts indicate EISY-UI is more ready for prime time.

eisy-ui is prime time ready, there are only a small number of things that have not been ported from Admin. There are also new things only available in eisy-ui that could break if edited with the Admin Console.

If using 6.1.2 or greater Admin Console is deprecated. It should only be used for Insteon Advanced configuration or Program Copy to Clipboard.

On 11/9/2026 at 9:39 AM, Javi said:

There are only a small number of things that have not been ported from Admin.

Is the time header going to be one of the ports Javi? I find it pretty handy.

IndyUDIuser's experience matches what I've read about eisy-ui at this point: mostly complete, with a few admin holdouts left. The time header question is fair to raise directly, since whether it lands among the remaining ports is something only the developer can confirm. Until then, the variable-write program keeps the display approximate rather than exact, which seems acceptable for a header glance. Checking DST-affected program behavior in the program summary still strikes me as the more important step, regardless of which interface shows the clock.

18 hours ago, mmb said:

Is the time header going to be one of the ports Javi? I find it pretty handy.

This is in Menu > System > Configuration. May be added to other screens in the future.

3 hours ago, Javi said:

This is in Menu > System > Configuration. May be added to other screens in the future.

Thanks, quite familiar with Configuration - Canadian permanent DL time zones what a headache.

I was thinking more of a persistent header like the AC so when you're preparing a Program that is time dependent you're not having to jump out and see sunrise and sunset times. For example sunrise+1.5hr. Maybe I'm the only one that refers to it.

Just a thought.

21 minutes ago, mmb said:

Thanks, quite familiar with Configuration - Canadian permanent DL time zones what a headache.

Fix coming soon for this, requires firmware upgrade.

21 minutes ago, mmb said:

I was thinking more of a persistent header like the AC so when you're preparing a Program that is time dependent you're not having to jump out and see sunrise and sunset times. For example sunrise+1.5hr. Maybe I'm the only one that refers to it.

Just a thought.

We are still deciding how to implement, might be after some bugs/features of higher importance.

On 11/9/2026 at 1:50 AM, benjaminrobinson said:

Using a program that writes the system date and time into variables and then reading those in UDM is a sensible workaround, though it only confirms the hour and minute whenever the program last ran, not the exact clock. Given that eisy-ui exposes the setting and UDM doesn't yet, staying on Admin Console for things like this seems reasonable until the new interface matures. On the DST question, IoX scheduling concerns like programs that fire during the repeated hour are worth checking directly in the program summary, since behavior there matters more than the displayed time.

To expand on my previous post... Several months ago I was playing around with a few programs that set variables iCurrentDayOfMonth, iCurrentHH (current hour), iCurrentMM (current minute), iCurrentMonth, and iMMDD. These run once a minute. I wanted to use them in other programs, such as ones that are active only on certain times of the year (summer, fall, etc.) This saved me from having to add a lot of IF conditions to cover multiple months. They're not accurate to the second, but close enough. It was an exercise in IoX programming.

Example:

DATTM SetSummertime - [ID 005A][Parent 0028]

If

$iCurrentMonth > 5

And $iCurrentMonth < 10

Then

$sSummerTime = 1

$sSummerTime Init To $sSummerTime

Else

$sSummerTime = 0

$sSummerTime Init To $sSummerTime

This program sets the value of state variable $sSummerTime to 1 (true) between May and September, and 0 (false) otherwise.

DATTM SetDehumidifierSeasonON - [ID 0068][Parent 0028]

If

$iMMDD is 401

Then

$sDehumidifierSeason = 1

$sDehumidifierSeason Init To $sDehumidifierSeason

Send Notification to 'Email jsvend1' content 'Dehumidifier season starting'

Else

- No Actions - (To add one, press 'Action')

This program determines the dehumidifier season runs from April 1 to November 1.

Sets variables appropriately. These are used in other dehumidifier-related programs.

Another program sets it to 0 otherwise, so it can send a different email.

Edited 10 hours ago10 hr by IndyUDIuser