mwester

Oh wow! 30+ years ago, my college electronics lab instructor (an ex-military engineer who loved to tell stories of his life among the electrical and electronics aboard Navy vessels) made a comment about User-testing and QA-testing that's stuck with me all my life. To paraphrase: "It's impossible to account for every use-case and mis-use-case, because the users are so d*** ingenious!" Ingenious, simply ingenious. It can't work -- it's WAY outside any design parameters, let alone the safety issues involved in putting a 120V plug on a low-voltage cable and bulb system. And it would never, in a million years, have occurred to me as a possible misuse-case were I the QA engineer in charge of the LampLinc! Nevertheless, it has a certain amount of logic to it... Please undo whatever you've done, for safety's sake.

Usually that means that the links in the devices do not refer to the PLM. Normally, one would restore each device to re-write this data -- when you replace the PLM, one of the steps that's supposed to happen involves the ISY computing the new link database entries, based on the new PLM's address, and updating each and every device. As I understand your last post, you have: - factory-reset your devices (switchlincs and appliancelincs, etc) - defined scenes in the ISY - ensured those scenes were written to the devices - tested that operating the switchlincs, etc, result in the other devices responding correctly Is that correct? Then, you are observing that: - a program triggered by turning on a switchlinc (or similar controller) does NOT trigger. Can you check to see if the ISY knows the correct status for the scene controlled by that switchlinc (or similar controller)? In other words, does the admin console's view of the controlled devices (responders) change when you manually operate the switchlinc (or similar controller)? If yes, then you have a problem with the program logic, folder conditions, or a runaway program, or something like that... but if no, then your symptoms are all compatible with missing a very important step when replacing a PLM -- one that could explain all the issues described above. Basically, when the ISY writes scenes (links) to devices, it always add a link to it's PLM by address -- this is how it knows when a device has done something (i.e. when a switchlinc has turned on). In order to do this, the ISY needs to know the PLM's address -- it gets this when the ISY boots up. So, if PLM was swapped while the ISY was running, then the ISY never obtained the PLM's address, and is continuing to use the old (failed) PLM's address. And that includes writing that old PLM's address into all the link tables instead of the new one. Hopefully that latter scenario isn't what happened, because if so, it's just plain easier to factory reset everything -- including ISY -- and start over.

Dunno what makes you say there's been no progress -- Chris' comment was a year ago, and lot has happened. What hasn't happened is a formal release -- so if you want to see if/how this device functions, you'll need to install the 5.0.10 alpha firmware. It's alpha - so things may not be perfect. But a lot of us are running it, and quite enjoying the new functionality. Again, I don't know if this device in this thread will work, but if you need to know, just load up the alpha version, and provide some feedback.

The locks are very sensitive to range issues -- part of the problem being that they are often mounted on steel doors, and sometimes are surrounded by masonry, but always are on the outside wall of a house (far from the ISY usually). Combine that with the fact that some of the most important events for them to transmit/receive happen when another huge signal blocker (a human) is right in front of the device, and said human may even have a hand on a keypad mere fractions of an inch from the antenna... The result is that a door lock is usually in one of the most difficult environments to get a reliable signal in and out of -- so you'll almost certainly need some sort of z-wave device that can repeat the signal, ideally directly opposite the door itself (even if that might be through a wall, it may be a better location than off to the side of the door where the signal has to go through your steel doorframe and the masonry around the door, for example). Note that the z-wave device you choose needs to support *secure* connections, and it needs to be always powered-on (battery-powered devices don't repeat the z-wave signal). Many here have selected the Aeon Siren module as a low-cost device for this purpose; it's reputed to perform far better than the actual Aeon repeater itself (!), and has the benefit of actually being useful for something other than just repeating the signal.

Well there's at least part of your problems -- you MUST have the GUI and the firmware at the EXACT SAME version level. You'll want to fix that before you go a step further in trying to fix the issues.

Reading this topic, a couple things jump out at me: First, I don't think the behavior of the device is as big a problem as the original poster does - but to each his own; it clearly is a big deal for some. Given that, it would be nice if each switchlinc device had a setting to disable the fade up/down, since *THAT'S* the real problem. Second, anything to do with the scene being "on/off" is wrong -- the root issue is that the device sending the command is sending a command that isn't wanted. The challenge here is the same one that comes up every few months in one context or another, and that is that there's no such concept as a scene having a value. You can't say a scene is "on" or "off" or 38% bright -- that's just not how Insteon works. Now, one can consider that design to be a mis-feature - but it's not going to change. The issue is that each device in the scene determines how it responds to the command that was just sent. So sending an "on" to a scene usually turns on everything associated with the scene - but that's not necessarily the case. Turning on the switchlinc on the wall in my family room sends an "ON" to everything in the room - but the cans that wash the wall turn on to only 50%. So what's the value of that scene? It's not off, that's for sure. But is it on? Some of the lights are 100% on. Some of them aren't dimmable, so they're just ON (with no percent). And three of them are on at 50%. And it gets worse - with the new scene support inside the ISY, one can add node servers for totally custom devices. So I can add my newest invention to the afore-mentioned scene - the mwesterLinc. When it gets and ON signal, it blinks green, red, and purple, plays the opening bars to "take me out to the ballgame", and spins a propellor round and round a dozen times, then goes back to sleep. Is it "ON"? Or what? (Yes, it's stupid -- and with a node server, we can even add that as it's value: "Off" and "Stupid" could be completely valid values! So what's an on/off scene, then??) Anyway, the above is just to illustrate that the concept of "On/Off", while it seem simple and obvious, like so many other things that are obvious to humans is very difficult for simple devices. This is a case where a program running on the ISY is the right place to sort out what "On" and "Off" means for a given scene -- and that make's Larry's suggestions far from a hack. That makes those suggestions absolutely the right way to go, and the very reason you have an ISY in the first place! Now, about that mwesterLinc -- I'm taking orders. Wanna buy a few?

Both have to be Insteon.

Which, in retrospect, is probably what we all should have recommended in the first place... would have been hours easier!

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!