Jump to content

LeeFleishman

Members
  • Posts

    31
  • Joined

  • Last visited

About LeeFleishman

  • Birthday 12/23/1954

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

LeeFleishman's Achievements

Newbie

Newbie (1/6)

4

Reputation

  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. Upgraded Java and RC6 without difficulty. Thanks for the quick response to the Java security issue!
  14. Upgraded from 3.3.6 without issue.
  15. Upgraded to 3.3.6 from 3.3.4 without apparent problem.
×
×
  • Create New...