johnnyt

This happened again last week and today, along with the problem posted here viewtopic.php?f=27&t=12144 that seems related (as of this posting). I will open a ticket to get the debug version.

ISY had to be rebooted last week (as part of installing Mobilinc Connect). At startup the following program ran true. This is quite strange because time was about 6 PM, the program is NOT enabled to "run at startup" (see screenshot) and it certainly didn't use to run at startup. I manually rebooted ISY this morning again (at about 5:15AM) to test this and the program ran again (see screenshot). Am on 4.0.5. If Time is 12:00:10AM Then $iDehumidifer.Halloween.Xmas.ManuallyOFF = 0 $iDehumidifer.Halloween.Xmas.ManuallyON = 0 Run Program 'Daily HVAC Resets' (Then Path) Else - No Actions - (To add one, press 'Action') Could this problem be related to viewtopic.php?f=27&t=11873?

Wow! I have to correct my comment above. Actually, the ISY DOES include a function to synchronize the 2441's internal clock with the ISY clock!! Its very cleverly named "synchronize clocks". I'm not sure how I missed it before. Maybe it was added in a recent software upgrade. Does it actually work? In an earlier post Michel said that there was no facility to update time in the 2441TH. I ask because I was thinking of getting one but would want the clock to be updatable if it drifts quite a bit as I do plan to leave the stat in charge of doing the temp set backs most of the time, plus it's in a place where I do look at it for the time. Sent from my iPad using Tapatalk

I do remember (and found the post where you were) mentioning that I stand corrected if instead of more CPU, I should be asking for the ability for ISY to leverage SD speeds. I don't know how much you would have to charge to go with SDIO at your end but I can get an 4GB Class 10 (10 megaBYTES per second) microSD card for about $10. I have no doubt you jump through hoops to make things as solid as they are. I wish I didn't have to jump through hoops at my end, particularly if it could be fixed with a bit more horsepower - whether that means faster CPU, RAM, disk, NIC or a combination. If it can't, it can't. Or if it's a case of it could but it simply won't, well, thems the breaks, as they say. In the mean time, I'll work with what I have and can get. At this point, I don't think it will be adding a second ISY so it currently rests on the changes I mentioned in my last post. Thanks for your replies.

Hmm, not pretty. Looks like if I wanted to go with a second ISY, I'd have to configure it from scratch. I broke up my worse high workload offender IO Linc query scene into two, spread the call to them apart by 12 seconds and made my programs fit into either the 7-12 sec space between the 1st and 2nd query or wait 7+ secs after the second query. I also stopped querying sensors separately after what I learned recently about IOLinc queries (viewtopic.php?f=27&t=11907). It's actually too bad (although understandable) that an IO Linc query hits both relay and sensor status because I only use 3 of the possible 11 sensors but have to live with the traffic - and apparent high degree of ISY processing resources it consumes - for 9 sensors I don't care about. In my definition of the perfect world, it would have been so much less work to just throw another CPU at it, as I can do with my HomeSeer VM... (and would still today happily pay for here - see viewtopic.php?f=7&t=7768&) even if that's not the most elegant / best way from an engineering point of view. This won't reduce the poor performance related to loading the GUI, backups, restores, etc. and it remains to be seen if it will eliminate all the non responses to external system events or noticeable delays of visible events like turning a light on/off, affecting the all important WAF.

I'll look for programs that call other programs that call themselves, etc. but the first two code samples above are a good and very typical example of programs that call another program in my setup. The programs that call a second program only call ONE other program and are the ONLY ONES that call that specific other program. As you see in the example in my previous post, the second program doesn't loop back into the first program, the second program DISABLES the first one AND the first one is prevented from running when the second one is running by the condition And Program 'Fan High Speed Off - Temp Sensor II' is False Often I have to use a second program to mimic an "else if" although in this and many other cases it's to workaround the fact that my temp variables change every minute. With my temp variables changing every minute (sTemp.MasterBedroom in the above example) I have to use a second program when I need to wait anything more than 59 secs - in this case a wait 15 mins done in the second program would never complete in the first program. I would also mention that, as shown in the example, I always put in a wait command, between 3-15 secs (depending on what the program is supposed to do) to allow the variables/node statuses to stabilize. So I believe I've been careful in thinking through each program and its impact on the overall state of things. I think the problem is that with 20 IO Linc nodes being checked within about 10 secs and multiple programs monitoring a number of them along with data coming in from other places - most notably my temp sensor solution - there will be many programs evaluated in a short period of time - what perhaps behaves like a "tight loop" but is really just a high workload, IMO. In the mean time, could I go back to my questions?

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