The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: Honeywell Smartfit research and the start of ageneric interface (wish me luck!)



Hi Dave
Any chance of having a look at your message structure....8 byte protocol
sounds good to me...

Frank
----- Original Message -----
From: Dave McLaughlin
To: ukha_d@xxxxxxx
Sent: Tuesday, November 04, 2003 10:15 AM
Subject: RE: [ukha_d] Re: Honeywell Smartfit research and the start of a
generic interface (wish me luck!)


Hi James,

I have just completed my own heating control system prototype and should be
wiring it in for real this weekend. It is currently on trial at the moment
to make sure the software is stable enough. So far so good.

http://www.embeddedcomputer.co.uk/Projects/Controller/controller.html

I have used the CAN bus for my own designed home automation and can
recommend it to anyone. The best bit about it, is that you don't need a
master to poll the bus. Each module can do this itself and transmit when it
wants, based on collision detection and arbitration. It is a great system
if
you only need to send limited data (there are only 8 bytes in the packet)
on
the control bus. If you need to move more data, then xpl or xap may be a
better solution.

Regards
Dave...
---
Very funny Scotty, now beam down my clothes!!!
---


-----Original Message-----
From: James Derrick [mailto:james-ukha@xxxxxxx]
Sent: 03 November 2003 17:11
To: ukha_d@xxxxxxx
Subject: Re: [ukha_d] Re: Honeywell Smartfit research and the start of a
generic interface (wish me luck!)


On Mon, 03 Nov 2003 09:57:57 -0000, you wrote:

>I also program Microchip Pic controllers and I will be passing info
>to the Pic via, RF modules using the Pic to stream data.

There's a pair of tiny 433MHz modules (TWS-434a) on my desk for a
future project!

>How suitable is MisterHouse on a PC, for interfacing via a single
>serial port?

Misterhouse is just a chunk of Perl. It includes lots of stuff you can
ignore, or build up slowly to create intricate systems. The standard
stuff includes generic serial item code so you can build what ever
protocol you want into it.

Examples include X10 CM11a, X10 MR26, Dallas 1-Wire bus, and I think
xAP (sorry- not seen xPL, but it can't be hard to do).

>As for the Pic protocol, I dont mind what it is, if we can create a
>Standard then thats fine or use an established one?

When I get that far, my own ancient attempt (Distributed Automation
Protocol) is toast as other more promising protocols are out there.
xAP and xPL are just two that look good, although a lighter binary
protocols with error correction might be needed for RF (SNAP?
http://www.hth.com/snap/).

Have you read about the commercial Z-Wave? (http://www.zen-sys.com/)

As you no doubt know, the main problem is watching a time-critical
interface AND doing asynchronus comms with limited CPU. Parsers and
state machines aren't too hard to write, but on a PIC too complex a
protocol will just eat up interrupt time.

Proton+ BASIC doesn't seem able to do interrupt routines making
watching two asynchronus interfaces 'interesting'. I'd prefer not to
invent another standard, though.

A shared RS485 serial interface (see the 75176 chip) is probably going
to be my physical layer as it seems pretty simple to do using a PC
master polling the bus. The CAN bus is another possibility, but looks
a bit harder (think there was a project in Elektor recently).

>Sorry I drifted fron the original topic a bit!

That's what forms are for :-)


James

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.530 / Virus Database: 325 - Release Date: 22/10/2003


[Non-text portions of this message have been removed]



Home | Main Index | Thread Index

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.