johnnyt

I don't think I have any tight loops, but maybe I don't understand what you mean by that. Here's an example of a loop as I understand the term. The 6-12 programs that are running at any given the time look like this. Edit: Program 'Query Countdown': If Program 'Query HVAC Devices II' is False Then Repeat Every 1 minute $sHVAC.Query.Count += 1 Else - No Actions - (To add one, press 'Action') Below are three very typical programs that are triggered by changes in some state variables or IOLinc node statuses: (the first two work together) - Do any of these qualify/cause "tight loops"? Edit: Program 'Fan High Speed Off - Temp Sensor': If $sFanHighSpeedManual is 0 And $iUpDownTempDiff < 100 And $iUpDownTempDiff is not -999 And $sTemp.MasterBedroom is not 0 And Status '1-MISC (Non Lighting) / HVAC / Kitchen.F-FanHigh' is On And Program 'Fan High Speed Off - Temp Sensor II' is False And Program 'HVAC - AC Call Flag' is False Then Wait 3 seconds Run Program 'Fan High Speed Off - Temp Sensor II' (Then Path) Else - No Actions - (To add one, press 'Action') Edit: Program 'Fan High Speed Off - Temp Sensor II': If Then Disable Program 'Fan High Speed Off - Temp Sensor' Wait 15 minutes Run Program 'Fan High Speed Off - Temp Sensor III' (If) Wait 3 seconds Enable Program 'Fan High Speed Off - Temp Sensor' Run Program 'Fan High Speed Off - Temp Sensor II' (Else Path) Else - No Actions - (To add one, press 'Action') Edit Program 'Furnace Damper ON': If Status '1-MISC (Non Lighting) / HVAC / Furnace Rm Damper' is Off And Status '1-MISC (Non Lighting) / HVAC / Fan Low Speed' is Off And Status '1-MISC (Non Lighting) / HRV / HRV Low Speed' is Off And Status '1-MISC (Non Lighting) / HRV / HRV High Speed' is Off And ( Status '1-MISC (Non Lighting) / HVAC / Fan On' is On Or ( Status '1-MISC (Non Lighting) / HVAC / Sensor - AC Off - Fan Low Spe' is Off And $sPowerFailure is 0 ) ) Then Wait 15 seconds Set '1-MISC (Non Lighting) / HVAC / Furnace Rm Damper' 100% Else - No Actions - (To add one, press 'Action')

Hi Michel,There are a few reasons for me to entertain this idea. Mainly it's because ISY does not have the horsepower needed to handle my peak workloads. The 60-90 sec GUI loading is certainly one of the workloads but there are other times when a high workload causes problems. And it's one of those things that isn't getting better as both the number of programs grows and the firmware footprint increases. 1. At any given time I have 6-12 programs running (mostly waiting but doing something every now an again) and it's not uncommon to see about 10-20 programs that last ran in the same second. Every 15 mins or less I have a program that queries about 20 IOLinc nodes (described in the 5th paragraph of this post viewtopic.php?f=27&t=11907). During the 7-10 secs this runs in some case it can cause maybe 40 programs to at least evaluate and a few of them to do something. Whenever this program runs the GUI is not able to keep up. It doesn't show what's going on as it's happening and I'll get some sort of socket failure message if I try to do anything. I've also returned to my computer to find one of those socket failure messages on the screen, i.e. things got overwhelming on their own. (I do leave the GUI running to mitigate the loading time issue.) 2. In addition to the workloads triggered by ISY programs, my external temp/humidity sensor solution (viewtopic.php?f=78&t=9840) now updates about 18 state variables every minute, between 1 and 2 secs apart each. Some of the state variables are in 20-30 programs and these will, at minimum, evaluate. ISY also needs to update or respond to communications coming from HomeSeer, DSCLink and ISY Data Logger (by io_guy). All four of these external subscribers make real time demands of ISY and are completely outside the control of ISY or any insteon collision avoidance algorithm. Multiple times a day both DSCLink and ISY Data Logger indicate they can't update their respective heartbeat variable. Often, DSCLink is not able to pass the activation of a alarm panel connected motion sensor to ISY and a program to turn on a light does not run, or runs very late (directly impacting the WAF). Sometimes (usually when I'm loading or saving programs) the HomeSeer ISY plug-in has to activate it's watchdog timeout to reconnect. 3. Notifications - which I often rely on for troubleshooting in the absence of a program log - are often delayed because they are queued up to run separately and end up running well after they were triggered. A good design idea when processing resources are scarce, except that they will often report programs ran False instead of True (when they were actually triggered). This means one can't rely on them to know exactly when a program ran, and one has to work around the issue if one wants to know with certainty that an else statement actually ran. I put in a 2 sec wait and ensure there's a command after the wait - sometimes having to insert a "dummy" command - since waits don't run if they are the last command. Moving to a 2nd ISY will not fix this; am just mentioning it as additional evidence that ISY hardware is not powered sufficiently to handle high workloads, at least mine). 4. In my case, I actually thought it might slightly improve manageability (although the jury is still out on that). About half my programs are to handle HVAC operations (see viewtopic.php?f=48&t=10174). Although there are a couple of exceptions where a KPL that controls something HVAC related also controls a light, I think I would be able to have a mostly clean/clear line between what the two ISYs would control. 5. Finally, we are likely moving in 12-18 months and I'm thinking of leaving the HVAC automation, which is unique to the house and has a bunch of highly embedded stuff (hardwired sensors, duct dampers, HRV, etc), and taking the other automation with us. I'm thinking having that separated out (and stable well before we start the buy/sell/move process) would be a good thing.

Thanks, LeeG. Searching for "two ISY and REST" I found a recent relevant post and a whole bunch of other irrelevant posts (which wasn't a big surprise given the prevalence of search words I used). The one relevant post (viewtopic.php?f=26&t=11761&hilit=two+isy+and+rest) does not really explain how to do this with REST beyond needing the network module and network connectivity. If you happen to remember anything about this topic (like the user who did it) that might help me find more info. I was walking through my migration plan in my mind and figured I would want/need to do the following things (someone pls correct me if I'm wrong): 1. restore ISY1 backup to ISY2 (ensuring appropriate firmware version alignment first - or will that happen with the restore?) 2. restore new PLM connected to ISY 2 (or should I/can I do the next step first?) 3. delete devices and programs on ISY2 that are not intended for ISY2 4. delete devices and programs on ISY1 that are not intended for ISY1 5. restore each device via the ISY that is now supposed to control them My questions are: 1. for step 3 will deleting devices on ISY 2 muck things up for ISY 1 in any way? (from what I understand, no, but would like to confirm) 2. If I want to work this out on the bench / in the lab - same house - before I deploy things into "production", I know I can put a filterlinc on the PLM to block power line signals but I don't think I can stop the RF signal from getting picked up by one of my many access points. Do I need to worry about that? From what I understand, devices will NOT respond to PLM2 until AFTER step 5 above. Is that right? Also, I know there would be extra insteon traffic that could interfere with normal operation of ISY 1 but will collision avoidance logic in the two PLM's work to reduce the impact of that? 3. If I wanted to stop PLM RF transmission, is there a way to do that by opening up the PLM (with or without voiding the warranty)? Would just putting it in a metal box work? 4. Am I missing anything I should be aware of?

Am thinking of offloading some of my nearly 650 programs (170 variables, 71 devices/156 nodes) to a second ISY to improve performance when I want to make changes and/or when the system is busy. For most of the devices I plan to offload there would be a clean break - the devices will only be linked to one of the two PLMs I would have - but for a few devices I would like to link them to both PLM's. Is it do-able? What are the pitfalls, if any, of doing this? I mean both from the perspective of having two PLM's in one house in general, and from having devices storing link records generated by two different PLM's. Also, specifically with respect to having two PLM's, from what I understand each PLM's commands would be echoed/retransmited by the other PLM. Is that right? Is that a source of potential problems and/or can it actually be helpful (like adding an access point)? Any info would be appreciated.

And If the company goes bankrupt you lose the automation capability you paid a premium to get. I'm also concerned about being held hostage to a service fee increase later simply to change my heat/cool set point. Not saying I wouldn't pay for value add, e.g. data storage and analytics that i might not want to do myself, but I want the basic capabilities I invest in today (including the time investment) to last for as long as the h/w does. Sent from my iPad using Tapatalk

Is that right? One can't directly talk to it from one's own local network? Hmmm, big knock if that's the case.

for those with ecobee stats, what model did you go with, why, and would you pick a different one today?

Not only do they only go on once, I've found they go on long before the battery really needs to be replaced. I've also found the status stays on for a few days then changes back to off. Don't know what makes it tick. I set up a counter that increments every time motion or light sensor does something. I recently replaced a battery after about 22000 "events" with close to 5000 of those happening after the low battery warning occurred (then disappeared). It's not perfect because not every motion event is sent out (at least I haven't configured my sensors that way). I like the countdown idea but what would be really great is a "last changed" timestamp on devices that could be checked by programs. I did submit that feature request but I think more people would have to ask. Sent from my iPad using Tapatalk

yes, absolutely, that happens. When my AC activates, it sets an IO Linc sensor monitoring the AC call AND it sets an IO Linc monitoring the Fan call (which is hard wired to occur at the furnace). If that's a problem, why is it only happening intermittently? Unfortunately, I didn't have notifications / log entries set up last winter to look back now and see if/when the "backup" X10-triggered program ran after a heat call (which does not come with a simultaneous fan call) so I can't say now if it was happening then.

So there's no need to query the sensor.... hmmm. Okay I'll remove that separate query from my program to reduce the insteon traffic. But it seems weird to me since sensors and relays are different nodes... It's intermittent. MOST of the time, the program I have that is triggered by the (insteon) sensor change of state works but OFTEN (see second screenshot in my post above) the backup program triggered by the X10 command that I've set the IO Lincs to send on sensor change is what runs to completion. So it's not a link record problem but it could be an intermittent comm problem. The weird thing is that the (I thought) weaker, non-repeated X10 makes it through... Of course, maybe the X10 command is interfering with the insteon command and causing the problem. Hmm... looks like I'm not done troubleshooting this but many thanks for the info, LeeG.

that's great news as I've heard good things about the ecobee stat but If I'm not mistaken you need the zigbee radio in the ISY for it. Is that right? One would then lose the ability to do zwave with ISY in the future. I've been waiting to get a stat and a must have is ISY integration; on it's own intelligence and Internet enabled are not enough or even that interesting. Sent from my iPad using Tapatalk

Really? I can't follow these insteon log entries like you can but doesn't the sensor only respond when you actually query it? What log entry shows that? I certainly have been querying both the relay(s) and the sensor(s) separately (like in your test program). Sent from my iPad using Tapatalk

Would the following help or am I missing something?: (note: I have 11 IO linc and use the sensor input on 3 of them) 1. breaking up my queries into smaller groups/scenes, e.g. four scenes of 4, 4, 3 and 3, or maybe even smaller groups (down to querying each one individually?) 2. adding a suitable delay between each query request, say, 1 sec per IO linc in the scene? Also, I was thinking of adding access point(s) in an attempt to reduce/eliminate intermittent comm problems (in other areas of the house). Am I understanding that adding RF devices could just increase the risk/occurrences of this problem? (I'm not worried about dual band devices as the metal junction boxes in my house render those useless.)

Thanks LeeG. Very interesting. (FWIW, my PLM is v9B) Not sure I understand all the inner workings at play. Is this a PLM issue, an IO Linc issue, or an ISY issue? In the meantime, currently my IO Linc Query Scene requests the status of 11 IO Lincs. Might breaking the query up into smaller groups/scenes help reduce the risk/occurrence of the problem by helping spread out the insteon traffic?

There is, sorta... You can use notifications to write directly to a file on the ISY's webserver. Very much like what you are doing now with your notifications but should be 0 latency. I do something very similar with network resources writing to a syslog server running on my RaspberryPi. Makes for lots of network resources or custom notifications but is very useful for debugging purposes. Here is the wiki link for writing to a file: http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Networking#Create_File_and_Send_Notification -Xathros Thanks Xathros. Yes, I was an early adopter of that. Problem is every program you want to monitor has to be set up and the files have to created and managed. I also ran into hassles formatting and "saving as" to excel. Eventually solved but way too much work. What I'd like to see is a program log similar to the insteon activity log, that is built-in and that logs all activity (with perhaps the ability to turn on/off or set log levels like event viewer.) See viewtopic.php?f=7&t=7779 for my wish list. It doesn't appear the current hardware has enough juice, though, and while I'd be happy to pay for more power and have posted about that, it seems no one else would be. Anyway, hopefully I didn't just send my own thread down another road but I wanted to acknowledge your reply.

I think I checked last run time and it was the day before. I say "I think" because I rarely look at that as I don't find it useful typically since it changes every time the conditions are evaluated - very few of my programs have only one condition like this one. I rely on notifications to troubleshoot program problems, although they can be delayed. (I wish there was a program log). The log doesn't have anything between about 11:50PM and 12:05AM so nothing going on from an insteon traffic perspective. The closest other program runs at 12:00:10 to reset a few variables. It terminates at the same time it starts. Also, I get notified when ISY boots up and I wasn't notified of that. By all indications ISY was running fine at 11:59:58 PM that night. I disabled ntp sync for about a day and a half and the clock lost maybe 1-2 secs. I had the clock set to sync every 6 hours - at that rate it should have remained pretty close, no? I have no idea when the sync actually occurs (is there a way to know? could there be a way to choose in a future release?) At every 6 hours, if the problem was an NTP sync, it would have happened every day at the same time and I think I would have seen more occurrences of the problem, no? Am I better off to sync only once a day? On one hand it would interfere with fewer programs when it does occur but on the other hand the time would be more likely to be off by a few secs when it does sync. Does changing the occurrence of the NTP sync reset the clock? I could use that to pick a time that would not be important. What happens to programs that rely on "Time is Last run" condition of a program if the NTP sync happens to occur and change the clock to just past when that condition would have occurred? I know there were a few times in the past when I would have liked to have a "Time > Last run" - not sure if others have asked for it but maybe this time sync situation points to a requirement for that? I may take you up on that. Could it could also be used to track a bigger, long standing problem I've had with IO Lincs that's wasted lots of my cycles over the past couple of years? viewtopic.php?f=27&t=11907

I have problems with IO Lincs mysteriously changing state. Here's an example (that happens with more than one IO Linc) First here's what's supposed to happen (and mostly does) every day at 2:59:08 AM during the summer: A program turns an IOlinc ON (along with some keypadlinc buttons) that sets my HRV to run at high speed (usually the coolest time of the day). Here’s what shows up in the log: Scene:1-MISC (Non Lighting) / HRV / HRV High for Prgs On Mon 2013/07/08 02:59:08 AM 1-MISC (Non Lighting) / HRV / HRV High Speed Status 100% Mon 2013/07/08 02:59:08 AM Outside / Back KPL.G - HRV High (XLink) Status 100% Mon 2013/07/08 02:59:08 AM Outside / Back KPL.H - HRV High (XLink) Status 100% Mon 2013/07/08 02:59:08 AM The HRV is supposed to remain on for 2.5 hrs (until 05:29AM) when another program turns it off and that’s exactly what happens most of the time. Intermittently, though, at different times in the middle of a cycle, the IO Linc ends up OFF even though no person or program turns it off (and there's no log entry showing an OFF command was sent). It's found OFF by a query that runs either every 15 mins OR every time an HVAC-related IO Linc sensor monitoring heat or AC call triggers. The latter are different IO Lincs (not the HRV ones). I've had to put this safeguard program in place to catch these mysterious, intermittent occurrences and because the IO Linc sensors don't always report their change of state. In fact I've had to set the IO Lincs with the HVAC sensors to send an X10 signal whenever the sensor state changes which triggers a second program in case the first one (set to trigger when an insteon signal is sent) doesn't run. See image further below for a screenful of occurrences of that program running. Notice that it isn't every 15 mins or less so the main program is triggering properly most of the time. For those naturally inclined to say that I might be having comm issues, note that the X10 signal is making it back to the PLM. While I'm not ruling out comm issues - occasionally there is the odd Hops Left=0 - mostly the hops left = 2 in that area of the house. I've reported IO Linc mystery behavior before but I didn't have enough data to offer up so either something else was pointed to or I (and likely others) rationalized that it was user error. It could well still be but I'm at a lost to know what I could be doing wrong after two years of intermittent troubleshooting and building/tweaking workarounds for this. Personally I'm inclined to think this is a hardware problem but I'm a bit stuck with coming here (instead of Smarthome) because I only have ISY captured/generated info to troubleshoot with. The entries below show the query that finds the "HRV High Speed" relay OFF followed by the result of the program that triggers when HRV High Speed is OFF but should be ON Scene:1-MISC (Non Lighting) / HVAC / HVAC Relays Status Query Mon 2013/07/08 05:02:40 AM 1-MISC (Non Lighting) / HRV / HRV High Speed Status 0% Mon 2013/07/08 05:02:40 AM Scene:1-MISC (Non Lighting) / HRV / HRV High for Prgs On Mon 2013/07/08 05:02:59 AM 1-MISC (Non Lighting) / HRV / HRV High Speed Status 100% Mon 2013/07/08 05:02:59 AM This also happens intermittently to a different IOLinc that sets my HRV to low speed. For all I know this is happening to other IO Lincs but I don't have the extensive set of checks and notifications set up for other ones so I can't pinpoint it for those. The screenshot below shows all the times (going back to mid May) that my checks/notifications have reported my HRV related IO Lincs in the wrong state. The screenshot below shows all the times I was notified that my second safeguard program ran/completed - this program should never get to the point of sending these notification.

looking back the appropriate entries are supposed to look like this: 2013/07/07, 23:59:59, Call Day of Month Advance ran True 2013/07/08, 00:00:03, Day of Month Advance ran True so the problem seems to be that the program trigger is delayed for some reason. how do I avoid that? the weird thing about this is I should have gotten an error yesterday (the 10th)!

Last night the following program did not run: If Time is 11:59:58PM Then Send Notification to 'me' content 'Generic Program Log' Wait 5 seconds Run Program 'Day of Month Advance' (If) Else - No Actions - (To add one, press 'Action') It's part of the Calendar series of programs although I changed it to run before midnight (and wait 5 seconds so the action takes place after midnight). This is so I can set the feature to "Catch up schedules at restart" - which I learned only goes back to midnight the day of - without the calendar getting advanced again should a restart happen. This is a problem I've seen before - with this program and others - and, for this one, I added 2 notifications, which write to a log, to catch it when it happens. The night before, as with most nights, the following entries appear in my log file: 2013/07/10, 00:00:05, Call Day of Month Advance ran True 2013/07/10, 00:00:09, Day of Month Advance ran True These entries are absent for last night. Also, as those familiar with this series of programs know, there's a mechanism to warn one when the program doesn't run and it's happened 6 times since late January (when I decided to start to keep the emails I receive for reference). See image for the date and time of past occurrences. What's happening? Am on 4.0.5 firmware and GUI

What do these message mean in the log? FF 10 01 1/FSL2/0 IDBX10 FF 10 01 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 10 02 1/FSL2/0 IDBX10 FF 10 02 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 10 06 1/FSL2/0 IDBX10 FF 10 06 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 07 01 1/FSL2/0 IDBX10 FF 07 01 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 07 02 1/FSL2/0 IDBX10 FF 07 02 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 06 05 1/FSL2/0 IDBX10 FF 06 05 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 07 03 1/FSL2/0 IDBX10 FF 07 03 1/FSL2/0 Tue 2013/07/09 02:59:49 AM System Warning FF 06 06 1/FSL2/0 IDBX10 FF 06 06 1/FSL2/0 Tue 2013/07/09 02:59:50 AM System Warning FF 07 04 1/FSL2/0 IDBX10 FF 07 04 1/FSL2/0 Tue 2013/07/09 02:59:50 AM System Warning FF 07 09 1/FSL2/0 IDBX10 FF 07 09 1/FSL2/0 Tue 2013/07/09 02:59:50 AM System Warning FF 06 07 2/FSL2/0 IDBX10 FF 06 07 2/FSL2/0 Tue 2013/07/09 02:59:50 AM System Warning FF 05 0C 1/FSL2/0 IDBX10 FF 05 0C 1/FSL2/0 Tue 2013/07/09 02:59:50 AM System Warning

I believe you lose the ability to use any X10 devices if you filter the PLM because it's my understanding access points do not repeat X10. Sent from my iPod touch using Tapatalk

Autelis has been rock solid for me. Got good help from them to get started and they modified their firmware twice to add stuff I wanted. I also use a free s/w serial server from Piracom to feed my DSC comm to DSCLink. I do end up with an occasional missed event ( door open doesn't trigger program as it should) but I haven't figured out where the problem actually lies. The thing is it's free so you can just download it to see if it works for you. Sent from my iPod touch using Tapatalk

Mike, you can also use IO Lincs, 1-wire sensors (with one of them outdoors) and ISY programming to build intelligence yourself. In this thread about humidifiers viewtopic.php?f=27&t=10621 about 3/4 of the way down I posted a "brute force" program I migrated to ISY from HomeSeer that sets my target humidity in the winter to the optimal level based on outdoor temperature. There's no mathematical formula for it that I could find so I matched up the optimal humidity to temp settings listed on my furnace humidistat. One thing ISY is missing is forecast data to allow you to set humidity (or cooling/heating) according to what the temp will be later so I have to tell HomeSeer to update ISY variables with the info. (forecast data and my stat have been the only things keeping me running HomeSeer) See more about what I have/do with HVAC here viewtopic.php?f=48&t=10174

Mike, there are a ton of posts on this forum about insteon thermostats. I estimate 3/4 of the posts are about problems with the h/w and not "user training" issues. Maybe many or all have been resolved but I made my decision a while ago to NOT go with an insteon thermostat. The decision for me now is to either get my wired one fixed or pick one of the RF stats that ISY does or will support. There's only room for one radio in the ISY so deciding which radio to go with is key if I go the ISY supported way. By the way, the last paragraph in this post viewtopic.php?f=78&t=9840 mentions how you can have ISY communicate with a wired stat. I'm not sure whether or not you can still get one from RCS but maybe there are others. For a while I didn't even want to consider wireless for such a vital system but I'm slowly softening up, although I'm still hesitant.

I'm tracking thermostat threads as I'm looking for figure out what to do about my broken (no comms) RS485 wired RCS TR40 stat that I was using HomeSeer - and indirectly ISY - to control. I thought I would ask a couple of basic questions I thought worth asking. What else is a 994i with zigbee radio good for beyond a thermostat? If I'm not mistaken smart meters is one answer but that doesn't count for me (and you mkbrown69). I asked our local utility company (I also live in Ottawa, Canada) if they would support SEP and allow RF enabled controllers like ISY (pointed them to UDI web site) to read our smart meters and they said no. This was last fall. I don't expect things to change quickly there but maybe if you asked too, mkbrown69, they would look at that again. In the mean time, that use of zigbee would be of no value. If I went with a zwave radio in my ISY I know I could add other zwave devices in the future so that's a plus, but are the zwave thermostats reliable? Does it partly or wholly depend on having a bunch of zwave devices to make sure the zwave mesh network is reliable? what if my only zwave device was a thermostat about 30 ft, two walls and one floor away? Finally, how far away is "gold" zwave thermostat support? (in quarters, if weeks or months is too risky to pronounce)