Nur mal kurz angemerkt: Gestern vor zehn Jahren habe ich hier zum ersten Mal ein Elektronik-Projekt veröffentlicht. Den USB-LED-Fader (der hier übrigens bis vor etwa vier Jahren tatsächlich im Einsatz war).

Ich habe seitdem einiges gebastelt, und auch einiges veröffentlicht. Das einzig doofe ist, dass ich zu wenig Zeit habe meine Projekte auch dann noch zu pflegen wenn ich mich schon längst anderen Sachen zugewendet habe. Soweit möglich mache ich das zwar, aber ich möchte die Gelegenheit nutzen mich bei allen Leuten zu entschuldigen die sich die Mühe gemacht haben sich mit meinem Bastelkram auseinanderzusetzen, und deren Fragen ich nicht beantworten konnte. Sorry! :oops:

Prefer english? This way!

Grilltemperatur in Zabbix

Grilltemperatur in Zabbix

Leider ist dieses Projekt noch nicht ganz fertig, aber ich berichte trotzdem vom ersten Probelauf. Die Elektronik wollte noch nicht ganz so wie ich wollte, aber man sieht wohin die Reise geht.

Vor knapp zwei Jahren habe ich mal einen Prototypen eines Grillthermometers gebastelt. Den habe ich auch hier vorgestellt, das war wirklich ein ganz krudes Projekt. Seitdem habe ich viel dazu gelernt, und ich will sowas jetzt nochmal in ‚ernsthaft‘ bauen.

Da ich mit dem Ding die Temperatur mehrerer Fleischstücke messen kann war der Name natürlich klar: Multimeater! :-D

Die Hardware

Die Hardware

Basis wird wie bei den letzten Projekten ein ESP8266-Modul, programmiert mit der Arduino-Software. WLAN ist somit vorhanden. Darauf kommt eine Firmware die — ebenfalls wie in mehreren meiner Projekte — auf dem Homie-Framework basiert. Das liefert die Messwerte per MQTT an meinen Broker, von da geht es weiter zu Zabbix. Gemessen wird mit zwei Hochtemperatur-Sensoren die jeweils an einem MAX6675 hängen, sowie vier normalen Einstichthermometern an einem MCP3208.

Sechs Temperaturen? Ja. Der Plan ist, mit zwei Sensoren die Innenraumtemperatur des Grills aufzunehmen. Unter bestimmten Umständen kann die so hoch sein dass die normalen Fleischthermometer das nicht mitmachen würden, also gibt es dafür zwei extra Fühler, jeweils am Ende des Grillraumes (der ist beim Smoker eher länglich, da gibt es tatsächlich ein Temperaturgefälle). Und mit vier Fleischthermometern kann ich die Kerntemperatur von eben bis zu vier Stücken überwachen.

Zabbix ist eigentlich ein Monitoring-System, damit überwacht man eigentlich Serversysteme. Das funktioniert aber nicht nur in großen Rechenzentren, ich erfasse damit zu Hause auch einige… eher ungewöhnliche Daten. ;-)

In diesem Fall habe ich mir damit nur die Temperaturverlaufskurven angesehen, aber wenn ich wirklich mal über Nacht ein Pulled Pork grillen möchte kann Zabbix mich auch aus dem Bett klingeln wenn die Temperaturen nicht so aussehen wie sie sein sollten.

Wie gesagt: das Heute war nur ein Probelauf. Und wie das so ist sind dabei einige Sachen schief gegangen. Ich habe ein Problem mit den Messwerten von den Innenraum-Fühlern gehabt, die waren leider unbrauchbar. Da ich aber eh nur drei Stücke Fleisch hatte konnte ich den vierten Fühler für die Pit-Temperatur benutzen. Der Fühler im Schinkenbraten war erst doof gesteckt, daher sieht die blaue Kurve sehr merkwürdig aus. Und als Krönung hat es zwischenzeitlich heftig geregnet, da der Grill zur Zeit nicht überdacht ist hat es das auch nicht einfacher gemacht.

Alles in allem war das aber schon sehr vielversprechend. Ich bleibe dran, und sobald das Ding wirklich funktioniert stelle ich es natürlich hier vor, mit Schaltplan und Firmware.

Oh, und da die Fragen kommen werden: die technischen Probleme haben dem Grill-Ergebnis keinen Abbruch getan, es hat hervorragend geschmeckt. :-D

Mit Begeisterung habe ich gerade gelesen dass der Hersteller Espressif einen Nachfolger für den ESP8266 — mit dem ich ja auch schon einiges gemacht habe — vorgestellt hat: den ESP32.

Im Gegensatz Zusätzlich zum 8266 hat das Ding

  • Bluetooth
  • Ethernet-Fähigkeiten
  • GPIOs für Touch-Sensoren
  • einen Hall-Sensor
  • … und vieles mehr

Neue Ideen was man damit umsetzen kann kommen noch während des Lesens. Allein die Möglichkeit damit stromsparende Anwendungen bauen zu können (Stichwort: Batteriebetrieb) eröffnet einen ganzen Strauss neuer Möglichkeiten.

Ich kann es kaum abwarten dass das Ding verfügbar ist. Man kann nur hoffen dass der Preis ähnlich attraktiv wird wie beim Vorgänger…

Die Augen des Stromzählers

Die Augen des Stromzählers

Gestern habe ich mich mal intensiv mit meinem Stromzähler auseinander gesetzt. Das ist ein ziemlich neumodisches Gerät, ein Iskra MT175. Dieses Modell verfügt über eine Infrarotschnittstelle (nach DIN EN 62056-21) mit der die Zählerstände ausgelesen werden, und das muss natürlich ausprobiert werden.

Zu dem Zweck habe ich mir eine Hardware gebastelt die die Daten auslesen kann. Dazu später mehr, in einem anderen Beitrag. Mein Zähler überträgt etwa alle zwei Sekunden einen Datensatz. Automatisch, ohne dass ich ihn darum bitten müsste. Wenn ich den auslese erhalte ich einen formschönen Haufen Hex-Code, ähnlich diesem:

Wie man unschwer erkennt habe ich private Daten anonymisiert. Lacht nicht! :-D

Nachdem ich da längere Zeit mit verbracht habe weiß ich mittlerweile ziemlich genau was da steht. Und damit andere einen besseren Einstieg finden schreibe ich das mal hier auf.

Die Sprache nennt sich Smart Message Language (SML). Es gibt auch Zähler die die Daten in anderen Formaten, oder direkt im ASCII-Format ausgeben. SML ist aber ein Standard, und wird von vielen Herstellern genutzt. Wie das funktioniert kann man zum Beispiel in der Technischen Richtlinie BSI TR-03109-1 beim Bundesamt für Sicherheit in der Informationstechnik nachlesen. Wenn man das tut kann man den Datensatz da oben tatsächlich lesbar machen:

Die ersten vier Bytes sind einfach eine Markierung für den Anfang der Übertragung, in der zweiten Zeile steht dass wir Version 1 des Protokolls lesen.

Als nächstes müssen wir ein wichtiges Konzept verstehen. Das erste Byte der folgenden Nachricht lautet ’76‘. Man muss das als Nibbles sehen, und bei Hex-Zahlen bedeutet das Ziffer für Ziffer. Das erste Nibble ‚7‘ können wir auf Seite 42 (natürlich ;-) ) des oben verlinkten Dokumentes nachschlagen. Da steht eine Tabelle mit einer Zeile ‚X111LLLL‘. Jetzt matcht das binäre ‚X111‘ auf das erste Nibble, also haben wir es hier mit einer Liste zu tun. Das zweite Nibble gibt die Länge an, wir erwarten also eine Liste mit 6 Elementen.

Das erste Byte der folgenden Zeilen ist jeweils nach dem gleichen Schema aufgebaut. In der Regel steht das erste Nibble für den Datentypen, das zweite für die Länge — merkwürdigerweise bei einfachen Datentypen die Länge inclusive dieses Längen-Bytes. Datentyp 0 in Zeile 4 ist laut Seite 42 ein Octet String. Die 5 sagt dass dieser Teil einschliesslich der Längenangabe 5 Bytes umfasst, wir erwarten nach der Länge also noch vier Bytes. Auf Seite 17 des Dokumentes steht dass hier eine Transaktions-ID kommen muss.

Nachdem das Prinzip klar sein sollte werde ich nicht mehr alles haarklein entschlüsseln. Das heisst: ich habe schon. Aber an dieser Stelle überlasse ich das mal dem geneigten Leser. :-)

Man sieht durch die Einrückung ziemlich deutlich dass man sich den Datensatz gut als Liste von Listen vorstellen kann. Außen wird eine Liste mit sechs Elementen angekündigt (76), darin stehen ein Octet String (beginnt mit 0, Zeile 4), zwei Unsigned Integer (6, Zeilen 5 und 6), eine weitere Liste mit zwei Elementen (72, Zeile 7), ein weiterer Unsigned Integer (6, Zeile 16) mit der Prüfsumme und eine Markierung für das Ende der Nachricht (00, Zeile 17). Die Liste mit den zwei Elementen enthält wiederum einen Unsigned Integer (6, Zeile 8 ) und eine Liste mit sechs Elementen (76, Zeile 9). Die meisten dieser sechs Elemente sind Octet Strings die samt des Längen-Bytes eine Länge von 1 haben (01), also leere Strings. Ein String (Zeile 12) enthält eine File-ID, einer (Zeile 13) die Server-ID. Letztere kann man auch direkt auf dem Gerät lesen, die ist aufgedruckt. Beruhigend. :-)

Jetzt wird es ernst: eine weitere Liste mit sechs Elementen (76), die ersten Zeilen entsprechen dem Block oben:

Enthalten ist eine Liste mit zwei Elementen (72, Zeile 22). Der erste Octet String (Zeile 23) gibt den Typ der Nachricht an, es ist ein getListResponse. Der wiederum besteht auf sieben Elementen (77, Zeile 24). Interessant ist hier vielleicht das vierte Element (72, Zeile 28. An dieser Stelle soll die aktuelle Zeit stehen, und die kann auf verschiedene Weise angegeben werden. Erklärt ist das auf Seite 22 des BSI-Dokumentes, dementsprechend haben wir es hier durch die 01 in Zeile 29 mit einem secIndex zu tun. In Zeile 30 folgt dann der Wert. Die Zahl 0x018A4D15 entspricht in etwa der Zeit die das Gerät hier eingebaut ist, das wird also eine Art Betriebsstundenzähler sein.

Die Liste die in Zeile 31 startet ist das fünfte Element der Liste aus Zeile 24. Und hier kommt der wirklich spannende Teil: die Messdaten. Naja, und ein paar Meta-Daten. Erst das Kürzel des Herstellers Iskra (ASCII-Codes in Zeile 38), dann nochmal die bereits bekannte Server ID. Die nächsten drei Elemente enthalten die verbrauchte Energie (die Kilowattstunden), sowohl als Summe als auch aufgesplittet in zwei Tarife — wenn man denn zwei Tarife hat.

Hier kommen wir übrigens zu einem Teil den ich noch nicht verstanden habe: in Zeile 50 wird ein Status angegeben. Wenn mir jemand sagen kann was der bedeutet: immer her damit! 0x0182 ist dezimal 386, darauf kann ich mir keinen Reim machen.

Die Energiewerte muss man übrigens durch 10.000 teilen um auf die kWh zu kommen die am Gerät angezeigt werden.

In Zeile 78 steht die aktuelle Leistung, also wie viel Watt tatsächlich in diesem Moment verbraucht werden. In Zeile 86 folgt ein ‚public key‘. Der steht auch auf dem Gerät, ich nehme an der ist relevant wenn der Zähler wirklich ’nach Hause telefoniert‘. Die SML-Kommunikation funktioniert nämlich nicht nur über die Infrarot-Schnittstelle, sondern bei Bedarf auch über die Stromleitung. So kann der Anbieter Verbrauchswerte ablesen ohne dass dafür jemand zu Besuch kommen muss.

Die beiden Werte in Zeile 88 und 89 sind optional und vervollständigen so die Liste die in Zeile 24 begonnen wurde.

Oh, noch ein interessanter Punkt zu Zeile 86: das Nibble ‚8‘ ist eigenlich eine 0, also wieder ein Octet String. Da aber das Most Significant Bit gesetzt ist wird daraus eine 8, und das bedeutet dass die Länge der folgenden Daten nicht nur durch das zweite Nibble — die 3 — angegeben wird, sondern zusätzlich durch das folgende Byte. Nützlich, denn mit nur einem Nibble könnte man maximal 15 Bytes ankündigen (nachdem eines für die Länge draufgegangen ist). So kommen wir auf 0x32 == 50 Bytes. Ausreichend also für 48 Bytes Public Key und zwei Bytes Längenangabe.

Es folgen noch eine Prüfsumme und das förmliche Ende der zweiten Nachricht:

Die dritte Nachricht ist einfach nur da um das Ende der Übertragung anzukündigen.

Zu guter Letzt folgt in Zeile 102 nochmal die vom Anfang bekannte Escape-Sequenz, dann 1A um wirklich die Nachricht abzuschließen und nochmal drei Bytes für eine Prüfsumme.

Jetzt noch was in eigener Sache: viele Blogs schließen ihre Artikel grundsätzlich mit einer Frage an die Leser, um Kommentare zu fischen. Ich finde das penetrant, und mache das in der Regel nicht. Aber nach diesem furztrockenen (!) Artikel erlaube ich mir das ausnahmsweise mal: bitte ein Handzeichen von allen die bis hier durchgehalten haben! Muss kein Lob sein, ein Hallo Welt genügt. :-D

Die Schaltung, so wie sie zwei Jahre lief

Die Schaltung, so wie sie zwei Jahre lief

Eigentlich würde es deutlich mehr Sinn machen, Projekte zu veröffentlichen direkt nachdem sie fertiggestellt wurden. In diesem Fall war ich mir sicher das getan zu haben. Vor zwei Jahren, als ich es gebaut habe. Dass das nicht so ist fiel mir erst kürzlich auf. Komischerweise drei Tage bevor ich das Ding durch etwas anderes ersetzt habe. Egal, ich liefere schnell nochmal nach…

Anfang 2014 haben wir das Wohnzimmer umgebaut. Dabei hat eine Wand eine steinige Struktur bekommen, und ich dachte dass da ein Streiflicht gut aussehen würde. LED-Streifen boten sich an. Beim Rumalbern habe ich den Töchtern gesagt dass wir eine rosa Lampe einbauen würden. Der Plan war eigentlich warm-weiß, aber die bestanden jetzt auf rosa… zwei gegen einen… ich stand unter Zugzwang. :-)

Ein einfacher RGB-Streifen kann theoretisch auch weiß leuchten. Praktisch ist das alles andere als gemütlich. Also habe ich neben den RGB- auch noch einen warm-weißen Streifen geklebt. In Kombination ließ sich das aber dann nicht mehr mit dem Steuergerät bedienen das bei dem RGB-Streifen dabei war. Eine fertige RGBW-Steuerung habe ich damals nicht gefunden. Also musste ich selbst was bauen.

So funktioniert das

So funktioniert das

Ich glaube das war das erste Mal dass ich ernsthaft was mit einem Arduino gemacht habe. Und es war erstaunlich einfach. Den ersten Prototypen habe ich mit einem Arduino Uno gebaut, und mit der hervorragenden Infrarot-Empfänger-Bibliothek von Ken Shirriff konnte ich schon nach knapp zwei Stunden eine RGB- und eine weiße LED steuern. Mit der Logitech Harmony Fernbedienung mit der ich auch die Medienwiedergabe kontrolliere.

Den zweiten Prototypen habe ich mit MOSFETs gebaut, um zu auszuprobieren wie ich mit dem Arduino die Streifen ansteuern kann, die ja immerhin mit 12V versorgt werden.

Der finale Aufbau ist oben auf dem Foto zu sehen: ein Arduino Pro Mini (der ohne USB-Interface), und eine Lochrasterplatine auf der die Ansteuerung verdrahtet ist. Am Arduino hängt ein Infrarot-Empfänger. Ursprünglich ein TSOP31238, den habe ich aber kurz vor Projektende durch falsche Verdrahtung frittiert. Da ich fertig werden wollte habe ich einen alten DVD-Player zerlegt — keine Ahnung was das für ein Empfänger ist, aber er funktioniert. :-D

Das heißt: er hat funktioniert. Ziemlich genau zwei Jahre lang. Bis Heute Morgen. Seitdem ist die Schaltung obsolet — wie gesagt. Sourcen und was man so für das Projekt braucht habe ich Heute unter dem Namen IRlicht veröffentlicht.

Oh, und falls sich jemand fragt: die Lampe ist bis Heute praktisch ausschließlich in weiß zum Einsatz gekommen. Bunte Farben — insbesondere Farbwechsel — sind praktisch nur zum Ausprobieren und zum Vorzeigen zu sehen gewesen. So selten dass ich letztens schon in den Sourcen nachsehen musste welche Tasten zu drücken sind…

H801 WiFi im Gehäuse

H801 WiFi im Gehäuse

Ich weiß nicht mehr wie ich darauf gekommen bin, aber vor einiger Zeit habe ich mir vom Chinesen meines Vertrauens ein Modul zur LED-Steuerung schicken lassen. H801Wifi wird es genannt, man bekommt es für etwa neun Euro. Dazu gibt es eine App um per Telefon die Lampe zu steuern, aber die habe ich gar nicht erst ausprobiert.

Im Prinzip tut das Ding das gleiche wie mein Projekt IRlicht — von dem ich sicher war dass ich es veröffentlicht hätte (wird nachgeholt): es steuert über mehrere Kanäle die Helligkeiten von LED-Streifen. Meine selbstgebaute Steuerung macht das mit vier Kanälen: RGBW. Also drei bunte Farben und zusätzlich ein Kanal für weiß. Dieses Ding macht RGBWW, so könnte man tatsächlich nicht nur einen Weiß-Streifen anschließen, sondern beispielsweise einen warm- und einen kalt-weißen.

Mein Eigenbau wird per Infrarot-Fernbedienung gesteuert. In diesem Modul steckt ein ESP8266, also arbeitet es mit WLAN. Ich bastele schon länger an einer Firmware für kleine WLAN-Geräte, die kommuniziert auf der Basis von MQTT (hatte ich hier schon erwähnt). Dieses Modul wäre ein Paradebeispiel dafür. Fraglich war nur ob man die Firmware darauf zum Laufen kriegt…

Stellt sich raus: ja. Kriegt man. :-)

Programmier-Jumper gesetzt, serielle Schnittstelle angeschlossen

Programmier-Jumper gesetzt, serielle Schnittstelle angeschlossen

Ich bin nicht der erste der das versucht. Andreas Hölldorfer hat das auch schon gemacht und beschrieben. Dass es so einfach wäre hätte ich nicht vermutet. Fast schon enttäuschend… ;-)

Auf der Platine — dank hervorragender Fotos des Anbieters wusste ich das schon vor dem Kauf — befindet sich eine gut beschriftete serielle Schnittstelle. Und direkt daneben ist ein Anschluss der praktisch nach einem Jumper schreit. Setzt man den Jumper, kann man über die serielle Schnittstelle flashen. Direkt aus der Arduino-Umgebung heraus. Dazu habe ich einfach meinen USB-Seriell-Adapter zwischen Computer und Modul gehängt (ohne externe Stromversorgung, keine Ahnung ob das geschadet hätte) und in der IDE folgendes eingestellt:

  • Board: „Generic ESP8266 Module“
  • Flash Size: „1M (64k SPIFFS)
  • Upload Speed: „1152200“

Nachdem ich RX und TX richtig herum angeschlossen hatte konnte ich direkt flashen.

Ich hatte wie gesagt schon eine Firmware für meine Zwecke fertig, basierend auf dem exzellenten Homie for ESP8266 Framework. Naja, fast: bis jetzt kann die nur RGB, noch kein RGBWW. Aber das einzige was ich für RGB ändern musste waren die Pins. Das Header-File für „Generic ESP8266 Module“ kennt keine sprechenden Bezeichnungen für die Pins. Die Belegung hat Andreas Hölldorfer schon herausgefunden (er scheint aber eine andere Hardware zu haben, bei mir waren einiges Pins vertauscht). Folgendes funktioniert bei mir:

Pin Funktion
15 Ausgang rot
13 Ausgang grün
12 Ausgang blau
14 Ausgang weiß 1
4 Ausgang weiß 2
1 Interne LED grün / Signal
5 Interne LED rot / Power

Schön ist, dass nach dem initialen Flashen auch schon das OTA-Update (Over The Air) funktioniert. So konnte ich das Gehäuse direkt wieder veschliessen, alle weiteren Updates kommen durch die Luft. :-D

Die meisten Pins sind belegt

Die meisten Pins sind belegt

Den ESP8266 habe ich hier ja schon öfter erwähnt. Kurz zusammengefasst handelt es sich um einen Mikrocontroller den man frei programmieren kann. Im Vergleich zu Arduino & Co. ist er aber sehr leistungsfähig. Er rechnet deutlich schneller, hat mehr Speicher und das beste: er funkt im WLAN. Genauere Daten finden man überall im Netz, nicht zuletzt in der Wikipedia.

Ich habe hier schon verschiedene Boards ausprobiert um mit dem Ding zu spielen. Vorstellen möchte ich Heute eines das unter dem Namen Witty Cloud bekannt ist. Lustigerweise findet man es in den automatisch übersetzten chinesischen Shops auch gerne unter dem Namen Witzig Wolke:-D

Es handelt sich um einen ESP-12-F, mit auf der Platine ist ein USB-Anschluss mit dem man das Ding mit Strom versorgen kann, ein Tastschalter, ein LDR (lichtempfindlicher Widerstand) und eine RGB-LED. So hat man direkt etwas Hardware zum Spielen. Geliefert wird das Modul als Stapel aus zwei Platinen. Die untere enthält eine weitere USB-Buchse, mit der kann man nicht nur Strom liefern sondern dank des USB-Seriell-Konverters auch direkt programmieren. Weiterhin sind hier ein Reset- und ein Flash-Button untergebracht. Zum wirklichen Betrieb braucht man nur das obere Board, und nach einer initialen Programmierung kann man die Module bei Bedarf sogar OTA (Over The Air) mit neuer Software betanken.

Das untere Board wird nur zum Programmieren benutzt

Das untere Board wird nur zum Programmieren benutzt

So gestapelt kostet das Modul weniger als drei Euro, und um mit dem Programmieren anfangen zu können braucht man nur noch ein USB-Kabel und einen Compiler. Da empfehle ich die Arduino-IDE, damit ist man auch als Anfänger sehr schnell im Rennen. Wenn man die Erweiterungen für ESP8266 installiert hat wählt man im Board Manager am besten den WeMos D1-Mini aus, damit klappt alles auf Anhieb.

Leider findet man zu dem Witty kaum Dokumentation. Also habe ich das Bildchen da oben gemalt, schon allein damit ich selbst nachsehen kann was an welchem Pin angeschlossen ist. So hängt an dem Pin der mit GPIO13 beschriftet ist der blaue Kanal der RGB-LED, in der Programmierumgebung heißt der Pin D7.

Label Pin (Arduino) Funktion
REST Reset
ADC A0 Analoger Eingang, belegt mit LDR
CH_PD Chip Power-Down
GPIO16 D0 GPIO, frei benutzbar
GPIO14 D5 GPIO, frei benutzbar
GPIO12 D6 GPIO, grüner Kanal der RGB-LED
GPIO13 D7 GPIO, blauer Kanal der RGB-LED
VCC +5V Versorgungsspannung
TXD TX Serielle Schnittstelle
RXD RX Serielle Schnittstelle
GPIO5 D1 GPIO, frei benutzbar
GPIO4 D2 GPIO, belegt mit dem Tastschalter
GPIO0 D3 GPIO, verbunden mit dem Flash-Taster, nicht völlig frei benutzbar
GPIO2 D4 GPIO, belegt mit der blauen LED auf dem ESP-Modul
GPIO15 D8 GPIO, roter Kanal der RGB-LED
GND Masse

Falls jemand einen Schaltplan des Boards hat, oder falls mich jemand korrigieren oder ergänzen möchte: immer her damit!

Mein Fazit: ein echt interessantes Board. Wer mehr GPIO braucht sucht vielleicht lieber nach einem NodeMCU, wer sowieso einen LDR oder eine RGB-LED braucht sollte zugreifen. Ich habe mittlerweile einige davon hier, und eine Firmware mit der ich die Dinger hier im Haus verteilen möchte ist auch fast fertig.

Oh, das Bild habe ich übrigens mit einer Grafik aus diesem Projekt gemacht, das ist die Witty Cloud für Fritzing.

Der fertige Joystick

Der fertige Joystick

Dies ist ein Projekt von 2004, auf der alten Schatenseite war es ausführlich beschrieben. Da gab es noch ein paar Bilder mehr, dazu Schaltpläne und eine Beschreibung wie ich den Tastaturcontroller analysiert habe.

Der PS/2-Anschluss von damals ist heutzutage obsolet. Mittlerweile würde ich so ein Projekt auf Basis von Mikrocontrollern machen, und dann per USB an den Rechner gehen. Deshalb lasse ich die Einzelheiten in der Vergangenheit und stelle das Projekt hier nur kurz vor.

Seinerzeit habe ich mich für MAME interessiert, den Multi Arcade Machine Emulator. Damit konnte man — man kann immer noch — auf einem PC die alten Spielhallenklassiker spielen. Eine Tastatur lässt aber nicht das authentische Feeling aufkommen, und so habe ich mir was gebastelt.

Ein Vogelnest

Ein Vogelnest

Die Joysticks waren eigentlich Zubehör für eine Sega Dreamcast Konsole. Ich habe die originale Elektronik rausgeworfen und stattdessen einen Controller aus einer PC-Tastatur implantiert. Dazu musste ich herausfinden wie die Matrix der Tastatur aufgebaut war, und die nötigen Kontakte dann mit den Mikroschaltern im Joystick verbinden. Gar nicht so kompliziert, eigentlich.

Die Kontakte für den zweiten Spieler habe ich auf einen Stecker gelegt, über ein Kabel das eigentlich für eine serielle Schnittstelle gedacht war konnte ich den zweiten Joystick anschliessen. Zusätzlich habe ich eine Y-Weiche gebastelt, damit ich neben den Joysticks auch noch eine richtige Tastatur anschliessen konnte. Irgendwie will so ein PC ja auch bedient werden.

Das Ergebnis war vom Aufbau her nicht schön, aber es hat funktioniert. :-D

Mittlerweile habe ich keinen PC mehr mit einer PS/2-Schnittstelle. Einen Joystick habe ich schon zerlegt und einer anderen Verwendung zugeführt. Aber das ist eine andere Geschichte, und die soll ein anderes Mal erzählt werden…

Siehe auch…

  • MAME – Die offizielle Seite des Arcade-Emulators
  • xMAME – Die Unix- bzw. Linux-Version
  • ArcadeControls – Tips und Anleitungen zum Selbstbau

Gestern habe ich auf Twitter gelesen dass es im Zabbix-Share ein Modul gibt mit dem man das Monitoring-Tool meiner Wahl — Zabbix — direkt auf einen Arduino zugreifen lassen kann: Zabbuino nennt sich das.

Komischerweise habe ich letzte Woche erst überlegt wieviel Aufwand es wohl sein mag, das Zabbix-Protokoll nachzuimplementieren. Ich bastele zur Zeit wieder mal mit dem WLAN-fähigen Chip ESP8266 herum, den hatte ich hier auch schon erwähnt. Damit lassen sich prima Messwerte einsammeln, und das schreit dann nach Zabbix. Mein erster Ansatz war, Messdaten per HTTP zur Verfügung zu stellen. Die werden dann von einem Skript periodisch abgeholt und per zabbix_send eingespeist. Wesentlich eleganter wäre es natürlich, Zabbix direkt auf den Sensor zugreifen zu lassen…

Es wäre also wirklich mal einen Versuch wert, das Zabbuino-Modul in Verbindung mit einer kleinen ESP8266-Platine zu testen, die kann man auch fuer deutlich unter fünf Euro kaufen. Oder hat das schon jemand ausprobiert?

Da ich das letzte Woche aber noch nicht kannte habe ich schon einen dritten Weg eingeschlagen. Noch viel besser, wie ich finde. Das ist aber eine andere Geschichte, und die soll ein anderes Mal erzählt werden…

Nachgemessen

Nachgemessen

Vor einer Weile hat mich jemand auf WeMos aufmerksam gemacht. Das sind kleine Entwicklungsplatinen, ähnlich wie Arduino. Im Gegensatz zu dem befindet sich darauf allerdings kein kleiner AVR-Controller, sondern der deutlich schnellere ESP8266 — mit dem ich ja in anderer Bauform auch schon rumgespielt habe. Dementsprechend funken die kleinen auch im WLAN. Da die WeMOS-Boards direkt per USB an den Rechner angeschlossen werden können entfällt das Gefummel mit RS232-Konvertern und 3,3V Versorgungsspannung, und programmiert wird komfortabel über die Arduino-IDE.

Sehr interessant ist die Mini-Variante. Dabei muss man zwangsläufig an das Buzzword Internet of Things denken. :-)

Für den Mini gibt es auch direkt ein Shield mit einem DHT22. Das ist ein Sensor mit dem man digital Temperatur und Luftfeuchtigkeit auslesen kann. Solche Messknoten will ich schon seit langem im Haus verteilen, und diese Boards sehen so aus als ob sie dafür gemacht sind. Der Wemos und das Shield kosten jeweils rund 4,50 Euro, so ist das auch ein bezahlbarer Spaß.

Abweichung je nach Anordnung

Abweichung je nach Anordnung

Die Programmierung war — Arduino-typisch dank der vielen Bibliotheken — nicht allzu schwer, so hatte ich nach kurzer Zeit einen funktionierenden Messknoten, samt der Messwerte im Zabbix.

Aber die Temperaturen waren verblüffend. Im Wohnzimmer ist es warm, aber nicht über 28°C. Nanu?

Das Infrarot-Thermometer hat mir dann verraten dass der WeMos stellenweise bis zu 32°C warm wird, und die Temperatur im DHT etwa 7°C über Raumtemperatur. Und richtig genug: wenn ich mein Platinen-Sandwich senkrecht positioniert habe waren es dank der Luftzirkulation nur noch 5°C zu viel. Mit dem Shield direkt neben dem WeMos — also nicht als Sandwich — waren es nur noch 2°C. Vielleicht hätte ich für den Versuch auch dünnere Drähte nehmen sollen. Vernünftige Werte habe ich erst bekommen als ich den Sensor thermisch komplett von dem WeMos entkoppelt habe, durch etwa 10cm Draht. :-(

Also: gute Idee, leider nicht ganz zu Ende gedacht. Von den WeMos-Boards werde ich mir wohl noch ein paar zulegen, aber die Sensoren kommen dann wohl in freier Verdrahtung zum Einsatz. Und vielleicht durch ein Gehäuse vom ESP getrennt…

Oh, eine andere Möglichkeit wäre vielleicht, die Sensoren aktiv zu machen. Bei mir werden die zur Zeit passiv abgefragt, per HTTP. Dazu müssen sie natürlich durchgehend im Netz sein. Wenn die sich beispielsweise nur alle fünf Minuten aktivieren und dann zum Beispiel per MQTT ihre Werte abliefern hätten sie vielleicht gar keine Zeit um sich aufzuheizen… und vielleicht würde diese Variante eh mehr Sinn machen. Schon allein wegen des Stromverbrauches (der im Moment übrigens bei 70mA am USB-Port liegt). Mal sehen…