Projekt Waschraumüberwachung

Projektstatus: aktiv
Leitung: Simon
Aktive Mitglieder: Alex, George, Aqeel, Simon

Wer kennt es nicht, das Problem mit dem Waschraum?

Welcher Student im Dorf kennt das Problem nicht: man will schnell seine Wäsche waschen und macht sich auf zu dem knallgrünen Waschraum im Gemeinschaftszentrum. Bepackt mit mehreren Ladungen Wäsche und Waschmittel betritt man den Waschsalon und – Ernüchterung pur… Alle Maschinen und Trockner sind besetzt, bei den Trocknern steht nichtmal dabei wie lange sie noch laufen, da das ja davon abhängt wie viel Wäsche darin ist und wie feucht diese noch ist.

Was macht man nun? Wieder alles heim schleppen und später wieder kommen? Warten, bis endlich etwas frei wird? Was macht man, wenn man einen Trockner hat, aber nicht möchte, dass irgendjemand die Wäsche, sobald sie fertig ist, auf den dreckigen Boden wirft, weil man nicht sofort daneben steht?

Einige von uns im OlyNet leben schon viele Jahre hier im Dorf und waren schon einige Male extrem genervt von diesem Dilemma. Daher dachten wir uns, wer, wenn nicht wir, kann eine Lösung dafür anbieten? 🙂

Der Weg zum aktuellen Entwurf

Damit begann die lange Entwicklungszeit zu diesem spannenden Projekt. Nach dem KISS-Prinzip dachten wir natürlich zunächst an die einfachste Lösung, nämlich die Daten von den Benutzern eintragen zu lassen. Dass dies jedoch nicht vollständig funktionieren wird, war uns allen schnell klar.

Somit sind wir dazu übergegangen, die Geräte, also Waschmaschinen und Trockner, direkt auf elektronischer Ebene zu überwachen. Dabei überlegten wir zunächst bestehende Features der Geräte zu nutzen. Die Mielegeräte, die von der Firma Rent-Wash aufgestellt wurden, bieten eine Schnittstelle für ein Modul von Miele selbst, mit dem eine Überwachung durch einen seriellen Anschluss möglich ist. Leider sind diese Erweiterungen ziemlich teuer und sie hätten einen Eingriff in die Systeme einer Fremdfirma bedeutet.

Mit der Firma, die die Maschinen betreibt und die die Kassiergeräte entwickelt und verwaltet, haben wir einen ersten Entwurf angedacht, bei dem das Signal bei Bezahlung abgegriffen wird. Die Schaltung im Kassierschrank ist jedoch sehr komplex und nicht sehr einfach zu überschauen. Es gab auch leider keine Dokumentation mehr von Seiten der Herstellerfirma. Also kam die Idee auf den Strom zu den Geräten direkt zu messen. Der Vorteil darin besteht, dass ein kontinuierlicher Messwert erhoben wird und nicht nur ein einzelnes Schaltsignal abgegriffen wird.

Der ideale Ort, um ein solches System zu installieren, ist der große Verteilerschrank, in dem alle Anschlüsse des Waschraums zusammenlaufen. [BILD EINFÜGEN] Wir begannen nun uns ein System auszudenken, welches klein genug ist, um an diesem zentralen Ort verbaut zu werden und gleichzeitig unsere Anforderungen erfüllte:

  • kontinuierliche Messdaten zum Stromfluss zu jeder einzelnen Maschine
  • simple Erhebung und automatische Abfrage der Daten
  • Schnittstelle als Webservice, um die Daten weiter zu prozessieren

Magnetismus (oder auch: zurück zur Physik der neunten Klasse)

Obwohl wir insgesamt verschiedene Konzepte angedacht hatten, fanden wir eines doch am spannendsten: die „Stromzange“ mit Busanbindung. Außer man ist Elektriker oder hatte so etwas schon einmal in der Hand, werden die Wenigsten dieses Gerät kennen. Hier eine exemplarische Abbildung von der entsprechenden Wikiseite.

Allstrom-Zangenamperemeter

Die Grundidee ist simpel: durch einen stromdurchflossenen Leiter entsteht in einer Spule ein Magnetfeld. Der Ringkern der Spule hat einen Luftschlitz, in den ein Bauteil eingelassen ist, das die Stärke eines Magnetfeldes messen kann (Hall-Sensor). Je stärker der Strom im Leiter, desto größer das Magnetfeld. Damit erlaubt eine Messung des Magnetfeldes auch indirekt Aussagen zu der Stromstärke. Die Tatsache, dass keinerlei bauliche Veränderungen an der Elektrik oder Gebäudesubstanz nötig sind, macht diese Lösung für uns besonders attraktiv.

Die Entwicklung

Auch wenn wir nicht viel Ahnung von E-Technik, Schaltungsentwurf oder Mikrocontrollerprogrammierung hatten, begannen wir uns in die Thematik einzuarbeiten. Die ersten Gehversuche mit dem Schaltungseditor EAGLE CAD verliefen noch arg holprig, aber mit der Zeit gewöhnte man sich an die neuen Namen und Muster. Ebenso suchten wir nach Möglichkeiten das Herzstück unserer Anwendung in silico zu modellieren. Am meisten überzeugt hat dabei die Software LTSpice von Linear Technologies, in der wir die Baugruppe mit einem Operationsverstärker simulieren konnten.

LTSpice Modell

So entstand eine Schaltung, die bei geringen Ausgaben des Hallsensors schon verwertbare Ergebnisse liefert, da das Signal durch einen Operationsverstärker, naja, eben verstärkt wird. Besonders tricky an der Sache ist, dass die Polarität des Magnetfeldes abhängig von der Spannung im Leiter ist. Da hier natürlich Wechselspannung vorliegt, ändert sich auch die Polarität des Magnetfelds. Vom Hallsensor bekommt man stets ein kleines Delta in Abhängigkeit zur Magnetfeldstärke. Die Ruheausgabe unseres Modells liegt bei der halben Versorgungsspannung, in unserem Fall +5V, also +2,5V. Fließt nun ein konstanter Strom durch den Leiter, so wechselt die Polarität des Magnetfeldes ständig hin und her, z.B. zwischen +2,4V und +2,6V. Das Delta ist dabei jeweils gleich, also 0,1V. Dies ist besonders wichtig für die spätere Weiterverarbeitung des Signals!

Die aufgearbeitete Ausgabespannung des Sensors wird mit einem simplen Analog-Digitalwandler in einem Mikroprozessor in eine Zahl gewandelt, mit der wir am Ende arbeiten können. Nur bringt sie uns leider nicht besonders viel in irgendeiner Speicherzelle in einem Computerchip. Hier kommt nun der schon weiter oben erwähnte „Bus“ ins Spiel. Nein, kein Autobus 🙂 , sondern ein Datenbus. Dieser verknüpft einzelne Geräte mit einer Datenleitung und lässt sie Informationen austauschen.

In unserem Entwurf haben wir uns für einen CAN-Bus entschieden, wie er in so gut wie jedem Auto vorkommt (oder auch in Mikroskopen, Robotern, Maschinen, etc…). Zu diesem Bus gibt es wahnsinnig viel Dokumentation auch im Bastlerbereich und sehr viele Bauteile, daher lag die Entscheidung dafür nahe. Nun weiter im Modell: der zuvor digitalisierte Messwert wird also über den CAN-Bus eines Sensors an ein anderes Gerät geschickt. Wir haben dieses „Controller“ getauft. Ein Controller ist für viele Sensoren zuständig und übernimmt eine wichtige Aufgabe. Er verwaltet alle Sensorenknoten in seinem Bus und fragt von jedem einzelnen regelmäßig Messwerte ab, welche er bei sich speichert. Das ist die Busseite. Diese gespeicherten Daten sollen aber natürlich auch von außen zugänglich sein. Dafür versteht der Controller das allseits bekannte Ethernet-Protokoll, genauer IP. Kurz gesagt programmieren wir einen kleinen Webserver auf dieser Platine, der die Daten in einem für uns freundlichen Format anbietet.

All diese Daten, Überlegungen und Informationen mussten dann „nur noch“ in ein Gesamtmodell übertragen werden. Wie bereits gesagt, nutzten wir EAGLE CAD zur Schaltungsentwicklung. Exemplarisch abgebildet ist hier das Boardlayout der Sensorplatine.

EAGLE Board Sensor

 

Dieser Schaltungsentwurf wurde nach intensivem Prototyping und Begutachtung durch diverse Fachleute an eine Firma zur Fertigung gegeben. An dieser Stelle möchten wir uns ganz herzlich bei der IT-Abteilung des Studentenwerk München bedanken, die uns dieses Projekt großzügig finanziert hat. Noch eine etwas bessere Vorstellung bekamen wir durch die Fertigung eines 3D-Modells der Platine, was auch dabei half die Platzierung der einzelnen Bauteile zu verbessern. Damit konnten wir auch für den Controller ein passendes Gehäuse suchen und Bohrschablonen erstellen. Der Controller soll, anders als die Sensorknoten, außerhalb des Schaltschranks liegen und sollte daher etwas abgeschirmt sein.

SketchUp Entwurf eines SensorsSketchup ControllerMit diesen CAD-Bildern (entstanden mit der Software SketchUp) bekamen wir zum ersten Mal das Gefühl, dass das Projekt so richtige Fortschritte machte.

Die Fertigung der Platinen hat sich leider sehr lange verzögert, aber aktuell (Stand Oktober 2014) rechnen wir mit einer baldigen und vollständigen Auslieferung. Nicht ganz ohne Stolz haben wir vor wenigen Tagen die erste Lieferung erhalten und konnten sie inspizieren:

Platinennutzen von OlyNet Sensoren

Zur finalen Montage fehlen natürlich die Ferritkernringe, die wir selbst einsägten und angebracht haben. Mit einer ruhigen Hand und etwas Geduld ging das ganz gut. Flo und Sebastian hochkonzentriert bei der Arbeit:

OlyNet Sensoren Endmontage OlyNet Ferritkern aufkleben

Nun nähern wir uns also langsam dem Ende der elektronischen Seite dieses Projekts und kommen zu der wichtigen Anbindung und damit auch, wie euch, den Bewohnern, diese Geräte nutzen werden.

Softwareintegration

Zeitgleich zu diesem Projekt entwickelt OlyNet e.V. eine Smartphoneapp für das Wohnheim. In diese App wollen wir auch die Daten zu den Waschraumgeräten aufnehmen. Jeder Nutzer soll dort schnell und einfach die Möglichkeit erhalten, sich über die Auslastung der Geräte im Waschraum zu informieren. Ein ganz wichtiges Feature wird dabei die Benachrichtigung sein, sobald eine Maschine fertig ist, vorausgesetzt man hat sich in die Warteliste „eingetragen“. Durch simple Auswahlmenüs und QR-Codes zum einscannen an den Geräten wollen wir die Benutzung so einfach wie möglich gestalten.

Controllerfirmware

Wie aber kommt man nun vom Strom, das durch ein Kabel fließt, zu einer Pushnachricht auf ein Handy? Die Technik im Prinzip ist ja oben beschrieben, aber es fehlt noch eine unerlässliche Komponente: die Firmware der Platinen, also die Software, die die Steuerung und Kommunikation übernimmt. Diese Firmware (bzw. die Firmwares, denn wir brauchen zwei verschiedene für unser Projekt, einmal ein Messknoten und der Controller) wird mit den Entwicklungsumgebungen des Herstellers der Mikrochips entwickelt. Wir haben uns für die PIC-Serie der Firma Microchip entschieden. Ihre IDE, MPLABX, basiert auf NetBeans und ist zwar nicht wirklich stabil oder komfortabel, aber erledigt den Job. Die Firmwares wurden jeweils komplett in C geschrieben, für den Controller haben wir uns das Leben leicht gemacht, indem wir auf einem Demoprojekt von Microchip aufgesetzt haben (dieses findet man im Harmony-Framework).

Die Entwicklungsarbeit für die Sensorknoten konnte quasi komplett auf den ersten beiden Prototypen, die wir bestellt hatten, ablaufen. Für den Controller war das etwas schwieriger. Wir haben uns für den Einstieg dazu entschieden auf einem getesteten und einsatzbereiten Demoboard von Microchip zu beginnen, dem Ethernet Starter Kit. An diesem haben wir uns auch beim Design unseres Controllers orientiert.

Das Demoprojekt ließ sich schnell auf dem Starter Kit zum Laufen bringen. Aber dann begann der harte Teil. Wir mussten eine eigene Administrationsoberfläche entwerfen und die Logik zum Verarbeiten der Eingaben programmieren. Dies bedeutet, dass sämtliche Sensoren auf dem Bus registriert und vom Administrator verwaltet werden müssen. Um die Arbeit zu erleichtern, haben wir ein Protokoll implementiert, bei dem sich jeder Knoten automatisch beim Controller „anmeldet“, sobald er Strom bekommt. Die so aufgenommenen Sensoren werden dann auf der Website gelistet und man kann jedem eine ID zuweisen. Der Einfachkeit halber werden wir später jeweils die ID zuweisen, die die jeweilige Waschmaschine oder der Trockner hat.

Conntroller Website Sensoren

Diese Konfiguration muss zusammen mit anderen Daten dauerhaft gespeichert werden. Leider besitzt der Chip auf dem Controller kein eigenes EEPROM, ebenso haben wir vergessen einen EEPROM-Chip per I²C oder per SPI anzuschließen. Deshalb haben wir mit einigen Compilertricks eine volle Seite im Flashspeicher reserviert, auf welcher die Daten abgelegt werden. Es muss daher eine ganze Seite sein, weil man diese zum Neubeschreiben erst löschen muss. Und damit nicht andere wichtige Programmteile verlorengehen, muss dieser Bereich eben exklusiv für die Konfigurationsdaten reserviert sein.

Nachdem wir den Webteil soweit fertig hatten, haben wir das Projekt auf unsere eigenen Controllerplatinen portiert. Die Spannung stieg, als wir die Firmware dann zum ersten Mal auf die Platine flashten. Die ersten Momente waren noch hoffnungsfroh, weil der Programmiervorgang offenbar erfolgreich war.

Die Ernüchterung setzte aber bald ein, denn wir bekamen keine Netzwerkverbindung zustande. Weiter beobachteten wir, dass der Chip, der für die physikalische Verbindung zuständig ist, sich nicht erwärmte, was darauf schließen ließ, dass er gar nicht lief. Mit Schweißperlen auf der Stirn machten wir uns also panisch auf die Suche nach dem möglichen Fehler, bis wir schließlich noch einmal alle Pläne durchgingen. Und siehe da, auf dem Boardlayout, ein fast schon peinlicher Fehler:

Controller Verbindungsfehler

Über dem Schriftzug „C5“ ist eine dünne gelbe Linie zu sehen, genau das war das Problem. Der Pin am PHY-Chip, der mit der Kupferfläche unter dem Label verbunden ist, muss aber am +3,3V-Netz hängen. Diesen Fehler konnte unser Elektronikspezialist Aqeel aber zum Glück schnell beheben, indem er den Stopplack von dieser kleinen Kupferfläche entfernte und dann mit etwas Lötzinn eine Brücke zwischen dem Kondensator C24 und dem Pin an dem Chip herstellte. Danach ließ sich der Chip erneut problemlos programmieren und der Webserver zeigte alles wie erwartet an! Einziger Wermutstropfen: die beiden Status LEDs des Netzwerksteckergehäuses funktionieren (noch) nicht, weil diese leider an Vcc anstatt GND angeschlossen wurden. Dies lässt sich aber eventuell noch im Nachhinein anpassen.

Es fehlt nun an der Software der Controller noch die CAN-Busseite. Damit der Controller mit seinen Messknoten ordentlich kommunizieren kann, ist es notwendig den CAN-Bus so einzustellen, dass alle Teilnehmer mit der gleichen Geschwindigkeit kommunizieren. Die Thematik ist relativ komplex und Details dazu sprengen hier den Rahmen. Einzig wichtig ist, dass es nach tagelanger, intensiver Arbeit endlich funktioniert. Der Hersteller unserer Mikroprozessoren hat es uns mit seiner Entwicklungsumgebung leider nicht besonders einfach gemacht. Denn obwohl es ein nettes Plugin für die IDE gibt, mit dem sich alle Parameter für den CAN-Bus berechnen lassen, können diese nicht einfach eins zu eins übernommen werden. Diesen fiesen Fallstrick haben wir erst nach mehrmaliger Inspizierung eines Demoprojekts entdeckt, in dem folgende Codezeile zu finden war:

ECAN Harmony demo Nur dieser kleine Kommentar half letztendlich, die Kommunikation zustande zu bringen. Der Wert für den sogenannten „Baudrate Prescaler“ musste also noch um eins erhöht werden, nachdem das Plugin ihn berechnet hatte.

Und siehe da, der angeschlossene Logikanalysator erkannte ohne Probleme unsere Testpakete, die zwischen einem Controller und einem Messknoten ausgetauscht wurden. Zunächst das Testsetup (links oben Saleae Logic Analyzer mit Eigenbauplatine zum CAN-Busanschluss von Aqeel, links unten Controller, einer unserer Prototypen und ein finaler Messknoten mit dem Programmer und Debugger, darüber ein Switch zum Test der Webschnittstelle mit integriertem CAN-Sniffer; geöffnetes Logikprogramm auf dem Laptop):

Logikanalysatorsetup

Vor der Umstellung auf den korrigierten Parameter gab es vom Controller kein ACK auf die vom Messknoten geschickte Nachricht zurück, das CAN-Modul des Prozessors warf stets einen „INVALID MESSAGE“ Fehler. No ACK von Logikanalysator

Nach der Neueinstellung des Wertes jedoch prompt das langersehnte ACK des Controllers und die tadellose Kommunikation:

ACK von Logikanalysator

Von den drei Kernkomponenten des Controllers, Ethernet, CAN-Bus und SD-Karte sind damit also zwei funktionsfähig. Bei der letzten, der microSD-Karte sind leider besonders viele Baustellen offen. Hier wurde beim Design der Schaltung nicht ordentlich genug recherchiert, bzw. mitgedacht.

Der Halter der SD-Karte bietet mehrere Anschlüsse mit verschiedenen Funktionen (siehe dazu auch http://de.wikipedia.org/wiki/SD-Karte#Anschlüsse). Die Kommunikation mit dieser Karte läuft über den SPI-Bus, diese Schnittstelle unterliegt keinerlei Beschränkungen in der Nutzung mit einer SD-Karte. Der Bus benötigt vier Leitungen: einen Takt, eine Chipselect (oder Slave select) Leitung und zwei Datenleitungen, Input und Output. Nun macht es natürlich Sinn, dass der Output der einen Seite in den Input der anderen gehen sollte (und andersherum). Leider liegt in unserem Entwurf genau hier das Problem. Es wurden beide Inputs und Outputs miteinander verbunden, was logischerweise nicht funktionieren kann.

Weiter gibt es an dem Kartenhalter einen Pin zur Abfrage, ob eine Karte eingesetzt wurde. Die Karte schließt einfach einen elektrischen Kontakt und gibt so ein Signal (nämlich logisch 0) and den Prozessor. Dazu muss aber diese Leitung im Normalfall logisch „1“ signalisieren. Dazu benötigt man einen sogenannten Pull-Up-Widerstand. Unser PIC32 hat normalerweise intern solche Widerstände, die man dafür einsetzen kann. Leider jedoch nicht an dem Pin, an dem diese Leitung angeschlossen ist.

Daher muss nun einiges an den Platinen nachgearbeitet werden. Der Widerstand muss eingelötet werden und die beiden SPI-Leitungen müssen gekreuzt werden. Dafür braucht es eine (sehr) ruhige Hand und viel Geduld mit dem Lötkolben. So in etwa sollte es am Ende auf allen Controllern aussehen:

Controller SD card correctionDer blaue Widerstand verbindet die Leitung mit +3.3V an der Stelle der Durchkontaktierung (Via). Die isolierten Kupferdrähte verbinden die Vias der Datenleitungen mit der jeweils freigelegten Kupferbahn der anderen Leitung. Jeweils kurz vor dem Via wurden beide Leitungen durchtrennt. Die so modifizierten Platinen können nun getestet werden, damit die Firmware endlich fertig implementiert werden kann.

Weitere Details folgen.

Sensorfirmware

Die Sensorknotensoftware war schon mit den Prototypen zu großen Teilen abgeschlossen, deswegen aber nicht weniger tricky. Hier haben wir uns lange mit der Planung Zeit gelassen und die einzelnen Aktionen in einem UML-Zustandsdiagramm zusammengefasst. Daraus ließ sich dann ein Zustandsautomat (state machine) ableiten, welchen wir in der Firmware implementierten. Der wichtigste Punkt hirbei ist, dass die einzelnen Knoten in einer Art Tiefschlaf sind und nur sehr wenig Strom verbrauchen. Würden alle Knoten im Bus gleichzeitig stets voll aktiv sein, ginge der Gesamtverbrauch im schlimmsten Fall in mehrere Ampere, was natürlich nicht handhabbar ist. Deshalb misst jeweils nur genau ein Knoten im Bus einen Wert und zwar auch nur dann, wenn er vom Controller dazu aufgefordert wird.

Die Messknoten warten also in ihrem Tieffschlaf auf eine Nachricht, nehmen dann die Messung vor und schicken das Ergebnis an den Controller. Anschließend gehen sie wieder schlafen 🙂

Als weiteres Schmankerl sitzt in jedem Bus ein Sensor, der die Umgebungstemperatur misst. Dies ist relevant, da der verwendete Hallsensor in Abhängigkeit der Temperatur arbeitet. So können wir diesen Faktor korrigieren und erhalten konsistentere Ergebnisse. Der verwendete Sensor ist der weit bekannte DS18B20 von Maxim nutzt einen sogenannten One-Wire-Bus. Die Programmierung dafür war ebenfalls relativ einfach, denn es gibt bereits sehr viel Material im Netz, welches nur noch angepasst werden musste.

Verarbeitung der Messdaten und Webservice für Smartphone-App

Um die Daten dann schlussendlich auf eure Geräte zu bringen, nutzen wir eine JavaEE Anwendung, die in unserem Webcluster läuft. Wir haben hinter einer Firewall Load-Balancer stehen, die durch virtuelle Linuxserver (IPVS) die Daten an Clusterknoten weiterreichen. Dort läuft jeweils neben einem Apache Webserver auch ein Wildfly (vormals JBoss AS) Server. Diese Anwendungsserver sind als Cluster miteinander verbunden und dienen einerseits der Verteilung der finalen Daten, andererseits der Analyse der Messdaten und der folgenden Benachrichtigung (z.B. über Google Cloud Messaging GCM).

An dieser Anwendung arbeiten wir aktuell auch noch, da es viel Zeit und Nerven gekostet hat die Serverumgebung einzurichten.

Interesse geweckt?

An diesem Punkt steht das Projetk aktuell also. Haben wir Deine Neugier geweckt? Hast Du Lust, uns bei der weiteren Umsetzung zu helfen, oder findest Du eventuell ein anderes Projekt auf unserer Liste spannend? Melde Dich!

Egal, welche Fähigkeiten Du mitbringst, ob technischer (E-Technik, Informatik, Maschinenbau), juristischer, betriebswirtschaftlicher oder sonstiger Natur, wir brauchen jede helfende Hand in unserem Verein. Schau doch einfach mal bei unseren Sprechstunden vorbei oder kontaktiere uns auf Facebook, per Email, oder wie auch immer! Neben den begehrten Wohnzeitverlängerungen bieten wir Dir Kontakt zu potenziellen Arbeitgebern, eine lockere und nette Gemeinschaft und die Möglichkeit Dich persönlich weiterzuentwickeln. Wir freuen uns auf Dich!