Energy Monitoring - Tracking Run Time

[Teken]

Hello Xathros,

 

I finally have time to add this program to my ISY. I noticed this program is using +=1 in the Integer Variable? There is no such option for this program.

 

Is it possible this is why the system was acting up when I used IS as the operator?

 

If
Status 'Gem Fridge Channel' > 800W


Then
$i.FridgeDefrostCount += 1
$i.FridgeDefrostCount Init To $i.FridgeDefrostCount

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

[Xathros]

Hello Xathros,

 

I finally have time to add this program to my ISY. I noticed this program is using +=1 in the Integer Variable? There is no such option for this program.

 

Is it possible this is why the system was acting up when I used IS as the operator?

 

If

Status 'Gem Fridge Channel' > 800W

 

 

Then

$i.FridgeDefrostCount += 1

$i.FridgeDefrostCount Init To $i.FridgeDefrostCount

 

Else

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

Hi Teken-

 

See:

 

That is certainly a valid statement. 

 

The "+= 1" increments the value of the variable by 1.  Make sure your focus is in the then or else sections when attempting to select this.  Also make sure you are editing a program and not a program folder.  We are using the same technique in the runtime monitor program as well.

 

The "IS" operator is used in place of "=" in the ISY.  Neither of these are an issue.

 

-Xathros

Edited August 8, 2014 by Xathros

[Teken]

Hello Xathros,

 

I am uncertain why this box is giving me so much headaches as of late!   I had to leave and enter the programs tab several times before the options I indicated would appear?!?! 

 

Now, the next problem is that I see the run time monitor is running as the file is solid green, fridge is running. Yet the minutes are not incrementing up as expected?

 

I do see the Autelis / Dash Box pushing updates to the ISY in the very same state variable page. I am going to reboot this box and see what happens in another 40 minutes when the fridge is supposed to kick back in.

[Xathros]

Hello Xathros,

 

I am uncertain why this box is giving me so much headaches as of late!   I had to leave and enter the programs tab several times before the options I indicated would appear?!?! 

 

Now, the next problem is that I see the run time monitor is running as the file is solid green, fridge is running. Yet the minutes are not incrementing up as expected?

 

I do see the Autelis / Dash Box pushing updates to the ISY in the very same state variable page. I am going to reboot this box and see what happens in another 40 minutes when the fridge is supposed to kick back in.

On the variables tab, click the "Refresh Values" button and see if they change.

 

-Xathros

[Teken]

On the variables tab, click the "Refresh Values" button and see if they change.

 

-Xathros

 

Xathros,

 

I rebooted and also selected refresh still no joy. I have replied back to your PM.

[larryllix]

Sounds like more Java problems. This happens to me if I let the Admin Console fall into background processing or go to sleep mode.

 

Perhaps doing a Java cache clear may help this somewhat. It seems until Java gets scrapped this isn't going to go away. I just downgraded back to Java 7 u67 from Java 8 to see if that helps some of the forgetfulness of ISY. Too early to tell yet.

[Teken]

Sounds like more Java problems. This happens to me if I let the Admin Console fall into background processing or go to sleep mode.

 

Perhaps doing a Java cache clear may help this somewhat. It seems until Java gets scrapped this isn't going to go away. I just downgraded back to Java 7 u67 from Java 8 to see if that helps some of the forgetfulness of ISY. Too early to tell yet.

 

No, doubt! I really can't wait for Java to be retired in the future.

[Teken]

Hello Xathros,

 

I have been able to replicate this program for various appliances in the home. So far the program seems solid in terms of how it  works and operates. I do however have a few questions in terms of resolving a few small details I hope you can shed some light on.

 

In the program listed below.

 

How can I obtain the actual run time that exceeds this program? As the notification simply sends out an alert once it meets 45 minutes. This does not actually mean the device has stopped, only that it exceeded the 45 minute limit. I have entered the actual state variable ID in the e-mail alert and surprisingly, it does not return the real time value that exceeds 45 minutes? 

 

If
$s.FridgeRuntimeCycleMins >= 45
And $s.FridgeNotifySuspend is 0

Then
Send Notification to 'YourCell' content 'FridgeCycleTimeExceeded'
$s.FridgeNotifySuspend = 1

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

 

 

Also, below you will noticed the system reset the counters at midnight. I was surprised to see that the minutes for (Cycle Minutes) did not match the (Daily Minutes) for that period?

 

Since this was at the very beginning of the new counter day. Both values should have matched until the next fridge cycle kicked in and the Daily Minutes would have incremented and be higher than the Cycle Minutes.

 

Any insight on that part would be great!

 

 

[Xathros]

Will reply in full later today. Cycle started before midnight and crossed boundary. Daily reset at midnight. Cycle resets at end of cycle and not at midnight. Variable should work in the notification. Needs to be selected from list or hand entered in the correct format for notifications.

[Xathros]

Hi Teken-

 

Sorry for the brief reply yesterday, was out with the family and responding via the small screen.

 

The Runtime variable will be reported by the custom notification as whatever value it has at the time the notification is sent.  The first time it is sent, it will be at the 45 min threshold.  If the cycle continues long enough that alert is repeated, the value will be higher with each repeat.  We are not sending an alert when the cycle ends so unless a cycle ends at the same time that an alert is sent, you won't get a message containing the actual full cycle time.  If that is a requirement, I can work in how to do that but it didn't seem from the initial request to be a requirement.  If you want to know the amount of time that the cycle exceeded the 45 minute threshold, we will need to define another integer variable and do some math to get that value for you:

If
        $s.FridgeRuntimeCycleMins >= 45
    And $s.FridgeNotifySuspend is 0
 
Then
        $i.FridgeCycleExtra  = $s.FridgeRuntimeCycleMins
        $i.FridgeCycleExtra -= 45
        Send Notification to 'YourCell' content 'FridgeCycleTimeExceeded'
        $s.FridgeNotifySuspend  = 1
 
Else
   - No Actions - (To add one, press 'Action')

 

As for the difference between daily and cycle times after midnight, since the cycle time is not time of day dependent, that counter can start before midnight and cross the boundary while the daily gets reset at midnight.  Lets say a cycle starts 10 minutes before midnight and runs for 30 minutes.  At the end of the cycle, the cycle time should be 30 minutes but the daily will only show 20 since it gets reset at midnight crossing.  Make sense?

 

 

 

-Xathros

 

[Teken]

Hi Teken-

 

Sorry for the brief reply yesterday, was out with the family and responding via the small screen.

 

The Runtime variable will be reported by the custom notification as whatever value it has at the time the notification is sent.  The first time it is sent, it will be at the 45 min threshold.  If the cycle continues long enough that alert is repeated, the value will be higher with each repeat.  We are not sending an alert when the cycle ends so unless a cycle ends at the same time that an alert is sent, you won't get a message containing the actual full cycle time.  If that is a requirement, I can work in how to do that but it didn't seem from the initial request to be a requirement.  If you want to know the amount of time that the cycle exceeded the 45 minute threshold, we will need to define another integer variable and do some math to get that value for you:

If
        $s.FridgeRuntimeCycleMins >= 45
    And $s.FridgeNotifySuspend is 0
 
Then
        $i.FridgeCycleExtra  = $s.FridgeRuntimeCycleMins
        $i.FridgeCycleExtra -= 45
        Send Notification to 'YourCell' content 'FridgeCycleTimeExceeded'
        $s.FridgeNotifySuspend  = 1
 
Else
   - No Actions - (To add one, press 'Action')

Screen Shot 2014-08-11 at 9.51.29 AM.jpg

 

As for the difference between daily and cycle times after midnight, since the cycle time is not time of day dependent, that counter can start before midnight and cross the boundary while the daily gets reset at midnight.  Lets say a cycle starts 10 minutes before midnight and runs for 30 minutes.  At the end of the cycle, the cycle time should be 30 minutes but the daily will only show 20 since it gets reset at midnight crossing.  Make sense?

 

 

 

-Xathros

 

Hello Xathros,

 

I will add in a new Integer variable to and modify the existing program with the example you have provided to obtain the actual run time that exceeds the threshold set.

 

What a great little program!

 

I envision using this in many other applications in the not too distant future, awesome!

 

Now, with respect to the daily vs cycle minutes I have watched the system many times since crafting the program. I have observed at midnight the following.

 

- The counters all reset at midnight

 

- The fridge has not been running during that reset period.

 

- Upon the fridge activating both counters for the very first cycle vs daily still does not add up. I have observed an (approx) ten minute difference from the start of a new days cycle being set back to zero.

 

Any insight or guidance would be appreciated, Sir

[Xathros]

Teken-

 

I have reviewed the code and see no reason for the counts to differ with the exception of a run crossing the reset boundary.  I suggest crafing a notification that reports both values and schedule that for right before the reset and again right after so that we can track and compare results.

 

-Xathros

[Teken]

Hello Xathros,

 

OK, so the code has been running for about two days. I have stayed up well past midnight to monitor this program and to validate its operations before deploying it en mass and integrating it into other aspects of the Insteon network.

 

1. It appears some fine tuning to the timing of processing of email was required for me. For what ever reason the same exact (five) programs which are in place now. The only one I care about at the moment did NOT send me any detailed information about run time, duration, etc?

 

I noted there were other (non related) programs timed for midnight to occur. So I have staggered these times from a 30 seconds, to whole minutes, in hopes to see reliable delivery of said tracking data. I have also set the delay to be longer for when the program is supposed to delete and reset the counters, just in case.

 

2. What is a clean and simple (watch dog program) approach to ensure the mail is delivered at midnight to avoid the above situation? As I noted the fridge program ran true (supposedly) that mail was sent. Yet the counter was not reset at all, but at the same time there was a boundary overlap at midnight as the fridge was still running.

 

Therefor have to assume this made the state still true, hence the counters did not get reset. 

 

I manually ran the THEN clause to ensure I received the daily totals via email and also reset the counters which seemed to take awhile to process this simple request? I am hoping the time shift / off set I have entered for the other programs will resolve this apparent freeze and miss firing of email.

 

Any insight would be appreciated! 

Edited August 14, 2014 by Teken

[Teken]

Does anyone see any problems with this code at all??   The ISY has been running like a utter crap for months now. 

[Michel Kohanim]

Hi Teken,

 

The first question is why would you think this specific program contributes to ISY performance issues? As I remember correctly, you have 100s of other programs.

 

Before jumping to any conclusions, I strongly suggest figuring out why you have performance problems with ISY. The first thing I would do is to disable all programs related to GEM. If performance gets better, then we know the problem is with those programs and at which time we can address accordingly.

 

If not, then we'll have to figure out what is the culprit.

 

With kind regards,

Michel

[Xathros]

Hello Xathros,

 

OK, so the code has been running for about two days. I have stayed up well past midnight to monitor this program and to validate its operations before deploying it en mass and integrating it into other aspects of the Insteon network.

 

1. It appears some fine tuning to the timing of processing of email was required for me. For what ever reason the same exact (five) programs which are in place now. The only one I care about at the moment did NOT send me any detailed information about run time, duration, etc?

 

I noted there were other (non related) programs timed for midnight to occur. So I have staggered these times from a 30 seconds, to whole minutes, in hopes to see reliable delivery of said tracking data. I have also set the delay to be longer for when the program is supposed to delete and reset the counters, just in case.

 

2. What is a clean and simple (watch dog program) approach to ensure the mail is delivered at midnight to avoid the above situation? As I noted the fridge program ran true (supposedly) that mail was sent. Yet the counter was not reset at all, but at the same time there was a boundary overlap at midnight as the fridge was still running.

 

Therefor have to assume this made the state still true, hence the counters did not get reset. 

 

I manually ran the THEN clause to ensure I received the daily totals via email and also reset the counters which seemed to take awhile to process this simple request? I am hoping the time shift / off set I have entered for the other programs will resolve this apparent freeze and miss firing of email.

 

Any insight would be appreciated! 

Hi Teken-

 

Sorry for the delay, I'm just getting back from vacation.  Are you still having issues with this or did you get the timing worked out?

 

-Xathros

[Teken]

Hi Teken,

 

The first question is why would you think this specific program contributes to ISY performance issues? As I remember correctly, you have 100s of other programs.

 

Before jumping to any conclusions, I strongly suggest figuring out why you have performance problems with ISY. The first thing I would do is to disable all programs related to GEM. If performance gets better, then we know the problem is with those programs and at which time we can address accordingly.

 

If not, then we'll have to figure out what is the culprit.

 

With kind regards,

Michel

 

Hello Michel,

 

As I see it now, there are several things at play here.

 

1. The ISY continues to freeze meaning I will see the system clock stop ticking away. From, the UI stoping from working and will not accept any user input.

 

When this happens a CTRL ALT DELETE is the only method to kill the UI.

 

2. If the above is not true, then the next behavior I see is where all energy readings stop coming into the ISY. As indicated in my correspondence to you two days ago all energy nodes were blank.

 

Nothing was done to the system at all as it was (somewhat) working even though it often stops populating the energy readings. As you noted the Zigbee connection had to be re initiated to restore the connection.

 

After a grueling 16 hours I was finally able to bring the system back on line and see energy readings.

 

3. Now, with respect to why do I think some of these programs may be impacting the ISY? Because with the assistance of Xathros we were able to determine one of the temperature programs were causing some sort of infinite loop. We have since redone the programs and also included delays in hopes of staving off any unneeded processing.

 

4. With respect to this program: Energy Monitoring, there are at least ten programs active and deployed. At different times of the day or based on environmental changes all of them can be active and running. What I have observed is the system (ISY) slows right down and freezes.

 

Hence why I wanted a second set of eyes as they say to validate if there could be something wrong with how these two programs are crafted and may be impacting the reliability of the ISY-994 Series Controller.

 

5. Related Items: What is different now in my environment are two extra devices sending state variables into the ISY. Which I never had before and they are the Autelis Bridge & Dash Box. The Autelis Bridge sends its data at 30 second intervals, and the Dash Box at aprox 60 second intervals.

 

The GEM is sending its Energy readings into the ISY at 10 second intervals. With all three of these things going on and with active programs monitoring the temperature and energy readings which the two listed programs above do. There is a huge performance hit on the ISY.

 

I have disabled all programs as a test to see how the system operates. At first blush it seemed there was one or more programs at play that may be causing all of this grief. While the programs were ALL disabled it was noted and observed the same problems with slow performance: UI not updating, clock stopping, energy readings not coming in, were still present??

 

I have been working on this problem for months as it has gotten worse as time goes by.

 

Never mind the never ending false readings that seem to appear and go away even when I know its not a power issue. As others have seen this exact same power spikes / unknown values appearing for no apparent reason as seen here: http://forum.universal-devices.com/topic/13055-aeon-smart-switch-dsc06106-zwus/

 

At this point as a lay person: It only makes sense to ask the community and UDI to validate if there is something in my programs or other related items that may be causing this device to slow down to a crawl and become unresponsive.

 

I really can't believe counting timers, state variables being sent to the ISY, and sending e-mail can be so taxing on the ISY-994 Series Controller?? I surely can't be using this device more intensely than the next guy??

 

Right now I can not count on the ISY to control my home in any direct manner. When the system can't even send me a e-mail on time, or at all, when its frozen. You can affirm how many endless e-mails have been sent to your support support address already. The only reason you have not since seen more is because I removed your alias from the mailing list as I worked on this problem.

 

I have high hopes and aspirations for the ISY-994 Series Controller as it will be (literally) the cornerstone of my HA System. As it stands, I need some help in sorting out any gremlins that lurk within my system which is giving me all this grief.

[Teken]

Hi Teken-

 

Sorry for the delay, I'm just getting back from vacation.  Are you still having issues with this or did you get the timing worked out?

 

-Xathros

 

Hello Xathros,

 

Glad you got a chance to get away and enjoy what is left of the summer! I have appended my reply to Michel and if you have some time and insight please do let me know.

 

I have created many of your Energy Monitoring / Temperature Monitoring programs to date. I have adjusted the values to real world temp conditions and electrical values needed. Right now, I am just trying to validate if there is anything else that can be done or redone to reduce any load on the ISY.

 

As some of the programs appear to be loading up the ISY at different times, while other times all of these programs are inactive but yet the ISY is still slumping away like a rabid dog.

 

As always, your time, patience, and guidance is most appreciated! 

[Michel Kohanim]

Hi Teken, thanks for the details.

 

I think our discussion is going into an infinite loop since there are multiple issues that are being juxtaposed into a narrative that makes troubleshooting pretty much impossible.

 

Please answer these question with Yes/No only (yes, i know you have spent gazillion hours and you cannot use ISY for your home automation, etc.):

When ISY freezes, the clock stops, the readings stop and then you have to restart the UI (Ctrl + Alt + Delete), what happens when UI is restarted:

A. Do energy readings populate?

B. Is ISY still slow and unresponsive?

 

With kind regards,

Michel

[Teken]

Hi Teken, thanks for the details.

 

I think our discussion is going into an infinite loop since there are multiple issues that are being juxtaposed into a narrative that makes troubleshooting pretty much impossible.

 

Please answer these question with Yes/No only (yes, i know you have spent gazillion hours and you cannot use ISY for your home automation, etc.):

When ISY freezes, the clock stops, the readings stop and then you have to restart the UI (Ctrl + Alt + Delete), what happens when UI is restarted:

A. Do energy readings populate?

B. Is ISY still slow and unresponsive?

 

With kind regards,

Michel

 

 

I just had a whole reply disappear?? Let me go and try that again!

 

A. Do energy readings populate? Yes, then stop updating at random times / intervals.

 

B. Is ISY still slow and unresponsive? Yes, again at random times with no frequency or duration when this may happen.

[Xathros]

Teken-

 

I believe you stated above that with all programs disabled, the ISY will still become unresponsive.  If this is true, then it would seem to be a problem unrelated to the programs that is causing this behavior.

 

As I mentioned when we last worked on this, I never saw any slowness or unresponsive issues with the console while I was connected from my MAC.  Granted, I have spent a lot less time connected than you have.  I still think it to be a worthwhile test to attempt a connection from a different platform when the system is in it's unresponsive state and see if there is anything to be learned.

 

-Xathros

[Michel Kohanim]

Hi Xathros, at the moment I think the problem is a GUI hang and not ISY performance problem.

 

Hi Teken, thank you:

A. Do energy readings populate? Yes, then stop updating at random times / intervals.

B. Is ISY still slow and unresponsive? Yes, again at random times with no frequency or duration when this may happen.

 

So, what happens if you restart the UI? Does A and B still hold?

In short, when energy readings stop, etc. and if you restart the UI (not ISY), everything goes back to normal. Correct or not correct?

 

With kind regards,

Michel

[Teken]

Teken-

 

I believe you stated above that with all programs disabled, the ISY will still become unresponsive.  If this is true, then it would seem to be a problem unrelated to the programs that is causing this behavior.

 

As I mentioned when we last worked on this, I never saw any slowness or unresponsive issues with the console while I was connected from my MAC.  Granted, I have spent a lot less time connected than you have.  I still think it to be a worthwhile test to attempt a connection from a different platform when the system is in it's unresponsive state and see if there is anything to be learned.

 

-Xathros

 

Hello Xathros,

 

This is something I am actively going to pursue so it can be one area to be eliminated from the possible areas of concern.

[Xathros]

Hi Xathros, at the moment I think the problem is a GUI hang and not ISY performance problem.

 

Michel-

 

This is my feeling as well based on my limited experience with Teken's system.  I had no issues with the UI when I was logged in from my MAC yet on several occasions, his Windows based console needed to be restarted for him to see updates.

 

-Xathros

[Teken]

Hi Xathros, at the moment I think the problem is a GUI hang and not ISY performance problem.

 

Hi Teken, thank you:

A. Do energy readings populate? Yes, then stop updating at random times / intervals.

B. Is ISY still slow and unresponsive? Yes, again at random times with no frequency or duration when this may happen.

 

So, what happens if you restart the UI? Does A and B still hold?

In short, when energy readings stop, etc. and if you restart the UI (not ISY), everything goes back to normal. Correct or not correct?

 

With kind regards,

Michel

 

In short, when energy readings stop, etc. and if you restart the UI (not ISY), everything goes back to normal. Correct or not correct?

 

 

That depends on how *stuck* the UI is. If I see the energy readings stop coming into the ISY I would say 70% of the time closing and opening the UI will let me see the energy readings for what period of time.

 

Other times I will observe at random the UI just stops accepting user input. Then, you will see the system clock stop for what ever period of time, then operate.

 

Keeping in mind when all of this happens the never ending JAVA pop ups in various nag prompts appear.

 

When the system is working I can sit and watch the ISY UI for hours ticking away updating perfectly fine as I have been doing for more than three years. Its like the system is out of memory or the processor is being tided up with lots of things to do in the back ground.

 

Whether this is because of programs, or data being sent to the ISY, I can not say.

 

On a related note: I have reached out to Brultech about how the ISY interacts with the GEM.

 

Why??

 

Because on multiple times when the ISY locked up it  actually took down my Dash Box / GEM. Meaning both systems had to be rebooted to recover from the ISY being in some unknown state.