Everything posted by IndyMike
-
Morning Industry RF Deadbolt - Remote Wiring
Hi Brian, As I indicated, I thought I'd take the easy way out an let SH do the wiring for me. I figured I give forum members the benefit. The connections to the pwb actually look pretty good. Better than I could do given my current eyesight (even with a 10X loop). They even cleaned the flux off the pwb. I didn't put up pictures of the "working sidie" of the pwb. A total of two small IC's and surface mount passives. It's amazing what you can do with house chips these days. As a side note - I walked out into the garage this afternoon and found a box delivered by ups. My timer system unlocks the door for 15 minutes when my better half is due home. If she's late, she has to use the keypad (and she was late today). Either my UPS guy is very good, or very lucky. Either way, I have half a mind to give him a call (all my friends will attest to the fact that I have half a mind). IM
-
Morning Industry RF Deadbolt - Remote Wiring
Hello All, Wasn't quite sure where to post this, but thought it could be handy for some of the forum DIYers. I've been evaluating one of the Morning Industries RF deadbolts (QF-01P) for use in various locations throughout my home. The unit provides both keypad and RF (rolling code) lock/un-lock functions. For my applications, I was interested in interfacing the RF remote to my ELK/ISY system for automatic locking. My family members appear to have a genetic deficiency that renders them incapable of locking doors. The deadbolt itself appears to be of decent quality and construction as does the quality of the exterior plating. The exterior keypad also has a nice feel with good tactile feedback on the buttons (not mushy). The indoor assembly is rather large, but it does contain the motor drive and 4 AA batteries. I've installed the unit on what is arguably the nastiest, most used door in the house - our garage entry. Installation on the door was straightforward requiring only minor modification of the jamb plate to prevent binding. I should point out that this is a steel door with magnetic seals. Doors that use compression seals would likely pose a problem with binding. Extensive modification of the jamb plate to prevent binding would leave the seals open. The garage itself is unheated, but normally does not get below 20F during winter. So far this winter we've experienced our share of single digit weather and the lock has not skipped a beat. I was a bit concerned that the motor drive might stick in subzero whether. So far so good. After a 3 month test drive of this unit, I decided to spring for the second half (on sale of course) - the RF interface. SH offers a IOLinc kit that interfaces 2 IOLincs to a Morning Industry RF remote. In this configuration, one of the IOLincs provides power (5V) and the unlock function (momentary contact) and the second provides the lock function (momentary). My real reason for purchasing the Kit was to determine the wiring interface at the Keyfob. While I'm only planning on using the lock function, I was able to rationalize the kit by using the IOLincs for other applications. That basically gave me the keyfob and wiring for free (yep - I'm lazy). So, that brings us to the entire point of this post - the wiring interface to the keyfob: Note that in the photo above, the white wire is labeled "blue/white" in the SH diagram and performs the momentary lock function. The black ground wire (difficult to see) connects to the middle terminal of the lower switch (right side). With the Keyfob interfaced to the IOLinc, range to my deadbolt is impressive (over 30' and through the garage wall). I've been using this to automatically lock the garage door based on an ISY schedule (haven't interfaced to the Elk yet). So far, the unit has been operating reliably and has coexisted with all the family members. I should not that my UPS man is not overly pleased - he's accustomed to the garage being unlocked.
-
sending x10 preset levels
Hello Paul, Preset Dim levels are covered in this thread: http://forum.universal-devices.com/viewtopic.php?t=1168 I believe that marksanctuary has also added this to the Wiki (too lazy to look at the moment). As Brian indicated, SmartHome Insteon and older Smarthome X10 units use "preset Dim" commands. X10 brand, Leviton, and ACT units use simple bright/dim or extended code direct dim commands (the PLM cannot transmit the extended code). Clear as mud, right? Give us an idea of what hardware (units) you are working with and what you're trying to accomplish. Chances are a Forum member has been there already.
-
Diagnostics
Michel, Am I to understand that Smarthome is working on implementing S/N measurement in the Insteon devices themselves?? Than would truly be a boon to the Insteon community. Do you know if this would be implemented in individual modules or just the PLM? IM
-
My ISY Time reset itself to 1941, too!
Curious, Just returned home from a road trip to find the ISY time 1 hour off (re-synch worked properly). In going through the log, I found the same time warp to 1941. The other curious item is that the ISY was performing exactly the same task on it's trip to 1941 and back. The F5 status is a response to an X10 Poll of my outside flood lamps. It's a program that runs every 15 minutes during daylight hours. The "A Extended Code" is a transmission from my CM15a to my Leviton Dimmers. The program is triggered by a X10 motion sensor, and executes a direct dim command to the Leviton switch. While the F5 status response is a synchronous event controlled by the ISY, the "A extended code" is very definitely a asynchronous event completely outside the ISY's control. Coincidence that these events happen to line up with the time warp? My automatic re-synch is set for 24 hours.
-
Any luck with 2420M low battery indication?
Darrell, Don't be sorry. My comment was in no way aimed at you. On the contrary, the discomfort was entirely of my own making. After convincing myself that this was an undocumented feature, I launched into the before mentioned test sequence to define the conditions under which the battery function worked. All that, when the feature was plainly stated on the web page. What a dope.
-
Any luck with 2420M low battery indication?
OK, now I'm miffed. I did buy into this as an "undocumented feature". There isn't a word about it in the quick start guide, and there is no full users manual that I can find (including the Wiki). I have to admit, I normally gloss over the web page as I've found it to be a great source is misinformation in the past (load ratings and such). What a SAP I was. Thank you for arming me with the correct information. I can see another conversation when the next battery goes down. IM
-
Any luck with 2420M low battery indication?
Illusion, Previously you were not getting low battery warnings - Correct? If so, were you using standard alkaline batteries previously? This could be a case where the discharge characteristics of the lithium batteries allow the low battery announcement to function properly (battery source resistance).
-
Any luck with 2420M low battery indication?
Darrell, Thank you for confirming. It's good to know that my experiences aren't due to that little black cloud that continually hangs overhead. When I spoke to Smarthome about this, they indicated that the "documented" battery low indication was the "double flash" of the led. Sure enough, my units double flash when the battery is getting low. The battery low communication to the ISY is apparently issued sometime much later (and typically after the communications have broken down). I'm currently running a comparison test between two of my sensors. One is programmed for full led brightness with the other programmed to 0%. Both are located in the same high traffic area (kitchen). I'll try to report back when they begin to develop problems. Thanks again, IM
-
Any luck with 2420M low battery indication?
Hi Illusion, The timeout period for the Dusk/Dawn was arrived at through experimentation. I was using my "drawer test" to activate motion and plunge the sensor into light/darkness. Most of these tests were performed with a 0.5 minute motion timeout and a 35% darkness sensitivity. I went back though my notes and found that the timeout period that I had documented was actually 3min 40sec (not the 3:30 that I had posted). Last night I played a bit more with the darkness sensitivity and the motion timeout period. Here's a summary of what I've seen: 1) NO Motion: If the light level changes state (no motion present) the sensor will delay around 3min 30 sec prior to changing the output state. This appears to be independent of the dusk sensitivity setting. This measurement was made by switching a 4 bulb T-40 fluorescent fixture on/off over the sensor. I did see a fair amount of variability in this time (3:05 to 3:50 with the same settings). I attribute this to the implementation of the photo cell/light calculation of the sensor. 2) Motion: The sensor will not change the state of the dusk/dawn output within the motion timeout. If motion is sensed and the light level is changed, the sensor will only change the dusk setting 3:40 after the motion off is issued. This timing was very consistent and was not affected by the dusk sensitivity. 3) Motion re-trigger (within timeout): If motion is sensed within the motion timeout period, the timeout is simply extended (i.e. motion off command is issued at the specified timeout period after the last motion). Since the dusk/dawn is only issued 3:40 after the motion off command is sent, this will be delayed as well. 4) Motion re-trigger (outside motion timeout, before dusk timeout): Since the sensor will not issue the dusk/dawn output while the motion output is active, re triggering motion again delays the dusk/dawn output. 5) Light re-trigger (light cycling within the 3:30 second timeout): Still playing with this one. I initially saw a lot of variability which may again be due to my light source and the photocell. The jumpers in all of the above were in their default position. I believe you mentioned that you were using the "dusk only" mode. I have not tested that configuration. IM
-
Using X10 Motion sensors? From the wiki
Chuck, Thanks for being patient with me. I see now that you were saying exactly that. I get a mental block when I see the reference to the "AC-RF2". I keep thinking powerline interface rather than software plug-in. I'd love to say that I'm normally not this thick, but then my Family would begin lining up to disagree...
-
Using X10 Motion sensors? From the wiki
Rich, Your DS10a's shouldn't be a problem (not that much activity). Whether your MS will present a problem depends on their activity level. I had four sensors in my Kitchen/dinette and they would overwhelm the powerline at times. On a different tack, I just downloaded Bob's latest Beta of the Homeseer ISY plug-in. According to the documentation, you should have two way communication with the ISY. Would it be possible to trigger off the security sensor and launch a Insteon command via the plug-in?
-
Using X10 Motion sensors? From the wiki
Chuck, No worries! You're simply trying to help a fellow ISY user which is commendable. You're experience with Homeseer makes you far better suited than I. IM
-
Using X10 Motion sensors? From the wiki
Rich, I'm way out of date on Homeseer. I demoed it years ago before the ISY was available. From what I remember, you can set up an event that triggers off the RF receive and transmits a standard X10 command via the powerline. There's a nice Hometoys article on how the V572RF32 performs it's mapping - Article Link: V572RF32 I haven't had problems with my X10 coexisting with Insteon but I've taken precautions not to allow motion sensors to access the powerline (i.e. I don't use a RR501 or similar transceiver anymore). Unfortunately the X10 motion sensors will transmit every time they sense motion. In a high activity area this can add up to a lot of powerline activity. From the standpoint of powerline activity, interfacing the W800 directly to the ISY would be far superior. My comments regarding your using Homeseer were intended to give you an idea of how the system would work before spending your hard earned cash.
-
Using X10 Motion sensors? From the wiki
Hello Chuck, I'm sorry, but I don't believe the X10 Security devices transmit at 433MHz. As you noted the carrier frequency for the USA is 310MHz. This includes the security devices. Both the WGL W800RF32 and the X10 CM15a (which can receive Security transmissions) operate at 310MHz. The issue here is that the X10 security devices use X10 extended code protocol and there are not a lot of receivers that understand it. Furthermore, the Smarthome powerline interfaces cannot decode or transmit X10 extended code protocols. Smarthome uses an older form of the X10 standard that does not include extended codes. If you want to "inform" the ISY of incoming security traffic from the W800, the straight forward method would be to mimic the V572RF32 - Use Homeseer to map the security data to a standard X10 address and transmit a standard X10 on/off to the ISY via the powerline.
-
Using X10 Motion sensors? From the wiki
Rich, From the screenshot that you provided earlier, Homeseer is monitoring both X10 RF and Insteon communications. Don't you already have a Powerlinc connected to the PC? If so, can't Homeseer be configured to relay the X10 RF communications through the Powerlinc? This wouldn't give you the stand alone configuration you desire, but it would allow you to play with the ISY X10 interface. IM
-
Using X10 Motion sensors? From the wiki
RichTJ99, You had asked for opinions on the V572a. Well, it's pretty much the Cadillac of the transceiver lineup, but you probably already know that since you use the W800. Other options include: 1) X10 TM751: Can receive on one house code (16 Unit codes). Decent range, built in relay (loud). Unfortunately, this device does not have a powerline receiver. It hears RF, and then transmits on the powerline. Without a transceiver, the device can't sample the powerline for existing activity before it transmits (it's known for stepping on other transmissions). Cost:$6 on ebay 2) X10 RR501: Similar to the TM751 only this unit has a powerline receiver and therefore doesn't step on other transmissions (Collision avoidance). Physically large, good range, built in relay (loud). Cost: $8 on ebay. 3) Leviton HCPRF: Can receive all house codes (similar to the V572). Decent range, built in outlet control (quiet), X10 2-way device (can be polled for status), physically small, includes collision avoidance. Device includes Levitons' Intellisense AGC (very nice and reliable). Cost: $39 on Smarthome. 4) WGL V572RF32: Similar to the V572, but this device can receive 32 bit RF security codes and translate them to a standard X10 house/unit code. Used with DS10a/MS10a RF security devices. Cost ~$100 HNUSA. That's pretty much the waterfront. You can start simple (RR501) and gain experience with integrating your X10 with the ISY or go all out with the V572. A few additional words on the "collision avoidance" feature - This feature allows devices to test the powerline for an existing X10 transmission prior to starting it's own transmission. I do not know if they can recognize an Insteon transmission as valid data. It's very possible that X10 devices will see Insteon traffic as noise and the collision avoidance will be inoperative. That said, I have a number of X10 motion activated switches and flood lamps and have not seen a degradation in my Insteon communications. IM
-
Any luck with 2420M low battery indication?
Sorry Illusion, I hadn't seen your last post indicating you were using night only operation. I am a bit curious about the excessive number of dusk/dawn indications you're getting. I just looked at my log for the motion sensors - 4 sensors are averaging 10 reports a day (1 on/1 off per sensor) over the past month. I looked at the dusk reporting on the sensors some time ago. It turns out the dusk reporting period varies with the sensor motion timeout. Said differently, if your sensor is programmed to send an off command 2 minutes after motion has ceased, the dusk/dawn period will be 2 minutes + 3 minutes 30 seconds. By setting the dusk/dawn sense period wider than the motion timeout the sensor avoids being fooled by local lighting that may have turned on when the motion was sensed. From your description, your sensors are behaving very differently than mine. IM
-
Any luck with 2420M low battery indication?
Illusion, The ISY gives you the ability to set the darkness sensitivity (options tab at the bottom of the device window). This is typically set at 35%. Presumably, adjusting to 0 would reduce the number of reports the 2420 gives (don't know if it would actually disable the feature).
-
Any luck with 2420M low battery indication?
Sorry folks, but the above appears to have been a waste of time. I had intended to put an older battery in one of the 2420's to monitor the decay and note when the low battery/looping kicked in. The battery I chose measured 6.8V in circuit. This produced a number of differences from the power supply test posted above. 1) The 2420m diagnosed the 6.8V battery as "low" by indicating two led flashes during activity. It did this with two of my detectors. 2) The sensor did not enter the "looping mode" as it did when I operated from the power supply. 3) The sensor did not communicate the low battery status to the ISY. In contrast, when operating from the power supply the 2420 would run down to ~ 4.25V before flagging a low battery. I imagine there is a significant difference in the source impedance of my power supply VS the 9V battery. Since the battery impedance will increase as the cells discharge, it's not an easy thing to simulate. The 2420 is apparently keying off this and flagging the battery as low. Back to the drawing board...
-
Any luck with 2420M low battery indication?
Update (6/27/09): the following tests were conducted using a linear power supply input to the 2420m. I have found that they do not represent operation with a 9V battery source. Refer to the following post for 9V source information. Manged to dig out my power supply and find some time to play. Setup: Two 2420M motion sensors, V1.1 Timeout: 0.5 Minutes Led Brightness: 100 Darkness Sensitivity: 35 Notes: 1)The motion sensors have a fair amount of storage capacity. When changing voltages, it's necessary to wait around a minute for the internal voltages to settle out. 2)Per the manual, the sensors will "double flash" then led when the battery is low. The good news - Both of my units worked flawlessly over a voltage range of 4.5 to 9V. This include linking and setting options. The results: 1) At around 4.25 volts, both units would begin to indicate a low voltage condition with a double flash. This double flash repeats at intervals equivalent to the timeout period. What I did not expect, was that the sensor also sends out on/off communications during this period. With my units programmed for a 0.5 minute timeout, the sensor would indicate on for 30 seconds, cycle off for ~ 1 second and then back on. For anyone who has had their lights cycle on/off repeatedly when linked to a 2420m, this is the culprit - the low battery indication. Really not good. Neither of my units communicated the "low battery indication" at this point. 2) Between 4 Volts and 3.25 volts we have somewhat of a race condition. Communication with the Accesspoint is beginning to degrade (comm errors popping up). Below 3.25 volts communication was off line. Out of 10 trials, I received one low battery communication during this section. 3) Reducing the supply voltage to 3 volts will latch the low battery communication flag in the sensor (not the ISY). Unfortunately, the sensor can't communicate this fact back to the ISY since the communication went off line at 3.25 volts. 4) Increasing the Voltage back to 5 Volts allows the sensor to communicate the "low battery indication" back to the ISY. This works 100% of the time. 5) Increasing the Voltage back to 9 Volts does not reset the low voltage indication. The unit will continue to double flash until the supply is cycled. The supply must be off for around a minute to allow the unit to discharge completely. 6) After power cycling to clear the low battery fault, the sensor does not communicate a "healthy battery" indication to the ISY. The only way that I have found to clear the "low battery ON" indication in the ISY is to delete the sensor and add it back in. We really could use a query or at least a manual override here. Well, that's it in a nutshell. For right now, I'm trying to figure a way to program around the potential "cycling light phenomena". If this were to happen in my better half's kitchen, I'm not sure I would survive the aftermath. IM
-
Trouble turning lights out with motion and light status
Hello to_lighter, When you issue the "Set Scene "Main floor Font Motion-50%" you are modifying the status of your condition "Main Entrance door posts". This causes all of the program conditions to be re-evaluated. Your "Main Entrance door posts" status is still true but you not longer have a "Control" event from the motion sensor. The conditions will therefor evaluate to "false" and the program terminates. You can get around this by moving the status check into a conditional folder and placing your current program in that folder. When the status condition for your door posts is true the folder will be enabled. By doing this you can modify the status of the door posts without creating an event that causes the program to be re-evaluated. To be honest, I haven't messed with conditional folders in over a year. I generated the following to make sure this would work. This is based on the various examples of the programming Maestro "Rand": Qualified Folder Folder Conditions for 'Lamplinc' Add conditions to limit when programs in this folder are allowed to run. If Status 'Icon Lamplinc V1.0 07.AE.1D.1' is not Off Then Allow the programs in this folder to run. Program within the Qualified Folder If Control 'KPL Table' is switched On And Control 'KPL Table' is not switched Off Then Wait 1 minute Set Scene 'Lamplinc 50%' On Wait 1 minute Set Scene 'Lamplinc 50%' Off Else - No Actions - (To add one, press 'Action')
-
triggerlinc
cslee, I noticed the same delay the very first time I linked the Triggerlinc to a lamplinc (manual link, no ISY or PLM involved). The delay was in the Triggerlinc itself. I could see the Triggerlinc LED flash to indicate that it saw the magnet status change but it would take 2-3 seconds for it to communicate with my Accesspoint. After a factory reset/re-link the device has responded almost instantly. I have not been able to reproduce the delay since that initial linking. IM
-
Any luck with 2420M low battery indication?
Hello Darrell, It's encouraging that the beta units provided low-battery triggers. I can't imagine Smarthome back-peddling on an advertised feature. I guess it's time to find my old variable DC supply and run some tests. Thanks for the reply, IM
-
Any luck with 2420M low battery indication?
Hello Joe, Sorry to have raised concern. I should have provided some more detail on the "high activity". On and average the weekday (3 kids at home), my kitchen sensor trips an average of 120 times (on/off) a day. If it's a rainy day I've seen as many as 250 trips. After my first battery died I realized that the ISY folks gave us the ability to decrease the LED drive. I changed the LED brightness on one unit to "0". It's on it's second battery whereas the other units are on their third. To early to tell, but I hoping for a significant battery improvement on my "test unit". I replaced two Hawkeyes with the 2420M's. The Hawkeyes would last roughly 6 months in the same location.