Zuletzt geändert am 15. April 2013 um 21:22

Heinzelmaennekes

Version vom 15. April 2013, 21:22 Uhr von Hephaisto (Diskussion | Beiträge) (inserted project template)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Heinzelmaennekes
project status alpha
maintainers Hephaisto
languages C, C++, Python
platform mixed
license unknown
latest downloads

Heinzelmaennekes (abbreviated heinz) is going to be a home automation system. It still has a long way to go, so the codes won't be available for now.

Naming

Heinz is named after Heinzelmännchen. They are house gnomes which do all menial tasks for the human inhabitants while those are asleep.

Basic design

Basic design diagram

The main system consists of three logical parts:

  • Devices: The devices directly control actors and poll sensors. Each device can have up to 255 endpoints.
  • heinzd: heinzd is a deamon on a central server (target platform will probably be a raspberry-pi). It receives notifications from devices upon endpoint changes, decides which actions to take, and sends appropriate responses to other devices. Decisions will be made using embedded python to enable easy expansion, while the backend is written in C++.
  • heinzctl: heinzctl is a library which provides a management interface for the deamon process. It is implemented as a shared library and communicates with the deamon using unix domain sockets, so user rights for the deamon can be implemented via the unix-filesystem.

In addition to these parts, there is a command-line interface heinzcl which uses heinzctl. To enable web-access, it is planned to add a php extension for heinzctl, too.

Communication between heinzd and the devices can happen via different bus systems. Currently only ethernet is implemented, but the interface is designed to be easily interchanged. The bus system (at least for ethernet) will be secured using HMACs.

Disadvantages

  • Single point of failure (heinzd and corresponding hardware)
  • Multiple hops between data input (e.g. light switch) and output (light) - Shouldn't be a problem in local networks.

Advantages

  • Devices are relatively stupid (easy to code), because they don't know each other (and they don't know their dependencies).
  • Functions can be easily changed without having to reprogram devices or distributing firmware over the network.
  • It is easy to create statistics, because all data is available on one machine.
  • Web access can direclty be connected to the deamon without knowledge of the bus system.