Category: IT


Das stand schon länger auf meiner Liste und das wird es wohl auch noch eine längere Zeit tun … Das Nachfolgende ist ein Erfahrungsbericht von einem Projekt, das ich allerdings für die nächste Zeit wieder auf Eis gelegt habe. Nachdem ich schon ein paar 1-Wire Temperatursensoren installiert habe und mit meinem Server und volkszaehler.org überwache, wurde es Zeit das volkszaehler.org-Projekt dafür einzusetzen, wozu es ursprünglich gedacht war, nämlich als „intelligenten Stromzähler“. Da bei mir aber kein Zähler mit S0 Ausgang rumhängt, sondern ein klassischer Ferraris-Zähler, habe ich dafür eine Lösung gesucht und auch gefunden. Meine Lösung besteht aus einem Foto-Reflex-Optokoppler, dem CNY 70 (Details) der die rote Markierung der Scheibe des Ferraris-Zählers erkennen soll. Diese dreht sich meistens 75 oder 96 Mal pro „verbrauchter“ Kilowattstunde.

Wer noch mehr Einleitung in das Thema möchte, den verweise ich auf diesen Blogartikel und natürlich auf volkszaehler.org.

Ich begann indem ich die Schaltung, wie hier beschrieben, aufbaute. Ich verzichtete also komplett auf analoge Aufbereitung des Signals und leitete das Signal direkt an einen AD-Wandler (10 Bit Auflösung) eines Mikrocontrollers weiter. Nach etwas probieren stellte sich heraus, dass sich die besten Messwerte erreichen lassen, wenn man die zwei Linsen des CNY 70 quer zur Ferrarisscheibe montiert (die Scheibe und die gedachte Linie durch die zwei Linsen bilden ein Kreuz). Die Ergebnisse waren überraschend gut. Ich dachte anfangs, das würde schwieriger werden, da ich mehrere Erfahrungsbereiche gelesen habe, aber so wie es aussieht, lässt sich die rote Markierung gut erkenne (siehe Punktdiagramm der Probemessung).

Um die Reflexkoppler vernünftig in den Zählerschrank einbauen zu können, steckte ich ein 6 poliges Flachbandkabel zusammen, über das zwei CNY 70 angesteuert werden können. Das Entwerfen hat mich ein bisschen Zeit gekostet und war auch nicht ganz einfach, daher dokumentiere ich das hier mit. Eine Bedingung war, dass die Anoden der IR-LED einzeln ansteuerbar sind. Außerdem natürlich die Emitter der Fototransitorten. Weiterhin liegen bei dem Kabel jeweils Kathoden und Kollektoren auf einer eigenen Leitung. Das sind meine Notizen dazu:

Leitungsbelegung:
1: A1:	180 Ohm -- +5V 
2: E1:	Pulldown (10k Ohm) -- ADC 
3: K:	GND 
4: C:	+5V 
5: A2:	180 Ohm -- +5V 
6: E2:	Pulldown (10k Ohm) -- ADC 

1. Stecker/Sensor: 
2 4	## Kabel  (Layer 1) 
1 3	## Kabel  (Layer 1) 

----- beschriftete Seite 
E C	## CNY 70 (Layer 2) 
A K	## CNY 70 (Layer 2) 


2. Stecker/Sensor: 
1 3 5	## Kabel  (Layer 1) 
2 4 6	## Kabel  (Layer 1) 

  K A	## CNY 70 (Layer 2) 
  C E	## CNY 70 (Layer 2) 
----- beschriftete Seite

Es gibt mehrere Varianten des CNY 70 (bei denen C und E vertauscht sind!). 

Ein CNY 70 (IR-LED): 14 mA

Und so sieht das dann in Real aus. Die Pfeile zeigen jeweils in die Richtung, auf der die Sensoren beschriftetet sind.
.

Da der Zählerschrank nicht direkt neben einer Ethernetdose ist, überlegte ich mir auch eine Möglichkeit, die Daten ins Netzwerk beziehungsweise in eine Datenbank zu bekommen. Da ich bei dem Projekt Temperaturerfassung bereits Leitungen (eine davon war noch unbenutzt) verlegt hatte, plante ich, diese für die Stromerfassung zu benutzen. Hierfür wollte ich einen kleinen Mikrocontroller einsetzen, der nur die Auswertung der analogen Signale durchführt und einmal pro Umdrehung ein Signal raus gibt. Die Kommunikation sollte auf einem Draht (unidirektionale TTL-Kommunikation) ablaufen. Das heißt, dass der Mikrocontroller nur senden kann, es war kein Rückkanal geplant.

So weit, so gut. An dieser Stelle steht das Projekt jetzt und wird es wohl auch für die nächsten Jahre tun.

Siehe auch:

Advertisements

Kein Plan wie ich mal auf die Idee gekommen bin, aber zurzeit habe ich circa 20 Temperatursensoren im Haus verteilt^^ Ich will hier mal kurz dokumentieren wie man das am Kostengünstigsten und am besten umsetzen kann.

Temperaturmessung

Als Temperatursensor kommt der Dallas DS18B20 zum Einsatz. Der Sensor ist bereits sehr hoch integriert und benötigt keine externe Beschaltung. Alle Sensoren werden einfach mit GND, +5V und einem „Eindraht-Bus“ (beziehungsweise One-Wire-Bus) verbunden. Man kann sogar den VDD Pin (an dem im normalen Modus +5 Volt anliegen) auf GND legen. Indem Fall (parasitäre Spannungsversorgung) läuft die Kommunikation über einen internen Kondensator, der über den „Eindraht-Bus“ geladen wird.

Um die Sensoren im Haus zu verteilen, braucht man ein paar Meter Kabel. Zur maximalen Leitungslänge und empfohlenen Topologie gibt’s hier Informationen. Da meine Installation aber nicht so groß ist, war das nicht so kritisch. Ich habe teilweise auch eine Sterntopologie im Einsatz. An Kabel habe ich alles genommen, was ich gerade da hatte. Aus Gründen der Erweiterbarkeit für spätere Projekte habe ich auch, wo es möglich war, noch eine vierte Leitung mit verlegt.
Um keine Löcher bohren zu müssen, habe ich auch ein bisschen getrickst und alle Sensoren im Keller über ein unbenutztes Koaxialkabel angeschlossen …
Als Stecker für die Sensoren oder Verteiler für Kabel (Sterntopologie) habe ich Präzisions-Buchsenleiste benutzt.
Die ganzen Leitungen kommen bei mir in einem Raum (ich habe die Sensoren auf drei getrennte „Eindraht-Busse“ gelegt). Die „Eindraht-Busse“ sind mit einem AVR Net-IO verbunden. Den Aufbau und meine Veränderungen/Verbesserungen am AVR Net-IO beschreibe ich in einem späteren Blogbeitrag. Auf dem AVR Net-IO läuft Ethersex. Die Ethersex Firmware holt wirklich alles raus, was die leistungsschwachen AVRs so können. Die Firmware, die auf fd0 zurückgeht, implementiert heute sehr viele Protokolle und Funktionen. Beim Konfigurieren der Firmware kann man Auswählen was man an Funktionen so haben möchte. Das bisschen IPv4 und „Eindraht-Bus“ Unterstützung passt locker auf den 32 KB Flash Speicher des Atmega 32 … Es werden zwar ein paar RFCs verletzt (zum Beispiel auf TCP Ebene), aber es funktioniert. In den 32 KB ist übrigens auch ein HTTP Server mit drin. Und nein, das KB ist kein Schreibfehler.

Auswerten

Um die Sensordaten vernünftig auswerten zu können, benötigt man noch eine Möglichkeit die Daten über einen längeren Zeitraum speichern und analysieren zu können. Hierfür kenne ich zwei geeignete Möglichkeiten:

  1. RRDtool
  2. Volkszaehler.org

Das RRDtool ist das klassische Werkzeug für solche Aufgaben, welches ich auch bereits im Zusammenhang mit Munin im Einsatz habe. Allerdings ist RRDtool nicht so schön in der Auswertung. Üblicherweise werden die Messwerte als PNG-Bild vorberechnet beziehungsweise bei Bedarf berechnet und dann dargestellt. Wenn man allerdings nur einzelne Sensorwerte über einen bestimmten Zeitraum vergleichen möchte, ist das ohne Frage möglich, aber dafür müsste man wohl auf die Kommandozeile. Deshalb habe ich mich für Möglichkeit zwei entschieden. Volkszaehler.org bietet auch noch den Vorteil, dass eine Datenbank die Messwerte speichert und keine Round-Robin-Database, bei der alte Messwerte mit der Zeit verworfen werden.

Die Installation und Einrichtung von Volkszaehler.org ist nicht ganz einfach aber durchaus machbar. Kenntnisse von SQL und anderen Sprachen sind hilfreich …
Als Datenbank benutze ich zurzeit MySQL. Ich würde aber heute eigentlich mehr zu PostgreSQL tendieren.

Um nun die Messwerte der Temperatursensoren in die Datenbank zu bekommen, benutze ich ein Perl-Skript vom Volkszaehler.org-Projekt. Dieses Skript wird regelmäßig per cron ausgeführt. Das Skript veranlasst alle am AVR Net-IO angeschlossenen „Eindraht“-Temperatursensoren einzeln ihre Temperatur zu messen. Danach werden die Temperaturen abgefragt. Anschließend wird die Temperatur über die API vom Volkszaehler.org-Projekt in der Datenbank gespeichert.

Das ist alles. Die Auswertung gestaltet sich nun sehr elegant über die Weboberfläche.

Änderungen 2015: Anstelle des AVR Net-IO Board benutze ich aktuell firmata auf einem Arduino als Onewire Busmaster.

Ich bin gerade beim Lesen von LaTeX Hacks (Hack #95 ff.) auf eine sehr mächtige integrierte Entwicklungsumgebung für LaTeX gestoßen. Es handelt sich dabei um den Texteditor Emacs in Kombination mit AUCTeX. Diese Möglichkeit stellt meiner Ansicht nach das obere Ende der Fahnenstange bezüglichen dessen dar, wie man seine LaTeX Dokumente verwirklichen kann. Die Macht von einem Textsatzsystem wie LaTeX zusammen mit einem Betriebssystem, das auch als Editor benutzt werden kann (emacs^^). Würde mich nicht wundern, wenn sich in den Dokumentationen auch ein Befehl „Weltherrschaft“ finden ließe …
Für jemand der weiß, dass er über die Nächsten zehn Jahre öfter komplexe Dokumente erstellen wird, für den dürfte sich die Einarbeitung in die unzähligen Tastenkürzel (von emacs selbst und auch von AUCTeX) vermutlich lohnen.
Da ich aber mit Vim mit oder ohne kile sehr zufrieden bin, werde ich mir das Umsteigen aufgrund der „steilen“ Lernkurve sparen. Jetzt wo ich schon Vim einigermaßen beherrsche …
Nachdem ich gesehen habe, was ein geübter Anwender mit emacs und AUCTeX alles vollbringen kann, habe ich mir auch mal kurz angesehen zu was Vim wenn vernünftig konfiguriert so alles imstande ist und siehe da, ein Umstieg ist absolut überflüssig. Für Vim gibt es eine Reihe von ebenbürtigen Erweiterungen. Ich vertrete also nach wie vor die Vim Front …

Ich versuche, wann immer möglich, meinen Quellcode von den hier veröffentlichten Dokumenten bereitzustellen. Dazu habe ich mir überlegt, dass ich einfach die Quelldateien mit in das erzeugte PDF einbauen könnte. Hierfür nutze ich das Paket attachfile. Auf diese Weise sind keine größeren Änderungen in meinen Arbeitsabläufen nötig. Ich muss nur einmal definieren, welche Quelldateien ich anhängen möchte. Die Dateien lassen sich dann beispielsweise mit pdftk $file.pdf unpack_files oder mit Programmen wie Adobe Reader extrahieren.

Ob Quelldateien eingebunden sind, steht in einer Tabelle (Informationen zu den Quelldateien) im Anhang.

Älterer Quellcode ist natürlich nicht meinem aktuellen Programmierstil angepasst. Das würde ich heute alles etwas anders machen (was ich wahrscheinlich in einem Jahr auch über meinen jetzigen Quellcode sagen würde).

Den Quellcode, den ich in allen Dokumenten verwende, also meine Pakete, werde ich später noch veröffentlichen.
Damit sollte klar sein, dass sich aus dem bislang eingebeteten Quellcode nicht einfach ein PDF erzeugen lässt, das genau gleich aussieht, wie meines. Ich integriere zurzeit nur den Quellcode zu den Inhalten. Dinge wie die Präambel sind in der Regel nicht eingebunden.

Ein Grund für mich meinen LaTeX-Quellcode freizugeben, ist die einfache Weiterverwendung und Abwandlung der mit TikZ erstellten Grafiken (bitte nach Möglichkeiten meine verwendete Lizenz beachten). Außerdem möchte ich das Nachschauen von Implementierungen vereinfachen. (Aus leidvoller Erfahrung: Man findet in irgendwelchen LaTeX-Dokumenten schöne Lösungen für Probleme, kann aber nicht nachschauen, wie diese umgesetzt wurden.)

Nachdem ich jetzt einigermaßen Perl programmieren kann, habe ich mal eine Idee umgesetzt, die mir vor ein paar Jahren gekommen war. Als interessierter CRE Hörer dachte ich mir, man könnte ja mal einen Graphen erstellen, auf dem man sehen kann, auf welche Folgen sich eine CRE-Ausgabe bezieht. Das habe ich jetzt mal umgesetzt. Hier ein kleiner Ausschnitt.

Aus dem Graphen kann man erkenne, dass sich CRE106 Mikrokopter auf CRE074 Hubschrauber bezieht. Gleichzeitig beziehen sich drei Episoden auf CRE106. Und so weiter …

Der komplette Graph ist hier zu finden. Ich habe allerdings alle Folgen rausgelassen, die keine Verbindung zu anderen haben. Der Graph ist aber trotzdem sehr groß. Vielen Dank Tim für die zahllosen Stunden.

Der Quellcode und die Dokumentation ist bei GitHub zu finden.