Open/Close-Monitor/Hardware-Schalter: Unterschied zwischen den Versionen

Aus Stratum 0
Wechseln zu:Navigation, Suche
K (To Do: Dauerhaft Strom im Flur beschaffen)
K (warum ags, wenn bluebrother auch ein stk500 hat :P)
Zeile 27: Zeile 27:
 
* Apps schreiben
 
* Apps schreiben
 
** Router-Seite
 
** Router-Seite
** Atmel-Seite (die ags hat Entwicklungsboards, Kontakt ist {{Benutzer|cbounce}})
+
** Atmel-Seite ({{Benutzer|bluebrother}} hat ein STK-500 dagelassen)
 
* Wenn Router-LEDs für Statusanzeige: andere LEDs im Router quiet machen
 
* Wenn Router-LEDs für Statusanzeige: andere LEDs im Router quiet machen
 
* unwichtig: das Magenta vom Router loswerden → Stratumlogo?
 
* unwichtig: das Magenta vom Router loswerden → Stratumlogo?

Version vom 8. April 2012, 03:28 Uhr

Open/Close-Monitor/Hardware-Schalter
Beschreibung: Hardware-Schalter zum Setzen des Open/Close-Status
Kontakt: Daniel Bohrer
Status: aktiv (Was heißt das?)
Quellcode: Branch stratum-openclose-spw500v in [1]

Plan

Da das manuelle Pflegen des Öffnungsstatus im IRC fehleranfällig ist (Leute vergessen, den Space auf- oder zuzumachen), soll neben der Eingangstür im Space ein Hardware-Schalter (Lichtschalter, Aufputz-Variante) installiert werden, der den Status auf der Homepage und im IRC setzt. Zusätzlich wären eine rote und grüne Leuchtdiode schön, die Rückmeldung über den aktuell gesetzten Status gibt.

Als Hardware kommt ein ausgedienter Speedport W500V zum Einsatz, auf dem OpenWRT läuft. Dieser ist potent genug, um per SSH eine Verbindung zum Webserver aufzubauen und den Status zu aktualisieren. Über den seriellen Port kommuniziert er mit einem Atmel-basierten Erweiterungsboard, das die LEDs ansteuert und den Schalterstatus an den Router weiterreicht. Das Erweiterungsboard soll wenn möglich über die 3,3V Versorgungsspannung am seriellen Port versorgt werden.

Als Alternative ist es auch möglich, die im Router integrierten LEDs zur Anzeige des Öffnungsstatus zu benutzen.

To Do

  • OpenWRT auf Speedport zum Laufen bringen
    • Serielle Konsole fit machen: keine Kernel-Logs, keine Login-Konsole
    • WLAN zum laufen bringen (Client-Mode, DHCP)
  • Protokoll über UART spezifizieren: Schalter-umgelegt-Event, Handshake? möglicherweise: LED-Farbe setzen
  • Atmel-Board (zB ATtiny 2313, bluebrother hat welche) entwerfen, Hardware beschaffen und bestücken
  • Schalter kaufen (Baumarkt), LEDs und Atmel-Board darin integrieren?
  • Apps schreiben
    • Router-Seite
    • Atmel-Seite (bluebrother hat ein STK-500 dagelassen)
  • Wenn Router-LEDs für Statusanzeige: andere LEDs im Router quiet machen
  • unwichtig: das Magenta vom Router loswerden → Stratumlogo?

Aktuell ungelöste Probleme:

  • Ist ein Aufputz-Schalter zum Schalten von 3,3V ausgelegt?
  • Wie wird der Status im IRC gesetzt?
    • Möglich: über eine Pipe oder Socket mit dem Python-Framework von ZombiePoet kommunizieren
  • Drosselung der Events, um Spam im IRC zu verhindern. Künstliche Verzögerung einbauen?
  • Dauerhaft Strom im Flur beschaffen

Erweiterungen

  • Automatismen:
    • im Türschloss wird ein Kontakt eingebaut, der erkennt, ob die Tür abgeschlossen ist. Falls dies der Fall ist, wird der Status unabhängig vom Stand des Schalters auf "zu" gesetzt.
    • Scannen des lokalen Netzes auf pingbare (gewhitelistete) Rechner, siehe unten
  • Der Router wird an die Klingel angeschlossen und leitet Klingel-Events ins IRC weiter
    • Spätestens hier wäre ein eigener IRC-Client auf dem Router sinnvoll, um nicht immer den Umweg über ZombiePoet gehen zu müssen.
  • Falls noch genügend Platz im Flash (4 MB) und RAM (16 MB) ist, könnte der Router auch für andere Aufgaben verwendet werden.

Hardwareanbindung

Nähere Überlegungen, wie

  • die Hardware (Schalter, Leuchten, Klingel) über einen Mikrocontoller an den OpenWrt Router geknödelt werden
  • Softwarestrukturen aussehen

könnte(n).
Teilweise lose Gedankensammlung von mir (100nano).

Hardware

Grobe schematische Darstellung der Hardwarekomponenten:

Grobe schematische Darstellung der Hardwarekomponenten

Spannungsversorgungen:

  • Router über Steckernetzteil: Steckdose benötigt
  • AVR vom Router: der Pinheader mit der seriellen Schnittstelle bringt gleich 3,3V mit. --> Forderung: AVR muss mit 3,3V laufen. --> Sollte kein Problem sein, AVR Takt auch unkritisch, bei Taktwahl spaetere Baudrate (Abweichungen Solltimings (Stichwort "Baudratenquarz")) beachten.

Umschalter:

  • 2 input pins am uC.
  • GND schalten, uC internen pullup verwenden.

LEDs:

  • Jeweils 1 output für Open/Closed. Z.B. grün/rot. --> Eindeutige geometrische Anordnung (Erkennbarkeit rot/grün-Farbenblinde)
  • Orange als "Update läuft" Anzeige. Wenn aus ist Status übernommen. Details siehe unten.

Einbindung der Klingel:
(Vermute, dass das Läuten auch über den Lautsprecher ausgegeben wird, der auch als Lautsprecher+Mikrofon beim Gegensprechen verwendet wird.)

  • Lautsprecher/Klingel über Optokoppler (OK) und evtl. Gleichrichter (Diode) + Tiefpass an inputpin. (Für Näheres erst Messungen machen)
  • je nach Aufbau den Schalter für "Gegensprechen an" an inputpin des uC. __> Unterscheidung zwischen Klingeln und Sprache.

Pegelanpassung:
Bei Betrieb mit 3,3V nicht nötig, nur, falls aus irgendeinem Grunde doch 5V verwendet werden.

  • Router zu AVR: Kein Problem, 3,3V werden auch bei erwarteten 5V als 1 erkannt.
  • AVR zu Router: zB Spannungsteiler mit 2 Widerständen.

serielle Kommunikation

  • AVR möglichst dumm halten (router ist flexibler, dort kann mal schnell ein script angepasst werden, kein neuflashen des uC nötig)
  • Router kann einzelne Werte des uC abfragen

beispiele:

  • 1 byte als abfragenachricht, uC antwortet mit wert oder setzt ausgang etc.

alternativ

  • ganzes aendern von registern einbauen (spaetere nutzung weiterer io-pins ohne umflashen moeglich

Logik/Ablauf

Ausgangssituation:

  • Irgendein Status ist global gesetzt (schalter und irc/website/...)


  • Schalter: Statuswechselanforderung durch Benutzer
  • uC merkt sich das und macht orange Updatelampe an
  • router pollt uC
  • router bemerkt statuswechsel und aendert den status (ssh etc. (kenne interne vorgaenge mit bot/homepage nicht)
  • wenn status geaendert, fordert router ausschalten der orangen led an.
  • update erfolgreich.
  • wartezeit (aenderung des poll-intervalls) um zu schnelle wechsel (spam) zu vermeiden. (Minutenbereich)


Übersteuerbarkeit des durch den Schalter gesetzten Status notwendig:
Szenario: Der letzte den space verlassende hat es doch mal vergessen, den status zu aendern und es faellt zuhause auf.
gewisser personenkreis muss moeglichkeit haben, den status manuell zu setzen. Router muss dies bis zum naechsten (hardwareschalter)statuswechsel ignorieren.

...to be continued --100nano

Alte Diskussion

hierher verschoben von Open/Close-Monitor

Im einfachsten Fall: ein Atmel (Arduino?) mit Ethernet-Buchse an der Tür, der per Reed-Kontakt oder Taster prüft, ob die Tür verschlossen ist. Falls die Tür auf- oder abgeschlossen wird, wird ein (noch festzulegendes) Signal (HTTP-Request?) an den Webserver geschickt, der entsprechend den Status auf der Homepage aktualisiert. Entsprechend muss Authentifizierung geschehen, damit nicht jeder den Tür-Status auf der Homepage kaputt machen kann...

  • Evtl. Raspberry Pi? Authentifizierung über ssh am Webserver (per pubkey) mit Skript zum Ändern des Türstatus (o.Ä.), dazu genug GPIOs um Reed-Kontakt und später Motor ansteuern zu können. Außerdem als zentrales Loggingsystem auf SD-Karte verwendbar. Einziges Problem ist das das Board noch nicht verfügbar ist :) --Emantor 06:39, 12. Jan. 2012 (UTC)
  • Evtl. AVR-Netio, kostet ungelötet als Bausatz mit NIC 20 Euro. Dazu wäre es praktisch das ethersex darauf läuft. --Terminar 10:11, 19. Jan. 2012 (UTC)

Alternativer Ansatz: Ich habe einen alten Speedport W500V mit OpenWRT wiederbeleben können, da könnte man alle 5 Minuten per Broadcast pingen und schaun, ob Rechner im Space sind. Wenn das der Fall ist, aktualisiert der Speedport den Status über SSH. Die einzige Schwierigkeit im Moment scheint der begrenzte Flash von 4 MB auf dem Router zu sein. --Daniel Bohrer 12:26, 31. Mär. 2012 (CEST)

Prinzipiell möglich, aber aus Gründen erstmal verworfen (was ist, wenn Personen ohne Rechner im Space sind?). Möglicherweise später als Automatismus noch implementierbar. --Daniel Bohrer 04:42, 7. Apr. 2012 (CEST)