Doorbell Extender: Unterschied zwischen den Versionen
(Systemarchitektur hinzugefügt.) |
|||
| Zeile 9: | Zeile 9: | ||
Zusätzlich scheint es sinnvoll nicht nur die Information einer Türklingel, sondern auch die Information eines betätigten Türöffners zu übertragen. Somit ist man <s>gewarnt</s> informiert, wenn jemand in den Space kommt. | Zusätzlich scheint es sinnvoll nicht nur die Information einer Türklingel, sondern auch die Information eines betätigten Türöffners zu übertragen. Somit ist man <s>gewarnt</s> informiert, wenn jemand in den Space kommt. | ||
| − | == | + | == Idee: == |
* An der Tür wird ein [http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html NetIO] eingesetzt, dass Schaltvorgänge an der Türklingel und am Türöffner überwacht. | * An der Tür wird ein [http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html NetIO] eingesetzt, dass Schaltvorgänge an der Türklingel und am Türöffner überwacht. | ||
* Passiert auf einer der beiden Leitungen ein Event, wird dieses per IP Broadcast über Ethernet Broadcast und ein UDP auf einem lustigen Port ins LAN geblasen. | * Passiert auf einer der beiden Leitungen ein Event, wird dieses per IP Broadcast über Ethernet Broadcast und ein UDP auf einem lustigen Port ins LAN geblasen. | ||
* Dort können beliebige Slaves mithören und das anzeigen. | * Dort können beliebige Slaves mithören und das anzeigen. | ||
* Im Frickelraum gibt es dann ein weiteres netIO, dass auf diese Broadcasts wartet und diese, wenn sie eintreten, visualisiert. | * Im Frickelraum gibt es dann ein weiteres netIO, dass auf diese Broadcasts wartet und diese, wenn sie eintreten, visualisiert. | ||
| + | |||
| + | == Systemarchitektur: == | ||
| + | Die Abbildung ''Doorbell-Extender: Event Propagation'' veranschaulicht den Aufbau des Systems. | ||
| + | [[Datei:Doorbell-Extender Systemueberblick.png|thumb|Doorbell-Extender: Event Propagation]] | ||
| + | Das sendende netIO überwacht die digitalen Eingänge 1 .. 4. Tritt an einem dieser Eingänge eine positive und/oder eine negative Flanke auf, so wird das dem Eingang zugeordnete Event per UDP ins LAN übertragen. Im LAN können nun mehrere Clients nach Broadcast-Events lauschen. | ||
| + | |||
| + | Auf Client-netIOs können Events im LAN lokale Aktionen zugeordnet werden. Solche Aktionen können das toggeln eines Ausgangs, das Ein- oder Ausschalten eines Ausgangs, sowie das zeitgesteuerte Aktiveren eines Ausgangs sein. | ||
| + | |||
| + | === UDP-Pakete: === | ||
| + | Doorbell-Extender Ereignisse werden per UDP als IP-Broadcast auf Port 1337 (''wir sind in einem Hackerspace; welcher Port auch sonst!) übertragen. Der Datenteil der Pakete hat dabei einen fixen Aufbau: | ||
| + | <Proto ID>;<Event name>=<Event type> | ||
| + | Den Feldern kommt dabei folgende Bedeutung zu: | ||
| + | * '''Proto ID''': String, der das genaue verwendete Protokoll beschreibt. Zunächst ist nur der String "''EVENTDISTRv1''" erlaubt! | ||
| + | * '''Event name''': Name des Events. Maximal 10 Zeichen. | ||
| + | * '''Event type''': Der Typ des Events. Gibt an, was genau Auslöser des Events war. Erlaubte Eigenschaften sind: | ||
| + | ** ''RISING'' | ||
| + | ** ''FALLING'' | ||
| + | |||
| + | Der Datenteil des UDP-Paketes darf eine maximale Länge von 100 Byte nicht überschreiten! | ||
| + | [[Datei:Beispiel UDP-Paket.jpg|thumb|Beispielhaftes UDP-Paket]] | ||
Version vom 17. Oktober 2012, 23:15 Uhr
| Doorbell Extender | |
|---|---|
| Beschreibung: | Verlängerung der Türklingel, sowie des Türöffners in den Frickelraum |
| Kontakt: | Matthis |
| Status: | aktiv (Was heißt das?) |
| Quellcode: | svn.tinyhost.de |
| Lizenz: | netIO Firmware: GNU GPL |
Inhaltsverzeichnis
Ziel:
Oft sitzt man gemütlich im Frickelraum und hängt seinen Problemen nach. Und dann passiert es: Es klingelt, aber niemand bekommt es mit. Das Problem: Mit N (N > 0) geschlossenen Türen oder halbwegs lauter Musik bekommt man von der Klingel im Frickelraum schlicht nichts mehr mit.
Dies soll nun dadurch behoben werden, dass ein Klingeln an der Tür von einem Gerät erkannt und über ein Protokoll über das Netzwerk verteilt wird. Slaves sollen aufgrund einer solchen Information ein Klingeln erkennen und somit ihrerseits ein Klingelsignal auslösen.
Zusätzlich scheint es sinnvoll nicht nur die Information einer Türklingel, sondern auch die Information eines betätigten Türöffners zu übertragen. Somit ist man gewarnt informiert, wenn jemand in den Space kommt.
Idee:
- An der Tür wird ein NetIO eingesetzt, dass Schaltvorgänge an der Türklingel und am Türöffner überwacht.
- Passiert auf einer der beiden Leitungen ein Event, wird dieses per IP Broadcast über Ethernet Broadcast und ein UDP auf einem lustigen Port ins LAN geblasen.
- Dort können beliebige Slaves mithören und das anzeigen.
- Im Frickelraum gibt es dann ein weiteres netIO, dass auf diese Broadcasts wartet und diese, wenn sie eintreten, visualisiert.
Systemarchitektur:
Die Abbildung Doorbell-Extender: Event Propagation veranschaulicht den Aufbau des Systems.
Das sendende netIO überwacht die digitalen Eingänge 1 .. 4. Tritt an einem dieser Eingänge eine positive und/oder eine negative Flanke auf, so wird das dem Eingang zugeordnete Event per UDP ins LAN übertragen. Im LAN können nun mehrere Clients nach Broadcast-Events lauschen.
Auf Client-netIOs können Events im LAN lokale Aktionen zugeordnet werden. Solche Aktionen können das toggeln eines Ausgangs, das Ein- oder Ausschalten eines Ausgangs, sowie das zeitgesteuerte Aktiveren eines Ausgangs sein.
UDP-Pakete:
Doorbell-Extender Ereignisse werden per UDP als IP-Broadcast auf Port 1337 (wir sind in einem Hackerspace; welcher Port auch sonst!) übertragen. Der Datenteil der Pakete hat dabei einen fixen Aufbau:
<Proto ID>;<Event name>=<Event type>
Den Feldern kommt dabei folgende Bedeutung zu:
- Proto ID: String, der das genaue verwendete Protokoll beschreibt. Zunächst ist nur der String "EVENTDISTRv1" erlaubt!
- Event name: Name des Events. Maximal 10 Zeichen.
- Event type: Der Typ des Events. Gibt an, was genau Auslöser des Events war. Erlaubte Eigenschaften sind:
- RISING
- FALLING
Der Datenteil des UDP-Paketes darf eine maximale Länge von 100 Byte nicht überschreiten!
