Goose66

It runs every time the state of one of the devices changes.

From the post above: "You create a scene that has nothing but the All On/Off button as a responder - let's call it "Backyard Keypad Button B." So it's a new scene that just has the All On/Off keypad button in it as a responder. The program sets the state of that scene on or off to toggle the state of the keypad button. Note that this isn't just controlling the backlighting of the key, it also toggles the button state between On to Off, which changes what command it sends when subsequently pressed.

I utilize Keypads in several places that have All On/Off button (usually button B in our house) linked to an "Everything" scene containing devices that are in other scenes or operated on their own. The approach that I use is programs on the ISY. You create a scene that has nothing but the All On/Off button as a responder - let's call it "Backyard Keypad Button B." The same All On/Off button is a controller in the "Everything" scene. Then add a program that names every device in the "Everything" scene like so: Backyard Keypad Button B Status - [ID 0032][Parent 001E] If 'Backyard / Balcony Lantern' Status is not Off Or 'Backyard / Balcony Can C' Status is not Off Or 'Backyard / Pool Deck Floods' Status is not Off Or 'Backyard / Gazebo L Sconce' Status is not Off Or 'Backyard / Gazebo R Sconce' Status is not Off Or 'Backyard / Balcony Lanterns' Status is not Off Or 'Backyard / Covered Porch Lantern' Status is not Off Or 'Backyard / Covered Porch Lanterns' Status is not Off Or 'Backyard / Stair Lanterns' Status is not Off Or 'Backyard / Backyard Floods' Status is not Off Then Set 'Backyard Keypad Button B' On Else Set 'Backyard Keypad Button B' Off In this way, if any device in the "Everything" scene is turned on directly, by another scene, or by another program, then All On/Off button will illuminate, and pressing it will make sure everything is turned off. If the last device in the "Everything" scene is turned off, then the All On/Off button will turn off. This example shows the setup favoring the All Off function. But it could be very easily changed to favor the All On function, i.e. change the if statements to "'<device>' Status is Off," the Then to Set 'Backyard Keypad Button B' to Off, and the Else to set it to On, and then the All On/Off button will be lit only when EVERY device in the Everything On scene is on. In some cases in the past, I have had to put a 2 or 3 second Wait in the program before turning the button scene on or off to prevent some "bouncing" of the status. But I just do this if I am noticing a problem.

If you aren't going to put a smart switch in the garage, then fine. But I'm OCD, so if there were a three-way switch in there before, I would want a smart switch operating as a scene controller (slave) in there now. Another advantage of this is that it could work as a bridge from the house Insteon network to the shed Insteon network, since they appear to be on different breaker boxes (although the shed breaker box is probably already downstream of a main one in your house). Or, you could take the opportunity to put an Insteon Keypad in and control lots of stuff in the backyard from the garage.

This message appears when the password for the ISY is lost, usually after a Polyglot restart. The Password you want to change is under Settings/Polyglot Settings in the ISY Settings section, and should be the password of the ISY (same one you use to access the Admin console).

@MrBill I don't know where this became so unnecessarily complex. If the OP rewires the circuit, most likely in the j-box at one of the fixtures, to have line (black) and neutral (white) go into each switch box, uses the red wire for load from one of the smart switches back to the light, and caps the red going to the other smart switch, then, bam, all good and to code - no fuss. Any suggestion that once you use a white wire as a traveler you can never go back and rewire it be a neutral is simply absurd.

I don't think anybody has suggested working around code. Installing smart switches here with the existing wire would not violate any code, again, as long as the entire circuit was rewired back to the source.

I'm not arguing code with you - just making an attempt at humor. Code has it's uses, one of the primary ones being that electricians aren't generally electrical engineers. But in this case the code creates an unnecessary expense, IMO, because if smart switches are being installed (requiring the neutral), then the travelers are no longer needed. Regardless, smart switches can be installed in the OPs circuit using the existing wiring just fine, as long as it is rewired all the way back to the source.

I'm just saying that creates a lot of additional expense for 3-way circuits over traditional use of 14/3 wire with the addition of a little electrical tape on the white wire.

Also note that the diagram above of the circuit using/requiring 14/4 wire was obviously made before the price of copper got so high! ?

I am going to stick with recommending an electrician since it seems that you are unsure. That said, I'm curious to why the switches were removed in the first place - I don't think your original post said. If the original switches were removed to be replaced with Zwave or Insteon switches, I am hoping your take away here is that the circuit HAS TO BE REWIRED all the way back to the original location of the power and neutral from the breaker in order to make it work, so the current wiring scheme will not be sufficient, even if you could identify it. Also, non-contact voltage testers are good for keeping you from getting electrocuted, but suck in determining how a circuit is wired. I would suggest a volt meter instead. If your house is in the U.S. and built since the 70s, you can test all wires to ground. 0V to ground will be a neutral, 120V to ground will be a hot (line) and some interim voltage is likely an unpowered traveler.

I have noticed also noticed that the finder frequently doesn't work. The only virtual network I have is the VPN to my office, and finder sometimes works when that is connected and sometimes when it's not. Regardless of the VPN connection status, though, doing an Add with either http://isy or http://<local-ip-address> always works. However, sometimes when I return to finder the manually added connections are there, and sometime they are not, and if finder has not found the ISY, I have to manually add it again. There appears to be no pattern in my situation, but I will admit I haven't spent a lot of time trying to track down the problem.

So, at the risk of getting flamed for not wanting to read 39 pages of posts to catch up, what's the net-net on the new Nokia branded products being compatible with the older Insteon brand products?

Not that I want to be that guy that is so easily triggered, but just so you know WE DID REACH OUT TO ZODIAC (the owner of Jandy) and Michel and I had several email conversations with them regarding access to the iAqualink API, on multiple occassions, in fact. Ultimately they proved unfruitful because Zodiac didn't see enough value to them in working with UDI and their customers. I even pursued some backchannels to the tech company that implemented the web and app interfaces, but to no avail. And this is far from the only time that such overtures have been made to manufacturers. I commend Michel for continuing to try to wedge an open platform into an perpetually closed world of home automation. I would also point out that all of us that continue to try and make the ISY work in as many ecosystems and devices as possible share your concerns - we talk about these issues all the time. You don't have a lock on indignation here. I had a PC with an IBM voice-recognition board, an X10 Serial Interface (the old one before the CM11A), a VGA genlock, and an RF modulator for music and voice-based home control throughout my first house back in 1993. I often express the thought that we haven't really come all that far in the subsequent 28 years. The primary difference here, IMO, is while we're out there trying to open things up, you are (along with ranting online) giving up and turning yourself over to big tech, which has proven time and time again that they are only willing to "cooperate" as long as they maintain branding control of the primary user experience and financial control of the primary revenue streams. I've been down that road time and time again and won't be so easily fooled a 13th time. As far as the iAqualink nodeserver being a "toy" and doing nothing useful, I appreciate the fact that I can control my pool lights, spa, spillover, and sheers from Insteon keypads at multiple doors leading to my pool deck and have the states all stay in sync. My wife also enjoys that she can say "Alexa, turn on the spa for <name withheld>" and the ISY will not only put the Aqualink controller in spa mode and enable the spa heat, but will adjust the pool and spa lighting, as well as the landscape lighting according to the time of day AND play appropriate music through the outdoor speakers. These are the types of home automation scenarios that should be ubiquitous in 2020, IMO, and while Apple and Google are talking about taking us there soon with Matter, I like the fact that I've enjoyed this level of automation with my ISY for several years now.

I mean, could it be because so many of us that are solidly in the UDI ecosystem have thousands of $$ invested in Insteon? Of course the subject will never die.

Ah - you are saying it works with two different Insteon hubs, not that you need 2 hubs to work as an Insteon PLM.

Curious what do you mean using 2 ethernet hubs as a PLM? My primary issues with the current hub(s) as an interface for a nodeserver is 1) the only local interface is directly to the embedded PLM, and 2) there appears to be no two-way (e.g., MQTT, sockets, or UDP broadcasts) protocol. What would make the most useful device for a nodeserver interface would be a hub with a local, two-way API. That way, all Insteon device installation, device configuration, scene building, network debugging, and the like could be done using the Insteon apps (and wouldn't require UDI to constantly keep up with the protocols and new device configurations which Insteon is less and less willing to share) while the ISY could integrate the Insteon devices and scenes with all other devices through nodeservers (and the native ZWave support). Also, cloud-based interfaces, especially ones that require polling, are simply a non-starter. If the PLMs were to be used as a local, synchronous interface, then the nodeserver developer would have to redevelop all the work already done by UDI for device installation, configuration, etc. and run into all the same problems they have. It wouldn't be pretty.

Very nice! That's better than the vast majority of ads I see on YouTube. Of course, I'm sure I will never see the ad out here in Georgia. Our electricity is embarrassingly cheap and schedule-wise un-tiered (thanks, plant Vogtle), and the only reason I schedule my Tesla charging is to avoid tripping a breaker if my pool pump(s) are running. ?

Ah, I swear the 2413U showed "sold out" when I posted that post, but it does now show "in stock."

What are the PLM options? Just USB or will a serial PLM work? EDIT: Never mind - can't buy either, so it doesn't really matter.

Yikes! Well it's far too late for me to convert to ZWave. I guess as my last Serial PLM dies I'll just have to go back to manual switching - if I could just win that lottery!

I have clients that build these types of devices all the time. They get a chip/module that has the bulk of what they need, like a Telit Wi-Fi/BLE module, and these modules usually have GPIO and/or SDIO and come with a reference implementation and application development tools to add customer-specific functionality. Cannibalize an Insteon Keypad for the 120V components and replace the Insteon chip with one of these WiFi modules with some custom code and bingo. A lot of my clients also go through the UL listing application process as well once they have a prototype. The trick is getting the circuit boards, enclosures, and other mechanical aspects manufactured in bulk and then getting the devices assembled and tested. I have clients and colleagues in the Georgia Manufacturing Alliance that could do all of this right here at home, but each would require some minimum order and the initial effort would take some cash, even if we think we could eventually sell 100,000 of them at $45 a piece when done. That's why I suggested a kickstarter. If it were easy, someone would have already done it.

I wonder what a minimum order for an 802.11ac Wi-fi keypad-type light switch would be with a Chinese electronics manufacturer? Could be considerably less than $2M. Maybe a kickstarter? BTLE for configuration of networking and then it could broadcast on the LAN for a specifically named MQTT server (the Polisy) and then send and respond to MQTT messages (It's probably clear at this point I don't know specifically how MQTT works).

Or if the Insteon patents would just expire, maybe somebody would release a generic chip, like what happened with X10.

The last batch of undiscounted 2635-222's I bought on Amazon were $49.99 a piece and sold by Smarthome, but they were fulfilled by Amazon (which means they arrived with Prime 2-day shipping). The batch before that was $49.00 a piece and sold by Amazon.