johnnyt

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)

Don't forget to consider that you (or someone else) might want or have to remove whatever insteon stuff you put in one day. Switches and bulbs are the easiest to "undo" and fix. Sent from my iPod touch using Tapatalk

Could comm error messages, in particular like the ones that I get occasionally from motion sensors (this thread) but also ones from always on devices, happen because of network connection problems between the GUI and ISY? I'm wondering about possible network (LAN) problems that might be causing some issues and want to know if comm errors could be a symptom of that kind of problem.

One is not available and I don't particularly want to run the event viewer at level 3 all day in the hope of catching one of these infrequent events. Recently when I've run the event viewer at level 3 it's hammered my ISY to the point of causing performance problems. See viewtopic.php?f=27&t=11219 for more info. Is there another way, or just some possible causes?

Every now and again I get a dialog box that says ISY can't communicate with a motion sensor. Got one a few minutes ago and looked at the log entries (below) to see a whole bunch of good comms followed by some kind of error right after it reports ON then everything goes back to normal. I've separated the bad from the good using a "code" box. Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:49:26 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:50:31 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:50:40 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:52:09 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:52:16 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:52:46 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:54:16 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:54:46 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:54:50 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:55:46 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:57:05 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:57:35 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:58:00 PM System Log Basement / Rec Room Motion-Sensor Error 1 Fri 2013/04/12 04:58:01 PM System Log Basement / Rec Room Motion-Sensor Fri 2013/04/12 04:58:01 PM System -2 Basement / Rec Room Motion-Sensor Error 0 Fri 2013/04/12 04:58:55 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:58:55 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 04:59:28 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 04:59:57 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 05:00:25 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 05:00:56 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 05:01:12 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 05:01:42 PM System Log Basement / Rec Room Motion-Sensor Status 100% Fri 2013/04/12 05:01:53 PM System Log Basement / Rec Room Motion-Sensor Status 0% Fri 2013/04/12 05:02:48 PM System Log This is a well used motion sensor that fails (or should I say, generates an error) only a fraction of the time relative to how often it doesn't. There's no indication the battery is low, at least not from it's low battery warning. Also, the lithium ion "10 year" battery in it is only a few months old and I track it's usage through a variable (since the low battery warning has proven largely unreliable in my experience) so I know that barring a defect it's got a lot of life left in it. FWIW, the last entry in the error log is: Fri 2013/04/12 02:57:40 PM System -170001 [uDSockets] HTTP:32 error:6 What might be going on?

What would make me FEEL better is knowing why ISY crashed twice a month ago, once apparently deleting or corrupting the error log and once after filling one up within a few days. I thought maybe I was getting closer but I guess I'm not.

I've got HOURS of log entries about socket 27, 32, 33 and others but can't tell if all entries are about the same socket 27, 32 and 33 throughout, or if a new socket just ends up with an old number. Should I send you the ~4MB file for you to see? Alternatively, can you add an informational message that shows when a socket is dropped in the next beta?

Thanks for the info. I'm a little confused because I know I did not have the event viewer on level 3 for the entire period from Friday 2 AM until I restarted the GUI at 8:30 last night. I specifically had to change the level to 3 yesterday (Sat) afternoon to verify communications in my kitchen area so I know it was at level 1 for most of the time the log was filling up. Not to say I hadn't changed it to 3 at some point in the past but it was at level 1 between Fri 2 AM and yesterday afternoon. Maybe I'll do some testing to see if once the event viewer gets set to 3 it remains there for logging purposes regardless of what I set it back to subsequently. What about sockets not being active for extended periods of time? I looked back and 27 was not the only socket not active; there were several others in the log file. I didn't review them all but a few I followed from start to finish were "not active" for 4-5 hours. Much of the time the log file was getting hammered with entries 3-6 times per second with only 1 or 2 second pauses in between. Is it ISY that doesn't close the socket or a subscriber to ISY? How do I find out which subscriber(s) is/are involved? This amount of logging of non active sockets has me worried there's a problem with my setup and I'm wondering if the problem is at the root of the two crashes I encountered less than a month ago (see viewtopic.php?f=25&t=11001), which remain a mystery and included both a lost error log file and a full (4.7MB) error log...

Last night I was noticing performance problems and checked the error log, a ~4MB file full of messages like this: Sat 2013/04/06 08:34:28 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:28 PM System -170001 [HTTP] 192.168.0.55:1465->80 Sat 2013/04/06 08:34:29 PM System -170001 0: GET-->/rest/vars/set/2/52/348 Sat 2013/04/06 08:34:29 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:32 PM System -170001 [HTTP] 192.168.0.55:1466->80 Sat 2013/04/06 08:34:32 PM System -170001 0: GET-->/rest/vars/set/2/58/1850 Sat 2013/04/06 08:34:32 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:34 PM System -170001 [HTTP] 192.168.0.55:1467->80 Sat 2013/04/06 08:34:34 PM System -170001 0: GET-->/rest/vars/set/2/59/2068 Sat 2013/04/06 08:34:34 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:35 PM System -170001 [HTTP] 192.168.0.55:1468->80 Sat 2013/04/06 08:34:35 PM System -170001 0: GET-->/rest/vars/set/2/61/2125 Sat 2013/04/06 08:34:35 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:37 PM System -170001 [HTTP] 192.168.0.55:1469->80 Sat 2013/04/06 08:34:37 PM System -170001 0: GET-->/rest/vars/set/2/51/181 Sat 2013/04/06 08:34:37 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:38 PM System -170001 [HTTP] 192.168.0.55:1470->80 Sat 2013/04/06 08:34:38 PM System -170001 0: GET-->/rest/vars/set/2/50/2468 Sat 2013/04/06 08:34:38 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:40 PM System -170001 [HTTP] 192.168.0.55:1471->80 Sat 2013/04/06 08:34:40 PM System -170001 0: GET-->/rest/vars/set/2/62/968 Sat 2013/04/06 08:34:40 PM System -170001 [HTTP] Socket not active#2 27 Sat 2013/04/06 08:34:41 PM System -170001 [HTTP] 192.168.0.5:11238->80 Sat 2013/04/06 08:34:41 PM System -170001 [HTTP] 192.168.0.5:11241->80 Sat 2013/04/06 08:34:42 PM System -170001 [HTTP] 192.168.0.55:1472->80 Sat 2013/04/06 08:34:42 PM System -170001 0: GET-->/rest/vars/set/2/60/2093 Sat 2013/04/06 08:34:50 PM System -170001 [HTTP] 192.168.0.5:11242->80 Sat 2013/04/06 08:34:53 PM System -170001 [HTTP] Socket not active#2 27 ...going back to Friday 2 AM Friday (about 42 hours worth) FWIW, at 192.168.0.55 is an Autelis RS232-to-ISY bridge reading data from my 1-wire temp/humidity sensor solution, and at 192.168.0.5 is the Admin GUI, which I leave running 24/7 Restarting the GUI fixed the problem. Does that mean it's what lived at socket #2 27? Are the entries happening at the same time related or unrelated and just coincidental? How do I find out for sure what lives at socket #2 27? Why doesn't ISY (or the subscriber to ISY?) close the socket after a period of time? Also, I understand from a previous post that having the event viewer at level 3 can fill the error log with these messages and I did have the event viewer at level 3 for a few hours yesterday afternoon, but before that (going back to 2AM Friday) it was at the default level 1. Does that mean the messages are warnings rather merely informational, as I understand they usually are? Finally, at what point (if any) does the error log drop the oldest entry to make room for the next one, e.g. is it by size or number of lines? Any info would be appreciated.

here's a thread on what I use: viewtopic.php?f=78&t=9840 if I was to do it over again (with the equipment I have), I would look at doing it like this: viewtopic.php?f=78&p=81828#p81828 the CAI board, which is very popular here so you would get good support, has only one humidity sensor. I would have needed 8 of them to do what I want to do

Ditto Sent from my iPod touch using Tapatalk