mwester

Here's what I use for the one door that still uses an IOLinc: AlertDoorLeftOpenShed - [ID 007E][Parent 0013] If Time is 9:44:09PM And 'Shed Overhead Door-Sensor' Status is On Then Send Notification to 'AlertEmail' content 'ShedDoorOpen' Else - No Actions - (To add one, press 'Action')

Good discussion. But, humans make mistakes, sometimes in coding, sometimes in judgement, sometimes in assumptions... and having spent my life in the field as the guy that parachutes in when a customer's systems go all wrong, I've adopted some seemingly-extreme but generally effective defensive techniques. As they relate to this topic, I'd be worried that whatever we figure out and document on this thread might change should some future programmer at UDI fix a long-standing bug report regarding date/time, or whatever. So, here's my rules for time periods: - avoid midnight, noon, and on the ISY, avoid the 3AM to 4AM hour. As noted above, when exactly is 00:00 tomorrow? Same as 00:00 without any qualifier? Or does 00:00 without a qualifier refer to the very first moment that happened today (i.e. in the past)? Similarly, 12:00 is an error-prone time spec -- is that midnight via 12-hour clock, or noon? And as for 3AM, the ISY is so busy swamped with its queries at 3:05 AM that any schedule starting or ending in the middle of that will at best be shifted by some amount, and possibly even lost (don't know the latter for sure, but I know that node server activity was lost when the system was swamped doing that query back a few versions ago...) - avoid anything on-the-hour. Humans schedule things for the hour. We're funny that way. So, if my automation does something, for example, sends me an alert or a reminder or a notification, I'll be way too busy clearing off one customer conference call and trying to dial into the next, and I'll ignore that reminder. Then hours later, I'll wonder why my system didn't tell me that the garage door was left open (when it did, but I was just too busy and ignored it). And of course, if all your schedules fire on the hour or half-hour, well, then the ISY has a flurry of activity not unlike the infamous 3:05AM query, and things get likewise squirrely. I have lots of schedules that start a random times, e.g. 17 seconds past 3:52 PM rather than 4:00PM exactly. - avoid complex from-to events. This thread's existence is based on a discussion about such oddities. It seems that it isn't just humans that get confused with complex conditionals, but also the ISY. We can assume that UDI will fix the ISY's logic problem, but I'm afraid my logic problem is only going to get worse as I age. I prefer to have multiple programs -- the first one is only schedule-based, it kicks off the "if" clause on sub-ordinate programs, which then evaluate the other logic (variables or devices). It's simpler to understand, and the ISY can handle hundreds of programs, so it's not an issue for the ISY to do it that way either. - do not use "wait" as a replacement for a schedule! I avoid long waits in programs - there's just so many things that can cause a program to terminate or restart, such as trigger events, or power failures, etc. Schedules are clear and unaffected -- the from and to times won't shift, and there's a provision to catch up schedules on reboot, even! So, I know that might not fit with the OP intent to clarify schedule obscurities, but life has taught me that the best thing to do is to avoid the edge cases as opposed to trying to define them or even understand them ('cause Murphy's Law says that the moment we all understand all the edge cases, someone at UDI will change something somewhere, and it'll all change...)

The ISY can't connect to it because it's asleep -- it's battery-powered, I presume. Never-the-less, the device will awake and report in to the ISY just as before -- so the red exclamation point won't go away, but the device will do as it did before. You can change/fix this with a program -- basically, the program should trigger on the device's heartbeat or motion detected or other event that you know will occur, and the action should be to update the device (I wait 1 second before doing so, so that whatever the ISY needs to do to respond to the reason the device woke up gets a chance to happen). Don't forget to disable that program once it writes the update -- otherwise it will run each time the device awakes, doing nothing other than wasting its battery. (I don't have that device, so I don't have a sample program for you, alas... perhaps someone else does, though...)

I used a Genie -- not sure what model (and I'm not home right now to check - sorry!). I specifically chose the model that had provisions for a backup-battery (due to an elderly person in the home at the time who couldn't have operated the door manually) -- and that limited choices greatly. I think there's a lot more companies with reasonably-priced (and self-installable) battery-backup units on the market now, and the trick of soldering wires directly across the pushbutton further broadens the selection.

I chose to solve the problem by looking for an opener that had a simple single-button wired operator. The unit came with a multi-function button (that shows the date and time -- just what I want, another clock to reset every time DST changes! And lets me turn on/off the built-in light.. .which nobody does ever... etc...). However, they also offered a simple one big-button wired-in unit. I simply wired the IOLinc (and now the z-wave unit that replaced the Insteon IOLinc) to the button's switch, rather than to the GDO itself. That way, I could use a modern GDO, with battery backup and all that, and still be able to remotely operate it. BTW, modern GDOs tend to make a lot of power-line noise -- so put an Insteon FilterLinc up on the ceiling to plug that GDO into...

Inappropriate humidity for the conditions can cause real property damage -- and for me, that meets the criteria for a purpose-built controller, as opposed to using any form of home automation as a controller. Integrating HA is still a very useful thing -- but only to monitor and at most to "nudge" the real controller. There's just too much at stake to risk it on the many things that can go wrong with any HA system (not the least of which is human error). Find a way to run a wire to the basement, and put a real humidistat in place -- your outdoor sensor ideally should be on a north-facing exterior wall of the house, but the second floor vs ground-level makes no difference, so that can help. If you can't get the external temp sensor, well, the weather up here is consistent enough over time frames that matter for a humidifier that a manually-adjustable control will suffice. (I live up in the frozen tundra with you, and deal with a humidifier in the winter along with all the problems and challenges they bring.) I agree that adjusting the humidity in the basement is not a useful exercise... so something needs to be fixed. But I'd worry that replacing that with something that we tinker with and modify and change and upgrade constantly is going to be a potential source of damaging humidity problems.

Two of mine are approaching that limit, that'd be disappointing indeed. I guess I'll find out...

Yes, all powered devices act as repeaters, but that doesn't mean that the routing selected by the "heal" will necessarily use them -- what I was referring to was that the routing the ISY determined started using that GE in-wall unit, as opposed to the far-closer Aeon Siren that it's always used previously (and I put there specifically to act as a repeater for the ISY -- the Aeon Siren is known to perform very well in that role, and does something useful in addition to being a repeater!). In order to view the routing information I use the diagnostic console and the "zwave->show information in event viewer->all" menu for each z-wave device. It's quite tedious. But I save the diagnostic output to a file, and parse it with a perl script, to select only the bits of info I'm after. Some day I might try to find the API to trigger this operation, and set up something to magically fetch all this data, and graph it -- kinda like the way one can display the routing graphically in HAAS.

The units send a single-tap and a double-tap -- but I'm referring to is the trick with Insteon where you can set up the local on-level, so that a single-tap on the Insteon device ramps it up to the specified on-level (e.g. 30%). And on Insteon, a double-tap is a "fast-on" with the side-effect that it also goes immediately to 100% on. I've found no z-wave devices that support a local on-level; they all go to 100% when they ramp up. Regarding healing the network, the only issue I've had has been with the new card in the ISY (the z-wave plus) -- it's range is far less than the old non-plus card. I finally made sure the ISY was within about 10 feet of a z-wave plus device to act as the first repeater. Oddly enough, now that I've done that, and run a few heals, most of the z-wave devices in the house have a direct path to the ISY! No idea what's going on - but it seems unique to the ISY's z-wave card, and seems to all work find as long as one has a close-by device to act as that critical first repeater.

Quality is good -- love the screw terminals as opposed to the wire leads that most switches have. Downside is that they're big - hard to fit in multigang boxes if you have a bunch of them side-by-side. Color changing is inexpensive -- they provide white, and light almond in the package (thought they used to include ivory - I'll have to check my parts box - but the web site says only white and light almond now. Works for me, but that's a consideration!) Feel isn't bad -- not quite as "clicky" as the Insteon switches (and way less "clicky" than the mechanical counterparts, of course). The GE Z-Wave Plus units are far, far better than the lower-cost z-wave units (like the Enerwave unit, which is so dreadful I tossed one in the trash rather than re-purposing it, after I replaced it with a GE unit). The LED is kinda lonely, if you're accustomed to the multi-color, multi-LED units like the SwitchLinc Dimmer, or the HomeSeer multi-color multi-led device (which is only in white, so I can't use them, alas ). There's also not a lot of customization you can set -- I have a bunch of Insteon devices where one press brings them up to 30% brightness for normal lighting, and a double-press brings them up to their whopping great full brilliance (for tasks like cleaning, etc). Can't do that with the Z-Wave stuff. However, the GE unit DOES support associations and will notify the ISY when the button is pushed - so programs, and ISY-based scenes, all work with the unit. For whatever reason, one of the basement GE units (the GE Z-Wave switch w/occupancy sensing) just popped up as a preferred repeater for a number of my z-wave devices, after I moved some plugin devices around post-christmas-cleanup. So it clearly works as a repeater, even though being embedded in a wall isn't the ideal location for a repeater. Bottom line: All future z-wave switches will be the GE units for me (at least until HomeSeer comes up with light almond faceplates).

Ok, whatever. Go ahead and ignore the capacitor issue, all you Insteon apologists! My opinion is that there's far too much evidence that this is a real issue, and one that needs to be considered when equipping someone else's house with an ISY... But I stand corrected: as long as the OP handles the PLM with care, ensures that it has nice clean power, and ensures that the new house is "a good fit", then there'll be no problem, I'm sure.

I'm laughing myself silly, larrylix! Seriously, you're trying now to tell us that everyone who suffers from the PLM failure problem has been throwing their PLMs against the wall, dropping them in pails of water, putting them in freezers and ovens, and/or has unusual electrical noise on their power lines? I think we can safely rule out all of those issues, with the only possible point-of-argument being what one would consider to be "unusual" electrical noise. I'd maintain that if the problem is the quality of power (which I don't believe for an instant - see below), then given the number of folks experiencing the issue, it's far more likely that those who do NOT have a failure are the ones with "unusual" power. Now the issue is, as has been CLEARLY identified by others and documented in the lengthy PLM repair thread, that Insteon has used the wrong type of capacitors in the PLM (and in the hub, for that matter) -- the capacitors used are not designed for high-frequency switching power-supply use, and fail as one would expect them to fail when used in an application for which they were not designed. So, I respectfully reject both your and lilyoyo1's theories that it's about water, temperature, noise, surges, or just plain "fit" (whatever that means)! The problem is simply that they use (present tense) the WRONG components. BTW, I have a whole-house surge suppressor -- multiple actually (one on each panel). Solves a lot of issues, and highly recommended -- but it doesn't solve this problem.

Your implication is that all those who've been suffering from the "two-years-and-dead" PLM problem should believe that the issue IS THAT THEIR HOME IS NOT A GOOD FIT for Insteon??!! And you base this on the fact that you, one individual, haven't experienced this problem??? I've re-read your post several times, but I just can't parse that sentence any other way. Perhaps you can clarify what you really mean?

One would presume that it's because the motion sensor is not repeatedly sending the "on" signal when people are moving about -- rather, it simply does not send the "off" signal until it determines that motion has ceased. Check the diagnostic log, at level 3, to see what's being sent by the motion sensor as you test the scenario. I would guess that you might get the results you're looking for if you implemented the following logic: a) When the motion sensor sends an "On" signal, turn on the lights and stop the timer, if it's running. b) When the motion sensor status switches to "Off", start the timer. c) When the timer expires, turn off the lights.

If you do choose Insteon, don't forget to set up a Subscription on Amazon for them to replace that PLM every two years. Detailed instructions for the process will be required.

I understand that it was designed, and perhaps even a few beta units were sent out (but perhaps that's just rumor). In any case, the brilliant, forward-looking geniuses at Not-So-SmartHome failed to deliver the chips and/or firmware necessary, so the product didn't make it to market. (I suspect Not-So-SmartHome decided to take the short-term revenue from ISY users replacing their PLMs every two years, rather than take the long-term view of owning a bigger market by making partners, and thus customers, successful.)

One of the features I'd *REALLY* like to see, and one I think would help UDI as well, would be the addition of an "Association Editor" for advanced usage. Hide this behind a "we're not responsible for what you do with this" Advanced dialog, if necessary. Such a tool would be used to allow us to create/edit/delete associations in all or any of the groups, or all or any of the Z-Wave devices. Closely related would be the ability to enable a program to be triggered on ANY message from a z-wave device -- perhaps allowing the use to specify some simple form of regular expression matching to limit the messages of interest. This doesn't have to be fancy, or even efficient -- just enough for experimenters to take actions for devices or messages that are otherwise not-yet-supported. The point would be to allow experimenters to see how best to set up and use Z-Wave devices -- once we establish mechanisms that work well, UDI could add those to the core support.

Actually, the hub has the same capacitor problem that the PLM suffers from -- I replaced the caps on my daughter's hub, and it came right back to life. I'm not sure I'd rate the ISY/PLM combination any better in that regard, since we still don't know that Not-So-Smarthome has *really* fixed the problem in the PLM yet.

Even if there's nothing connected to the red "load" wire on the KPL, the on/off buttons continue to send their "on/off" signals -- so you can happily use those on/off buttons in a scene to control something else. I do this in my kitchen, where due to a strange layout and a somewhat odd interpretation of what constitute a "hallway" (and thus requires three-way switches), I have far more KPLs on the wall than I have actual loads to control. It works out really well.

It's not a matter of the technology being replaced. It's a matter of Insteon being single-sourced and proprietary, and then failing to keep up with the rest of the world. IMO, if a company wants to be closed and proprietary, that's up to them -- but to be successful, that demands that they take the sole burden of ensuring that their devices work as the technology around them changes (e.g. LED lighting, switching power supplies, etc). In other words, if my Sony BlueRay player sucks, I can go buy another brand that works better in my home. I can do that with Z-Wave. But, if my Insteon PLM dies every two years, for example, I'm stuck with buying a new one, 'cause they don't care, and I have no other source to go to. So, yeah, if all you want is seven-year-old technology, that works with seven-year-old lighting, then the seven-year-old Insteon technology is great! Except for the PLM, which you'll have replaced at least three times in that seven years...

As for why, well, it's because it's my belief that Insteon has no long-term future as a company or as a technology -- the current owners show no interest in new market areas nor in cooperating with partners, and the current technology remains tied to the zero-crossing point of the AC waveform, accurate detection of which is becoming extraordinarily difficult given modern high-efficiency power supplies and lighting. I use an older version of the GoControl/Linear GD00Z-4 garage door controller. It's a proper garage door controller, unlike the Insteon solution, and offers a secure comms connection as well as the recommended audible and visual alert signal before closing the door. The GD00Z unit uses a tilt sensor on the door itself to detect when the door is open -- there are other companies (such as Enerwave) who offer just the tilt-sensor as a z-wave device if you don't need to open/close the garage door.

I'll be different. Avoid Insteon-based solutions -- instead consider the use of a z-wave tilt sensor, or for a complete solution, a z-wave garage door opener device.

Try replacing the power supply.

In general, LED loads are incompatible with any neutral-less dimmer. The issue is more than the load; it's the nature of the load that can also cause problems. I'll skip the details, but in general, any neutral-less dimming device needs to be able to satisfy its required minimum load with a non-reactive load (i.e. resistor-type load or incandescent lamp load -- not LEDs, CFLs, and certainly not things like fan motors).

Yes, that does -- it implies that the device may be working just fine, but the problem is one of the other things noted earlier -- noise on the electrical line, or a failing PLM.