Teken

As another data point for those following along. This problem is present on different computers at different locations. It doesn't matter if I am using the direct IP, or the Public IP to remote in to view / control the ISY. I have used various web browsers and the problem is present in various degree's but don't take much stock on it being a web browser issue as there is no defined threshold of when and if the freeze, unresponsive, to the never ending Java nag prompts appear. What is factually different is when the ISY started supporting higher encryption methods etc. Which thus caused that never ending nag prompt to appear to create a self signed cert. Why am I bringing this to light?? Because this is just one element that has added to this issue. From work using the Public IP address with the same IP address at the same computer terminal I have always received the nag prompt. Good, or bad it appears and it has been a known variable of when I connect. This same behavior has been the case while at home using the same (Fixed IP) address and static IP computer terminal. Now, even at home the self signed cert pop up does not always appear??? I have been told various things to explain away this behavior but the facts do not support the answer. I know if the self signed cert pop up DOES NOT APPEAR that session is going to be gamble as to how its going to operate. Maybe the above data point will provide some insight to some of the issues I see.

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.

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.

Your ability to dumb it down for the masses is greatly appreciated! After all these years I continue to struggle with the operations of these operators and how best to craft programs that not only make sense, but are small, clean, and just plain work! Thank You!

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.

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!

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.

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

OK, I appreciate the break down of the theory of operations. I am going to program my Axis PTZ camera to watch the light bulb this evening to confirm the final operation. Much Thanks!

OK, I have been playing with this program for a few hours to fine tune the expected behavior. Now, my only concern is the following and if there is some work around or extra program that can resolve what I see please do let me know. As this is a state variable it requires a change of state to activate, no? I was able to confirm that the time, duration, and watch dog timer all functioned as expected. But, if the temperature during the evening stabilizes at say (-20'C) and does not change state during the 4-8:00 AM window. Will it actually turn on and activate as expected? I ask because doing a quick test did not result in the expected behavior I am looking for. Example: The garage interior was already 24'C, I changed the value to something lower (20'C) and I was with in the time schedule range. Yet the timer program did not activate?

OK, I quickly crafted the program as out linedd above. Please check for any errors and I shall test this out once I am back from the gym. Thank you very much for the insight and taking the time to craft this for me. If From 4:00:00AM To 8:00:00AM (same day) And $s.Dash_Box_Garage_Interior_Temp <= -20 Then Send Notification to 'GMX' content 'GEM - Block Heater - Active' Run Program 'Block Heater - Watch Dog' (Else Path) Else Set Scene 'Appliance 10' Off ================================ ================================ If Time is 8:00:00AM Then Set Scene 'Appliance 10' Off Enable Program 'Block Heater - Monitor' Else Disable Program 'Block Heater - Monitor' Set Scene 'Appliance 10' On Wait 3 hours Enable Program 'Block Heater - Monitor' Run Program 'Block Heater - Monitor' (If)

Larry, Your program you posted up is very similar to one I was using last year.

This is what I have put together based on your feed back. I am unsure how to add in the if the time is NOT 8:00 AM? How is that done as I don't see an obvious choice to select in the schedule time area? If From 4:00:00AM To 8:00:00AM (same day) And $s.Dash_Box_Garage_Interior_Temp <= -20 Then Send Notification to 'GMX' content 'GEM - Block Heater - Active' Run Program 'Block Heater - Watch Dog' (Then Path) Else Set Scene 'Appliance 10' Off If Time is 8:00:00AM Then Disable Program 'Block Heater - Monitor' Set Scene 'Appliance 10' On Wait 3 hours Enable Program 'Block Heater - Monitor' Run Program 'Block Heater - Monitor' (If) Else Set Scene 'Appliance 10' Off Run Program 'Block Heater - Monitor' (If)

This is why I come to the board to bounce off some ideas and hopefully come up with something robust and solid in application. What would be a solid program that would allow the basics I listed above? - I would like the heater to be turned on only from 4-8:00 AM each day. - It should only run for a maximum of three hours upon first turning on. - What kind of watch dog safety time should be crafted to ensure the two conditions are true? - I would not expect it to be a problem that it would trigger over and over at 4-8 AM since I am still in bed!

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!

OMG! No wonder I have been receiving alert notifications about the program turning on! Doh!

Since my ISY meltdown a few weeks ago I decided to start from the beginning in terms of how I would manage some key devices in my home. One of the programs is for the all mighty block heater! Yes, I know you boys who live in the South can't relate and may not even know what a block heater is! Yes, in the cold aszz north we snow men have to plug our vehicles in when the mercury dips to -45'C So, I am first looking for any new idea's or thoughts to craft, fine tune, or to over haul the program listed below. Here are the requirements and hope to fill any blanks as your questions are posed. - The program should turn on (true) when a temperature threshold has been met, or (is) colder. In this case I selected a random number of -20'C. - I only need the program to be active from 4:00 AM to 8:00 AM each day (approx) - The device should run no longer than 3 hours per cycle. - Looking for any new idea's that would make this program smarter. While being energy efficient in its intended goal. I have several resources and data points available now which I either did not use, or explore in the past. I now have the ability to measure the local temperature in any area in and around my home. I have two dedicated temperature sensor systems in place. Both systems monitor the garage interior, garage attic, and outside. I also have the weather module which can provide today's temp, 24 hour weather for cast etc. Any insight or feed back is greatly appreciated! If $s.Dash_Box_Garage_Interior_Temp >= -20 And From 4:00:00AM To 8:00:00AM (same day) Then Send Notification to 'GMX' content 'GEM - Block Heater - Active' Set Scene 'Appliance 10' On Wait 3 hours Set Scene 'Appliance 10' Off Else - No Actions - (To add one, press 'Action')

May I suggest you do a quick search with in the forums for NEST TSTAT. There have been a few related updates and members who have been able to link the two together. But, keep in mind it also requires a computer to be running 24/7/365 for some aspects of the program. I personally am going to wait for ISY native support instead. As I am not a huge fan on middle ware / servers playing a part in something as critical as your HVAC. I have six Insteon Venstar 1800 / 1900 units at the moment which are not used very much at this point in time. Perhaps this fall I will finally take the dive and install one of them to control the HVAC.

LOL! I keep begging SH to bring back the 7 year extended warranty. Given some of the failure rates in previous generation devices along with bad firmware affecting other related Insteon devices. I can see that was impacting their bottom line. I too would like to Beta test a UDI PLM when its available!

Are you talking about the native graphs / charts in the ISY? If so I have never seen or heard anyone having success in generating charts from the ISY. Not sure how its supposed to work actually.

From other related posts it was suggested the system might move to a HTML5 sort of deployment structure. I am just guessing at this point in time, so take that with a hefty grain of salt! Also, off the top of my head a lot of the restrictions you noted are a Mac related issue. Apple has been loathed to support Java from the on set.

I believe you and the majority feel the same way about Java. Enduring never ending updates, clearing the cache, seeing java socket errors, blah blah, really is pain. I can't wait until this system moves away from the whole java platform . . .

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

+1 on this request as I was completely confused how the system indicated a station was only 2 KMS from me. When in fact it was more than 12 KMS!

OK, so I finally got around to create this program as indicated above. As soon as I finished the last program the entire ISY freaked out and the strobing started in the three programs as you saw in the video. It literally took me an hour to regain access to the system as I was unable to disable the folders / programs. All of the error codes and java error. socket failed, etc were all over the place. The system clock actually stopped working during this entire process. My Dash Box was completely off line and not accessible as the ISY was obviously in a tizzy during this infinite loop. I believe this program needs a toggle watch dog program as you crafted for the other energy thread. Please let me know what you come up with. The bright side is the problem has been determined.