johnnyt

I have a forced air furnace with a flow through bypass humidifier, AC, and a thermostat I can control with HomeSeer right now but plan to move it to ISY. I've successfully (after some tweaking for sure) automated humidification, dehumidification and general venting. I made sure where fail safe was needed that if the relay(s) involved were off due to failure or a blown fuse or whatever, no damage was done. I have one situation where I decided to override the furnace high speed trigger and I use the Normally Closed outputs on an IO Linc instead of Normally Open such that fan high speed is ON when the IO Linc relay is OFF. That fail safe is important during AC season. I use the thermostat to lower my cool set point down when the humidity is high in summer but the temperature would not otherwise call for cooling (I don't have a dehumidify feature on my furnace/stat combo.) You have to be careful using IO Lincs in scenes where it is reversed from the other ones but that's manageable (and will be using scenes when a bug is fixed in next release viewtopic.php?f=27&t=10499) here's a thread on my HVAC related set up viewtopic.php?f=48&t=10174 and here's a post on humidifiying in particular viewtopic.php?f=27&t=10621&p=80841#p80841

Have you checked out the Logitech Harmony Remote? For just controlling your IR devices in the same room, it's pretty cool. I've had one for about 10years now. I have not set it up to trigger any insteon lighting scenes but if you have the IR version of the ISY, you can either put it into your entertainment unit or set up a remote emitter and program it to run a scene when it sees certain IR code(s). I haven't tried anything else so I can't tell you what the trade offs are but it does seem cheaper if you don't go for the top of the line remote. Sent from my iPod touch using Tapatalk

How about an X10 universal module? It's like an IO Linc but with a "sounder" option. You can just use it as a sounder (chime) either in a momentary or steady on/off configuration. I put one in my daughter's room set to momentary as part of her alarm clock "system" that starts by brightening her light slowly then ISY sends 3 X10 ON commands 3 secs apart. Sent from my iPod touch using Tapatalk

My furnace/stat combo doesn't manage humidity and recirculation so I'm glad I've got the ISY. I have to say even if I had the choice I'm not sure I would pay extra next time I buy a furnace for the heating company to take care of it because I'm betting it's a little crude in its intelligence. Maybe not, though; particularly, I would hope, if there's an outdoor temp sensor. The indoor humidity setting is highly dependent on outside temperature (if you don't want mold in your walls). Based on the mapping indicated on my humidistat and stuff I found on the net, I wrote some programs to set the recommended indoor humidity level. It's brute force programming but there's no easy equation for it (I think it actually requires Calculus): Here is my HomeSeer program (script) for it, which is both easier to post and was easier to program - but I happily moved it to the ISY: Temp is in Celcius if lngTempToUse < -28.8 then intTargetHumidity = 15 else if lngTempToUse < -27.7 then intTargetHumidity = 16 else if lngTempToUse < -26.6 then intTargetHumidity = 17 else if lngTempToUse < -25.5 then intTargetHumidity = 18 else if lngTempToUse < -24.4 then intTargetHumidity = 19 else if lngTempToUse < -23.3 then intTargetHumidity = 20 else if lngTempToUse < -22.2 then intTargetHumidity = 21 else if lngTempToUse < -21.1 then intTargetHumidity = 22 else if lngTempToUse < -20 then intTargetHumidity = 23 else if lngTempToUse < -18.9 then intTargetHumidity = 24 else ' 0F = -17.7 C -> 25% if lngTempToUse < -17.7 then intTargetHumidity = 25 else if lngTempToUse < -16.6 then intTargetHumidity = 26 else if lngTempToUse < -15.5 then intTargetHumidity = 27 else if lngTempToUse < -14.4 then intTargetHumidity = 28 else if lngTempToUse < -13.3 then intTargetHumidity = 29 else ' 10F = -12.2 C -> 30% if lngTempToUse < -12.2 then intTargetHumidity = 30 else if lngTempToUse < -11.1 then intTargetHumidity = 31 else if lngTempToUse < -10 then intTargetHumidity = 32 else if lngTempToUse < -8.9 then intTargetHumidity = 33 else if lngTempToUse < -7.8 then intTargetHumidity = 34 else if lngTempToUse < -6.7 then intTargetHumidity = 35 else if lngTempToUse < -5.6 then intTargetHumidity = 36 else if lngTempToUse < -4.5 then intTargetHumidity = 37 else 'max is 38% intTargetHumidity = 38 End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If End If Below is a snapshot of my ISY programs (to show why it would be hard to post). There's probably many ways to do this but I like this way because (FWIW) the fewest required number of programs actually run, and only one when the outside temp is above -4.5 C. I use only integer variables and only check the temp periodically since it doesn't have to be adjusted that precisely given that outdoor temp changes relatively slowly. Edit: yes, the low temp in my programs is an extreme, even where I live in eastern Ontario (Canada) where it can get very cold (-22 C last week) but that low and below is rare.

I use a flow through (bypass) humidifier similar to the one in the photo. It runs on 24 V so I use an IO Linc in latching mode to control it. The nice thing about the IO Linc is that I also use the sense with a low voltage detector probe into the mini jack of the IO Linc (that I can no longer find at Smarthome ) to detect a furnace heat call so I only run the humidifier (and other stuff) when there's a heat call and for about 3 minutes after. These flow through humidifiers drop water down an evaporator pad every 30 seconds and not much evaporates when the air going through is cold. Mine, and I suspect most, has a temp sensor to work around this but I don't use it. I also installed a motorized NC duct damper in the bypass because the bypass needs to be closed at minimum during AC season and, in may opinion, whenever the humidifier is not needed. The duct damper is fed by the same 24V source and controlled by the same IO Linc relay as the humidifier. You can read more on my HVAC and other non lighting stuff at viewtopic.php?f=48&t=10174 Hope this helps.

Anyone try or think about selling with the stuff in and some help getting started but then making it clear their services cost $40-$50 / hr after? Sent from my iPod touch using Tapatalk

I have one scene to turn all lights on and a second one that contains a few less lights for blinking program so some lights stay on (escape lighting like arw01 says). I think 1 second is too short. Suggest minimum 2 seconds, maybe even 3. Can't remember what I used (not near my console now). Sent from my iPod touch using Tapatalk

I only saved the "before" device table (after the compare), thinking the results of the compare would be saved with it but looking at the xml it doesn't look like it. Let me know if there's any point in posting just half the story.

Ended up missing a couple of KPLs in my sweep. Both of those had at least one record mismatch. One had records missing. In the latter case I decided to take a before and after screenshot. For the others previously I did save the file but the XML produces means nothing to me, while screenshots I can read, even if I'm not clear on what all the codes mean. If the xml would be of use, I can post one of those from previous compare. I tried to upload the before-and-after (restore) screenshots I took combined into one image but got the message that board attachment quota has been reached (which had been fixed a few days ago but I guess is back). In hindsight I think I should have tried reading the device table again - Could missing records be because the query quit midstream for some reason? Although most of the events were hops =2, there were some 1's and 0's, as well as a bit of normal (other) traffic happening. I'll try again to upload tomorrow or in a few days...

by the way, sometimes when restoring the device, the green "writing" arrow would disappear rather quickly even though the event viewer was still showing lots of updates being sent out for quite a while after. Kind of a problem if one doesn't have the event viewer open, perhaps thinks things are done, and tries other stuff that struggles as it competes with the device restore traffic. This was intermittent - noticed it once or twice as I went through restoring 6 KPLs.

I was checking device links tables using a KPL to generate traffic in an attempt to troubleshoot an intermittent comm trouble spot in my kitchen area. The area comm can vary from hops left 2 down to 0 depending on the time of day or the alignment of moon and sun - not sure what exactly. For fun I did a compare while I was there and it showed a couple of record mismatches. I went through and checked other KPLs and found only one that didn't have record mismatches. For the mismatches I checked, they were not insteon addresses I could find under My Lighting, i.e. not devices on my network, according to ISY anyway. I religiously follow the prime directive and link all my devices to ISY, never to themselves outside ISY. The ones I checked showed addresses like 15.A1.CF in the device and 15.A1.FF in the PLM. I didn't check them all but this was the case in a couple of instances. Seems like kind of a strange coincidence that the addresses were so close. I have had some intermittent weird things happen in my (problematic) kitchen area like turning a scene on, having all the lights in it go on as expected, then having one of the lights go off. In one case that I investigated I attributed it to what I noticed in the log was a command to turn another device off at the same time or within a second. The rest of the time, I would just write it off as related to my intermittent powerline comm issues. Weird things don't happen that often (although enough to degrade the WAF a little) and not consistently enough to blame an errant link in the affected device. I didn't investigate all mismatches but have restored all the devices, checked them again and they are fine now. Will check them again in the future but wanted to mention it here in case someone has a suggestion as to what might be happening.

Doesn't have to be bare (and no doubt can't be). My garage door openers both have an insulated antenna wire hanging down from themThe wire exiting the garage door opener is not exiting a high voltage junction box.wouldn't insulated make a difference? I'm not an electrician and I don't know all the code details but I would think the fuse would blow long before an insulated antenna wire hanging from a metal box that's grounded would be live. But maybe that's one of the differences between metal and plastic boxes, and hence maybe a code requirement where plastic boxes are permitted...

the 4-tap test? for a dual band device? I have a new dual band KPL relay (they only sell dual band kpl relays now so I got DB whether I wanted to pay for it or not) so after reading the comment I went looking on the smarthome wiki but could not find reference to the 4-tap test for it. That said the manual is for the pre-dual band model so maybe it's just missing that info. How do I test my dual band KPL relay's ability to talk to the network via RF instead of powerline? Certainly I've done the 4-tap test with my access points, although I thought in that case it was for testing that they are on separate phases, not in RF range. It turns out my kpl and the whole circuit it's on is in a marginal area for powerline insteon signals and having one of my access points 3 feet from it (on the wall behind with my metal junction box between the two) didn't help. see viewtopic.php?f=27&t=10513&p=79841&hilit=less+than+feet+away+from+access+point#p79841. You'll see veteran poster LeeG makes a few comments that might help you too.

Nor the WAF. unless you have a hole in your wall, you wouldn't see a wire hanging out of the back of a junction box...

yesterday I upgraded from 3.3.9 to 3.3.10 and after the update the browser closed but I could not reconnect to ISY. Cleared the cache, tried connecting over a span of about 5 mins but kept getting browser timeout. I went down to the ISY where the PWR, TX and RX were steady on. Pull the plug, waited a few secs, and plugged it back in. Everything was fine after. Upgrade did work and nothing was lost but thought I would mention it.

Doesn't have to be bare (and no doubt can't be). My garage door openers both have an insulated antenna wire hanging down from them

They don't help if you have metal junction box (required by code in Canada.) I think it would be nice if the antenna was a little wire that could be fed out of a hole in the box so it could dangle in the wall a little further away from metal parts. Personally the only time I would have chosen to purchase a dual band switch (if I didn't have metal boxes) is if I had to communicate with a motion sensor near the switch that was maybe a little far from my access points. Do you have any/enough access points? I don't think you can replace the need for access points with dual band devices. Sent from my iPod touch using Tapatalk

Hi Michel, If I had an unused motion sensor I could add in then cascade down through my affected sensors using "replace with" functionality (if that would even work toward troubleshooting the problem), I would gladly do that but unfortunately I don't. Removing the sensors, adding them back in and fixing the many programs that will be affected along the way seems like a lot of work unless I'm missing something about what would need to be done. Even if a factory reset fixed the problem, would that go toward identifying the root cause or would it just make the problem go away? and maybe only for a while? At least one and maybe two of the affected sensors has had its battery replaced since I went from 3.2.6 to 3.3.4 (am now on 3.3.9) if that helps narrow this down, although another one that has not been affected (yet, anyway) has also had its battery replaced not long ago. I'm due to replace the battery on another one soon and will keep an eye out for a message coming from that one in particular both before and after in case that helps.

Am getting an error dialog message in Admin Console that ISY cannot communicate with motion sensors. Been happening for several weeks. The actual motion sensor varies. None indicate low battery. The one today just had a lithium battery put into it a week ago. They have all been working okay (in range of access points) for the last couple of years, except for one that started not reaching ISY when I moved an access point, however: 1) that access point is back where it was, and 2) I wasn't getting that message for it when it wasn't working; I just noticed that things that should have triggered didn't. Overall I'm confused because I haven't seen these until recently and didn't think ISY checked the status of motion sensors given that they sleep most of the time to conserve battery power. Any info would be appreciated.

LeeG is right that the initial problem was different than what my test this morning showed. Since I deleted the IO Linc from the scene that was causing the problem I had to move the slider from 100 to 0 in another one and that's what I reported on. But if the slider move does not get written then I can't replicate the situation because I don't have another IO Linc that's already set at 0% in a scene.

Using a scene and regardless of trigger reverse setting: 1. setting the scene OFF turns IO Linc OFF whether the IOLinc was on or off before. So OFF works as expected. 2. Setting the scene ON turns or leaves an IO Linc ON that is set to 0%; something that would have turned a light off. There's no toggling (reversing) going on. The only aberration is that 0% turns the device ON instead of OFF. I think "trigger reverse" setting comes into play when one uses the sense and sets "relay follows input" - I don't use it in this case and can't confirm that right now. If this is something UDI can fix with ISY code, I personally can't think of a situation for "latching mode" where it shouldn't work like a light (0 means off), however you or others may have examples where that is the case. I might add too that there's precedent for fixing this otherwise presumably factory default behavior. I would point to the fact that ISY changes the factory default latching mode to momentary mode when linking in or restoring an IO Linc, which caused me grief a number of times before I posted about it earlier this month and the issue came to light. Thanks again to LeeG for working through these things in detail with me.

By the way, if this is the way IO Lincs (and other devices) work, can I ask that ISY show the proper state for them? Having programs triggered when the device turns ON (even though it's supposed to be being turned off) would not only be appropriate but it certainly would have helped me (maybe others?) both notice the behavior and be able to more easily identify the root cause of what I thought was a problem... well, actually, still think is a problem, at least for latching mode. Fortunately - or maybe unfortunately since it made it harder to find/track down - I only have one of my 9 IO Lincs (all similar "latching mode" HVAC applications) that I've put in OFF-when-another-one-is-ON scene. But interestingly I had been thinking of putting more of them in those kinds of scenes as a way to cut down on the number of programs I have (now at over 535). That's not going to happen now, of course. Would I need to post this idea in Product Requests or is this good enough?

Am on firmware 3.3.9 and have a v41 KPL 6 button relay setup as an 8 button kpl and was looking up the device links table with event viewer at level 3 when I noticed the message: Unexpected Response (i.e. DB range): ignored The first time I read the device links table it returned only 5 (of the 48) links with the last one being 00 00 00 ... The second time I did the query I got all 48 link records (which matches what PLM has) but still got the above message part way through. What happened? What does this message mean? If I'm to guess at it the DB stands for Dual Band. Interestingly the KPL is less than 3 feet away from an access point (on the wall behind it). I do have metal junction boxes and I know they reduce the range but 3 feet should be close enough to see it, no? Or do metal junction boxes completely block out RF even at that close a range? Overall there were a lot of hops left=2 but there were a few hop lefts=1 and 0, including a 0 just before the message. Here's an extract of the event viewer starting a little before and a couple of events after the message Sun 01/20/2013 10:44:27 AM : [iNST-SRX ] 02 50 20.43.49 1E.48.AD 27 2F 00 (00) Sun 01/20/2013 10:44:27 AM : [std-Direct Ack] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=1 Sun 01/20/2013 10:44:28 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 11 2F 00 00 01 0F 47 20 A2 05 1A 1D 09 FF 1F 07 4E Sun 01/20/2013 10:44:28 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 01/20/2013 10:44:28 AM : [iNST-TX-I2CS] 02 62 20 43 49 1F 2F 00 00 00 0F 3F 01 00 00 00 00 00 00 00 00 82 Sun 01/20/2013 10:44:28 AM : [iNST-ACK ] 02 62 20.43.49 1F 2F 00 00 00 0F 3F 01 00 00 00 00 00 00 00 00 82 06 (00) Sun 01/20/2013 10:44:28 AM : [iNST-SRX ] 02 50 20.43.49 1E.48.AD 2B 2F 00 (00) Sun 01/20/2013 10:44:28 AM : [std-Direct Ack] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 01/20/2013 10:44:29 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 11 2F 00 00 01 0F 3F 20 A2 05 17 A3 7B FF 1F 03 65 Sun 01/20/2013 10:44:29 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Sun 01/20/2013 10:44:29 AM : [iNST-TX-I2CS] 02 62 20 43 49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A Sun 01/20/2013 10:44:29 AM : [iNST-ACK ] 02 62 20.43.49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A 06 (00) Sun 01/20/2013 10:44:31 AM : [iNST-ERX ] 02 51 20 43 49 1E 48 AD 13 2F 00 00 01 0F 3F 20 A2 05 17 A3 7B FF 1F 03 65 Sun 01/20/2013 10:44:31 AM : [Ext-Direct ] 20.43.49-->ISY/PLM Group=0, Max Hops=3, Hops Left=0 Sun 01/20/2013 10:44:31 AM : [Ext MH ] Unexpected Response (i.e. DB range): ignored Sun 01/20/2013 10:44:40 AM : [iNST-TX-I2CS] 02 62 20 43 49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A Sun 01/20/2013 10:44:40 AM : [iNST-ACK ] 02 62 20.43.49 1F 2F 00 00 00 0F 37 01 00 00 00 00 00 00 00 00 8A 06 (00)

LeeG, Thanks for the detailed response. The insight is always appreciated. I see this as about basic device behavior and would not personally position it as describing the internals of link records. The concept that sending 0% on level turns a light off is well known and a key benefit of insteon automation. (By the way I use the latching mode of the io linc, not the momentary modes and not for a garage door application.) Maybe there's good reason to have a different story for lighting vs non-lighting but I think it should be better publicized, especially since it's different than the well known behavior. I say that but maybe I'm the only one who didn't know the difference in behavior. I also think the latching mode of an IO Linc should behave like a light. I realize this comment should be made in the Smarthome forum more than this one. Just mentioning it in case UDI can fill another gap, as it so often does, and save others some grief. (Personally, now that I know I'll just work it) Thanks again.

Thanks for pointing out the needle in that haystack, but I'm confused. It's counter to all other scenes I have that turn a device off when the scene is turned on or off when the device is set to 0 on level in the scene. Is this unique to IO Lincs? If so, I guess it means I'll have to take the IO linc I want off out of the scene and write a program to do the work instead. And I guess it would explain past weirdness that I didn't understand (and didn't always notice), but what's up with that approach? Is it useful for garage door applications or something? Where is this in the Smarthome documentation? Did I just miss it? Could it be added to ISY doc (assuming I didn't just miss it there either)? It seems like kind of an important exception for people to know, whatever the application.