Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
uberbus [2011/01/22 23:06] 2001:a60:10ff:c401::2uberbus [2011/01/24 19:17] – created schneider
Line 1: Line 1:
-====== Intro ====== +~~REDIRECT>uberbus:start~~
-The uberbus shall get the home automation bus of our hacker space. +
- +
-===== Persons ===== +
- +
-  * schneider +
-  * fpletz +
-  * bsx +
-  * neunr +
-  * andi +
- +
-===== The RS485/Wireless/IPv6 Hybrid System ===== +
- +
-==== Basics ==== +
-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 https://brezn.muc.ccc.de/svn/uberbus +
- +
-=== Firmware === +
-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. +
-=== Software === +
-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 [[ubd|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: +
-^Position^Length^Description^ +
-|0|1 Byte|Source| +
-|1|1 Byte|Destination| +
-|2|1 Byte|Flags| +
-|3|1 Byte|Length| +
-|4|      |Data| +
- +
-Address format on the local segment: +
-^Mask^Description^ +
-|0xxxxxx|Unicast| +
-|1xxxxxx|Multicast| +
-|1111111|Broadcast| +
- +
-Flags: +
-^Value^Name^Description^ +
-|0x01|ACK|The packet contains a valid ack sequence| +
-|0x02|SEQ|The sequence number of the data transmitted| +
-|0x04|NOACK|This data doesn't need to be acked| +
-|0x08|MGT|This packet contains bus management data| +
-|0x10|UNSOLICITED|This packets is not part of a connection| +
-|0x20|ACKSEQ|The ack sequence transmitted with the ack| +
- +
- +
- +
-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) +
- +
-==== IPv6 ==== +
- +
-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.txt
  • Last modified: 2022/09/14 09:00
  • (external edit)