This is an old revision of the document!


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


  • schneider
  • fpletz
  • bsx
  • neunr
  • andi

The RS485/Wireless/IPv6 Hybrid System


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.

Wired Network

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.

Wireless Network

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.

Current Implementation

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

svn co


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.

Internal specification

Packet Description

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:

01 ByteSource
11 ByteDestination
21 ByteFlags
31 ByteLength
4 Data

Address format on the local segment:



0x01ACKThe packet contains a valid ack sequence
0x02SEQThe sequence number of the data transmitted
0x04NOACKThis data doesn't need to be acked
0x08MGTThis packet contains bus management data
0x10UNSOLICITEDThis packets is not part of a connection
0x20ACKSEQThe ack sequence transmitted with the ack

Compare with implementation by jolly: 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.


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.

Authentifikation / Authorisierung

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.

uberbus.1295896542.txt.gz · Last modified: 2011/01/24 20:15 by schneider