Open Source Hardware controller

[linuxha]

The cloud is an option, ... .

Dang, I hate to do this but I'm going to have to refrain from any further discussions on cloud computing as my employer is a cloud provider (AT&T, I work for the Labs). I don't work on cloud services directly but what I do for a living (Managed Network Services) is way too close and I don't want my opinions to be taken as a commentary on my employer's services (which, so far, my discussions are not).

I can still talk about HA but I must walk a very careful line as my employer is getting into a form of HA (that announcement was scary). So far what I do seems to be outside the scope of their products.

Edit: I've got to find a name for this "device" how about BaaMoo

BaaMoo?

PS: I don't have HVAC in my home. It's all electric (thermostat in each room) and a couple of window air conditioners for summer cooling.

 

[BlueBill]

BaaMoo well I'm pretty sure it's not taken

Lets give it a working name, HydrA (HA get it) it's not set in stone but is better than "device". I'll hold back on the cloud for now.

 

[electron]

Very interesting thread, especially since I always wanted to build something like this myself. Maybe you can even consider using KickStarter.com to launch the project If done right, this could be a really popular project.

 

[linuxha]

Very interesting thread, especially since I always wanted to build something like this myself. Maybe you can even consider using KickStarter.com to launch the project If done right, this could be a really popular project.

I'm not sure what to say (other than very cool). Let me do some reading on the site. I've not gotten to the point of thinking about making a real product (heck I'm still working on the DollHouse software architecture). I will say this: if this were funded I would change a few of the specs (but not many). Definitely a more USB busses and the ability for a bit more ram. Now I need to trim the requirements such that it can be defined and purchased. Now that my mind is wondering I need to really bear down on this idea.

Dan, you're a troublemaker! :axe: Thanks for the pointers. ray:

 

[BlueBill]

I'm listening, what specs would you like to change? And yes Kickstarter is a definite possibility. Remember HydrA is just a node, it's also simple and cheap. Possibly less than a half dozen ICs on a PCB that could be also sold in kit form (64pin TQFP is by far the largest IC and this can be hand soldered with a little skill). Nowhere near the HCS-C PCB complexity and cost. The Linux component could control many HydrA's, I would also imagine most NAS devices could be easily tasked as the master controller.

As for more RAM what would it be used for? More Flash would be nice as it would allow for a more graphical interface & logging but that could easily be handed off to a Linux box or cough the cloud. USB is a resource hog and can be a nightmare to get the manufactures on board, there is also licensing required if I'm not mistaken. Simple USB protocols are fine like HID (useless for HA) or thumb drive support (useful). A Bluetooth stack would be nice but getting the firmware written might be an ordeal. Even the ZigBee stack isn't as straight forward as one would hope and that's why I chose XBee ZB modules as the dirty work is already done and firmware updates and licensing are supplied by Digi.

I guess it would be called a NAC (Network Accessible Controller) if that's true then we could call it a "NIC NAC"

 

[linuxha]

I'm listening, what specs would you like to change?

Switch from the PIC32 to the PIC18, make the module a more general purpose device. Build a hardware equivalent of an Arduino. Make plugin modules that handle conditioning. I think there are several Open Source RTOS available.

And yes Kickstarter is a definite possibility. Remember HydrA is just a node, it's also simple and cheap. Possibly less than a half dozen ICs on a PCB that could be also sold in kit form (64pin TQFP is by far the largest IC and this can be hand soldered with a little skill). Nowhere near the HCS-C PCB complexity and cost. The Linux component could control many HydrA's, I would also imagine most NAS devices could be easily tasked as the master controller.

As for more RAM what would it be used for? More Flash would be nice as it would allow for a more graphical interface & logging but that could easily be handed off to a Linux box or cough the cloud. USB is a resource hog and can be a nightmare to get the manufactures on board, there is also licensing required if I'm not mistaken. Simple USB protocols are fine like HID (useless for HA) or thumb drive support (useful). A Bluetooth stack would be nice but getting the firmware written might be an ordeal. Even the ZigBee stack isn't as straight forward as one would hope and that's why I chose XBee ZB modules as the dirty work is already done and firmware updates and licensing are supplied by Digi.

I guess it would be called a NAC (Network Accessible Controller) if that's true then we could call it a "NIC NAC"

Dang licensing BTW, are you thinking of putting this stuff into the NAC? I would think that getting another main controller like one of the NAS or the Sheeva. Licensing is already taken for these boxes. The cost of these boxes with the various IO is $100.

The reason for the extra RAM is that all software grows to fit available RAM. You may start out with too much but after a years you need more. We learned this with routers. Max RAM, max flash is the general rule. Once you start using features future feature creep eats memory.

BTW, the libusb can use HID to communicate with such devices (though I hate HID for serial type communications which is why I've written device drivers to turn the HID into tty like devices).

 

[BlueBill]

I'm just in the process of contacting Steven Goodwin (Minerva) and see if I can get his take on this on these forums.

The HydrA (NAC) will have a USB port although it's purpose is a little vague at the moment, it's there like early HDTVs used to advertise HD ready.
As for what's inside the NAC it's currently as follows. I'm also thinking there is no reason to load the NAC up with software (bloatware) that's not needed for the task at hand. It would only need to support the protocols of things it's actually going to communicate with. An HVAC NAC would be identical hardware wise to a HA or sprinkler system NAC but would have different firmware. Modular programming, it's common on your PC but seems very uncommon on embedded devices.

Flash 512Kb, SRAM 128Kb, ~ 75MIPs, RTCC (not battery backed up but working on a supercap solution)
Ethernet
Two universal serial ports RS232, 422, 485 *RS232 mode can be split into a dual RX, TX pair with a cable. +5V on pin 9
XBee ZB (S2) ZigBee module
Three relays, 120VAC @ 2A should do the trick plus simple RC snubbers.
Phoenix header for Four GPIO (depending on what's left A/D, PWM, CCP, interrupt...)
IR inputs on CD line or either RS232 port (capture mode, handy for capturing PWM data) using external IR adapter (TSOP1138 with a couple of parts on a DE9 socket, similar to the GC-100)
Three IR outputs (programmable modulation)
USB OTG port
Four bit generic RJ6 socket with +5V designed for simple bit bashed I/O or relay driver expansion.
DIP switch or jumpers for setup, serial port mode, termination and biasing (the bias & terminating resistors could also be done inside a DE9...)
9V to 35V operation, a switchmode regulator to 5V @ 2A (relays, external I/O) and 3.3V for the logic.
Possibly the "Sparkfun version" of Power Over Ethernet capable.

As with anything there are tradeoffs, keeping it simple yet practical is always a balancing act.
Example I could add an SD card but that would mean giving up a serial port, the USB OTG can support a Flash drive and I still say give the horsepower and storage to a cheap & cheerful Linux box but leave the connectivity to me

 

[linuxha]

...
Possibly the "Sparkfun version" of Power Over Ethernet capable.

As with anything there are tradeoffs, keeping it simple yet practical is always a balancing act.
Example I could add an SD card but that would mean giving up a serial port, the USB OTG can support a Flash drive and I still say give the horsepower and storage to a cheap & cheerful Linux box but leave the connectivity to me

SD vs a serial, since both are just bit ports on the controller why not let the user decide? The correct software module would setup the port accordingly and *poof* serial becomes SD card or serial ROM or IR or ... I think you get the idea. I'm not certain why you would need one device with so much IO in one place. I tend toward many smaller devices (with Ethernet that becomes difficult as there seems to be a shortage of small, ready made uC chips with Ethernet).

I'm not sure why you would need the SD card if you have the Linux box. The Linux box would keep track of the data (if for logging). The rest of the hard work is left to the Linux box. When I was discussing memory that's where I was suggesting the extra RAM (sorry if I confused anyone).

 

[BlueBill]

On the particular 32MX the SPI port shares the same pins as one of the serial ports, and the RTS/CTS pins are muxed with another ports RX/TX (actually a good thing). I agree about storage being handed off to an external device so the SD card went bye bye.
As for the ports, that's the tough one. Mostly it's connectors, the single most expensive components are the CPU & MAX3160 ICs, to save a buck or two I could use a single MAX3160 & MAX3232 but the savings would be minimal and it adds an additional part to the mix and slightly reduces the flexibility. The option could be available to order only the configuration you need, PCB stays the same but like a car you can order it with several combinations.

Spartan I like that too.

 

[BlueBill]

I'm concerned the LQFP is not going to be possible to hand solder so I'll probably only offer the device in assembled form. That said there is little need to avoid the 100pin TQFP 32MX.

So with all those extra pins the addition of the following two items would not be difficult, remember adding more will always increase the cost.

1. I2C Real Time Clock Calendar DS1388 RTCC with trickle charger.

2. Micro SD-Card like the kind you'd find in a cell phone.

 

[BlueBill]

I've added a trickle charged RTCC IC (no batteries to change ever) and the POE (Sparkfun variation) to the list. Also added I2C expansion to the mix.

Product description.

32MX695F512L (80MHz, 512k, 128k)
10/100 Ethernet
Two DE9 RS232/422/485 serial ports can be split for up to four RS232 ports
USB OTG port (mostly for Flash drives)
(CD pins are capture inputs and can be used for IR in via TSOPxxxx)
(DTR & DSR are TTL level compatible)
Socket for ZigBee (XBee S2 or S2P)
Three relays
Three IR blaster jacks
(can be internally jumpered to control external small signal relays)
Four GPIO
I2C expansion connector (internal & RJ6)
SPI RTCC (DS139x) with supercap & trickle charger
SPI SD card slot
8 position DIP switch (address (4), serial mode(4))
JTAG & PICKit3 headers
9V-37V power connector, Power over Ethernet (Sparkfun variation)

 

[BlueBill]

The peripherals often have much better documentation than the controllers. Also easy enough to use port sniffers to figure out the protocol. I'm building one piece of the puzzle at a time, starting with what IMHO is an integral part of any HA / HVAC system, the I/O controller. You've got to start somewhere.

 

[BlueBill]

Twas a busy thread, something I said?

Anyways a small snag but nothing major. The PNY chip on the 32MX695 uses some UART pins so I had to consider an alternative. I've chosen the ENC28J60 (10Mb Ethernet IC from Microchip) to replace the 10/100 Ethernet PNY.
The rub is that I can't see it being very practical to use an SD card as I would figure the transfer time to backup when using 10Mb Ethernet would be very slow but I could be wrong. In place I'll use a couple of EEPROMs (128k x 8)

The IR outputs will use three of the capture outputs (PWM) this allows the IR modulation to be done at the hardware level.
ICD and JTAG connectors will be available for in circuit programming and debugging.

 

[linuxha]

Twas a busy thread, something I said?

Yeah, you said you were going to build it. :lol:

I'm working on my half, the Linux stuff.

 

[BlueBill]

Ok Professor Chaos

Yes, I'm building it and currently trying to drive the cost down, may change the serial ports and drop in an 8 bit MCU to make this much more approachable to the programmers.

The USB has to go but I'll keep the SD card (2Gb max) a single RS232-485 and an RS232 port OR ZigBee XBee radio. This will drop the cost by around $30

Trying to keep it under the $200 US mark.

A Serial to Ethernet bridge isn't cheap.