Bumbershoot

That's my initial thought as well. This also makes sense. Powerline noise might bring down a mesh fairly quickly if these devices weren't designed to have immediate RF/PL communications with their peers. What I'm hoping for with a phase coupler is to buffer against the analog of what people see happening with their PLMs; a degradation over time -- as devices begin to weaken and fail, noise (both PL and RF) increases, and the mesh begins to collapse. Maybe the question I'm asking is wrong: if PL/RF noise is managed, the mesh should stay as robust as ever if individual devices are swapped out as they begin to fail? This network was essentially built all at once -- providing for adequate maintenance and replacement parts, should it last indefinitely? We're becoming less eager for wholesale technology swaps in this house (not getting younger), though I hope to be able to swap out individual devices for years to come. Thanks.

At present, I'm very happy with my Insteon network -- it responds quickly and reliably. What I'm hoping for is long-term viability. Reading the description of this phase coupler makes me think that if my Insteon mesh degrades over time ( --why is everything like that-- ) this device will help reduce signal attenuation/degradation. <unfair questions> Gazing a few years into the future, what would a phase coupler provide that my SwitchLincs, OutletLincs, and ApplianceLincs don't already provide? Long term reliability? Will the quality of the Insteon mesh degrade, after years of service, without these? I kind of expect that the incremental introduction of noise into the network will eventually overwhelm it, though I haven't seen any sign of it yet. Could a dedicated phase coupler help overcome that? Is degradation of the Insteon mesh a problem? </unfair questions> BTW - I just swapped out a 3 year old PLM as a simple maintenance practice - AFIK it was still working perfectly.

You can get there using all Network Resources, but I've found those to be a bit fragile in my installation, and proved to be too complicated to deploy and maintain. If you're willing to move up to the latest/greatest that the ISY has to offer, then (IMHO) your Sonos functionality is easier to maintain and deploy, but the installation will have some requirements. Those requirements include (and this list may be non-trivial if you're not at least somewhat comfortable with Linux and your ISY): Run the 5.x.x series of firmware on your ISY Run Polyglot and the Sonos nodeserver on an RPi For advanced features, you can also/alternatively run the Jishi API bridge on your RPi Write programs to make things happen when buttons on your KPL are pressed It appears that the Sonos nodeserver in Polyglot will get you all of your requirements save the "favorites systems button", but that can be achieved in a limited way with the Jishi API bridge. Below is a screenshot of what functionality the Sonos nodeserver gets you (all the functionality provided by the buttons are available to ISY programs). Also, I've included the contents of a program that runs when a SwitchLink dimmer is switched "Fast Off", that utilizes both the nodeserver and Network Resources: DiningFastOffDinner - [ID 00AF][Parent 000A] If 'Devices / dirKitchen / sldDining' is switched Fast Off Then Set 'Scenes / scnDinner' On Wait 1 second Resource 'Sonos.Announce Dinner Music.Kitchen' Wait 3 seconds Set 'Devices / dirNodeServers / Sonos / Sonos Controller / Sonos Kitchen' Stop Wait 1 second Resource 'Sonos.Wes Montgomery Radio.Kitchen' Set 'Devices / dirNodeServers / Sonos / Sonos Controller / Sonos Kitchen' Volume 20% Set 'Devices / dirNodeServers / Sonos / Sonos Controller / Sonos Kitchen' Play Else - No Actions - (To add one, press 'Action') Also, I've included screenshots of the contents of the Network Resources that are called in the above program -- one simply announces, via Text To Speech, "Playing jazz guitar", while the other specifies and plays a specific Sonos favorite, "Wes Montgomery Radio", which is a Pandora station. The scene called in the first line of the "Then" stanza of the program adjusts a bunch of lighting in the house. I haven't shown what's required to map your programs to your KPL buttons, or how to make those buttons behave in the manner you're desiring -- I don't use a KPL for this purpose -- but there are other resources on this forum for that. Good Luck!

If this is the case, then I'll be a big proponent of this, simply for the simplicity and security of having ONE device to backup and maintain. I think this would be a big improvement in the usability department for UDI.

If you start reading this thread from this post onward, you'll see that UDI is developing a stand alone device on which to run nodeservers. It won't be an ARM processor and it won't run Linux, so it's not an RPi.

This --------------------------------------------------------------------------^^^^^^^

I'm not exactly sure what you're asking, but this program turns on my external lights 30 minutes prior to sunset, and shuts them off 5 minutes prior to sunrise the next day. ExternalLightingOn - [ID 0002][Parent 000A] If From Sunset - 30 minutes To Sunrise - 5 minutes (next day) Then Set 'Scenes / scnExternalLights' On Else Set 'Scenes / scnExternalLights' Off Turns house external lighting on 30 minutes prior to sunset every day. Lights go off at sunrise.

Sorry, I have a different system alarm system, so you might have better luck asking the same question on the NodeLink forum.

This will need a Raspberry PI and NodeLink, and you have to be running the 5.x.x series of firmware on your ISY.

I believe so. It's like a cloud backup/restore of the Insteon hub.

Who knows if UDI has the time/resources to manage something like this. IMHO there's probably not much point in creating videos until the 5.x.x firmware series reaches a production release (the 4.x.x series must be nearing EOL, so no point in spending time there), and the AC has been rewritten in HTML5. Otherwise, there might be a short shelf life for the videos. There are some very nice Polyglot setup videos available here.

There is a requirement that you upgrade your ISY firmware to the the current BETA to use this module. It won't work on the 4.x.x series firmware.

It is now, and it's located at: https://polyglot.isy.io/ It's limited to devices that have cloud based APIs: https://polyglot.isy.io/store Devices currently available are: Nest thermostats, Ecobee thermostats, Honeywell Total Connect thermostats, Ambient weather stations, WeatherFlow weather stations (there are also two WeatherFlow nodeservers that can be entirely local) and Solar Edge solar panels. It requires and active UDI Portal account, I believe. There are several other good candidates for inclusion to Polyglot cloud, notably CAO Wireless Tags, among others. For folks who don't want to maintain another CPU and have devices with cloud based APIs, this should be perfect.

Terrific, that sounds like a significant feature. If this were a horse race, I'd bet that we're in for another lap around the Beta track. @Blackbird, there you go. It very much sounds to me that UDI considers 5.0.14 to be stable, though not entirely feature complete (if you're not investing in Z-Wave, however, it may well be). Also, I don't see any promises made here that the migration process will be made entirely automatic or painless (given the endless configurability of the environments that the ISY can control, is it even reasonable to expect that?) I certainly didn't find the migration to be onerous. YMMV.

At this point, it seems the the 5.x.x series of firmware is essentially feature complete and stable, as it has been over a few iterations now (which in my mind is what a Beta should be). There are still migration issues that seem to need a bit of work (mostly to do with program conversion), as well as idiosyncrasies with devices that need working through. For me (and to be fair, I'm not terribly risk averse -- I always maintain a current backup of my ISY) the multiple benefits of nodeservers made the pain and frustration of migration worthwhile. They have changed the game for the ISY, and multi-channel Z-Wave devices haven't hurt any, either. If you decide you don't like pain/cost of the upgrade, restore your old firmware and backup. The only thing lost is some time/hair follicles. If you decide to upgrade, you may have some migration issues. You will, however, have a much expanded universe of devices (Polyglot, NodeLink, Z-Wave multi-channel and some Insteon) available to you, as well as some nice programming features. I'd be surprised if you see stability issues with the base platform, as not many are reported here.

I don't think "Status" will do it. I think you need to use "Control" in the IF stanza of your program.

If your MSII is powered by battery, then I believe they don't communicate with the ISY unless they're woken up by motion or by a button press. My understanding is that there is a short period after the sensor detects motion that you can use to connect to the device and query it. If the device is powered by USB, then you can query it anytime. MSIIQuery - [ID 00FF][Parent 00DF] If '4A.54.E8.1 Motion' is switched On Then Set '4A.54.E8.1 Motion' Query Else - No Actions - (To add one, press 'Action')

Insteon will replace a hub that has died, however, even past warranty. That's not much, but it's more than they're doing with dead PLMs. https://www.insteon.com/support-knowledgebase/2015/10/20/migrating-to-a-new-insteon-hub

I have a hub set up in a relatives 2nd home, and it works just fine for that simple setup; they just want some lighting and HVAC control when they're not there, which the hub provides. It's basic, easy and it works, and all the setup/control can be done with the Insteon app on a mobile device. The hub has plenty of limitations, but if you're only looking for simple scheduling, and on/off and level control of devices, and on/off control of scenes, the hub should work. It works with Alexa and Google Assistant, though I can't speak to how well it works in that environment. It should be maintainable without relying too much on specialized knowledge, which I believe is the sole benefit of choosing it over the ISY.

Good find, I forgot about raspi-config. I assume that the time values that NodeLink provides to your ISY Data nodes are correct, and that you're off to the races...

Not normal. I think that NodeLink gets the time from the RPi, which should be set up to use NTP (Network Time Protocol, I believe) to set the time. You might be seeing time for the default location, which is Greenwich Mean Time, which is equal to the time in London, instead of your location. Run the 'date' command from the command line (it should look something like this): pi@raspberrypi:~ $ date Tue Jan 22 22:09:52 PST 2019 This tells me that I'm in Pacific Standard Time. If yours doesn't show EST, then you don't have the RPi configured correctly. I think this command will work to change the timezone for south Florida: sudo cp /usr/share/zoneinfo/America/New_York /etc/localtime You should see the time update correctly with the next time update in an hour or so. I think...

BTW, this did not produce the correct result. The reason for that is that you failed to capitalize the "L" in NodeLink, so the command only returned the process number for the command you just ran. FYI, case in Linux is IMPORTANT! An upper case "L" and a lower case "l" are completely different animals. It should look something like this: pi@raspberrypi:~ $ ps aux | grep NodeLink pi 8346 0.0 0.0 4376 572 pts/0 S+ 17:15 0:00 grep --color=auto NodeLink pi 32043 1.5 5.3 101436 50152 ? Ssl 03:43 12:50 /usr/bin/mono /home/pi/Nodelink/NodeLink.exe Anyway, glad you got it going. Cheers! ?

Don't thank me, thank io_guy, and maybe buy him a beer (link at the bottom). Your ISY is getting awesome!

Almost there! Have a look here.

Okay, the ISY address field needs to have the IP address of your ISY in it: 192.168.x.x The ISY username and password are what you use to log into the AC.