LeeFleishman

When Admin Console is accessed via ISY Portal, attempting to use the "Notes" function fails. This is consistent across all of the many ISYs that I manage for clients (all are at firmware 4.7.3). The failure manifests as follows: When a Note is created or edited (for a device or scene), it appears to succeed when the Save button is clicked. However, if any other action (e.g. turn on a device, query a device, recall the Note just edited, etc.) is attempted within the next 20 seconds, a "Socket Timeout Error" is displayed. If more than 20 seconds pass before that subsequent action is attempted, the "Socket Timeout Error" does not occur. In either case, the change(s) made to that Note were not saved. This failure does not occur if Admin Console is accessed via DDNS , or local connection.

It's also very important to know that there are in fact TWO different kinds of 3-way wiring configurations (both are legal/code-compliant). The most common 3-way circuit utilizes TWO traveler wires between the two 3-way (SPDT) switches. One of those switches has line voltage connected to its common terminal. The other 3-way switch has the load wire (sometimes referred to as the "switchleg" wire) connected to its common terminal. The two traveler wires connect to the non-common terminals at each switch. In the less common 3-way configuration (sometimes called the "Coast" or "West Coast" 3-way), there is only ONE traveler wire between the two 3-way switches, and it connects to the common terminal at EACH switch. EACH switch box also has a load wire from the light fixture AND a line voltage wire (the line voltage wire in each box is, or at least SHOULD BE, from the SAME circuit breaker). In each switch box, the line voltage wire connects to one of the switch's (non-common) terminals, and the load wire connects to that switch's other (non-common) terminal. Regardless of which configuration is present, conversion to INSTEON SWL or KPL is fairly straightforward, as long as each switch box has a real (confirmed) Neutral wire. In the case of the less common "Coast" 3-way, the load wire from the light fixture in ONE of the switch box locations is capped off and not used (as is the red wire of the INSTEON device in that switch box). It doesn't matter which INSTEON device is connected (by its Red wire) to the load wire. I hope this helps. Lee Fleishman INControl Home Automation Certified INSTEON Integrator Thousand Oaks, CA

Just sat down to re-cap another 2413S. This time, it's a brand new one slated for a new system I'll be installing tomorrow for a new client. My thinking is that re-capping now may prevent the all-too-common failure 2+ years from now (couldn't hurt, right?). The label on this new PLM indicates that it is rev V1.C, with the date code 1425. Upon dis-assembly and inspection, I found that: **C7 and C13 are now 100uF, 35V, Fujicon (as opposed to 10uF, 35V, Samcon); **C3 is still 6.8uF, 250V but it is no longer Yihcon brand (now it's "CA" brand, as best as I can tell); **C8 and C11 are both unchanged from earlier rev units (as specified by danu1964). I suspect the changes at C7 and C13 is SmartLabs' attempt to mitigate the 2413S's high failure rate. However, I don't know if simply increasing the capacitance from 10uF to 100uF will in fact "do the trick" (do these new caps address the ESR issue?). On that basis, I plan to go ahead with the re-cap, using the 10uF, 50V caps suggested by danu1964. Additionally, the change in brand of C3 (with a cap of the same 250V rating) does not address the headroom issue on the primary side of the power supply. Changing C3 to a 400V rated cap just makes good sense. All the best, Lee INControl Home Automation Thousand Oaks, CA Just sat down to re-cap another 2413S. This time, it's a brand new one slated for a new system I'll be installing tomorrow for a new client. My thinking is that re-capping now may prevent the all-too-common failure 2+ years from now (couldn't hurt, right?). The label on this new PLM indicates that it is rev V1.C, with the date code 1425. Upon dis-assembly and inspection, I found that: **C7 and C13 are now 100uF, 35V, Fujicon (as opposed to 10uF, 35V, Samcon); **C3 is still 6.8uF, 250V but it is no longer Yihcon brand (now it's "CA" brand, as best as I can tell); **C8 and C11 are both unchanged from earlier rev units (as specified by danu1964). I suspect the changes at C7 and C13 is SmartLabs' attempt to mitigate the 2413S's high failure rate. However, I don't know if simply increasing the capacitance from 10uF to 100uF will in fact "do the trick" (do these new caps address the ESR issue?). On that basis, I plan to go ahead with the re-cap, using the 10uF, 50V caps suggested by danu1964. Additionally, the change in brand of C3 (with a cap of the same 250V rating) does not address the headroom issue on the primary side of the power supply. Changing C3 to a 400V rated cap just makes good sense. All the best, Lee INControl Home Automation Thousand Oaks, CA

Successfully re-capped two additional failed 2413S PLMs, plus the working one in my own home system (as I said I would in my earlier post). The two additional failed units are once again in proper working order. The PLM from my home system is (as expected) also working properly following the re-capping. Now, only time will tell if replacing the electrolytic caps in the power supply section of the PLM will indeed reduce the outrageously high failure-rate of the 2413S PLMs. At the very least, being able to "resurrect" a failed PLM, and putting it back in service in the ISY-based system in which it was previously working (as opposed to replacing it with a new one) has one very attractive benefit (assuming no other failure besides the power supply caps)...don't have to perform the "Restore Modem" process, which can take several hours if the system includes a large number (100+) of devices. Again, thanks (and kudos!) to danu1964 and Brian H !! Lee Fleishman INControl Home Automation Thousand Oaks, CA

Just completed the re-cap of a 2413S that died in May of this year. As is typical, this PLM failed approx 2 years after installation at a customer site. I used the specific caps suggested in this thread (procured from Mouser). Very happy to report that the unit is restored to working order. I will re-cap 2 additional dead PLMs (also replaced for clients this year), plus the one that's been in service in my own home since Dec 2012 (so as to - hopefully - prevent its "upcoming" demise). I'll post the results of these 3 additional "resurrections" upon completion. Thanks to all who provided the specifics of this solution. Lee Fleishman INControl Home Automation Thousand Oaks, CA

Hello Michel, Excellent news! Very glad to hear it. I would be very pleased (more accurately ecstatic) to offer my own home system (90 devices), plus all the time & effort necessary, as a beta test site. At the very least, I want to purchase one just as soon as they are released for sale. Thanks for your awesome support and commitment to continuous improvement. Lee Fleishman INControl Home Automation Thousand Oaks, CA

Any update on the status of the development of UDI's PLM ? I had to replace another SH 2413S PLM last week for another client. That makes 5 PLM failures, just since March...all of which failed right around the 2 year point following original installation. And SH has been almost completely unsympathetic...out of warranty, too bad. We really need an alternative! Lee Fleishman

Based on the statement, "The rest is pretty much identical to SmartHome's reference design...", is it correct to assume that the UDI PLM will be dual-band, and not just PLC? Sure hope so. Please, PLEASE!, add me to the "I want to order one as soon as they're available" list. I've had to replace several SH PLMs for clients just in the last 60 days (nearly all just barely over 2 years old). A viable, RELIABLE, alternative is very sorely needed. Keep up the fantastic product development and support, UDI! Lee Fleishman INControl Home Automation Thousand Oaks, CA

Sears Craftsman garage door operators and Liftmaster garage door operators are both manufactured by Chamberlain. In a previous life, I worked for the Sentex division of Chamberlain as a Product Manager. In that capacity, I became very familiar with all of the Chamberlain products and brands. Yes, Chamberlain garage door operators will work with the I/O-Linc. Lee Fleishman INControl Home Automation Certified INSTEON Installer / Consultant Thousand Oaks, CA

Michel, I need a little help to understand this. If the T'stat does not in fact send an Insteon message when the ambient temperature changes, how can this be resolved with a firmware change in the ISY? Best, Lee Fleishman

I too have found that ambient temperature (as indicated on the face of the T'stat) is not always correct in Admin Console (and by extension, MobiLinc). I've replaced my two original Venstars (for other issues in addition to this), in favor of a couple of the Insteon 2441TH T'stats. This did not resolve the erroneous ambient temperature indications. Steve Lee provided me with the answer during a telephone conversation a few days ago. According to Steve, the 2441TH does NOT send an Insteon message when the ambient temperature changes. It only communicates changes in OPERATING STATUS (e.g. heat or cooling going from on to off, mode changes, etc.). The thinking, during development of the 2441TH, was that if the T'stat sent a message for every change in ambient temperature, it could cause a lot of Insteon traffic -- especially in a commercial or industrial application in which many T'stats are deployed in a large building (such as the project I was recently involved with -- 80 HVAC package units, 80 T'stats, in a very large fitness club). The solution for my two Insteon 2441TH's was to create an ISY program to query both T'stats every 15 minutes. While this may not be appropriate for the large commercial/industrial applications (because it too would cause tremendous Insteon traffic), it seems to be a satisfactory work-around for my simple residential application. I hope this helps. Lee Fleishman INControl Home Automation Thousand Oaks, CA

The "Darkness Sensitivity" of an Insteon Motion Sensor (2842-222) can be set via that device's "Set Options" dialog of the ISY's Admin Console (when the sensor is in linking mode, of course). The range of settings is from 0 to 255. I understand that the Darkness Sensitivity setting determines just how dark it must be in order for the sensor to be in "night" mode -- the lower the setting, the darker it must be. At a setting of "0" the sensor will always be in "day" mode ("OFF"), while a setting of "255" will cause the sensor to always be in "night" mode ("ON"). Question: Does anyone know if the Darkness Sensitivity range is linear? In other words, does "64" represent approx. 25% actual light level, does "128" represent approx. 50% light level, does "192" represent approx. 75% actual light level? Thanks, Lee Fleishman

Upgraded Java and RC6 without difficulty. Thanks for the quick response to the Java security issue!

Upgraded from 3.3.6 without issue.

Upgraded to 3.3.6 from 3.3.4 without apparent problem.

Hello Michel, Thanks for the feedback. I checked the log, and I could find no entries involving Fan Mode. Contrary to my previous post (in which I stated that the anomaly only seems to affect the newer, integrated stat), I've now seen several occurrences of it on the older stat with the external adapter. Also, I have not implemented any ISY programs that involve Fan Mode (just heat & cool setpoints, depending on time of day/night). Any further insights you could suggest will be most appreciated. Thanks, Lee Fleishman INControl Home Automation

Correction to above: Upon further (and more careful) observation, the anomaly now seems to manifest only for the newer, "All-in-one" thermostat adapter V.95. Although I'm certain I initially witnessed the anomaly occurring on both stats, I can now reproduce it only on the V.95 unit.

Are you referring to the firmware of the stats themselves, or the firmware of the INSTEON adapters?

Continuing from my previous post (I forgot to include)... Using ISY program to update thermostat clock fails for both stats: Venstar 1700's - one with external adapter V.91, other with integrated "All-in-one" adapter V.95.

Upgraded, first to 3.3.1 then to 3.3.2. No problem encountered during upgrade process, and ISY backup completes with no difficulty (running Vista and Windows7). However, discovered anomaly with thermostats. Two Venstar 1700's, one with the external adapter V.91 -- other has integrated "All-in-one" adapter V.95. Anomaly is as follows (same behavior for both stats): Both stats are set for Fan Mode: Auto. However, after a cooling cycle, Admin Console reports Fan State as ON, even after cooling cycle has ended and fan is not running. Stats still indicate (on their LCDs) that Fan Mode is Auto. But, since Admin Console now shows Fan State = On, MobiLinc also indicates that the fan is ON (running). Using MobiLinc's Refresh function does not correct fan indication. Likewise, MobiLinc's "Sync with ISY" function does not correct it either. Using Admin Console's query function (for either stat) also does not correct the fan indication. The only way to get Admin Console to properly indicate Fan State = Auto is to either (1) manually change it from the Fan State pull-down selector, or (2) do essentially the same thing from MobiLinc. But, following the next cooling cycle, Admin Console (and hence MobiLinc) are back to indicating Fan State = ON. I'm pretty certain this anomaly was not present in current official release 3.2.6.

LeeG & andrewm... I'm fairly certain that during my testing I have seen the fanlinc light turn off in response to a fan off command sent from RemoteLinc, even though the fan was actually off at that time (the fan off command from RemoteLinc is used as one of many possible triggers in some of my ISY programs). Since the fan was not actually running when the command was issued, and yet the fan-light turned off (improperly) in response, I have my doubts about it being due to inductive kickback from the fan motor. I'll keep testing... As for the fanlinc motor's current status reporting to Admin Console as "LOW" following a query (when the fan is in fact off)...I have confirmed that the behavior exists regardless of the fan's actual speed/state. This seems to me to be a design deficiency. I've raised the issue with the folks at SH...their initial response was that when they tested for the behavior using HouseLinc, the fan motor's current status is always correctly indicated. On that basis, they threw it back on the ISY. It's very curious to me though, that I am able to successfully use the current status of the fan motor in ISY programs (e.g. IF / Status / FanLinc-fan / Is / Med / Then / Set / Scene 'Fan Indicator Med' / On ). On that score, I'm going to treat it as, "If it ain't broke, don't fix it." LeeFleishman

FanLinc experience with 3.2.1... I have experienced similar anomalies as reported by andrewm... 1. Admin Console shows current state of fan (motor) as "LOW" when in fact the motor is off. Moving the slider to the OFF position, and then querying the fanlinc-fan node causes the fan's indicated current state to revert back to "LOW" 2. Turning the fan off via RemoteLinc often causes the fan light to turn off (fan light is definitely not a responder-member of any of the fan-motor scenes). I'm using a 6-button KPL to control the fan light and motor (large ON & OFF buttons for the light, A, B, C, & D buttons for fan Med, Hi, Low, & Off respectively). MobiLinc correctly shows fan state, by relying on four distinct scenes: Fan OFF, Fan Low, Fan Med, & Fan Hi. RemoteLinc controls fan speed exclusively via programs. To accomplish this, I had to create a total of eight scenes and eight programs (not relying on any variables). Although it all works as intended (with the exception of anomaly #1 above), it just seems to be way too much overhead...just to control (and accurately indicate) fan speed/status. There has to be a simpler way. Lee INControl Home Automation Thousand Oaks, CA