johnnyt

Thanks. That would explain why this one happens daily without fail. I changed the program to send an OFF. I don't actually remember setting it to do a Fade Down but that's what was there. Probably did it to get a nice slow off since the local ramp rate is not that slow, but maybe I'll just create a scene to do it. I'm not going to notice / look for a companion switch being off when it should be on given that no load is attached to it so for this device I'm not too worried about it. For other things though, like my bedroom ceiling light (original post), this issue is of greater concern. I'll have to watch more closely and, I guess, run more overnight level 3 event viewer and sift through the data as I now think this may explain other misbehavior that I just ignored. For example I've occasionally gotten up in the middle of the night to find lights on downstairs and just turned them off without looking into it.

Thanks for the reply, LeeG. Am, not worried about the EZIO8SA here unless querying it caused or contributed to ISY crashing. I have another post on the EZIO8SA and will update that post when I have more data from some programs I added yesterday to do a second round of query tests when the status is not as expected. For this problem, I left the event viewer at level 3 overnight last night and the following two unexpected statuses were reported during the 3AM query: Scene:My Lighting Status Query Sun 2014/02/02 03:00:03 AM Program Log Main Floor / Front Inside Light Status 0% Sun 2014/02/02 03:00:29 AM System Log Main Floor / Front Light Companion Sw Status 100% Sun 2014/02/02 03:00:30 AM System Log Below is the event viewer data: Front Inside Light = 16.10.F6 Front Light Companion SW = 0F.D4.91 Sun 02/02/2014 03:00:22 AM : [iNST-TX-I1 ] 02 62 16 10 F6 0F 19 00 Sun 02/02/2014 03:00:22 AM : [iNST-ACK ] 02 62 16.10.F6 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:22 AM : [iNST-SRX ] 02 50 16.10.F6 24.1B.FE 27 22 00 (00) Sun 02/02/2014 03:00:22 AM : [std-Direct Ack] 16.10.F6-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 0F D4 91 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 0F.D4.91 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 2B 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 02/02/2014 03:00:23 AM : [iNST-TX-I1 ] 02 62 16 D9 56 0F 19 00 Sun 02/02/2014 03:00:23 AM : [iNST-SRX ] 02 50 0F.D4.91 24.1B.FE 23 0F FF PING (FF) Sun 02/02/2014 03:00:23 AM : [std-Direct Ack] 0F.D4.91-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 02/02/2014 03:00:23 AM : [iNST-ACK ] 02 62 16.D9.56 0F 19 00 06 LTSREQ (LIGHT) Sun 02/02/2014 03:00:24 AM : [iNST-SRX ] 02 50 16.D9.56 24.1B.FE 2B 0A FF LNK-OFF(FF) Sun 02/02/2014 03:00:24 AM : [std-Direct Ack] 16.D9.56-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Did the Front Light Companion Sw respond twice? Both devices had been turned off earlier in the evening with the push of a Front KPL Sleep button. Here are the log entries showing that: Main Floor / FrontKPL.H-Sleep Status 100% Sat 2014/02/01 09:46:02 PM System Log Scene:All ON/OFF Downstairs Off 0 Sat 2014/02/01 09:46:03 PM Program Log Main Floor / Front Light Companion Sw Status 0% Sat 2014/02/01 09:46:03 PM System Log Kitchen / EatingKPL.1 Status 0% Sat 2014/02/01 09:46:03 PM System Log Kitchen / EatingKPL.1 Off 0 Sat 2014/02/01 09:46:06 PM Program Log 30 secs after KPL Sleep Button is pushed, Front Inside Light is turned off, per the program I have: Main Floor / Front Inside Light Fade Start 0 Sat 2014/02/01 09:46:33 PM Program Log Below is the corresponding event viewer data: Front Light Companion SW is part of All ON/OFF Downstairs scene, which I presume is the highlighted address below (in ISY the scene number is 51164) 17.A3.7B is FrontKPL address 18.58.D8 is EatingKPL address Sat 02/01/2014 09:46:04 PM : [iNST-SRX ] 02 50 17.A3.7B 00.00.08 C3 11 00 LTONRR (00) Sat 02/01/2014 09:46:04 PM : [std-Group ] 17.A3.7B-->Group=8, Max Hops=3, Hops Left=0 Sat 02/01/2014 09:46:04 PM : [ 17 A3 7B 8] DON 0 Sat 02/01/2014 09:46:04 PM : [iNST-SRX ] 02 50 17.A3.7B 24.1B.FE 41 11 08 LTONRR (08) Sat 02/01/2014 09:46:04 PM : [std-Cleanup ] 17.A3.7B-->ISY/PLM Group=8, Max Hops=1, Hops Left=0 Sat 02/01/2014 09:46:04 PM : [iNST-DUP ] Previous message ignored. Sat 02/01/2014 09:46:04 PM : [ 17 A3 7B 8] ST 255 Sat 02/01/2014 09:46:04 PM : [iNST-TX-I1 ] 02 62 00 00 14 CF 13 00 Sat 02/01/2014 09:46:04 PM : [iNST-ACK ] 02 62 00.00.14 CF 13 00 06 LTOFFRR(00) Sat 02/01/2014 09:46:04 PM : [ F D4 91 1] ST 0 Sat 02/01/2014 09:46:04 PM : [ 18 58 D8 1] ST 0 Sat 02/01/2014 09:46:07 PM : [iNST-TX-I1 ] 02 62 18 58 D8 0F 13 00 Sat 02/01/2014 09:46:07 PM : [iNST-ACK ] 02 62 18.58.D8 0F 13 00 06 LTOFFRR(00) Sat 02/01/2014 09:46:08 PM : [VAR 2 56 ] 34 Sat 02/01/2014 09:46:08 PM : [iNST-SRX ] 02 50 18.58.D8 24.1B.FE 2B 13 00 LTOFFRR(00) Sat 02/01/2014 09:46:08 PM : [std-Direct Ack] 18.58.D8-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sat 02/01/2014 09:46:08 PM : [ Time] 21:46:07 4(0) and 30 secs later: Sat 02/01/2014 09:46:34 PM : [iNST-TX-I1 ] 02 62 16 10 F6 0F 17 00 Sat 02/01/2014 09:46:34 PM : [iNST-ACK ] 02 62 16.10.F6 0F 17 00 06 LTMCON (DOWN) Sat 02/01/2014 09:46:34 PM : [VAR 2 68 ] 3 Sat 02/01/2014 09:46:34 PM : [iNST-SRX ] 02 50 16.10.F6 24.1B.FE 23 17 00 LTMCON (DOWN) Sat 02/01/2014 09:46:34 PM : [std-Direct Ack] 16.10.F6-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 There are no other entries for those devices in either the log or the event viewer between 9:46 PM and 3 AM, and the Front Light was not on when I got up this morning (and no program would have turned it off if something had turned it on so it would have been on when I got up.)

I'm finding the 3 AM "query all" regularly returns unexpected statuses that are either likely false or confirmed false. In researching this, I also uncovered a nasty little surprise. More on that in a minute. First, looking back over the past two nights, starting with last night / this morning, the following events were recorded at 3AM: Scene:My Lighting Status Query Fri 2014/01/31 03:00:03 AM Program Log Main Floor / Front Inside Light Status 0% Fri 2014/01/31 03:00:37 AM System Log Bedrooms / Master Bedroom Ceiling Light Status 100% Fri 2014/01/31 03:00:46 AM System Log This had a downstream effect because I have a program that calls a night lighting scene (a bedroom floor lamp to about 20%) after the bedroom ceiling light has been on for 1 hour. So shortly after 4AM the last 2 nights, our bedroom floor lamp has gone ON to 20%. The Front Inside Light being at 0% should not have been a surprise to ISY as that light had been turned off several hours earlier. Similarly, the Master Ceilling Light had been turned OFF long before, and I can confirm that it was OFF all night or it would have woken me up / kept me from sleeping. The OFF events of earlier in the night are shown as having been picked up by ISY in these log entries: Bedrooms / Master Bedroom Ceiling Light Status 0% Thu 2014/01/30 08:34:32 PM System Log Main Floor / Front Inside Light Fade Start 0 Thu 2014/01/30 08:36:36 PM Program Log Here's an excerpt from the error log around 3AM. Fri 2014/01/31 03:00:49 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:00:52 AM System -10 n/a Fri 2014/01/31 03:00:54 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:00:59 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:04 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:09 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:14 AM System -170001 [uDSockets] HTTP:20 error:6 Fri 2014/01/31 03:01:19 AM System -170001 [uDSockets] HTTP:20 error:6 I was not able to find error -170001 on the wiki but found that error -10 means "UNEXPECTED DEVICE RESPONSE ". Of course in response to the 3AM query that could have been about any of many devices. Similarly, this happened last night and I can confirm that neither of the lights reported as ON were ON. Scene:My Lighting Status Query Sat 2014/02/01 03:00:03 AM Program Log Bedrooms / Master Bedroom Ceiling Light Status 100% Sat 2014/02/01 03:00:45 AM System Log Bedrooms / Boys Bedrm Ceiling Light Status 26% Sat 2014/02/01 03:00:52 AM System Log Bedrooms / Master Bedroom Ceiling Light Status 0% Fri 2014/01/31 07:50:34 PM System Log Bedrooms / Boys Bedrm Ceiling Light Status 0% Fri 2014/01/31 07:50:50 PM System Log Error Log around 3AM: Sat 2014/02/01 03:00:10 AM System -10 n/a Below are more 3AM query all log entries. 1D.5B.9E is a v41 IOLinc, which very frequently responds to being queried (causing programs to run when they shouldn't or don't need to) - I believe this to be a flaw in this particular IO Linc. I have 2 v41 IOLincs and 9 v36 IO Lincs and only this one behaves this way. Front Inside Light is a frequent repeat offender Scene:My Lighting Status Query Fri 2014/01/17 03:00:00 AM Program Log 1D.5B.9E-Sensor Status 0% Fri 2014/01/17 03:00:24 AM System Log 1D.5B.9E-Relay Status 0% Fri 2014/01/17 03:00:25 AM System Log 1D.5B.9E-Sensor Status 100% Fri 2014/01/17 03:00:25 AM System Log Main Floor / Front Inside Light Status 0% Fri 2014/01/17 03:00:27 AM System Log Scene:My Lighting Status Query Sat 2014/01/18 03:00:00 AM Program Log 1D.5B.9E-Sensor Status 0% Sat 2014/01/18 03:00:25 AM System Log 1D.5B.9E-Relay Status 0% Sat 2014/01/18 03:00:25 AM System Log 1D.5B.9E-Sensor Status 100% Sat 2014/01/18 03:00:26 AM System Log Main Floor / Front Inside Light Status 0% Sat 2014/01/18 03:00:28 AM System Log Scene:My Lighting Status Query Sun 2014/01/19 03:00:01 AM Program Log 1D.5B.9E-Sensor Status 0% Sun 2014/01/19 03:00:25 AM System Log 1D.5B.9E-Sensor Status 100% Sun 2014/01/19 03:00:26 AM System Log I'll stop there but these kinds of unexpected (to me) responses are a daily occurrence in the life of this log file. Now to the nasty surprise I uncovered. Looking back at all my "query all's" I noticed this little gem that was not initiated by me: 0 null Sun 2014/01/19 04:41:45 PM System Start Scene:My Lighting Status Query Sun 2014/01/19 04:42:29 PM System Log this was followed by about 3 mins and 250 status reporting entries in the log (which is more than the ~170 nodes I have), followed by a second "query all" with more responses Scene:My Lighting Status Query Sun 2014/01/19 04:45:13 PM Program Log X10 G9 Status = On ( Sun 2014/01/19 04:45:14 PM System Log X10 Transceiver Module Outlet Status 100% Sun 2014/01/19 04:45:14 PM System Log 15 B9 70 2 Status 0% Sun 2014/01/19 04:45:24 PM System Log 1D.5B.9E-Relay Status 100% Sun 2014/01/19 04:45:49 PM System Log Wouldn't ISY already know this from the query all just before? Unfortunately my error log doesn't go that far back (I have been doing a lot of level 3 event viewing lately so the error log is full) Below is what was happening just before the crash. The "web" entries indicates I was doing some testing of my new EZIO8SA at the time. I suspect this ISY crash only looked like a GUI crash to me, which happens with some regularity. And because at over 700 programs, 200 variables and 172 nodes the GUI takes so long to load for me, I believe I didn't notice / clue in to the fact that ISY had crashed so didn't know until now that's what happened. 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/01/19 04:35:47 PM Program Log Scene:1-MISC (Non Lighting) / HVAC / HVAC Sensors Status Query Sun 2014/01/19 04:35:53 PM Program Log 1-MISC (Non Lighting) / HVAC / Sensor - Heat Off - Office Da Status 100% Sun 2014/01/19 04:35:53 PM System Log 50405 Status Query Sun 2014/01/19 04:36:13 PM Program Log Main Floor / Laundry Room Motion-Sensor Status 100% Sun 2014/01/19 04:36:56 PM System Log Main Floor / Laundry Room Motion-Sensor Status 0% Sun 2014/01/19 04:37:32 PM System Log Z-Unused Relay Sensors / Relay for Fan OFF Sensor Off Sun 2014/01/19 04:38:00 PM Web Log Z-Unused Relay Sensors / Relay for Fan OFF Sensor Status 0% Sun 2014/01/19 04:38:03 PM System Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Off Sun 2014/01/19 04:38:21 PM Web Log 1-MISC (Non Lighting) / HVAC / Office Damper-EZIO.4 Status 0% Sun 2014/01/19 04:38:25 PM System Log Z-Unused Relay Sensors / Relay for Fan OFF Sensor Status Query Sun 2014/01/19 04:38:35 PM Program Log Z-Dusk and Low Bat Sensors / Laundry Room Dusk-Dawn Status 0% Sun 2014/01/19 04:38:38 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 On 255 Sun 2014/01/19 04:38:55 PM Program Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Error 1 Sun 2014/01/19 04:38:59 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Sun 2014/01/19 04:38:59 PM System -2 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Error 0 Sun 2014/01/19 04:39:00 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Sun 2014/01/19 04:39:00 PM System Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status Query Sun 2014/01/19 04:39:25 PM Web Log 1-MISC (Non Lighting) / HVAC / Basement Dampers - EZIO8SA.1 Status 100% Sun 2014/01/19 04:39:26 PM System Log Bedrooms / Boys Bedroom Table Lamp Status Query Sun 2014/01/19 04:40:00 PM Program Log 0 null Sun 2014/01/19 04:41:45 PM System Start What's going on with the query all responses, and is there any clue in the above as to why ISY crashed?

but it's intermittent - in practice this would mean I need to run at level 3 for as much as a day (it usually happens at least once a day) and hope it happens sooner rather than later. Long ago I was told not to leave the event viewer at level 3 as the disk (and ISY performance?) gets hammered with data logging. is it overly simplistic to suggest ISY simply ignore duplicate message to a single query command? - By duplicate message I assume you don't mean the second distinct message that comes in (one for the outputs, one for the inputs), e.g. RINPUT (00) and RINPUT (30) in this sample query I just ran: Thu 01/30/2014 07:48:21 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 4F 02 Thu 01/30/2014 07:48:21 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 4F 02 06 IOCTL (QUERY) Thu 01/30/2014 07:48:21 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 4F 4A IOCTL (4A) Thu 01/30/2014 07:48:21 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Thu 01/30/2014 07:48:22 PM : [ 28 AD BD 1] ST 0 Thu 01/30/2014 07:48:22 PM : [iNST-TX-I1 ] 02 62 28 AD BD 0F 49 00 Thu 01/30/2014 07:48:22 PM : [iNST-ACK ] 02 62 28.AD.BD 0F 49 00 06 RINPUT (00) Thu 01/30/2014 07:48:22 PM : [iNST-SRX ] 02 50 28.AD.BD 24.1B.FE 2B 49 30 RINPUT (30) Thu 01/30/2014 07:48:22 PM : [std-Direct Ack] 28.AD.BD-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

Am intermittently seeing EZIO8SA devices being ON (or at least reporting ON) when they should be OFF. I first emailed Smartenit support and, in a fit of laziness, simply copied most of it and their reply here as the body of my post. (I left the comment he made to me about the EZX10RF as an FYI.) Note that I happen to know he has only just upgraded ISY to the current 4.1.2 version today - and replied to him my concern that he hadn't really had much of a chance to test this...

I just got an EZIO8SA to replace some IOLincs I use to control HVAC stuff. So far, it looks like this will be a good move but with a drawback being that I don't have a visual indicator that a relay is on at the EZIO (which is not anywhere near my ISY admin console). There also isn't a button to physically turn them on/off manually but that's less of an issue. Does anyone know if I would be able to connect a small LED between NO and C (the terminals I use) of each relay to give me a visual of the state the relay is in? I'm using some of the relays to run 24VAC to duct dampers and some to "jumper" a setting in my furnace (fan on, fan high speed), also 24VAC. Of course I would look for LEDs that can handle 24V and think they would flicker because of the AC but that wouldn't bother me. Just as long as it would a) work and not fry something. Any info or suggestions would be appreciated.

Thanks so much for the insight, LeeG. This will be so much more efficient than querying 8 IOLincs individually or as part of a scene given that each query of an IOLinc returns an individual response for both the relay and the sensor in the IO Linc (16 response messages instead of one). I wish I would have known about this product sooner and am so glad it's working out of the box.

I was querying nodes 2 and 3 for my testing. Querying node 1 DOES send a command out but I only got a response back for node 1. For the record I do have input 5 & 6 connected to Gnd and I double checked the packaging - the only cable was a blue network cable that plugs the PLM into the EZIO8SA.

I just bought an EZIO8SA and PLM combo to replace some IOLincs. I was able to link it to ISY and am able to turn relays on and off no problem but a query does not work. With the event viewer at level 3 there is NOTHING sent out when I do a query. I did find/read the post related to the ISY status not being updated at viewtopic.php?f=27&t=12405 but the query worked in that case. My problem is the opposite of that: the status works fine but the query doesn't. I downloaded the smartenit utility but there are no instructions in the download or online on how to connect the PLM so the utility can communicate with it. It means that for the moment I can't find anything out about the PLM around firmware version, etc. to do some of the troubleshooting steps suggested in the other post. FWIW, a smarthome forum post on this subject indicates I'm not the only one who's come across this and seems to indicate that I will need a special cable that did not come with the kit and that I don't have. I contacted support@smartenit.com about this but thought I would mention it here in case someone can help on this front. Any suggestions would be appreciated.

Would like to tentatively close on this. The problem has not re-occurred at this point and I suspect it won't because I reduced the workload demands I've been placing on ISY. It may yet re-occur but given the additional test programs I've been running to try to cause/observe another instance of the problem and the fact that no one else seems to have encountered the problem I'm thinking it won't happen again with this firmware generation. Briefly, I've been running 4.0.11 (an alpha release with more debug info being captured as I understand it) for well over a month. I also created 24 programs like the following one to run each hour: If Time is 1:00:00AM Then Send Notification to 'me' content 'Generic Main Log' Else - No Actions - (To add one, press 'Action') The notification sends an email and writes to a log using this feature viewtopic.php?f=25&t=10905. Writing to a log file resolved / worked around the issue of an email not making it out, which happened at least half a dozen times. (Thank you UDI for the log feature; it's been a helpful troubleshooting tool) For more info on my workload issues see viewtopic.php?f=27&t=11999#p92535. And the workaround that I suspect fixed the problem is in this post viewtopic.php?f=27&t=11999#p92637 I'll report back if something changes.

No, my cert is gone and all they're going to do is give me my $18 back (I think - not even sure I'll get it all back) which isn't going to help me now that price for 1 yr has gone up to $65. I might try to fight with a free cert I read about or wait until/if there's another $6/yr sale again. I don't know what I'll do at this point. Are there better instructions somewhere (or coming) or is the current method of having to guess at what actually applies in the current doc + read through forum + try to fill in the gaps with trial and error as good as it gets? Sorry. I'm a little ticked off right now. Sent from my iPad using Tapatalk

hbsh01, Firefox is giving me a "cannot connect" message. Michel, yes, I'm running 4.0.11 as part of trying to get to the bottom of this viewtopic.php?f=27&t=11873 For the benefit of all, Revoking a cert is NOT the way to go if you can avoid it. Here's an excerpt from an email I got from godaddy about it: They offered to give me an "in store credit" so I could buy another one. At least I hope so. I paid $18 for 3 years but now the price for an SSL cert is $65 per year. If all they give me back is $18 I won't be able to buy a new cert with that. Just waiting to see what happens now.

Tried to "rekey" cert instead of revoke, which allowed me to immediately copy in an ISY server cert request and also immediately created a new cert that I downloaded, opened using notepad and copied into "Receive Cert" in ISY Server Certificate. Problem is I still get a message that I can't connect after that. So I went the "revoke" route but now I have to wait (up to 24 hours) for that cert to get revoked, then I guess I'll have to go through the whole cert approval process - another up to 24 hours. sigh.

oops. just realize I meant to post here viewtopic.php?f=3&t=12074&p=94138#p94138, not this thread. thanks. will cancel/revoke current cert and request server cert then open it in notepad. wish the instructions were clearer.

I need help with this. It's not working for me. Am on 4.0.11. All is there in ISY (minus cert stuff, I presume) and on router for ISY to answer from the internet on port 443. Have followed this thread and: - got a godaddy credit for a cert for $6 - got a Dyn DNS Standard account for $30 - changed my domain name's nameserver to DynDNS nameservers - did a whois to see my domain pointing to DynDNS nameserver - checked my DynDNS account to see that my IP address is correct for isy.mydomain.com - opened up http/80 on my router, tried it with isy.mydomain.com and it worked followed the UDI instructions and: - created a Cert Request (CSR) under "Client Certificate" (TLS 1.2, High, no verify, SHA-2, 2048 bit) - copy/pasted CSR data and provided it to godaddy - did what was needed to get the cert approved for my - received two .crt file from godaddy, one for my subdomain and one called gt_bundled-g2.crt - imported them both under "CA Certificates" in the ISY dashboard - did nothing with "Server Certificate" - do I need to? if so, can I use the same cert credit (didn't see anything anywhere about needing two certs) - couldn't do anything with "receive cert" as UDI instructions seems to suggest because I don't have anything to copy/paste into it. Or at least I can't find what to copy/paste info to paste in. - ISY didn't reboot, as suggested in instructions, so I manually rebooted it. I get unable to connect message. help, what am I missing?

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?