Liebe Freunde und verehrte Briefträger, gebt es zu: Gibt es etwas schöneres als eine gute Sache noch besser zu machen? Heute werden wir unseren “mitdenkenden” Briefkasten weiter optimieren, damit er irgendwann den Status eines Prototyps verlassen kann. Bereits jetzt ist unsere Postbox in der Lage selbständig festzustellen, ob es Postgut enthält oder nicht. Und über diesen Zustand kann er seine Herren in Echtzeit stets aktuell informieren.

Rückblick

Was ist bisher geschehen? In früheren Beiträgen (Teil 1) haben wir über die generelle Idee, Zielgruppe, den Aufbau sowie den Programm-Code des smarten Briefkastens berichtet. Auch die noch geltenden Einschränkungen des Systems haben wir in Teil 2 nicht verschwiegen. Der erste Aufbau (Version 1.0) benötigte noch eine direkte USB-Verbindung zu einem Rechner, auf dem der Code ausgeführt werden kann. In der neuesten Version 1.5 werden wir u. a. diese Einschränkung auflösen!

Aufbau der Version 1.5

Mit dem Ziel die USB-Verbindung aufzulösen, greifen wir auf den Tickerforge RED-Brick zu. Der RED-Brick ist an sich ein kompakter (4cm x 4cm), aber für seine Verhältnisse mächtiger Mini-Rechner, auf dem ein vollwertiges Linux-System läuft. Unser RED-Brick führt als “Basis”-Station die notwendige Software aus. Somit ist es nicht mehr notwendig separat einen entfernten Rechner zu betreiben. Auf die Basis-Station kommt der Master-Brick. Dieser bindet über seine Schnittstellen die Bricklets (Abstands-Sensor & Segment-Anzeige) an. Der RED-Brick verfügt leider über keine direkten Bricklet-Anbindung.

Schematischer Aufbau der “RED-Edition”

Und wie kommunizieren wir nun mit der Außen-Welt? Nun, es gibt hier wie immer mehrere Möglichkeiten: Über Funk (WLAN) oder Kabel (Ethernet). Wir halten die Kabel-Verbindung für verlässlicher und setzen daher eine Tickerforge Ethernet-Extension ein. Das beste daran: Wenn man die etwas teurere PoE-Variante wählt, muss man sich nicht mehr um die Stromversorgung kümmern. Der gesamte Stack-Aufbau wird über die Extension (durch PoE) mit der notwendigen elektrischen Spannung versorgt. Wer allerdings keinen PoE-fähigen Switch/Router Zuhause hat, benötigt zusätzlich einen PoE-Injektor, der die Spannung in das Netzwerk-Kabel (Cat5/Cat7) injiziert. Alternativ kann man auf PoE verzichten und die Hardware mit einem normalen 5V-USB-Netzteil betreiben.

Kurz vor der Inbetriebnahme des gesamten Systems müssen wir dafür Sorge tragen, dass alle Tinkerforge-Module vor allem mit dem neuen (noch unbekannten) RED-Brick zusammenarbeiten. Hierfür aktualisieren wir die interne Firmware aller Komponenten. Wir gehen wie folgt vor:

Master-Brick flashen (mind. auf Version 2.3.0) nach Anleitung:

• Master-Brick per USB anbinden
• Optional: Treiber installieren (wenn NICHT windows 7/8)
• Erase-Knopf halten + Reset-Knopf drücken: LED leuchtet nicht mehr
• Im Brick-Viewer auf “Updates/Flashing” klicken
• Im Tab “Brick” COM Anschluss auswählen, Firmware “Master (x.x.x)” auswählen und mit “Save” bestätigen

Bricklet-Firmware aktualisieren:

• Alle Bricklets an Master anschließen
• Master-Brick per USB anbinden
• Im Brick-Viewer auf “Updates/Flashing” klicken
• auf “Auto-Update All Bricklets” klicken

RED-Betriebsystem aktualisieren:

• Neuestes Fast Image herunterladen (derzeit Version 1.3) und auspacken
• “Win32 Disk Imager“ herunterladen und starten
• Image (.img) auswählen auf SD-Karte schreiben mit “Write” schreiben

Programmierung

Den eigentlichen Programm-Code haben wir nach bestem Wissen und Gewissen weiter verbessert. Dieser mag immer noch nicht ganz Perfekt sein – aber wer ist schon ein Alles-Könner und auch noch C#-Experte vor dem Herrn…?

Der neue Code ist deutlich schlanker und sorgt dafür, dass (asynchron) Meldungen über den aktuellen Zustand (leer [off], befüllt [on], gesperrt [locked]) über einen Web-Request an unseren FHEM-Home-Server gesendet werden. Der Home-Server verarbeitet diese Status-Berichte und führt ggf. weitere Aktionen aus: Sprach-Ausgabe-Meldung, Email + Pushmessage-Versand aus.

Der zusätzliche Status “gesperrt [locked]” löst eine temporäre (5 Sekunden) Sperre/Deaktivierung des Sensors aus, kurz nachdem der Kasten geleert wurde. So werden mögliche Handbewegungen innerhalb des Sensor-Erfassungsbereichs nicht als Zustandsänderung erfasst. Somit verhindern wir mögliche Fehlalarme beim Leeren des Briefkastens.

Den kompletten Code findet ihr auf Github. Eventuelle Updates werden wir regelmäßig dort einspielen einspielen.
Einige feste Vorgaben bzw. Konstanten (Tinkerforge-UIDs, IP-Adresse/Hostname, Distanz-Ranges, etc.) sollten unbedingt vor dem Betrieb auf eure individuellen Werte im Code angepasst werden und anschließend neu kompiliert werden (Rebuild Solution)!

Das Einzige, was wir nun abschließend machen, ist die kompilierte .exe-Datei auf den RED zu laden. Mit Hilfe des Mono-Frameworks und anderer, “schwarzer Magie” wird der C#.NET dort laufend betrieben. Die Einstellungen sollten etwa wie folgt aussehen:

define Briefkasten dummy
attr Briefkasten devStateIcon on:message_mail off:message_mail_open locked:secur_locked undefined:unknown


Fertig! Der schlaue Briefkasten ist fertig – der Briefzusteller respektive “Fachkraft für Kurier, Express und Postdienstleistungen” ist herzlich willkommen! 🙂

Bedenke Phlebas

Was gibt es zusammenfassend noch festzuhalten oder zu bedenken?

Die jährlichen Stromkosten der Version 1.5 “RED-Edition” belaufen sich auf ca. 7 EUR (basierend auf 0,30 EUR / kWh) – Stromverbrauch (bei konservativer Betrachtung – unter ständiger Vollast):

• Distance-Sensor: 6 mA
• 4×7-Segment-Anzeige: 64 mA
• RED-Brick: 220 mA
• Master-Brick: 68 mA
• Ethernet Extension (mit PoE): 175 mA

Pi mal Daumen nach Adam Riese macht das bei 5V und 24/7-Betrieb rund 24 kWh im Jahr.

Momentan machen wir uns noch über folgende Punkte Gedanken:

• Wie lässt sich das System im Außenbereich (Outdoor) frost- und witterungsbeständig betreiben? Wie kann man die Hardware vor Hitze und Kondenswasser schützen und vor Frost isolieren?
• Wie kann man den Sensor im Inneren besser vor Staub & Schmutz schützen? Wäre ein Licht-(Schranken)-Sensor besser geeignet?
• Welche Probleme könnten im Dauereinsatz noch auftreten?
• Lässt sich das allgemeine Prinzip auch auf eine heimische “Paket-Box” á la Deutsche-Post-Paket-Kasten übertragen?

Was meinst Du dazu?

Vorschau

Wie geht es nun bei uns weiter?
Nachdem das System den Dauertest (mehrere Wochen ohne Unterbrechung) bestanden hat, wollen wir alternative, evtl. etwas kostengünstigere Konstellationen ausprobieren. Denn die “RED-Edition” ist nämlich (im folgenden Vergleich) nicht ganz billig:

Günstiger könnte man mit der “Espruino-Edition” davonkommen:
Espruino ist ein winziges Board, das ca. 30 EUR kostet und mit JavaScript programmiert werden kann. Daneben kann es mit einer Batterie betrieben werden und mit Sensoren und Addons erweitert werden. Es kann also z.B. mit einem Netzwerk-Modul eins heimische (W)LAN eingebunden werden. Ein Ultraschall-Abstands-Sensor existiert auch hier.

Espruino-Board

Diese Einzelteile werden wir in nicht allzu ferner Zukunft in unsere smarte JavaScript-Post-Box einbauen:

Bleibt uns gewogen und abonniert ggf. unseren Feed, um auf dem Laufenden zu bleiben!