johnnyt

A scene activated by a v.36 KPL secondary button suddenly stopped doing its thing after working for years. It's an "After Dinner" scene that we use quite often so whatever happened to break it is recent. When I looked at the scene in question the KPL button that was the scene's controller was no longer part of the scene. Re-adding the button to the scene fixed the problem but its disappearance concerns me. I have not messed with the KPL in question for quite a while, and it's been even longer since I messed with the scene in question. That said, I have added and modified other scenes involving other devices within just the last few days. Has anyone seen / Is there a known issue with KPL scenes getting mucked up like this when one is configuring scenes in other device(s)? I can't say I've seen this before but I have had other weird things happen to KPL's before. See list below. While the cause remains unknown or unclear for the issues below, it appears in some cases to be related to the KPL having been restored. viewtopic.php?f=27&t=10175 viewtopic.php?f=27&t=9297 viewtopic.php?f=28&t=7911 viewtopic.php?f=27&t=10577 While the KPL in this case has been restored before, it was a long time ago and it did not / does not exhibit the problems reported above. (The non-toggle mode and LED brightness problem are still there for another v36 KPL right next to it.) After fixing things I did check the device links table and compared it to what the PLM link table has for it and everything is fine with the 60 or so device links. In hindsight I wish I would have checked the two before re-adding the button. Am using a 994i with the latest firmware and my PLM has 415 links - well below the max, I believe.

Interesting to read about this, although I still don't quite understand its use/purpose. I think it might help me understand - and maybe get two birds with one stone - if someone could comment on whether or not it would help troubleshoot intermittent comm error messages from ISY about motion sensors? viewtopic.php?f=27&t=11266.

I can't find one. I've attached an updated screenshot of the validation emails I get from the program that runs at 1:00AM to check the day of the week and it includes the latest two occurrences. If you see a pattern let me know. Until today I haven't had any other program scheduled to run at the same time. I added one today to fix to other (confirmed unrelated) issue I mention in my last post. I guess I'll get to see if both are affected by this if it happens again. Also, as of tonight I'm running a special firmware version that will provide UDI some debug info. I've added programs to send me a notification every hour hoping that expedites the next occurrence.

Yep, that's it. I only turned it on a few months ago and last week was no doubt the first time ISY rebooted since I did it. I guess I'll have to move my daily reset to 11:59PM (given that catch up only goes back 12:00AM) and will have to check other programs that might be in the same boat but haven't caught my eye.

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.