Frustrated with home automation software

-jim said:
"..you won't have a problem with Insteon.."
 
When it first came out I jumped on the Insteon bandwagon.
I already was using a lot of smarthome products in X-10. The advertising and specs sold me on the protocol.
Then I find out that the devices really did NOT do Powerline And Radio as the specification and advertising said they would. 
(They only recently, in the last couple of years started shipping the dual mode devices).
Spent more than $1,000.00 and now it all sits in a box with a lot of other Home Automation pieces.
 
Insteon has a huge issue if you have backup power supplies. Never had issues with X-10 (well at least on the power line side of things)
 
-jim
 
Just walked around and counted - I have 11 UPSs in the house plugged into every TV, Directv, Stereo, Sonos, Computer, etc. in the house  Basically everything I don't want zapped by the numerous power drops and surges we have in my neighborhood. Including one 240V 3kVA unit in the racks. I also have all CFL bulbs (except for 3 Cree LEDs), electrically noisy pool pump motors (controlled by Insteon) and all the other things that supposedly kill Insteon signals. As I stated above - no problems with dropped or missed signals, ever. 
 
As with all things YMMV.
 
Dean Roddey said:
BTW, I'm not sure we have 'all kinds' of discovery protocols, not in the sense that they are ubiquitously supported. Of course Z-Wave could have used a proprietary one, and they do. But for security reasons they chose to require low power transmission for enrollment, to make it harder for someone from the outside to get themselves into your network. At the time that all of this was done, there was no support for encryption in Z-Wave modules, and of course that means that most modules that exist don't have it. Without that, network wide, long range auto-enrollment would be sort of dangerous.
 
Well, here are (13) I found at: https://en.wikipedia.org/wiki/Service_discovery.
Which includes SSDP a component of Universal Plug and Play which I would say is ubiquitously supported.
 
And no security in Z-Wave modules. Really, in todays climate, no security! Well that is a great idea!
 
TCP is a protocol. And generally, thing work well together. But I do agree, one of the biggest problems with Z-Wave is the lack of support by many manufactures for parts of the even basic protocol. Heck, they do not even agree on the terminology of the protocol.  And "Z-Wave certified" is a joke because of it.
 
And all of this Home Automation stuff sure looks like we should be using SNMP which hich does everything(?) we have been discussing that Z-Wave is lacking. Why do we need yet ANOTHER protocol when SNMP is a mature and well implemented on millions of devices and allows for great discovery and flexibility.
 
I did run across Network Inclusion (NWI) which implies that a device could be included across the network. Requires that the routing nodes support NWI. I saw some of the VisaRF+ devices support it from the routing node standpoint. Anyone know if it works and if there is a controller that supports NWI?
 
 
Dean Roddey said:
Because these system have to be supported. If you want to hack away, you can do that and there are 'you are on your own' type products out there I'm sure that will allow it. But if someone is selling you a product, and they are going to be the ones getting yelled at if it isn't working right, then the less such open ended, uncontrolled entry points to the system the better. JavaScript is a horrendously loose language, which would let people shoot themselves in the foot before they even got it out of the holster for the most part. It's one of the last things I'd want anyone writing critical logic in.
 
Well I have shot myself in the foot a more than once trying to work with 3-4 different scripting languages. I would assume an implementer would perform some parsing on the JavaScript to ensure that nothing stupid was done within reason. Form an end-user perspective, there are MILLIONS of people that already know JavaScript and only a few hundred that know these proprietary scripting languages at all and probably less than 100 that know them well.  And is that not what all those Software User Agreement legal stuff is all about?  :mellow:
 
Again, thanks for the feedback and input. Good discussions and I just want to be sure there is not some magic out there that I was missing.
 
-jim
 
picta said:
You nailed it, so don't use z-wave if you want a reliable whole house automation. z-wave is a protocol, not a product, so no z-wave devices are created equal. I only use these as a supplemental extension of my HA, if it goes bad, it's not a big deal. Wireless devices will always perform sub-par compare to wired alternatives, but when it comes to lighting, there is not much of a choice. IMO, the best bang for the buck are zigbee based centralite switches, my friends and family use these successfully for over 5 years now. The next best choice, but much more expensive, is RadioRA2. Both products are very robust, and come with extensive RS232 command interface, so you can integrate them with almost any controller.
 
Well, sure. Hard-wired stuff is probably faster, more secure and reliable. But, most of us are not doing life threatening stuff with most of our devices.
And (most anyhow) Wireless networks are fast enough for most things we are doing.
 
And like you said, at this point in time, do we really have a choice? The Market, at the moment, chose Z-Wave. Sure ZigBee is better. (But not there yet)  and BetaMax was better than VHS.
 
And when I built our new home 10 years ago, put in 3k feet of Cat5 and 1k feet of COAX.  My Smoke/Fire detectors and alarms bells/strobes and whistles and 50+ more devices are hard-wired. But most people will go with Wireless for the convenience (and cost) and that half of them live in an apartment or rent a place where they can not put in wires.
 
-jim
 
-jim said:
Well, here are (13) I found at: https://en.wikipedia.org/wiki/Service_discovery.
Which includes SSDP a component of Universal Plug and Play which I would say is ubiquitously supported.
 
UPnP isn't really very reasonable for small devices. It requires a reasonably full XML parser implementation, and it requires regular broadcasts on the network, which battery powered devices would have an issue with.
 
-jim said:
And no security in Z-Wave modules. Really, in todays climate, no security! Well that is a great idea!
 
Well, they didn't back then when Z-Wave was laid out in its basic form. They have it now, but a lot of modules were already sold by that time, and of course for those devices that don't require it, they still don't implement it. It's saved usually for devices like door locks, probably because it's heavier weight in various ways. If enrollment required it, then they'd all support it, but it's a chicken and egg thing. The old modules can't be required to since they don't have it, so it would likely require a completely new enrollment mechanism and both would have to be supported for some time, adding to the confusion. Since it's not required for most modules, they don't implement it.
 
@jim
 
People usually look to home automation to simplify maintenance and enhance convenience, to outsource routines to a controller and free time to do something else. If you have to babysit your system all the time and spend weekends on debugging, that would defeat the purpose of HA. Many newcomers to HA hope to circumvent the "triangle" equation of price/reliability/functionality - choose any 2 features and you can find a product on the market that implements them.  And the manufacturing also follows the triangle rule, so it would be pointless to expect the product makers to produce super functional and reliable products for the price the consumers are willing to pay; and this will always hold in relative $$, even as the technology improves in the future.
 
Over time many HA enthusiasts settle on the last 2 features and switch from the "starter" products (zwave,insteon,x10) to more expensive commercial grade components and many others bite the bullet and add more wire to their homes. There is a huge difference between having a reliable home automation and living in a lab for trying to make it all work. After spending endless hours in the past trying to make x10,zwave,insteon toys to work, we are finally at piece with our automated house.
 
picta said:
Over time many HA enthusiasts settle on the last 2 features and switch from the "starter" products (zwave,insteon,x10) to more expensive commercial grade components...
Which "commercial grade" components are you referring to?
 
NeverDie said:
Which "commercial grade" components are you referring to?
In my earlier post above I have named a couple: Centralite jetstream and RadioRA2. Both are used in commercial applications, like hotels. There are many other systems, but they are more expensive and/or less open for integration. I personally have a hard-wired lighting system, but that is only possible in a new build.
 
Yeh, if you require a retrofit solution, and a just works solution, Something like RA2 or Centralite is the way to go. If you can do wired, something like C-Bus becomes an option in terms of a reasonably priced wired system, or at least I think it's reasonably priced (as such things go), I've never looked at the pricing myself. It's available in the US now. What's the pricing like on the Centralite wired system, Elegance I think it's called? Their wireless system is Zigbee based.
 
I am not sure if C-bus is available in the US, its more popular in UK and Australia. HAI was going to release US version of omni-bus, but I have not seen it yet. As for the elegance pricing, it'll depend on the configuration, the more devices are in your system, the less will be the cost per device, but it will be robust even with a lot of devices unlike the wireless setups. As a ball-park, the price per load plus 3 buttons in a similar setup will be about $90 for jetstream, $100 for elegance and $120 for RA2. RA switches look the nicest but its prices for buttons (sceen controller) are ridiculous.
 
C-Bus was purchased by Schneider (sp?) a while back, which is a US company and supposedly they are now making it available here, or that's what I heard.
 
IN terms of scene controllers, if you are using an automation system with RA2 integrated, you don't necessarily need to use their scene controllers. Some folks don't want to depend on a third party system for lighting; but, for scenes, I would think that's not critical functionality. The individual lights would still be controllable via the lighting system's own switches.
 
-jim said:
And why do (almost all) Home Automation systems use proprietary scripting ?  Did they not see that ECMA/JavaScript Script won this war several years ago ?.
 
I agree! Over at CastleOS we chose to use C# for scripting. Easy to learn (especially for Javascript/Java devs), and unlimited potential. You can literally do anything in that language. 
 
And, therein lies the rub. You can do anything. At some point, you will want to take your architecture upwards and onwards, and that can become very difficult because user customization and third party device drivers were free to do whatever they wanted, whenever they wanted to. It can put you into a very limited box when you want to make changes to your system's plumbing. You won't be able to make hardly any assumptions at all.
 
It also means that third parties can create drivers that only they have the code for, which in and of itself can become a stone around your neck, because you'll have customers who depend on them, but you can't modify them to adapt them to changes in your architecture. The Homeseer folks definitely experienced the realities of that problem. You also can't do anything if the folks who wrote them disappear and you have customers who depend on them but some problem crops up, or the device is upgraded in some way and the driver won't work with it anymore. You can say, well, we didn't write it, not our problem. But the customers don't tend to see it that way. They will say they only purchased the product because they could control the hardware they have.
 
There are pros can cons to anything. But, in this case, our approach has more pros than cons. Or at least it avoids a huge number of cons, whatever its pros may or may not be. The insidious thing about going the other way is that you don't often realize what the real cons are until it's too late.
 
Anyway, not trying to start a fight, just explaining the situation as I see it.
 
Dean Roddey said:
And, therein lies the rub. You can do anything. At some point, you will want to take your architecture upwards and onwards, and that can become very difficult because user customization and third party device drivers were free to do whatever they wanted, whenever they wanted to. It can put you into a very limited box when you want to make changes to your system's plumbing. You won't be able to make hardly any assumptions at all.
 
It also means that third parties can create drivers that only they have the code for, which in and of itself can become a stone around your neck, because you'll have customers who depend on them, but you can't modify them to adapt them to changes in your architecture. The Homeseer folks definitely experienced the realities of that problem. You also can't do anything if the folks who wrote them disappear and you have customers who depend on them but some problem crops up, or the device is upgraded in some way and the driver won't work with it anymore. You can say, well, we didn't write it, not our problem. But the customers don't tend to see it that way. They will say they only purchased the product because they could control the hardware they have.
 
There are pros can cons to anything. But, in this case, our approach has more pros than cons. Or at least it avoids a huge number of cons, whatever its pros may or may not be. The insidious thing about going the other way is that you don't often realize what the real cons are until it's too late.
 
Anyway, not trying to start a fight, just explaining the situation as I see it.
Some concrete examples would helpful....
 
Dean Roddey said:
And, therein lies the rub. You can do anything. At some point, you will want to take your architecture upwards and onwards, and that can become very difficult because user customization and third party device drivers were free to do whatever they wanted, whenever they wanted to. It can put you into a very limited box when you want to make changes to your system's plumbing. You won't be able to make hardly any assumptions at all.
 
It also means that third parties can create drivers that only they have the code for, which in and of itself can become a stone around your neck, because you'll have customers who depend on them, but you can't modify them to adapt them to changes in your architecture. The Homeseer folks definitely experienced the realities of that problem. You also can't do anything if the folks who wrote them disappear and you have customers who depend on them but some problem crops up, or the device is upgraded in some way and the driver won't work with it anymore. You can say, well, we didn't write it, not our problem. But the customers don't tend to see it that way. They will say they only purchased the product because they could control the hardware they have.
 
There are pros can cons to anything. But, in this case, our approach has more pros than cons. Or at least it avoids a huge number of cons, whatever its pros may or may not be. The insidious thing about going the other way is that you don't often realize what the real cons are until it's too late.
 
Anyway, not trying to start a fight, just explaining the situation as I see it.
 
Not exactly, our scripting doesn't work like HomeSeer's, so we won't run into those issues. I'll explain...
 
The first big difference is we don't support third party device drivers. One of our competitive differentiators is all of our device support is integrated internally, with the goal of providing the end user a consistent experience. At present, we ship with support for more devices internally integrated than any other automation software/hub as far as I know, though with 3rd party driver support there are other pieces of software that support more total devices than we do at present. We're working to fill in those gaps however, working top down with the most popular protocols/devices.
 
With our scripting, you can do the following:
  • have a voice command that runs any script, and can speak back to you. 
  • have a scene or event fire a script as an action
  • have an event run a script as a condition checker (i.e. event only runs if script returns true)
  • have a script that interfaces with the internal CastleOS Scripting API to interface with internal devices, scenes, groups, etc. This will allow much more complicated conditions, including those that rely on external services, than what's built in, for example.
  • have a script act as a virtual device through the scripting API - but the driver is never loaded internally and is the responsibility of the script to manage, it simply reports back to the API as needed
With the way we've designed it, we've been able to leverage the full power of .NET and C#, without creating any potential points of failure as CastleOS evolves. The only thing that could potentially change is the scripting API, and that can be managed with versioning. 
 
Edit: Also I should add our scripting is not only more powerful in capability, it's much faster as it runs natively - the code is compiled in real time as needed and run natively on the .NET CLR, which as far as I know no other automation software does. 
 
Back
Top