The uberbus shall become the home automation bus of our hacker space.

• System Overview
• Network Protocols
• Security
• Client Libraries
• Server Applications
• Device Classes
• Node Development
• Hardware

• schneider
• fpletz
• bsx
• neunr
• andi

The idea is to run several small and cheap wired or wireless networks connected to a small, embedded and IPv6
capable computer like a Fonera running OpenWRT or a Dockstar running Debian. These computers then provide an
IPv6 capable interface to the nodes attached to them. Every node gets at least one unique address in the sub net
associated with this master computer.

The wired network is based on a RS485 bus. It is a single master bus. The node at the master acts as the bus
master which periodically polls other nodes for new messages.
Nodes can set a preferred polling interval which is submitted when they send their discovery packet. The bus master then
tries to poll the node at the given interval. This is useful to lower the load on the bus which is used to poll the nodes
for new messages. A node which handles user input like a light switch should request a lower polling interval than
nodes which just gather sensor data like temperature sensors or actuators like lamps or power outlets.

The current implementation reserves 10% of the time for polling other nodes. The nodes can request a polling interval in
multiples of 30ms which is the minimum polling interval supported.

The wireless part is done using cheap RFM12 modules operating at 433MHz. The system uses a CSMA/CD approach using
random back offs when the medium is busy. In general the wireless network is less reliable than the wired network.

The current implementation can be found in the svn repository in the uberbus project.

svn co https://brezn.muc.ccc.de/svn/uberbus

trunk/firmware/lib contains the current implementation if the uberbus library for avr devices. It supports a single master
RS485 bus and a CSMA/CD wireless network. The firmware is capable of switching from a slave mode to a master mode to
pose as the bus master. The code can be compiled to include either one or both of these modes.

trunk/firmware/moodlamp-rf contains a sample application which can run as a slave on the wireless or wired bus and can
switch to the master role to control the bus when attached to a host computer.

trunk/software/ubd contains the control application running on the computer providing the IPv6 connectivity. The details
and usage of this tool is described on this page.

trunk/software/simplelamp contains a simple python script capable of serving a single lamp on the usb bus. It is much more
simple to set up compared to ubd and doesn't require special permissions on the host computer. It sets up TCP and UDP sockets on the host
computer and accepts the same packet format as ubd.

trunk/software/pythonlib contains a simple python library to access the uberbus via IPv6 and a TCP connection to the devices.
Currently a second library is supplied to access moodlamps which are connected to the bus.

Packets are encapsulated in frames specific to the interface on which they are transmitted. This is transparently
encapsulated in the interface drivers in the firmware.

The actual packets always have the following format:

Address format on the local segment:

Flags:

Idea:
Compare with implementation by jolly:
http://home.eversberg.eu/simp.txt Jolly does not have source dest mac, as he thinks of a single master, which sets
a master-flag so the slave knows if he has to listen (master flag set)
Maybe, we can combine the ideas.
(luja)

Es werden hierbei globale IPv6-Adressen fuer jedes Device zugeordnet. Um Authentifizierung und zum Schutz vor Replay Attacks zu gewaehrleisten wird IPsec AH (alternativ ESP fuer Verschluesselung) eingesetzt. Jeder HSC3 kuemmert sich hierbei um die Authentifizierung/Entschluesselung der Pakete und schickt die reine Payload an das Device ueber RS485 weiter. Etwaige Antworten werden dem jeweiligen Host zurueckgeschickt (UDP oder TCP), hierbei muss aehnlich wie bei NAT ein Connection State gehalten werden.

Jeder HSC3 bekommt ein /112 Subnetz zugewiesen, wie z.B. 2001:470:9aca::23:0/112. Die Device-IDs werden direkt aus der letzten Gruppe des IPv6-Adresse gewonnen. Das Device mit der ID 42 haette dann die IP 2001:470:9aca::23:42. Es muss sichergestellt werden, dass entsprechende Routen im Netz (Router) gesetzt werden, so dass Pakete an den zustaendigen HSC3 geleitet werden.

Die Authentifizierung der Keys sollte von einem weiteren Rechner (brezn) durchgefuehrt werden. Hierbei waere eine feingranulare Moeglichkeit der Rechtevergabe zu implementieren (z.B. Zugriff auf bestimmte Klassen von Devices). Die Daten zur Authentifikation sollten aus dem LDAP gezogen werden. Zur Authorisierung soll eine weitere Datenbank zu diesem Zweck erstellt werden.