[OpenTRV-dev] RF protocol

[Mike Stirling]

Starting this separate thread in response to Jack's post flagging up the two RFM12-based products, as I think we need to start giving the protocol some serious thought:

Summary of current status:

* We are planning on using RFM22B/23B (which are basically the same apart from output power) rather than RFM12B. The primary reason for this is their ability to operate down to 1.8 V. They are also a significantly more capable radio, e.g. they can speak the FHT OOK protocol with a fairly minor software trick and no horrible hacks.
* I have an ATMEGA328 + RFM23B based sensor board close to being ready that can do temperature, light and pulse count/interval timing (for utility meters). Aiming for sub £10, and Stuart has some nice plastics for anyone wanting a finished unit. Target lifetime off a pair of AA alkalines is 5+ years.

As I have mentioned before, I want to develop a properly documented, open protocol for home automation/sensor projects that could be handled by both RFM2xB and RFM12B (maybe others). Security is a key requirement for me, and I have already done some work on doing AES256 on an AVR to determine feasibility - it seems ok. Simplicity is also important - if a full implementation will fit in a 16K 8-bit MCU then I would be happy.

Stuart: I lost the link to that Arduino RFM22 library that looked like it might be along the right lines - please can you repost it?

We already discussed using binary name/value pairs for the payload. Philip suggested BSON for the format, but it suffers from some deficiencies, e.g. no native support for fixed-point decimal, important for embedded use - we'd need a workaround to specify the position of the decimal point. I had in mind a binary name field that would encode (separately) the quantity being measured and the unit. This would enable applications to "discover" packet contents, given a suitable global registry and a sufficiently open way of registering new quantity and unit IDs.

Thoughts?

Mike





-- 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20130320/e516ff5e/attachment.html>