mwester

Like all marketing department schlock, it doesn't really say a d*** thing! I'm still waiting to see a proper, working PLM.

https://www.lightdims.com/index.php I use these on a LOT of my devices, although not so much on the insteon ones (the while LEDs are not so "eye-piercing" as the blue ones... the blue one on the ISY is blinding.)

I'd agree that there's huge confusion about what things are triggers and what are not. I'd second this idea -- some sort of markup or annotation or perhaps just auto-adding comments to the program that would indicate with certainty what the ISY considers to be triggers would save a lot of trouble. (If one were to start all over, I would strongly suggest a program structure other than "if (events and conditions) then (something) else (another thing)" -- perhaps something like "when (events) do if (conditions) then (something) else (another thing) -- which would allow one to simplify most real-world programs to the very clear and very obvious "when (events) do (something)", which even the most basic beginner would find obvious. JMO)

Basically, the device functions as a normal occupancy switch -- it turns on the load if it senses motion in the field of view. There's a paddle switch for manual on/off, if desired. If you add it to a z-wave controller, like the ISY, it will respond to on/off (or dim, if you get the dimmer version) commands -- and it'll send events upon detecting motion (in addition to turning on the local load). (I could do without the blasted blue LED, though - why do manufacturers insist on using those horrible eye-blinding-blue leds on everything??? I'll give Insteon credit for having avoided the temptation to "blue" everything, and instead going with a softer white led...)

I've been quite enjoying my z-wave occupancy sensors -- they're wired in (replacing the light switch), but actually give very good coverage of the areas I need covered in the basement. And while I just use the occupancy mode, they DO work as motion sensors (signaling motion to the ISY when detected).

Alas, that's not how Insteon scenes work. When you linked the two devices manually, one was the controller and the other the responder -- the PLM was not involved. When you added the device to the PLM, another scene was created, involving the PLM as the controller and the device as the responder -- note that the other device was not involved in that link (it exists solely so that the PLM (ISY) can control and monitor that device). So, given those two scenes, when you turn on the device from the ISY, according to the Insteon protocol, the device that you tapped on the shoulder is specifically, per protocol, to turn itself on (or off) -- it is NOT to run off to do "something" because that activity is a DIFFERENT scene (which you defined manually, and thus it isn't even possible for the ISY to add itself to that other scene). So, while it might be logical, or "out of the box", none of that matters because that's not how the Insteon designers built the devices. I'm afraid you're going to have to delete that manually-created scene and re-create it from the ISY in order to have it work they way you wish.

The parameters are determined by Fibaro, not Universal Devices. So check the Fibaro documentation... near the bottom of this page (https://manuals.fibaro.com/door-window-sensor/) they list various parameters.

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.