Änderungen
Aus Hackerspace Ffm
Die Seite wurde neu angelegt: „'''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. …“
'''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 [http://en.wikipedia.org/wiki/Heinzelm%C3%A4nnchen Heinzelmännchen]. They are house gnomes which do all menial tasks for the human inhabitants while those are asleep.
==Basic design==
[[Datei:Heinz_system_design.png|right|300px|thumb|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.
It still has a long way to go, so the codes won't be available for now.
==Naming==
Heinz is named after [http://en.wikipedia.org/wiki/Heinzelm%C3%A4nnchen Heinzelmännchen]. They are house gnomes which do all menial tasks for the human inhabitants while those are asleep.
==Basic design==
[[Datei:Heinz_system_design.png|right|300px|thumb|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.
