mwester

4.7.3 does not support the 500-series z-wave chip.

Select the device, right click, you should see an option to "group" it.

The only thing that might require you to use the newer firmware is if your new ISY includes the newer z-wave module. If it has no z-wave, then it'll run whatever firmware you want. The correct procedure would be to load the desired firmware (making sure you are using the matching UI version), and then restore your backup.

More than likely you'll need a high-current high-voltage switch -- preferably a normally-closed relay version. The switch body is red, which is a giveaway -- and if you look closely at the metal strip, it's stamped with "20A" meaning it's a full 20 amp rated switch. Submersible well pumps are usually run at 240VAC, in order to reduce the voltage drop on the very long cable down the well shaft. Plus, the powered "thing" is a motor. Any one of those three would pretty much disqualify the 2477S. When you replace such a critical item in your home, you need to give some serious thought to how to handle failure. Failures can happen in many ways -- we all like to think that the only way it'll go wrong is if Insteon had a manufacturing defect, and the part fails. But it's actually more likely that it'll fail in other ways -- a runaway program on the ISY... noise on the electrical line... etc. So you need to consider what to do, or what to tell the kids or the spouse to do ('cause Murphy's law dictates that you'll be out of town when it fails, of course). And that something shouldn't be to pull the switch out of the wall and replace it. Not sure what other choices you have, but I'd design a custom control box, with a high-current HVAC contactor, LED indicators, a switch to bypass the insteon micro on/off that I'd use to control the contactor, and detailed drawings of the circuit for a contractor or electrician to read to figure out how to bypass the entire box if the relay fails.

Nope. You'll have to delete the old 2477S, and then re-add the 2477D to the scenes manually.

Odd. The links in your quoted message worked just fine for me. Here's the URL they expand to -- try these links: https://forum.universal-devices.com/applications/core/interface/file/attachment.php?id=8899 https://forum.universal-devices.com/applications/core/interface/file/attachment.php?id=8900 One other note to make -- these were printed and tuned for a 0.50 dia nozzle; if your printer has a smaller shnozz, you may need to tweak the scad file dimensions to make a good fit!

You're dreaming. It's a good idea though!

Ah, thanks for the clarification. In order to catch something like Beethoven you need a device with response times measured in milliseconds -- the ISY's response is measured in seconds, generally. So yes, you'll need an external circuit to latch and hold on the signal so that the ISY can respond correctly.

There was also the short-lived 10v dimmer device, and siren...

Don't toss the iolinc -- still has value as an input-only device. And if you don't need it for that, well someone on eBay will buy it for that purpose (they're generally easy to fix devices, might be practical to repair it).

The two conditions work together with the "then" and "else" clauses. Consider the following pseudo-code, two programs, one of which handles the event that is triggered when a button is turned "on", and the other handles the "off" case: if switch is switched-on then lower blast shields if switch is switched-off then raise blast shields In the above two programs we see a very simple and very understandable flow. There's a single event (and it's clear which it is), and only an if clause -- this is the fundamental way event-based logic works. I use the above almost everywhere, because it helps me understand the program logic and how the ISY is really doing things. However, some prefer to conflate the two programs above into one single program. In order to do that, we need to make use of two triggers (the "on" and the "off"), and we need to use the "then" and the "else" to sort out which trigger it was. Clear as mud? I think so, which is why I avoid this conflated construct. But for those who prefer, here's how we would construct this using both triggers, and using both then and else clauses: if (switch is switched-on or switch is NOT switched-off) then lower blast shields else raise blast shields By mentioning both triggers in the if, we cause the ISY to run this logic on either of the two triggers. If we were to specify a simple "or" without the "NOT", it would sort of work - the problem is that if we did so, then either event (turning on, or turning off) would lower the blast shields... we don't want that. Hence, we invert the sense of the "off" event. The result is that when the ISY evaluates the logic, depending on which of the two events triggered it, it will run either the "then" or the "else" clause. Confused? If so, that's good! Because this sort of conflation of event-based logic into traditional coding logic doesn't work well -- it's like pig-latin, it might sound like programming, but it requires one's brain to do mental gymnastics (and, I'll add that even without knowing the internals of the iSY, I think it safe to say that the translation of this odd coding to the underlying event structures has to likewise be non-trivial, and probably involves simplifying complicated multi-trigger constructs like this into multiple simple event-based bits of code internally). So, if you get it, good! If not, no worries, because if you code as I did in the first example, you're not losing anything at least from the perspective of the ISY. Some will argue that conflating the triggers into a single program is better for humans, because it makes sure when edit and change things that you can see both the "on" and "off" event logic in one place -- that is true. On the other hand, doing so requires the sort of "if" clauses that make no logical sense unless you rewrite them in your head (or sometimes as I have to do, on paper) -- and I'd argue that there's just as much chance of mistakes with those strange and odd "if" clauses as there might be by having the "on" and "off" logic in two different programs. To each their own...

Of course, just to be clear on this -- it's not just toddlers and pets. For example, on my shed door, the optical sensors are low enough that they can peek beneath the truck. And while it has an auto-reverse on it, it'll still leave at least a mark if not outright scratches in the paint on the roof or hood of the vehicle. I prefer to be notified -- I've a camera in the shed that I can use to double-check, and a button on the kitchen KPL that I can press to close it. (And yes, we've beaten this issue to death, just want to make sure that nobody has false expectations for their automation...)

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?