Recommendations for Easily Expandable and Programmable Home Automation.

[AdamCollins]

Well in that case, I say give it a shot! And despite what I said about not wanting to use your code, if you get something working well think about open sourcing it. Either way I would be interested in how things go for you, please post some progress reports here as you get further along.

I would really think about using an event-driven engine (there are lots available: Python Twisted, Perl AnyEvent, lebev for C, etc) as a basis for your work. You can look at EventGhost for windows to see how something was written with stacklass python with a very simple event-driven framework.

Misterhouse has a lot of community support and works well for a lot of people - but it is basically just a giant loop where you each device / interface is checked to see if there is a new action to take. There are a lot of better / more modern ways of tackling that now, so if you are writing your own from scratch don't use that as a guide on how to build one of these systems. If Premise gets open sourced (http://cocoontech.co...se-open-source/) I would check that code out too.

Either way I would grab any of the free or open source products you can (Misterhouse, Premise, Heyu, Zenah-Perl [1], EventGhost, Freedomotic) and see how they do things to get some ideas. Remember Picasso, "Good artists copy, great artists steal".

Oh, and I don't think three way switches are too hard. Just to be save you could pick up a book on wiring (something like Black & Deckers Complete Guide to Wiring for $15) and scan through it. Wiki has a good description of basic 3-way/4-way wiring: http://en.wikipedia....y_and_four-way. The tricky thing about home automation products is they don't use a typical 3-way or 4-way wiring circuit, and each manufacture does things a bit different. For instance, Intermatic z-wave switches use standard switches (not standard 3-way, standard 2-way) to add a 3-way zone. If you understand how normal circuits work, and then just spend a few minutes studying the little piece of paper that comes with your device, you can figure it out. Or, just post your existing circuit here and ask how to modify it and I'm sure someone will help.

[1] https://github.com/beanz/zenah-perl/

I doubt I'd have anything anyone would actually be interested in using for a long time, if ever. This is more a personal project that I want to do because it sounds neat. However, if something comes over me and I end up writing something awesome (unlikely ), I'll share it.

Someone else mentioned Premise, and it looks interesting, so I'll be looking into that, if for nothing else than to just poke around and see how it does things; as one of my computer science professors in college told me, "Never be too proud to steal a good idea."

As for the three-way switches: if all else fails, my father-in-law is an electrician. I hate asking him for help though... "Hey could you come over and help me with this? Because I, the man your daughter married, am too useless to figure it out."

 

[tmbrown97]

So, if I am understanding you correctly, Elve's plugin architecture would allow me to write pretty much any logic I wanted into a plugin, and then that plugin would trigger actions in Elve. Is that right, or am I misunderstanding you?

There is a lot of info for people to develop their own drivers and interfaces; I'd be surprised if you'd need to write a plugin for any logic though - there's some wizard-type rules engines that exist, but you can bust into full blown scripting within the rules engine and get as wild as you want. If a device or library doesn't exist (something that checks for flying ping elephants, returns a boolean value) - you could write that, then access it via the rules engine.

Check out www.codecoretechnologies.com - there's a 40-day free trial, then to buy the starter edition is only $99 right now - there's just no way to lose there. Also I haven't written anything custom (fiddled with making a google driver but someone else came along and took care of that, thankfully!)... but you might peruse his forum and get a better idea.

 

[AdamCollins]

...There are two versions of Insteon, the older version there were CRC errors in the firmware so you couldn't send bulk messages, you were forced to send 1 byte at a time. So network discovery can take 10's of minutes. The newer firmware has fixed that as well as enable dual-band communciation and enhanced security...

Thank you for the tips.

How does one ensure that they get the newer Insteon firmware. Is it just a matter of buying the correct controller/switches, or is there something else I need to look out for?

 

[AdamCollins]

Adam,

If you're hell bent on writing an Insteon driver, consider writing one for an existing HA application (that lacks an Insteon driver). You're efforts will benefit the HA app's community and you can benefit from the community's existing body of work. It makes more sense to me than creating a standalone Insteon driver that, quite honestly, will have limited appeal to the general HA community.

Premise has an Insteon driver but it works with the PowerLinc Controller (PLC) as opposed to the newer PowerLinc Modem (PLM). A new Insteon PLM driver for Premise would earn you the undying gratitude of the Premise community (how cool is that!). If you know how to code in C++, C#, or VB.NET then you're good to go. Otherwise, you could attempt to write a driver using Premise's flavor of VBScript (the existing ZWave driver is written this way) as long as your driver model is single-threaded and uses no callbacks.

If that doesn't appeal to you, consider writing an Insteon driver for XaP or XPL. Several HA apps know how to communicate via these standards and would benefit from your hard work.

Thanks for the info/suggestions. The software that's catching my eye right now is Elve, and Premise, so I am looking into those. They both appear to be .Net friendly, and since I am most familiar with C#, that's a big plus. Also, undying gratitude is something I could use more of, generally.

 

[AdamCollins]

And don't forget to check the link in my sig to see what other home automation software is out there, you can even filter by INSTEON support. There is so much software (and hardware) out there, rolling out your own solution only makes sense if you are looking for the experience (or researching fast-acting hair loss methods).

I'm losing my hair quickly enough as is, so thanks for the software list.

 

[AdamCollins]

There is a lot of info for people to develop their own drivers and interfaces; I'd be surprised if you'd need to write a plugin for any logic though - there's some wizard-type rules engines that exist, but you can bust into full blown scripting within the rules engine and get as wild as you want. If a device or library doesn't exist (something that checks for flying ping elephants, returns a boolean value) - you could write that, then access it via the rules engine.

Check out www.codecoretechnologies.com - there's a 40-day free trial, then to buy the starter edition is only $99 right now - there's just no way to lose there. Also I haven't written anything custom (fiddled with making a google driver but someone else came along and took care of that, thankfully!)... but you might peruse his forum and get a better idea.

Elve is looking better and better the more I learn about it.

Alright, this probably a dumb question, but I'd like to ask it anyway just to make sure I have an accurate high-level understanding of what it is I need to buy/do:

Let's say that, to start out, I just want to replace one light switch with an Insteon light switch. To do that, I would need to buy:

1. An Insteon light switch to replace the old dumb light switch.
2. A PowerLinc Modem (or some other controller that speaks Insteon) to send commands to that Insteon light switch.
3. Some sort of software that can interface with the controller and tell it what commands to send out.

I used Insteon in the example above to be concrete, but, more generally, one needs to have switches/sensors/devices that speak a particular protocol (Insteon, Z-Wave, X10, UPB, etc.), a controller (PowerLinc Modem, MiCasaVerde Vera 1/2/3, etc.) to issue commands in that protocol, and software (Elve, Premise, CQC, HomeSeer, etc.) that can interface with that controller in order to tell it what commands to send out.

Is that about right, or are there some steps/items I've left out?

 

[jhdale]

Let's say that, to start out, I just want to replace one light switch with an Insteon light switch. To do that, I would need to buy:

1. An Insteon light switch to replace the old dumb light switch.
2. A PowerLinc Modem (or some other controller that speaks Insteon) to send commands to that Insteon light switch.
3. Some sort of software that can interface with the controller and tell it what commands to send out.

That's true, except that if the PLM and the light switch are on different legs of your home's electrical supply, you'll generally need a way to couple the phases. Typically that means two dual-band devices, one on each legs. If you start with a dual-band PLM and a dual-band SwitchLinc, that might be covered right there.

Other issue to consider is that generally the PLM will be plugged in near your computer, UPS, other related hardware. Some of these tend to generate powerline noise. It is not always required but sometimes best to get a powerline filter (e.g. filterlinc).


Other comments... for getting newer components (up to date firmware), you will be fine if you buy from Smarthome. If you buy on Ebay all bets are off.

Three-way switches... you do need to replace both switches. They need to be installed so that both switches get power all the time. Usually you do this by repurposing the traveler wire. There are instructions included but if you have questions plenty of people on the Smarthome forum can help if you describe what your wiring looks like.

 

[wuench]

Thank you for the tips.

How does one ensure that they get the newer Insteon firmware. Is it just a matter of buying the correct controller/switches, or is there something else I need to look out for?

The insteon firmware bugs and support is mostly undocumented by Smarthome/labs. They mostly try to hide the issues from consumers, and even worse, the developers. Buying new today you would most likely get I2 stuff and definitely if you buy dual-band devices. When buying used, or off Ebay, etc, I would make sure to confirm the versions you are getting, as firmware is not upgradable by the end user.

The best site I have found for reference info is Insteon Device List .

 

[Dean Roddey]

I used Insteon in the example above to be concrete, but, more generally, one needs to have switches/sensors/devices that speak a particular protocol (Insteon, Z-Wave, X10, UPB, etc.), a controller (PowerLinc Modem, MiCasaVerde Vera 1/2/3, etc.) to issue commands in that protocol, and software (Elve, Premise, CQC, HomeSeer, etc.) that can interface with that controller in order to tell it what commands to send out.

Pretty much every automation system works similarly in that respect. They will have some internal view of a device, which is generic, and they will provide a means to create drivers or plugins or whatever they are called. These drivers will be 'two faced', in that on one side they look inwards towards the automation system and expose the viewable and settable attributes of the controlled device via that generic view. On the other face, they talk to the device in its 'native tongue'. They translate between these two views.

For instance, in CQC, every device has a name, and a set of named 'fields', such as Volume, Power, etc... So CQC drivers expose the attributes of the device as fields, each of which has some type (on/off, numeric range, text, etc...), access mode (read and/or write), and some other settings, that define how each attribute of the device can be accessed.

Within CQC, you see the devices via this generic view. So you want to turn on the power of a device, you'd write to a field, most likely called Power. The driver will receive that value and translate that into the appropriate message to send to the device. The driver also keeps up with the current values of the attributes of the device that it understands, and makes those values available within CQC. There again, you just read the value of a field to get the current state of that device attribute. These two things are the fundmental building blocks of automation and most everything comes down to reading and writing these fields ultimately.

Things get more complex in a highly networked product like CQC, since you can have lots of clients out there wanting to get to the status of various attributes of any given device. So drivers just keep the information up to date with as little latency as they can manage, and that already stored data is what is handed out. This allows for minimum overhead all around. The drivers just store current data in their fields, and CQC's driver host service can hand that data out to anyone that wants it without having to bother the driver. The drivers only have to really respond directly to clients when they need to send out information written to a driver field (and hence needs to be translated into some command to the device.)

Some devices provide asynchronous reporting of state changes, which makes for minimal latency, as apposed to having to continually round robin through lots of separate requests for various bits of state information. But it also increases complexity since you have to be able to respond to unsolicited messages from the device while you are waiting for a solicited response. But there are well known structures for drivers that work in that way that make it not too bad.

The most complicated ones are the ones for things like Z-Wave, UPB, Insteon, etc... These are drivers that are both dealing with 'meta devices', i.e. really dealing with a whole network of devices, and dealing devices that are very slow to respond by modern communications standards, and due to the nature of the technologies often subject to interference and whatnot. So these types of drivers always tend to be the biggest pain to do. They generally require a lot of configuration information to figure out what's out there, how to deal with it, etc... And since your driver has to expose the devices under control in some generic way, just finding a good way to expose a dynamic list of possibly hundreds of individual devices that make up that 'meta device' can be tricky. I.e. it doesn't have fixed set of fields, those fields change depending on what devices are out there to talk to, which can change over time.

 

[AdamCollins]

Dean Roddey,

Thanks for all the info! I'm looking forward to getting some equipment and diving in. My plan is to order a switch or two and a PLM this weekend, and then when those come in, I'll be giving CQC a shot.

 

[hobbes487]

If you are truly interested in an inexpensive solution that will allow you to directly do development on your system in order to expand it I would suggest one of the open source option available. Open Source Automation is an option that is, obviously, open source and very extensible through developer plugins. It currently supports many protocols, but if you wanted to choose one that is new, you would be able to develop a plugin for it yourself which would satisfy your desire to program it.