Xathros

Just modify the original -Xathros Sent from my iPhone using Tapatalk

@Canz So sorry for the delay in getting back to you. I was away on Vacation and have spent the last 3 days catching up here. On first glance, my suspicion is that your problem occurs on Wednesdays. This could be due to the fact that Weds is missing from the Spring_Weekday_1630-Sunset program. I also notice Weds missing from Spring_Weekday_0530-630. If this is by design, I will dig deeper but on first glance this appears to be the issue. -Xathros

That program is an every 5 minute nag. what you want instead is: if $s.GEM_FridgeNotifySuspend = 1 and $s.Fridge_Wattage_Variable < running Wattage value <---- Obviously not the correct syntax here. Then $i.GEM_Fridge_Cycle_Extra = $s.GEM_FridgeRuntimeCycleMins $i.GEM_Fridge_Cycle_Extra -= 34 Send Notification to 'GMX' content 'GEM - Fridge Cycle Exceeded' You will also need to add a delay in the original monitor program to hold off resetting the runtime variable long enough for this notify to be sent: If <Fridge_Running_Condition> Then Wait 1 minute Repeat Every 1 minute $s.FridgeRuntimeCycleMins += 1 $s.FridgeRuntimeCycleMins Init To $s.FridgeRuntimeCycleMins $s.FridgeRuntimeDailyMins += 1 $s.FridgeRuntimeDailyMins Init To $s.FridgeRuntimeDailyMins Else Wait 15 Seconds <----- Add delay here! $s.FridgeRuntimeCycleMins = 0 $s.FridgeRuntimeCycleMins Init To $s.FridgeRuntimeCycleMins -Xathros

While the Digital Loggers DIN relay will certainly allow you to open more than one valve simultaneously, it has no runtime protection to automatically close valves if left open. This is something you will need to consider if you use the DIN relay in place of an EZFlora type device. -Xathros

Teken- The reset/throttle program would look like this: If $s.GEM_FridgeNotifySuspend is 1 Then Wait 5 Minutes $s.GEM_FridgeNotifySuspend = 0 Else So, after 5 minutes of suspended notifications, the timer runs out and sends another notification as long as the fridge is still running. -Xathros

There would need to be a second program to reset the variable $s.GEM_FridgeNotifySuspend back to 0 after a predetermined delay. After that has been reset, if the fridge is still running, another notification will be sent this time showing the time beyond 34 minutes. -Xathros

The first notification is sent at 34 minutes because runtime is equal to 34. Since 34-34=0, I would expect a notification using $i.GEM_Fridge_Cycle_Extra to read 0 on the first notification. Does this Re-Notify after a period of time if the cycle has not ended? If so, the next notification should show the amount beyond 34 minutes that the cycle has been running. -Xathros

Start with: ISY994 with ZWave and the external antenna Add Digital Loggers web power switch: http://www.digital-loggers.com/lpc.html Depending on placement of the ISY and considering that you have no other ZWave devices, at least two ZWave range extenders to extend the mesh. If you are planning on Insteon devices as well, then a pair of Insteon range extenders that will also provide phase bridging. Set up the web switch to ping the router/gateway, ISY and other critical gear and power cycle on failure. I'm sure others here will have additional useful ideas to add. Hope this helps. -Xathros

As we have seen elsewhere, the notification process takes time. I think you saw this with the daily report where we were resetting the daily values after the notification line in the code yet the email contained post reset values. Inserting a delay after the notify and before the reset fixed this issue. I came across this with my daily report as well. I suspect a similar timing issue in this case where having the wait come first in conjunction with the 10 second update frequency from the GEM is not leaving enough time for the notify to send before the if is re-evaluated. A very simple fix would be to move the notify to a separate program and put a RunThen in place of the notify in the current program. Then, placement should not matter. However, I believe it was your goal to simplify and reduce the number of programs, if that is the case, then just leave the notify as is in the current program placed ahead of the wait. -Xathros

Its not that the wattage value drops but rather it changes and does so frequently, The change in wattage value re-triggers the program and because the value of $i.Refridgerator_Defrost_Status is now 1 after the first True evaluation, the If evaluates false and the else fires. This is an odd situation because there is a value that is not clearly on/off used with Status. While the outcome of testing Wattage > 460 may remain true with subsequent triggers, its the additional triggers that are tripping you up here. The notification takes time to process and it appears to me that if the outcome of the If changes before notification processing is completed, the notification process is terminated. Maybe Michel can comment on this point in particular. -Xathros

I have exactly one program that is set to "Run at Startup" I call other programs from that. Some of those call others. Building in some delays here and there, allows me to time phase startup runs so that they don't all just run at once as well as add some logic to decide what needs to run and what doesn't. -Xathros

Try Restore PLM then check you link counts again. -Xathros

I wonder if the ISY is running out of network buffers. This might explain an apparent UI hang since the UI is a network client. Michel, is there data that can be captured via the console port to determine if there is an issue with the network stack? -Xathros

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- 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

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

Yes, scenes add links. Delete unnecessary scenes. Combine other scenes if possible. Then, You can do a restore PLM to compress out deleted links.

Correct. In addition, you could buy a basic non IR 994, xfer all of your modules including the IR. Then take the IR board out of your 99 and install it on your new 994.

The IR has a hardware component. If you wish to keep that then purchase the 994/IR.

Buy the base 994 and xfer all but the IR module.

I have been working with Teken over the last week or two to develop and test some programs for monitoring household temperatures and generating notifications if values go out of range. Teken is using a network of OneWire temperature probes tied to an Autelis OneWire Bridge. The Autelis bridge periodically updated state variables in the ISY with the probe temperatures with .1 degree resolution. Since the ISY only supports whole numbers at the moment, the Autelis multiplies the value by 10 before posting to the ISY. I am posting these at Teken's request. The programs and variables below are used to monitor the kitchen temp probe and provide for the following requirements: Send an alert once every 30 minutes if/while the Kitchen temperature exceeds 23 Deg C (230 Autelis Units) If the kitchen temperature continues to rise by 2 or more Deg C (20 Autelis Units) - Alert Again without waiting for the 30 minute delay and do so each time the last alerted temperature is exceeded by 2 or more Deg C. Reset once kitchen temperature drops below 23Deg C threshold. Support up to 32 temperature sensors. This set of programs and variables serves as a model for the remaining 31 programs and variable sets. Variables: s.Autelis_Kitchen_Temp - State variable - Set by Autelis bridge (or other sensor input source) i.Autelis_Kitchen_Suspend - Integer Variable - Used to throttle notifications - 1= Suspended, 0=Normal i.Autelis_Kitchen_Alert_Temp - Integer Variable- To record the temp at last alert send. i.Autelis_Kitchen_Delta - Integer Variable- Used to calculate the change in temp since last alert sent. Kitchen_Temp_Monitor If $s.Autelis_Kitchen_Temp > 230 And $i.Autelis_Kitchen_Suspend is 0 Then Wait 0 secon ds Send Notification to 'GMX' content 'Autelis - Kitchen Temp Alert' Wait 3 seconds $i.Autelis_Kitchen_Suspend = 1 $i.Autelis_Kitchen_Alert_Temp = $s.Autelis_Kitchen_Temp Run Program 'Kitchen_Notification_Suspend' (Then Path) Else Wait 0 seconds $i.Autelis_Kitchen_Delta = $s.Autelis_Kitchen_Temp $i.Autelis_Kitchen_Delta -= $i.Autelis_Kitchen_Alert_Temp Wait 6 seconds Run Program 'Kitchen Override Suspend' (If) Send a notification if the Autelis probe reads higher than the threshold defined in line 1. Threshold is set in Autelis units which equal 10 units per 1 Deg C. We record the temp at notification so that we can monitor and alert again if temp continues to rise. NOTE: If you need to change the threshold, you also need to set the same value in Kitchen_Temp_Reset line 1 The First Wait in the Then and Else sections are to insert a delay for multiples of these programs to offset the runs and reduce ISY load when the Autelis updates all temp values at once. Stagger groups of these programs by 1 second. Kitchen_Notification_Suspend If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 30 minutes $i.Autelis_Kitchen_Suspend = 0 Else - No Actions - (To add one, press 'Action') Notify every 30 minutes while the temperature remains above the threshold set in the Kitchen_Temp_Monitor program. Kitchen_Override_Suspend If $i.Autelis_Kitchen_Delta >= 20 And $i.Autelis_Kitchen_Suspend is 1 Then Run Program 'Kitchen Temp Monitor' (Then Path) Else - No Actions - (To add one, press 'Action') The delta setting in the IF section controls the override if the temp continues to rise beyond this value since last notification was sent. This value is in Autelis units of 1 deg = 10 units. ie 20 = 2Deg C Kitchen_Temp_Reset If $s.Autelis_Kitchen_Temp < 230 And $i.Autelis_Kitchen_Suspend is 1 Then Wait 10 seconds $i.Autelis_Kitchen_Suspend = 0 Stop program 'Kitchen Notification Suspend' Else - No Actions - (To add one, press 'Action') Reset the override and stop the override timer when the temp drops below the threshold. NOTE: If you need to change the threshold, you also need to set the same value in Kitchen_Temp_Monitor line 1 In the coming weks, I plan on reworking this model to work for both high and low temperature limits. I will follow up with the updates once completed and throughly tested. -Xathros

The problem is the SSL settings in the ISSY dashboard. Thanks to MWareman, we know that setting the SSL Server settings to SSL3, ALL, Verify unchecked will allow the UBI connections to succeed. I have been using my UBI as the voice and ears for my ISY for a few months now. It kinda works, as long as the TV isn't on, nobody else is talking and UBI is in a good mood. I find it more useful as an output device to let me know about critical events in the home rather than an input device for issuing commands. -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

Hi Teken- I just reviewed the code again and still see no obvious reason for this to happen unless one of the integer variables was defined as a state variable instead. -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