mwester

Yes. So weird that one has to stretch a bit to come up with plausible explanations. If we were wagering, my bet would be on the scenario where Smarthome/Smartlabs has no engineers on-staff that actually know the protocol or the devices any longer, and instead they have outsourced all that work to a subcontractor -- and probably that subcontractor also codes their hub -- and the icing on the cake is that the contract with the subcontractor was screwed up by someone such that Smarthome has to pay to get useful documentation on the API between the device and the hub. The above theory/speculation also explains a lot of other behavior by Smarthome/Smartlabs regarding things like the PLM fiasco (they don't have anyone who understands electronics well enough to fix it), the FanLinc mess (their subcontractor found a way to shave a penny or two off the manufacturing cost, and Smarthome/Smartlabs has no engineers on-staff in charge of QA who caught that substitution), the Siren debacle (same as the new motion sensor - bad contract), and finally, the fact that there's been no further investments in the Insteon protocol (security, robustness, etc) for years as well as the recent sale of the company all fit into the narrative above. My conclusion - I made a poor, very poor, choice with Insteon; it's a protocol that has no future. I'm glad that UDI has opened things up with Z-Wave and the concept of "Node Servers"; that part of my investment is protected at least.

If the finder can't find your ISY, then something is wrong with your network (unless of course, you deliberately and knowingly configured your network in such a fashion to disallow the finder the ability to find your ISY). Start by turning off all the firewalls and antivirus and antimalware and anti-this-or-that-posing-as-security-ware software -- if that doesn't help, then you probably have disjoint subnets (multiple routers/firewalls) or you have subnet problems (router mis-configuration or host PC mis-configuration).

There is no effective difference in terms of response time, or resource utilization. The Insteon devices don't care or know if it's an ISY that set up the links, or not. Your observations regarding the limitations of manually setting the scene up are correct (although not complete). The difference is, primarily, that when the ISY sets up a scene, it ensures that the PLM is a responder to the scene, and adds another scene (in the Insteon sense) where the PLM is the controller and the two other devices are the responders. This allows the ISY to both be aware of the status of the scene and be able to control the scene. There are lot of opinions about setting up links outside the view of the ISY -- but one thing that is certain is that should you do so, you have entered the "ultra-high-maintenance mode" for home automation. There is little you can do on the ISY without considering the potential for impact on your manual links, including certain recovery operations such as restoring devices.

Lulzbot mini -- fits perfectly as-is (but to be fair, it wouldn't have fit with the factory adjustments; I spent a great deal of time calibrating the blasted thing -- and not just for the filament I was using; the factory settings were quite off for everything...) Regarding ventilation, I certainly would recommend it. I initially set it up on my workbench in the utility room, and ended up with enough visible smoke that I worried about setting of the smoke alarms. So now I move it to the basement bathroom where I can turn the exhaust fan on, and close the door so the fumes don't get into the rest of the basement/house. Some plastics are absolutely toxic when burning, and since I don't know what type the buttons are, I'm going to play it safe.

Thanks!

I can't imagine that Amazon doesn't want Canadians' business. So, one is forced to conclude that there's some other reason. Most probably the reason is language -- I wonder if Amazon's legal team has determined that for some reason Alexa would need to speak and understand French (at least the French-Canadian dialect)? (Does Alexa speak/understand German? I didn't think so... but then Germany doesn't have a requirement similar to the bilingual laws in Canada, either...) Or, it could just be the legal system. Perhaps there's a liability issue with the Echo that Amazon just doesn't feel it's worth dealing with. Just curious; it makes no difference in the end, I suppose.

Clear your java cache, and download and run the 4.5.4 version of the console, and see if that will connect to your other ISY. I currently have two ISYs, at different versions -- I did manage (once, and for a while) to have two icons on the desktop that brought up different versions of the console, each connecting to the correct ISY. It was wonderful. While it lasted... I cannot seem to duplicate this anymore, so now I have one version of the console on my laptop, and another on my daughter's old laptop. It's a pain, but you simply cannot expect things to work with console/ISY version mismatches. I hate Java client apps.

Fair point. Counterpoint: if the PLM was fully integrated into the ISY, then one could easily imagine that the PLM's Insteon ID would be derived from or part of the ISY's UUID -- all it would take is adding a means to set or change the Insteon ID in the PLM. That said, z-wave has the same problem/feature -- the association, and the unique z-wave id (MAC), is all on the z-wave board. So replacing the z-wave board requires excluding and re-adding every z-wave device. It's actually a little bit worse: that's followed by the need to audit and update all programs to account for the new z-wave names, since there's no guarantee your devices will all end up with the same suffix in the name when you re-add them.

To answer your specific question (it seems that's a hard thing for some of us to do! ), not sure if there is any documentation -- it's really very easy. In a nutshell: a) acquire a new ISY - same make, model* b ) request via UDI's support team to move all your software modules from the old dead one to the new one - they're really good about that. c) plug in your network and PLM d) connect, install the same version firmware as the old one e) restore backup f) enjoy. *You can save some moola, IF the zwave module is still functional -- you can try to move that to the new ISY. In fact, since that module has the association with your existing zwave devices, I'd try that first.

Hey stmrocket -- can you upload the double-size button template to your github site? I'm using the single-size button template; works great -- about to embark on some custom lettering for a double-size shortly. Thanks!

Well, I carefully twist them all together, clockwise, then cut them to length, put a wire nut on them, tighten it thoroughly, then remove the wire nut, and using a small diagonal trimmer, cut the wires (which have often shifted a bit due to the extra twisting) to precisely the same length. Then I solder them together, put on a new wire nut (no used wire nuts will mar MY installs!), and finish by wrapping the base of the wire nut and the wire with electrical tape, choosing the tape color to match the wires. It seems a shame to hide such craftsmanship -- but I've yet to find transparent cover plates for the switches and outlets.

If the ISY doesn't come back, it's worth trying another wall wart before replacing it -- those power supplies have been known to fail.

I could google, guess at your model number, try to hunt down or dig up technical manuals and parts diagrams for it... but I guess I'm just not willing to go through all that effort! Sorry, nothing personal, I'm just busy with my own stuff. On the other hand, if YOU were to post a url to the technical manual and parts breakout, I'd be sufficiently curious to see what might be possible and practical...

Yep. Iz broke.

Good question. First, I don't think it's a matter of it being "right" or "wrong", just a matter of preference and situation. I have very few programs, and work hard to eliminate them where-ever possible -- my preference, and my situation, suggest that I use Insteon scenes whereever I can instead of programs. Basically, I've already had two PLM failures, and have constant noise-induced issues with Insteon devices, which when combined with the fact that I am often on-the-road for business leaving my family behind to deal with any ISY/Insteon issues make me very much unwilling to depend on the ISY's programs for correct operation of anything. So the ISY *augments*, which generally leaves a relatively small number of "helper" programs. You may have a different situation, where reliance on the PLM and the ISY makes more sense.

To start, consider the first part of your program's condition: If CONTROL xyz is switched OFF This establishes what *triggers* the program to run -- specifically, it's the "Turn OFF" signal being sent from device xyz that causes the rest of the conditional to be evaluated. It doesn't matter if xyz is already off -- or on, or dimmed somewhere in-between, just that the switch itself sent the Insteon message code meaning "turn off". The only way to get this message sent is if the button/switch is mechanically operated -- using the admin console, or any other means to tell the button/switch to turn off will result in that button/switch turning off, but that button/switch will not send the message -- the message is only ever sent if the button/switch is physically operated. From the above, you can see that there's just no way to have Alexa operate that switch. Having Alexa send a "turn off" message to the switch is possible, and does exactly what turning off the switch does from the Admin Console -- the button/switch will turn off, but it will not send the "Turn OFF" message, and thus won't trigger the program on the ISY. Having Alexa run that program rather than operate that switch is more interesting -- but immediately you can see that evaluating the condition would fail -- the first part will never be true, because it's Alexa that's running the program, not a "Turn OFF" message coming from the switch. It's also rather vague syntactically -- telling Alexa to "turn on xyz" vs "turn OFF xyz" should do something different, but if both just ran the program starting with the "if" statement, they'd end up meaning the same thing. So instead, UDI built the integration so that Alexa doesn't run the "if" part of a program -- it doesn't make sense in many cases -- and instead Alexa runs the "then" part when you tell it to "turn on" and the "else" part when you tell it to "turn off". Finally, without understanding what you actually want to have happen, and what the devices involved really are, it's just guesswork -- but there IS a way to have a program run based on the *change* in status of a device regardless of why that status changed, rather than having the program run when the "Turn OFF" message is sent by the device. This has some subtle but important caveats -- for example, right now, if the switch is already off, and you wack the bottom of the paddle, it will send a "Turn OFF" message even though the light/load is *already* off. That can be very useful, and if you depend on this functionality, don't change anything. On the other hand, if you don't care about that, then you may consider changing the CONTROL to STATUS -- that change tells the ISY to run the program when the ISY's idea of the device's on/off state changes, without regard for what caused it to change. That'll trigger the program even if Alexa turns off that switch. However, if the device is already off, you can wack on the "off" side of the paddle all day long, and the switch will keep sending "Turn OFF" messages, but because the ISY is looking for a *STATUS* change (from ON to OFF), it won't run the program.

And take the insteon device off the garbage disposal, too -- before someone gets hurt!

I should probably be a little more clear on the polling thing, at least for the benefit of others who stumble upon this thread. You'll need two programs actually -- one that is triggered on STATUS of the IOLinc and does the email/text msg sending bit. Another that actually does the periodic polling of the IOLinc. I do this with one of my z-wave switches that doesn't support "instant status". Here's the program that does the polling - it's set to run at startup, and every 75 seconds thereafter: pollz - [ID 0005][Parent 0001][Run At Startup] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 1 minute and 15 seconds Set 'ZW 002 Dimmer Switch' Query Else - No Actions - (To add one, press 'Action') And here's the dirt-simple program that controls my desk lamp: officeLights - [ID 0004][Parent 0001] If 'ZW 002 Dimmer Switch' Status > 50% Then Set 'Hue Hub / Dimsum' Turn On Else Set 'Hue Hub / Dimsum' Turn Off

What is the purpose of signaling the event to the ISY? This is an important factor. If the ISY is required in order to perform critical operations such as load-shedding, etc, then you need to rethink your entire solution -- hardwiring is necessary, and the controller probably shouldn't be an ISY. The big problem is that at the time the generator is coming on-line, it's pure optimism to think that a powerline or even RF signal is guaranteed to make it through. On the other hand, if the ISY is simply going to do some convenience things for you after the generator is up and running, well, then just poll the IOLinc rather than relying on it sending a message. Write a program that's based on STATUS rather than Control, and arrange to run that program every minute or two. That should be fast enough for any "convenience" actions, but still not pose too much of a load on the system. My concern with z-wave is that at the time the generator is coming online, who knows what the status will be of the various "things" we all have in our houses that have power supplies and capacitors in them -- the probability of spurious RF noise seems fairly high to me, so I suspect you may also occasionally miss a z-wave device's message during the generator switch-over as well as certainly missing any power-line signal.

Because this forum is for the ISY controller?

It's possible - but the most probable failure in the KPL would be the output TRIAC, which wouldn't prevent it from communicating. It's also possible that the fixture (if it uses an electronic ballast) is damaged -- and putting enough noise (or sucking out enough signal) to cause problems. Or, perhaps nothing has failed, it's just in a state where it's messed up (either the KPL or the ballast). So, the first step to do is to remove that florescent fixture - ASAP. Then pull the tab on the KPL to reset same, and see if it comes back to life. Then test the load on the KPL to see if that part of it is still working.

All of the above is true. But doesn't provide you with a lot of immediate help. Here's the very next steps you should take before you even start reading up on creating scenes in the ISY: Grab a clipboard and an pencil, go around the house to each Insteon device, and make some notes: - Location (e.g. "Guest Bedroom", or if more than one switch in the area, something like "Kitchen counter lights - North, middle paddle" - Actual function (e.g. "main light, dimmer", "ceiling fan, fan on/off", or "no direct function" for switches that no longer operate anything - Virtual function -- this is a memory exercise at this point! -- what was it that this "no direct function" device *used* to do? Now in the ISY Console, match up each device with what you have on the clipboard -- you may need a helper to check that the switch clicks or the leds on it move in order to ensure that you have a match in the Console to the actual location you noted on your clipboard. Name the device appropriately (I use terms in the name such as "Main" to describe the device that actually has the light wired to it, and "slave" or "secondary" to describe the "virtual" switch -- the one that should control the light, but no longer does. Once you've got all devices identified in the Console, you're more than half-way done. The rest is just dragging and dropping and setting up scenes to link the various switches together as described in the previous posts -- and all that is done from your computer, no more need to futz about with the switches themselves.

To help you troubleshoot the issue, the portal doesn't connect to the ISY -- it's the other way around. The ISY reaches out to contact the portal. Combining that with the fact that it cannot connect to the NTP server, the logical conclusion is that it's your ISY or your router that's the issue. Reboot both (router first) -- that would be a logical next step.

Not unless you use a network *hub* or have a managed switch that you've set up to duplicate traffic to the monitoring port. The issue is that all modern network devices are "switches" at heart, which means that aside from broadcast traffic, as soon as the switch learns which devices are on which ports (based on ethernet MAC addresses), it directs traffic to only the target port. The result is that wireshark will only see broadcast packets, and traffic to/from the device on which it is running. As for wifi -- slightly better, but the hidden transmitter problem can also make a full capture difficult.

I feel your pain -- I've a brand new house, wired per code with all modern (and name brand) appliances and devices -- even the phone chargers are all top-quality name brand. My Insteon network "works", and that's about all -- for example, I just replaced a failed KPL in the kitchen, and it took most of an afternoon to get the link database successfully written to it. The general troubleshooting advice available is painful for any modern house -- prepare to reset clocks and reboot computers, etc. You have to go to your basement, turn off all the breakers, and turn them on one by one until the noise problem appears -- that last breaker you turned on is the circuit that has the problematic device on it. Now you need to find everything on that circuit, and remove it -- everything. In my case, I even un-wired an outlet that had a built-in USB charger, just to make sure that wasn't contributing to the noise. Hopefully that'll find the problematic device(s) for you. (For me - I'm switching to z-wave as devices fail and I find acceptable replacements... I've just too many Filterlincs littering my house walls, and still have too many noise issues. IMO, the days of the clean sine-wave on the power-line are past us, what with high-efficiency switching power supplies in everything (including LIGHT BULBS!). Insteon's RF is, by design, coupled to the power-line zero-crossing, so the dual-band thing isn't an effective solution to noise (just to bridging or extending)... which basically means that, in my opinion, as a protocol Insteon is doomed to the dust-bin, and I just don't see that SmartHome has what it takes to bring a viable replacement to the market (there's already too many players there, what with Zigbee and Z-wave, etc). But all that's an opinion - there are many here who feel I'm full of **** )