Projekt:AMTUef: Unterschied zwischen den Versionen
Dg3hda (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{Infobox Projekt |name = AmTUef |status = idea |beschreibung = Anwesenheitsmeldetaster, überforderungsfrei |autor = Benutz…“) |
(kein Unterschied)
|
Version vom 20. Februar 2020, 10:17 Uhr
AmTUef
Status: idea | |
---|---|
Beschreibung | Anwesenheitsmeldetaster, überforderungsfrei |
Ansprechpartner | Hendi |
Version | 1.0 |
IN ARBEIT
Überforderungsfreie Space-Open-Aktualisierung
Ziel
Gelegentlich ist der Space geöffnet, oder aber nicht, oder aber er ist nicht geöffnet, ist es aber, oder ja, oder nein.
Manchmal stimmt die Spacestatus-Meldung nicht mit der Realität überein ohne das ein technischer Fehler vorliegt. Unter anderem deshalb wurde schon im alten Space, da noch mit Bezug zum alten Schloß, ein nächtlicher Reset durchgeführt der den Spacestatus auf geschlossen stellt, falls dies nach dem verlassen einfach vergessen wurde.
Einen Teil des Problems dürfte die etwas umständliche Prozedur zur Änderung des Spacestatus sein:
- (Verbindung zum WLAN herstellen falls erforderlich)
- Telegram aufrufen
- Änderungskommando auf Schaffen-CIX oder als Bot-PN absenden
Durch eine Vereinfachung könnten menschlich bedingte Statusfehler möglicherweise minimiert werden, das soll ausprobiert - und bei Erfolg produktiv werden.
Weg
Im Space wird in der Nähe der Tür ein Tastenfeld mit zwei Tasten angebracht, mit einer grünen Space-Open-Taste und einer roten Space-Close-Taste. So muss man nur, quasi im vorbeigehen, drücken und der Status wird wenn alles funktioniert korrekt abgebildet. Die Information wer es tut ist dadurch nicht direkt verloren, sie war ja quasi auch vorher nicht da. :) Die Tasten werden von einem Mikrocontroller abgefragt und die Information wird zum Space-Status-Server weitergeleitet.
Hardwarekomponente
Tasterfeld
Ein Tasterfeld mit 2 Betätigern in rot und grün war im Spacefundus bereits vorhanden und soll idealerweise zum Einsatz kommen, was Kosten und Abfallmenge reduziert. Die Schalter hatten im ausgeschalteten Zustand hohe Leckströme/und hohe Übergangswiderstände, darum gab es etwas Ballistol Sprühöl das die Probleme beseitigte und dessen Effekt nach einigen Wochen Kontrolle noch nachhielt: Vermutlich gut genug. Leider handelt es sich um einen öffner und einen Schließer, was nicht ideal ist. Mit einem
Elektronik
Als Microcontroller kommt ein ESP8622 zum Einsatz, weil vorhanden und durch das integrierte WLAN der Weg der Daten zum Status-Service nicht so lange wird. Ziel ist, die Ruhestromaufnahme durch Nutzung von (deep) sleep gering zu halten, so das das Gerät längere Zeit batterieversorgt funktionieren kann. Das erfordert ggf. eine Modifikation des Development-Board zulasten der der nur für USB-Betrieb notwendigen Linear-Spannungsregler und USB-UART-Bridge, oder ein Modul das die erst gar nicht hat. Zur Versorgung kommt eine Lithium-Batterie (LiSOCl2-Typen sind toll, aber am oberen Rand der zulässigen Betriebsspannung) oder zwei Alkaline-Zellen oder irgendwas vergleichbares zum Einsatz, was ins Betriebsspannungsfenster 2.5-3.6V passt. Die Elektronik erhält außerdem Pull-Up Widerstände und Dioden die notwendig sind, um bei Tastendruck den ESP durch einen Reset zu wecken und den Nutzerwunsch an GPIO "sichtbar" zu machen, und ggf. Entstörbauteile. Eventuell wird noch eine Überwachungsmöglichkeit für die Batteriespannung integriert.
Firmware
Die Firmware muss nach einem Start des Controllers folgende Schritte ausführen:
- GPIO abfragen, ob Status Open oder Closed sein soll, Status speichern damit Anwender loslassen kann
- (Tastenbetätigung quittieren?)
- WLAN initialisieren
- Status an Server melden mit z.B. HTTP GET Request
- (Bestätigung von Server anfordern und ggf. quittieren?)
- (Meldung der Batteriespannung an Daten-Server?)
- Shutdown bis zum nächsten Reset
Spacestatus-API
Die existierende Space API muss so geändert werden das die Requests des Tastenfelds akzeptiert werden und ggf. die Batteriespannung speichert.