I was an X10 home control power user, or nearly so, up to and by late 1990's. X10, introduced in the 1980's, was the poor man's home control system. You could start with a $49 starter kit... And soon have X10 control over all lights, whatever. You were endlessly told that you needed to have your lights turn on and off to make it look like you were home, and back in the 1980's what could I do? I never even imagined an actual home security system (as I have now) or even Class 1 deadbolts and pins (as I have now). So light automation for security was the first thing I did and I still think it's essential. Also, remote control of lighting from the bedside.
Actually, by the late 1980's, I had an X10 wired light switch in my master bedroom...and I hated it. The real switch that you normally used to turn the light on or off was a tiny slider below the button. The button itself was the dimmer and if you pressed that, either nothing would happen or you'd begin slowly raising the light from dim to bright, and it would take a hurried series of presses then to get it all the way up.
Even back then, right from the late 1980's, I had an X10 computer controller, a very nice one with buttons too, hooked into my Amiga computer. I could easily write scripts to control X10 through the computer interface, and I had it doing as tricky things then as I ever have (since then, the issues have grown so great, generally, that I haven't had time or inclination to do tricky things).
Now I appreciate something unique about X10 compared with subsequent more advanced, sophisticated, expensive systems. X10 is extremely transparent, on the operational level down to the device. With two little dials you had 255 possible items under control, and you could use these housecode/unitcode numbers easily, entering them into programs and scripts, for example. And if a unit went bad, or you wanted to use it for some other thing, you could easily change.
After what I've been through several years of one advanced system, Insteon, I'm really appreciating the transparency and simplicity of X10.
The two biggest problems with X10 were (1) once they designed something, they never improved the obvious useability faults of the original essential modules, they just kept on introducing new modules with equivalent faults, and (2) ultimately powerlines simply got too noisy for X10, IMO, in order to keep X10 going in my home after the early 2000's I used special filters on noisy appliances, and cross-house bridge (plugged into my dryer power outlet, I tried active reinforcers and found them worse than nothing, I bought several different kinds of X10 meters, and I started thinking about wireless hybrid strategies, since the wireless X10 coverage was fine, I could just use RF modules on more and more things...except ultimately those lightswitches, and when the main lightswitches, switched since the 1980's for security purposes, stopped working, and no matter how many filters I applied to all computers and USB chargers, I still couldn't get them to work anymore, that was about 2013, I switched to Insteon. I had been buying stuff from Smarthome all along, since they generally had slightly higher quality modules (or so it seemed at the time, sadly many of the X10 Smarthome devices didn't have the near immortality of early X10 devices--crude but tough, however later generation X10 were about the same in reliability as Smarthome).
Now, like many Insteon users, I have my horror stories, however just as I started using Insteon finally started making virtually all products "dual band." Without dual band you've got real real trouble in a modern home.
I've been sticking with Insteon, and have no reason to change yet (gasp, it would cost thousands for the switchover, gasp), but many times I've been to the point where changing over was the best thing I could imagine, because I has having so many hours of frustration trying to get the system to work again, and it's essential for security and convenience and everything.
One of those times I felt the strong desire to change was yesterday.
Yesterday after the electrician replaced 3 light switches in my house (one upgraded Insteon, two replacement Insteons) I had a harrowing 5 hours even getting my system working again.
And yet, I should make clear 2 things. Firstly I never lost direct control of my Insteon devices, only computer operated control (those light timers, and so on) through my Universal Devices ISY944i controller (often said to be the best, but all of my frustration appeared to be due to that...until toward the end, when I finally figured out that connectivity problems were at the root of my problems. And then I pulled out all the stops plugging Insteon modules into every nearby outlet, and then finally I think the AC power itself may have gotten cleaner around 4:00 PM.
The most basic problem with the Universal Devices ISY994i is that by the Insteon 2413S PLM it must use seems relatively weak by itself. In my house it appears it must have very close receivers for the mesh type system to work. Individual Insteon links are weak (in an electrically noisy house) but if you have a bunch of them, they work better and better.
But since the PLM by itself seems weak* it means in particular I must have connectivity to something at least as close as the kitchen light. Once I have good connectivity to the kitchen light (which is just across the room from the PLM, but often has a hard time, making me erroneously think that the 2413S was single band, that's about what it seems like), everything starts working again. Strangely connectivity to the patio light, in the same box as the kitchen light, doesn't help much at all. I must have connectivity to the kitchen light. If the Kitchen Light has just been replaced, I'm in Catch 22 because I need the Kitchen Light for the ISY to have connectivity to the Kitchen Light, which it hasn't linked yet until it gets that connectivity. Plugging in enough known good modules nearby can help push it up the mountain.
(*Just noticed, I have the switching supply for the ISY plugged into the same outlets as the PLM, which probably doesn't help connectivity.)
I'd figured this all out before a couple years ago, but it all came back with the kitchen light switch replacement. But before I figured that out, I had spent 4 hours digging myself into a deeper and deeper hole with less and less working, until nothing was working at all. And that's on top of upgrades in which the you need to remember to do the second part of the upgrade, which isn't done automatically, and then you must fight Mac security to do so.
You MUST have clear enough power line to reach the next Insteon dual band device. If not, it cannot communicate with anything. I often forget this however, but it's basically why my system stopped working, and trying to fix it without fixing that problem just made matters worse and worse.
Fortunately, the ISY994i is a network device, and in principle could be located anywhere (not near a computer itself...for best results). However, as it happens, mine is near the computer, plugged into the same kitchen circuit as the UPS which powers the computer, but an earlier-in-circuit outlet. Well it's OK mostly, but it also appears the ISY994i needs above-simple-control level of communication reliability, for sending the complex linking and scene changing commands.
So as it turned out in the end I was really trying to work around a basic hardware problem, it wasn't really (or at least entirely) the fault of the Universal Devices software, and the conceptual design of Insteon itself. But I have many of complaints about those things as well, and those seemed to be bothering me entirely for 5 hours or more yesterday, and they still do bother me.
First, not really the source of my problems in general, but always on my mind since the days of X10, is the whole notion of "scenes." Conceiving of the home control scenarios as "scenes" in virtually all cases makes configuring the system, and often just using it, far more complex than necessary.
The X10 notion of "macros" (a combination of actions) is far more direct and useful. Basically in a Macro you just do things, as you would if you were personally directing the system. Some of those things, in principle, could be contingent on other things (and I figured tricky ways to do that using my X10 computer interface in the late 1980's) but generally that wasn't even necessary.
A good example of macro is what I now have as a scene called Relax. It dims the kitchen light (that is no longer possible, I've planned an alternative low level light), turns off the living room light and turns on the living room Lava Lamp.
Now as a macro, this set of changes makes perfect sense, it's what I do when I want to relax in the kitchen and living room area, I basically replace the bright lights with dim ones. But, as a Scene, it makes no sense, because the Scene implies there is an "off" state as well and an "on" state, and it turns out there is no general "off" state.
It could be, for example, that leaving Relax means finally going to bed, turning out all the lights that are turned out under such circumstances. Or it could be that you want to turn all the lights back on, or specifically in the living room or specifically in the kitchen. Now I supposed you could say those are all different scenes too. But there's no benefit in conceptualizing them as scenes when the macro equivalent, which is simpler (as it has only one direction), does just fine.
In fact, scenes propagate loose ends, for the reason that if scenes are turned on, there is (at least in an open ended system like Insteon or X10) they might never be turned off. Say I turn on Relax but later decide I need the living room light back on, then go to bed and turn all lights off. Now the "Relax" scene is still turned on, but all the devices in that scene were directly or through other means turned off. So it's "on" but it's not "on" at all. This creates problems when you want to turn it on later, or have an indicator for the scene. So, to fix this loose end, it's necessary to have a "program" (in Universal Devices terminology, essentially a timer driven macro) clean it up, at some convenient time of day, by turning the Relax scene off presumably when it's no longer being used anyway.
So in an open ended system, you propagate loose ends which need to be cleaned up. What about a closed system, where there are nothing but scenes? Well there, of course, you have the issue that it's barely possible to know all the possibilities that will be needed in the future, and every small change will require a great reconception of everything to add back in all the new possibilities. You can see why the very high end systems (which use direct communication like Ethernet to every device) which are closed must be very expensive and require a huge design/support effort.
But in all that, I still can't see how anything is gained over the most basic level of Macros. Every scene imaginable could either be a macro, or a pair of on/off macros.
The Scene idea is similar to the way computers have gone generally in the past 40 years. More complex, and less transparent. I think the transparency part is actually the biggest loss of all. Computers of the 1980's, like the Amiga, were generally more fun than computers today precisely because they were more transparent, I am coming to think. In modern systems, transparency is out because that interferes with Job #1: selling you more stuff! And selling information about you to others, largely for that purpose.
I've generally noticed that systems take greater and greater lengths to hide you from both the files behind how a system works, and your personal collection of music files, photo files, and video files, and document files, and so on.
This idea was actually embodied in reverse in the original Mac OS. In Mac OS, you files were front and center through the then primary Finder application. You find your file, and click on it. You don't think, necessarily, about the program involved. Mac figures that out.
Nowadays, it's the reverse. Front and center, is the application. It may or may not save or use personal files. If it does save them, it almost always defaults to some proprietary format with no direct interpretation by any other program. It may or may not be possible to "export" to standard file formats, and of course in doing so you lose much operational information.
Anyway, while I consider ISY994i indispensible for Insteon (and they have a new version that adds Zwave also), in a lot of ways, the complexity shows the poor choice of design ideas, which I think comes back to the idea of Scenes (v Macros).
Insteon itself at the raw level lets you link buttons and actions. That's how you can set up remote control features. But in ISY994i, there is no such simple linking. To make a button turn something on, you need to create a Scene, then you link both a "controller" and a "responder" to that Scene. In a relatively simple system where you mostly have single buttons controlling single actions, this is a ridiculous level of added complexity.
And then, every time you add anything to anything, ISY994i takes that as an opportunity to update every part of the system, even it seems controllers and modules that have nothing to do with the change(s) made. And then, if certain parts aren't operating correctly, such as in the situation where you made major changes to the system and full communication capability is not yet restored, ISY994i seems to run retries at updating things that weren't fully updated, this time or on some previous occassion.
So here we can see, and I think this very often happens in more obscure systems where we can't at all tell what is going on, but things seem rather slow, you have a combinatorial re-update explosion, where long delays (waiting for things to respond that aren't going to respond because their communication isn't working well enough yet) compound other long delays. Really it has seemed ridiculous at least since 1995 that we know computers can perform millions if not billions of operations per second, but making some small change can nevertheless take minutes if not hours. What in the heck is the machine doing???
So for example I simply create a new scene, with nothing yet added to it. It would seem to me that this new Scene is just a placeholder at this point, and ISY994i console application as yet needs to do nothing. But instead it takes the opportunity to try updating everything. Then likewise when you add the first controller, and subsequently when you add the first responder. So simply making one button perform one action can take 15 minutes or so, mostly waiting the system to communicate with and update every device to match the new configuration.
Actually, by the late 1980's, I had an X10 wired light switch in my master bedroom...and I hated it. The real switch that you normally used to turn the light on or off was a tiny slider below the button. The button itself was the dimmer and if you pressed that, either nothing would happen or you'd begin slowly raising the light from dim to bright, and it would take a hurried series of presses then to get it all the way up.
Even back then, right from the late 1980's, I had an X10 computer controller, a very nice one with buttons too, hooked into my Amiga computer. I could easily write scripts to control X10 through the computer interface, and I had it doing as tricky things then as I ever have (since then, the issues have grown so great, generally, that I haven't had time or inclination to do tricky things).
Now I appreciate something unique about X10 compared with subsequent more advanced, sophisticated, expensive systems. X10 is extremely transparent, on the operational level down to the device. With two little dials you had 255 possible items under control, and you could use these housecode/unitcode numbers easily, entering them into programs and scripts, for example. And if a unit went bad, or you wanted to use it for some other thing, you could easily change.
After what I've been through several years of one advanced system, Insteon, I'm really appreciating the transparency and simplicity of X10.
The two biggest problems with X10 were (1) once they designed something, they never improved the obvious useability faults of the original essential modules, they just kept on introducing new modules with equivalent faults, and (2) ultimately powerlines simply got too noisy for X10, IMO, in order to keep X10 going in my home after the early 2000's I used special filters on noisy appliances, and cross-house bridge (plugged into my dryer power outlet, I tried active reinforcers and found them worse than nothing, I bought several different kinds of X10 meters, and I started thinking about wireless hybrid strategies, since the wireless X10 coverage was fine, I could just use RF modules on more and more things...except ultimately those lightswitches, and when the main lightswitches, switched since the 1980's for security purposes, stopped working, and no matter how many filters I applied to all computers and USB chargers, I still couldn't get them to work anymore, that was about 2013, I switched to Insteon. I had been buying stuff from Smarthome all along, since they generally had slightly higher quality modules (or so it seemed at the time, sadly many of the X10 Smarthome devices didn't have the near immortality of early X10 devices--crude but tough, however later generation X10 were about the same in reliability as Smarthome).
Now, like many Insteon users, I have my horror stories, however just as I started using Insteon finally started making virtually all products "dual band." Without dual band you've got real real trouble in a modern home.
I've been sticking with Insteon, and have no reason to change yet (gasp, it would cost thousands for the switchover, gasp), but many times I've been to the point where changing over was the best thing I could imagine, because I has having so many hours of frustration trying to get the system to work again, and it's essential for security and convenience and everything.
One of those times I felt the strong desire to change was yesterday.
Yesterday after the electrician replaced 3 light switches in my house (one upgraded Insteon, two replacement Insteons) I had a harrowing 5 hours even getting my system working again.
And yet, I should make clear 2 things. Firstly I never lost direct control of my Insteon devices, only computer operated control (those light timers, and so on) through my Universal Devices ISY944i controller (often said to be the best, but all of my frustration appeared to be due to that...until toward the end, when I finally figured out that connectivity problems were at the root of my problems. And then I pulled out all the stops plugging Insteon modules into every nearby outlet, and then finally I think the AC power itself may have gotten cleaner around 4:00 PM.
The most basic problem with the Universal Devices ISY994i is that by the Insteon 2413S PLM it must use seems relatively weak by itself. In my house it appears it must have very close receivers for the mesh type system to work. Individual Insteon links are weak (in an electrically noisy house) but if you have a bunch of them, they work better and better.
But since the PLM by itself seems weak* it means in particular I must have connectivity to something at least as close as the kitchen light. Once I have good connectivity to the kitchen light (which is just across the room from the PLM, but often has a hard time, making me erroneously think that the 2413S was single band, that's about what it seems like), everything starts working again. Strangely connectivity to the patio light, in the same box as the kitchen light, doesn't help much at all. I must have connectivity to the kitchen light. If the Kitchen Light has just been replaced, I'm in Catch 22 because I need the Kitchen Light for the ISY to have connectivity to the Kitchen Light, which it hasn't linked yet until it gets that connectivity. Plugging in enough known good modules nearby can help push it up the mountain.
(*Just noticed, I have the switching supply for the ISY plugged into the same outlets as the PLM, which probably doesn't help connectivity.)
I'd figured this all out before a couple years ago, but it all came back with the kitchen light switch replacement. But before I figured that out, I had spent 4 hours digging myself into a deeper and deeper hole with less and less working, until nothing was working at all. And that's on top of upgrades in which the you need to remember to do the second part of the upgrade, which isn't done automatically, and then you must fight Mac security to do so.
You MUST have clear enough power line to reach the next Insteon dual band device. If not, it cannot communicate with anything. I often forget this however, but it's basically why my system stopped working, and trying to fix it without fixing that problem just made matters worse and worse.
Fortunately, the ISY994i is a network device, and in principle could be located anywhere (not near a computer itself...for best results). However, as it happens, mine is near the computer, plugged into the same kitchen circuit as the UPS which powers the computer, but an earlier-in-circuit outlet. Well it's OK mostly, but it also appears the ISY994i needs above-simple-control level of communication reliability, for sending the complex linking and scene changing commands.
So as it turned out in the end I was really trying to work around a basic hardware problem, it wasn't really (or at least entirely) the fault of the Universal Devices software, and the conceptual design of Insteon itself. But I have many of complaints about those things as well, and those seemed to be bothering me entirely for 5 hours or more yesterday, and they still do bother me.
First, not really the source of my problems in general, but always on my mind since the days of X10, is the whole notion of "scenes." Conceiving of the home control scenarios as "scenes" in virtually all cases makes configuring the system, and often just using it, far more complex than necessary.
The X10 notion of "macros" (a combination of actions) is far more direct and useful. Basically in a Macro you just do things, as you would if you were personally directing the system. Some of those things, in principle, could be contingent on other things (and I figured tricky ways to do that using my X10 computer interface in the late 1980's) but generally that wasn't even necessary.
A good example of macro is what I now have as a scene called Relax. It dims the kitchen light (that is no longer possible, I've planned an alternative low level light), turns off the living room light and turns on the living room Lava Lamp.
Now as a macro, this set of changes makes perfect sense, it's what I do when I want to relax in the kitchen and living room area, I basically replace the bright lights with dim ones. But, as a Scene, it makes no sense, because the Scene implies there is an "off" state as well and an "on" state, and it turns out there is no general "off" state.
It could be, for example, that leaving Relax means finally going to bed, turning out all the lights that are turned out under such circumstances. Or it could be that you want to turn all the lights back on, or specifically in the living room or specifically in the kitchen. Now I supposed you could say those are all different scenes too. But there's no benefit in conceptualizing them as scenes when the macro equivalent, which is simpler (as it has only one direction), does just fine.
In fact, scenes propagate loose ends, for the reason that if scenes are turned on, there is (at least in an open ended system like Insteon or X10) they might never be turned off. Say I turn on Relax but later decide I need the living room light back on, then go to bed and turn all lights off. Now the "Relax" scene is still turned on, but all the devices in that scene were directly or through other means turned off. So it's "on" but it's not "on" at all. This creates problems when you want to turn it on later, or have an indicator for the scene. So, to fix this loose end, it's necessary to have a "program" (in Universal Devices terminology, essentially a timer driven macro) clean it up, at some convenient time of day, by turning the Relax scene off presumably when it's no longer being used anyway.
So in an open ended system, you propagate loose ends which need to be cleaned up. What about a closed system, where there are nothing but scenes? Well there, of course, you have the issue that it's barely possible to know all the possibilities that will be needed in the future, and every small change will require a great reconception of everything to add back in all the new possibilities. You can see why the very high end systems (which use direct communication like Ethernet to every device) which are closed must be very expensive and require a huge design/support effort.
But in all that, I still can't see how anything is gained over the most basic level of Macros. Every scene imaginable could either be a macro, or a pair of on/off macros.
The Scene idea is similar to the way computers have gone generally in the past 40 years. More complex, and less transparent. I think the transparency part is actually the biggest loss of all. Computers of the 1980's, like the Amiga, were generally more fun than computers today precisely because they were more transparent, I am coming to think. In modern systems, transparency is out because that interferes with Job #1: selling you more stuff! And selling information about you to others, largely for that purpose.
I've generally noticed that systems take greater and greater lengths to hide you from both the files behind how a system works, and your personal collection of music files, photo files, and video files, and document files, and so on.
This idea was actually embodied in reverse in the original Mac OS. In Mac OS, you files were front and center through the then primary Finder application. You find your file, and click on it. You don't think, necessarily, about the program involved. Mac figures that out.
Nowadays, it's the reverse. Front and center, is the application. It may or may not save or use personal files. If it does save them, it almost always defaults to some proprietary format with no direct interpretation by any other program. It may or may not be possible to "export" to standard file formats, and of course in doing so you lose much operational information.
Anyway, while I consider ISY994i indispensible for Insteon (and they have a new version that adds Zwave also), in a lot of ways, the complexity shows the poor choice of design ideas, which I think comes back to the idea of Scenes (v Macros).
Insteon itself at the raw level lets you link buttons and actions. That's how you can set up remote control features. But in ISY994i, there is no such simple linking. To make a button turn something on, you need to create a Scene, then you link both a "controller" and a "responder" to that Scene. In a relatively simple system where you mostly have single buttons controlling single actions, this is a ridiculous level of added complexity.
And then, every time you add anything to anything, ISY994i takes that as an opportunity to update every part of the system, even it seems controllers and modules that have nothing to do with the change(s) made. And then, if certain parts aren't operating correctly, such as in the situation where you made major changes to the system and full communication capability is not yet restored, ISY994i seems to run retries at updating things that weren't fully updated, this time or on some previous occassion.
So here we can see, and I think this very often happens in more obscure systems where we can't at all tell what is going on, but things seem rather slow, you have a combinatorial re-update explosion, where long delays (waiting for things to respond that aren't going to respond because their communication isn't working well enough yet) compound other long delays. Really it has seemed ridiculous at least since 1995 that we know computers can perform millions if not billions of operations per second, but making some small change can nevertheless take minutes if not hours. What in the heck is the machine doing???
So for example I simply create a new scene, with nothing yet added to it. It would seem to me that this new Scene is just a placeholder at this point, and ISY994i console application as yet needs to do nothing. But instead it takes the opportunity to try updating everything. Then likewise when you add the first controller, and subsequently when you add the first responder. So simply making one button perform one action can take 15 minutes or so, mostly waiting the system to communicate with and update every device to match the new configuration.
