I’m going to start by admitting that this isn’t going to be a tirade of abuse against the oddly named 802.15.4-based wireless tech, but rather a request for comments on an open, lightweight alternative, particularly for low-cost sub-GHz applications. I know what the point of ZigBee is, and the ability to form into self-organising mesh networks is an obvious advantage for large scale industrial automation, but for domestic applications it feels like overkill.
The industry is apparently thinking along the same lines, because the vast majority of DIY Home Automation (HA) stuff on the market in the UK at least is using proprietary sub-GHz like LightwaveRF. The driver here is probably cost, but it is my view that the lack of interoperability that this leads to is holding back the mass-market acceptance of HA, and is unnecessary.
What I am looking for is a simple, open (as in freely available, properly documented, royalty free) standard for sub-GHz RF that could be implemented on the cheapest of radios in minimal code space. I am aware of MQTT-S, although even that looks too complicated for simple sensor/actuator applications, and it doesn’t define the lower layers, instead running on top of something like ZigBee or 6LoWPAN.
Some outline requirements:
- Both master/slave and peer-to-peer networks should be supported. Meshing need not be ruled out, but is not a key design aim.
- Security should be a primary design criterion – most proprietary protocols seem to be wide open.
- The use of IP on the air interface should not be considered – bridging to IP networks is a job for a central controller/bridge rather than pushing this complexity (read cost) out to every single node.
- Battery powered nodes must be supported, e.g. discontinuous receive/timeslot techniques.
- Unidirectional nodes must be supported for extreme cost-sensitive applications.
- Obscure modulation schemes must be avoided to maximise the range of available radios.
An initial implementation would aim to support SiLabs EzRadio and EzRadioPro, which covers HopeRF RFM12/22/23 modules which are all in common use.
I am keen to hear from anyone with an interest in this area, particularly if there is something filling this need that I have missed. I am also particularly interested in others’ views on the complexity of existing solutions – perhaps I am being over-sensitive!