jeffpdavis1

Sorry. The devices are no longer available.

Sometimes it helps to visualize (and verify too) the items. The three devices in boxes are unused. I think I plugged that Insteon Hub in once (it came with something else that I wanted 7 or 8 years ago) and didn't even connect anything to it. Yes, pos. Two of the five LampLincs may be bad as you can see by my notes on the back of them. I tried again later and one of them worked correctly. I was suspicious when I removed them from service that the cause was something else and now I'm unsure. Still, probably not a deal killer I had forgotten how many of those FilterLincs I had. One for each of the UPSs scattered around the house among other things. Oh yeah, I have the Garage door close sensor too that I've been using with one of the IoLincs. I just have to retrieve it. I had some idea of the inflated value for the 2413S PLMs...maybe $150 but not $450!! I was originally thinking that my whole collection might be worth $1000-$1200 to someone. I don't know but somewhere in there might be fair.

Yes, the one I've been using for 3 years or so is V2.1, 1514. No problems with it at all. The one still the box is Revision 2.3 4216

I've got all of the following I want to sell as a lot. I'm not interested in in selling them individually. All but 4 items have been in use by me for the past 4 years. The unused items are 1x 2477D, 1x2466DW, the Insteon Hub and 1x 2413S. I was unsure of the original cost of the items listed as whole numbers so I estimated. I'm also unsure what a fair asking price is or how the transaction could take place. I'm hoping not to have to deal with ebay. Update: The devices are no longer available.

I am almost to the point where I was thinking the same thing. Not ISY. Not the locks. Not ISY z-wave dongle or network. It must be the missing siren. Any recommendation for an equally strong repeater like the siren. I've looked for a way to disable the siren and just have it be a repeater, but I admit not very thoroughly. Thanks for the clear concise evaluation.

I only have 5x z-wave devices: 3x Kwikset 914, 1x Aeotec Siren Gen5 and 1x Minoston miniplug. They were all communicating fine in my ISY 5.3.0 (Firmware and UI) with the upgraded Z-wave Series 500 dongle (Version 6.82.01) added on a few months ago. While we were away for a few days a neighbor could hear the siren going off from the street. She contacted us and we gave her the codes to enter and unplug/disarm the Siren. That fixed the main problem except for why the siren went off in the first place. In our normal away mode, it would go off for a while if and only if someone opened one of the doors and triggered one of the Insteon in-the-jamb Open/Close sensors. These events would have sent us a notification, but none of that happened. I was left to think when we returned that the Siren had just gone off in the weeds. Fine. I only got it over a year ago because I thought I needed a repeater in between the straight line of sight between the front door and back door. The back door lock wasn't always working with Series 300 Z-wave without it. My office (location of the ISY) is only about 15 feet from (nearly line of sight of) the front door lock, which works well. The third lock is also about 15 feet away from the ISY but through one wall into the garage. Also when we got home none of the 4 remaining Z-wave devices were working reliably, so I quickly ordered another Minoston miniplug to go where the Siren was and repeat the signal. That didn't solve the problem. So is it the device(s) or network? The third garage entry door never stopped working reliably...phew. That's one. For the front door I took it apart, removed and replaced the batteries and the put it back together and the front door was working fine...Update Neighbors, Queries all worked just fine. Well it should, it's only 15 feet away! For the back door, brought it back to within 12 inches of ISY, removed and added it back in. All queries and other tests of it worked...from < 3 ft. I moved it out 10 feet away into the long open area between the front door and its eventual destination 40 feet away. All tests still good. Moved it 20 feet closer to final destination...still good. Moved it the last 15 feet and couldn't communicate with it. The same scenario was repeated for the new repeater. Works at < 3 ft, and at 10 feet line of sight but not at 25 feet (around the corner but still only through one wall). Also, same scenario with the siren being removed and added back in to its formerly good spot. The neighbors seem to be updating correctly at each stage from the Front Door (Show Information in Event Viewer). And the same with the Garage Entry Door. If I go back to the Siren going off while we were gone, I wonder whether the siren malfunction was the cause or the effect of something else in the Z-wave network. I'm willing to do a dongle reset if needed and then add everything back in. Could the Z-wave dongle have just failed...sort of? Why does the back door lock work at closer ranges but not 45 feet away in direct line of sight of the front door lock. Did the back door lock (and not the other two) just fail coincidentally with the Siren inexplicably going off? Could it be something in the ISY z-wave dongle? I'd like to have smart locks that can be controlled with the ISY and its other 50+ insteon devices. What are some other troubleshooting steps that I can take?

Ok, thanks. I'll give them a call when the time comes.

When I get another ISY for the new house, I'd like to move the Climate, Portal and Networking modules to it. 1) I see that I can delete this ISY from my portal. I assume that will make it (and Networking that came with the subscription) disappear from the admin console, right? 2) If not, what do I need to do in order to detach all of them from the current ISY and hold them in limbo until I get the new one? 2) Any other consideration other than Admin/PW, email addresses in the Notifications, smtp sender email? 3) Is there a list of steps disentangling me from the ISY that someone else has already prepared so I don't miss anything? Thanks for the help, Jeff

I'm feeling better all the time. Mine is v9E as well.

In reverse order, I think it's working correctly now. The high ceiling fans come on with heat and turn off with no heat. Perfect. Ever since the first PLM went bad and I had no ready replacement, I've soured a bit on having a system that is wrought with these critical points of failure, the PLMs, especially since they have been so problematic. So I did my best to address it by keeping a spare one on hand. I'm not sure if that's the best response, but it was based on thinking the new one wouldn't have the same bad components. Maybe there are other strategies for that. That first time when the PLM failed, I bought two more so I'd be prepared. Ironically (it's actually a little funny now), both of the two that I bought were the ones with the bad capacitors. So my second one lasted a while, then the next one was installed and got the first (of the two) RMA'd. Now I'm on my fourth one, always with a replacement on hand RMA'd from the previous failure. This 4th one is supposedly beyond the bad batches and has the improved capacitors. I'm not sure if one of the numbers is the date code you refer to but it may be. Also, I was in error about the age of this one. It's actually only been in service since August 4, 2015, but received by me in February, 2015. Here is the information about it: Rev 2.0, "1438" date code?, Purchased 2/5/15, Rec'd 2/9/15, In service 8/4/15. My current spare: V2.1, "1514", Rec'd 8/10/15. I've taken to keeping the invoices and shipping documents, but Smarthome has always been really good about the exchanges. Let me know if you can decode the date codes. They look suspiciously like they may have a year in them. Thanks for your help.

I think you were right on this last suggestion. I might have stumbled on to trying it as a last resort but it sure is counterintuitive. What makes these thermostat adapters different from the other Intsteon devices that they would report something that coincidentally was what was in the ISY links table? It sure calls into question all the other times I've used the Compare to move on to some other cause. Earlier today I had used the program in the wiki to query the thermostats every 15 minutes just so that it would get the status and turn the fans on and off. I don't seem to need that any more. I'll know more after it's gone through several more cycles.

Yes, often I neglect that Diagnostics step but this time I hadn't. They all were identical. And yes, the "then" portion performs correctly. The one thing that I didn't mention was that in the last 4 years, I've replaced the PLM 2013S annually or sooner because of failures. Probably a familiar story for many. I'm now 13 months since the last one and it seems ok.

I have had the older Venstar T1900 and the Insteon 2441V rev 2.2 for over 4 years now with little trouble. I have tried to use the status info, like calling for heat, from the T1900 to drive other events, like turn the ceiling fan on/off, and it seemed to work fine a couple of years ago. For some reason or another I disabled the simple program I had created a few years ago to do just that but now I want to enable it again. I've also noticed that in the past year or so MobiLinc HD used to display "Heating" after manually increasing the SetPoint from the app without having to refresh the particular TStat display. Now it will only display heating if I refresh it. The program mentioned above simply says if Status tstat is calling for heat, set ceiling fans on else set ceiling fans off. If I query the Thermostat main node from the Admin Console, the program indeed fires and operates correctly turning the fan on or off. My question is Has something changed in the way the ISY994 v.4.4.2 responds to the 2441V Insteon Thermostat adapter's status or is the adapter no longer reporting the status without being queried for it. If the latter, then is there something I can do to troubleshoot that or reset it somehow to start sending its status again without being prompted. I'd sure rather not have to get another Thermostat, as this is only one of three in the house. Thanks for the help. Jeff

The one that's operational right now says V1.B on the back of it and v9B in the PLM Info/Status box. My spare that I got in Feb 2015 says V2.0 on the back. How do I tell what the version is that compares with "v.9E" or is the v2.0 enough to confirm it has the corrected capacitors? Perhaps I should call it quits on the current one, replace it with the v2.0 I have, get Smarthome to send in a replacement under warranty and then keep the new one as the next one in rotation.

25.29.36 v9B / Connected Does the firmware tell you anything? I was thinking that this doesn't answer the question of cause. There were a couple of GFCI outlets that were thrown inside because of landscapers using their portable concrete mixer. Neither of those outside circuits were shared by the ISY or PLM but still it happened a couple of times. I noticed nothing in the ISY system when it happened. Any other guesses as the cause? I know they're supposed to last 2 years but the last two have been under a year or at least closer to one year than two.

FIXED. No unplugging the Monster power strip did not make a difference but I am going to replace it anyway. File | Restore PLM was successful and all the programs work as they did previously. Thanks to all for the helpful suggestions. Jeff

Yes, the PLM is the 2413S dual band one, and as you might guess I started out swapping out old toggle switches with a few ToggleLinc. Now I've got 20 ToggleLincs and upgrading to the other kind is not really a job I would relish but wish I'd had the foresight I have now. Oh well.

I bought another one that is simpler than the Monster one. That's probably a good idea to switch it out.

I was going to do this until I read the warning about ensuring all battery devices are in programming mode. For all three devices, the links compared identically. It seems like the process would take settings from the ISY and write them to the PLM regardless of whether the Motion sensors and door sensors are in programming mode, right? If that's the case then I'll try that right away.

Also my switches are ToggleLincs that are not Dual Band, so RF shouldn't (should it?) affect it.

Thanks for both of your replies. Yes the PLM is actually on its own circuit, shared only by a Monster power strip with three IOLincs in it. All 3 IOLincs have been working fine for a long time. I could plug the strip into a FilterLinc as another testing step but I think I'll leave it alone while I test other hypotheses. The link records for all three Kitchen lights were Compared and had mostly "Identical" with 2 or 3 "Identical/Ignore" which I have so far. Curiously the GR W switch which is in the same general area had one mismatch, that I've corrected with a Restore. Regarding the addition of any new electronics about the time the programs stopped working, yes I have. I can't pinpoint exactly when things stopped working but it may have been coincident with a couple of my motion sensor batteries dying (Grrrr, that's another story) and being replaced/deleted and added again. I wish there were a better option for those things. The biggest thing that changed was the addition of two Ubiquiti Unifi APs, one in the same Great Room / Kitchen area. These are both in the 2.4GHz range though and shouldn't (in theory) interfere. No other appliances or CFLs. I could I guess do without the APs but it sure evens out the wifi in and around the house quite nicely. There is another piece of information that I'm sure most will feel relevant. The UDI 994i Controller is plugged into a UPS that's plugged into a filter on a separate but physically near circuit to the PLM. I've struggled with ways to keep the Controller powered during outages. We have a generator that comes on 35 seconds after the outage is detected, but I have the controller send me an email when it detects the power change in either direction and used to need the controller to stay on for that. I'll look at those two programs again to make sure they would work in these conditions of losing and regaining power. I'll try filtering the powerstrip the IOLincs are in that's residing in the same circuit as the PLM. Would it be ok to have the Controller and PLM on the same circuit? I had it that way a year or so ago.

I've had a program that has been working flawlessly for the last year that when enabled turns off all 3 kitchen lights by just switching one of them off after a certain time in the evening (e.g. as we're headed to bed). Now it no longer recognizes when I switch any one of them off. The event viewer (at any level) registers nothing. The light the switch controls of course turns off but the program is no longer triggered and none of the other lights in the "Kitchen Night" scene are turned off. This same behavior is happening in other programs of not recognizing previously working "If Control" conditions. I created a test program even simpler than this that also doesn't work. See second code segment. Echo Kitchen Off - [ID 00A8][Parent 008F] If Control 'Main Living Area / Kitchen Dining Lights' is switched Off Or Control 'Main Living Area / Kitchen Lights' is switched Off Or Control 'Main Living Area / Kitchen StoveTop Lights' is switched Off Then Stop program 'Echo Kitchen On' Stop program 'Kitchen 4 Nighttime?' Set Scene 'Kitchen Night' Off Wait 3 seconds Enable Program 'Kitchen 1 Motion Lights' Else - No Actions - (To add one, press 'Action') In the following program the West light is turned on at the switch but the North light remains off. Test Control - [ID 00C4][Parent 0001] If Control 'Main Living Area / GR W Ceiling' is not switched Off Then Set 'Main Living Area / GR N Ceiling' 50% Else - No Actions - (To add one, press 'Action') In addition, I thought that the Admin Console used to register the state of the switches correctly when a switch was turned on or off locally. But it doesn't any longer, except after an active Query. Could all this behavior be the result of yet another PLM going bad in less than 8 months. I sure would appreciate any help with this. I've looked for others having similar problems but it didn't seem to correlate with recent firmware releases. Thanks, Jeff

Thanks, that did it. Jeff

I've got a problem with a TriggerLinc (2421) v.34 on a door that definitely is responding by showing a status of On(Opened) and Off (Closed). The jumper is installed on the TriggerLinc, so only one node is active. I've watched it in Mobilinc change even when opening and closing fast. The problem is that a program doesn't exit from a Wait command to reevaluate the If condition in the way I thought it would. Here's my Furnace Room Opened program: Furnace Room Opened If Control 'Garage-Furnace Room / Furnace Room-Opened' is switched On Then Set 'Garage-Furnace Room / Furnace Room Lights' On Else - No Actions - (To add one, press 'Action') Comment: When door is opened turn the lights on indefinitely. ...and the Furnace Room Closed program: Furnace Room Closed If Control 'Garage-Furnace Room / Furnace Room-Opened' is switched Off Then Wait 15 minutes Set 'Garage-Furnace Room / Furnace Room Lights' Off Else - No Actions - (To add one, press 'Action') Comment: When door is closed, wait 15 minutes and then turn the lights off so someone in there will have time. If more time is needed, prop the door open If I walk in there to spend more than 15 minutes and forget to prop the door open and it closes, the CLOSED program is triggered correctly and starts the wait time. I usually realize my mistake in not propping the door and then go back and open it again to prop it open. The problem is that the OPENED program is triggered correctly (although it changes nothing since the lights are already on), but it doesn't trigger a reevaluation of the CLOSED program condition and stop running the THEN clause in it. I've also tried combining the two programs in one but it didn't work either: Furnace Room Lights If Control 'Garage-Furnace Room / Furnace Room-Opened' is switched On Then Set 'Garage-Furnace Room / Furnace Room Lights' On Else Wait 15 minutes Set 'Garage-Furnace Room / Furnace Room Lights' Off What am I doing wrong?

I have had a snow sensor in my system for a couple of years that just determines if there is snow on the ground at a point in time initially to turn on my roof and gutter heaters in order to prevent ice dams. While it did that fine, I found I needed to use IP cameras to visually inspect the roof to turn it off appropriately without using too much energy. The snow sensor itself was just the Photoelectric Sensor E931-S35RR paired with an I/O Linc and mounted vertically on a fence post near the house. When the bottom reflector was covered up enough, it closed the I/O Linc and vice/versa. In the beginning I wanted to mount it on the roof or actually in the gutter but settled for a place that was close by, easy to maintain and paralleled the behavior. It works reasonably well for turning on the roof heaters but getting the algorithm for turning the heaters off usually resulted in having them on for a day or two too long. This year I've installed the rain water collector heater (for melting snow) on my Davis Instruments Vantage Pro weather station. I will use the snow sensor to turn on/off the heater on the collector so that in times of heavy snow and wind, the collector is able to keep up, hopefully. We live at 8400 feet in Colorado. I suspect that even though, again the sensor is on a fence post 12 feet away from the weather station, there's going to be some tweaking of the heater power, although I should be able to use the Total Rain staying constant for some period of time. It'd be nice to have the Rain Rate reported to the ISY too, since it certainly is sent off the PWS. Your application could work with this provided the sensor were mounted in that position that most closely mimicked your driveway's snow state. Once the snow sensor stopped sensing snow, you could turn to some other means, time or outside temp, to find the optimal point to shut it down. Your biggest problem is that your driveway heater needs to be melting the snow where the snow is being sensed. You would know best about how to rig that, perhaps mounting the sensors horizontally in some key place where you don't drive, but you do heat. Your need to turn the system on a couple of hours before the snow was one of mine too so I think you could use the snow predictor program from burakk above for that. This whole snow sensing idea has resulted in much writing/rewriting. Up until a month ago, I was only using the snow sensor to send me alerts when it was snowing enough to cover the snow sensor (wind and snow required some special attention to avoid alert overload) so that I could choose manually to inspect the roof via cameras and manually turn the heaters on or off. This was only because the weather conditions were so variable around the time when the snow sensor got cleared that too much energy was wasted in leaving the heaters on too long. It may be also I just haven't spent enough time with it. This year, using the snow sensor to turn the rain collector heater on/off should be much more straight forward, that is once Hamweather gets all the PWS weather stations showing up in my climate module. Mine shows up as a CWOP station but the data is unreliable, but that's another thread.