Does the HA world need yet another hardware I/O device?

I've been checking out various hardware I/O devices and even built a few myself. I want the devices and sensor states to be accessible from my HA software on my PC, currently HomeSeer. However, I'd like the flexibility to move to other software at some point if desired. The problem has been an absense of a standard hardware I/O protocol that most HA software would support. You're left with creating plug-ins, assuming the HA software even supports that. Given that most HA software supports X10 over a CM11A, my thought is to have a box that emulates a CM11A over an RS-232 port. The CM11A emulator would represent each endpoint as a specific X10 device type, depending on whether it was digital or analog, input and/or output. To the HA software, the sensor network looks like regular X10 devices, but with the reliability and speed of a hardwired network.

Any serious automation software should allow the creation of drivers for supporting external hardware, otherwise they would be hugely limited.
 
I've been checking out various hardware I/O devices and even built a few myself. I want the devices and sensor states to be accessible from my HA software on my PC, currently HomeSeer. However, I'd like the flexibility to move to other software at some point if desired. The problem has been an absense of a standard hardware I/O protocol that most HA software would support. You're left with creating plug-ins, assuming the HA software even supports that. Given that most HA software supports X10 over a CM11A, my thought is to have a box that emulates a CM11A over an RS-232 port. The CM11A emulator would represent each endpoint as a specific X10 device type, depending on whether it was digital or analog, input and/or output. To the HA software, the sensor network looks like regular X10 devices, but with the reliability and speed of a hardwired network.

Any serious automation software should allow the creation of drivers for supporting external hardware, otherwise they would be hugely limited.
I agree with your statement, but it also limits the market for your hardware if a plug-in has to be developed before it can be used. I'm only suggesting a path to rapid adoption by supporting a widely used -- albeit somewhat limited -- protocol. The native protocol would also be available for more feature rich plug-in support down the road.
 
I agree with your statement, but it also limits the market for your hardware if a plug-in has to be developed before it can be used. I'm only suggesting a path to rapid adoption by supporting a widely used -- albeit somewhat limited -- protocol. The native protocol would also be available for more feature rich plug-in support down the road.

a simple protocol would be way to limiting and as soon as you have to deviate to accommodate an enhanced feature you end up having to customize the driver anyway and as soon as you start creating a protocol to do all things for all people you end up with a design by committee that gets nowhere fast. Any large company that invests significantly in their product doesn't want to give up their protocol for anybody else to use. I started this thread with the ideal of getting some feedback on my hardware system, network-able, expandable, and open protocol but it doesn't get much attention because it is not a known quantity and not established. kind of a chicken and egg situation...
 
Also make yourself know to all the open source projects, those guys respect the little guy and the free access to your code. :) Might post on the forums at http://www.EventGhost.com this is a very hardware IO limited project built with python for easy development. Also MisterHouse, really search sourceforge.net and you may find a several.
 
Also make yourself know to all the open source projects, those guys respect the little guy and the free access to your code. :) Might post on the forums at http://www.EventGhost.com this is a very hardware IO limited project built with python for easy development. Also MisterHouse, really search sourceforge.net and you may find a several.
it's funny that you would mention this because I did decide to go the open source way but haven't said anything yet as I have a few details to work out first.
 
CV = Channel Vision (http://www.channelvision.com/)

They make cans that are compatible with Leviton. They have a grid of holes to mount things into and various racks and brackets and products that snap right in the grid. It looks very clean when everything snaps in. It is also nice because the way their brackes work one can route wires beneath them... Many of us have lots of wires....
 
here's a sneak peek at the new boards (Project Prometheus) The major features are:
- 50 I/O lines
- 2 Xpansion ports with your choice of plug in modules for RS232, USB, Ethernet, XBee
- mounts in plastic case, Leviton mount or on standoffs in standard home automation cabinet
- User downloadable firmware defines the boards functionality
- Built in Controller Area Network for networking to other boards
- Can also act as a protocol converter from RS232 to XBee, Ethernet to CAN, USB to RS232 etc, etc
- Current functionality includes switch inputs, status LED outputs, dimming outputs (AC or PWM DC), infrared inputs, analog inputs, real time clock, timers, RS232
- Driver available for CQC

This picture is an overview of the main cpu board with the current plug in modules
overview.jpg


This picture is the main cpu board mounted in a plastic case. I milled out the two slots in the front to accommodate the two RS232 ports. In this configuration it could act as a protocol converter
incase.jpg


This is the cpu mounted to a Leviton plastic mount and sitting in a Leviton cabinet
levitonmountingbracket.jpg


This is the CPU board mounted on standoffs in a Leviton case with an expansion board next to it that brings out 48 points of I/O
standoffswithIOexpansion.jpg


This is the cpu board acting as a 5 port CAN hub
5portCANexpansion.jpg


This is the board with a specific I/O board to handle 6 rooms of lighting control through a single CAT5 cable to each room. In this case each room would get either 3 switches/3 status LEDs and one dimming output (for driving a local solid state relay) or 2 switches/2 status LEDs, an infrared input and one dimming output.
6roomlightingexpansion.jpg
 
Very slick!

You say it allows downloaded firmware. Are we talking writing all of the code from scratch (not a problem) or coding on top of some sort of tiny OS? Is there a development software package?
 
Very slick!

You say it allows downloaded firmware. Are we talking writing all of the code from scratch (not a problem) or coding on top of some sort of tiny OS? Is there a development software package?

I am going to make a bootloader freely available for the microprocessor. This will allow the firmware to be downloaded across either the CAN network or the RS232 port (which means USB or ethernet if you are using that module)
The firmware is already done and has been in use on older boards for a number of years. I am just trying to figure out in what configuration I will either make the hardware open source (and invite a number of board builders to build and sell them if a user doesn't want to built their own) and then I would sell the firmware modules.
If you wanted to create your own software you would need the C compiler and possibly a debugging module/software. I can release some of the low level routines for the board to get somebody started and I would like to see others contribute to this as open source but there is also the option of creating custom software and selling it. As I mentioned, I haven't figured out exactly how this will all pan out.
The processor is the Freescale MC9S12DP512
 
Back
Top