Seit geraumer Zeit sind Rauchmelder in Neubauten ja Pflicht. Macht ja auch durchaus Sinn. Gerade wenn man an solche USV-Aktionen denkt Also muss ein Rauchmelder her. Der Otto-Normal-Nerd möchte aber mindestens irgendwas haben, was sich auch in die Standardhaustechnik integrieren lässt – am besten noch ein Set von mehreren Rauchmeldern. Da gibts es zig Varianten:

1. Die Billigrauchmelder (um die 5-10 Euro)
2. Die Billgrauchmelder die per 433MhZ miteinander sprechen (ab 60 Euro im Set mit 4 Stück)
3. Die teueren Systemrauchmelder die nichts anderes als (2) machen, nur das G*ra oder sonstwas draufsteht.
4. Die sündhaft teueren Rauchmelder mit eingebauten GSM-Modul (ab ca. 150 Euro aufwärts…)

Gelinde gesagt: Alles doof – da es entweder meinen Ansprüchen nicht genügt, oder massivst zu teuer ist.

Nun denn erstmal Dinge sichten – also ab zum Baumarkt und mal einen Rauchmelder der Kategorie “1″ gekauft. Schimpft sich RM120 und hat schlappe 8,- gekostet. Laut ist das Ding ja, wenn man Zigarettenrauch reinbläst, oder mal den Testknopf drückt – bringt nur nix, wenn niemand zu hause ist Nach dem öffnen des Geräts, schaut einen ein wenig SMD-Technik (Oha) an, darunter ein IC mit der Aufschrift “CS2105go“. Wie sollte es anders sein, dazu gibts leider kein Datenblatt. Aber Moment, vielleicht ist der CS2105GO-M12 ja Pinkompatibel mit dem MC145010 – Bingo, ist er ! Der MC145010 (manchmal auch MC145012) wird in fast allen Rauchmeldern der Kategorie 1 und 2 (teilweise auch 3) verkauft.

Der aufmerksame Leser merkt was: Bei 2 ist doch eine Vernetzung möglich ! Korrekt, so ist es. Mit anderen Worten: In den Rauchmeldern der Kat.1 ist derselbe IC verbaut, wie in 2, nur das in 1 halt das 433MhZ Modul fehlt. Brauch ich (zumindest jetzt zum Testen) eh erstmal nicht –  doch dazu später. Der MC145010 verfügt über einen sog. I/O Pin, der bei 2er Rauchmeldern dann das 433MhZ-Modul per TTL-High triggert, sobald es qualmt. Beim 1er liegt PIN7 (I/O) tot herum. Perfekt. Also fix den Ground (-) und PIN7 per Kabel rausgeführt und an den Arduino geklemmt:

Links (Schwarz) die Masse – Also GND direkt mit dem GND des Arduino’s verbinden,

Recht (Rot), etwas fuckeliger, den PIN7 (I/O) des CS2105GO-M12 auf einen Analogen Input-PIN des Mikrocontrollers legen.

Auf dem Arduino selbst habe ich derzeit die gute Wohnzimmerinfo-Anzeige am laufen, da ist also schon ein “Ethernet-Shield” drauf. Da dort noch diverse Analoge Ports frei sind, und der Rauchmelder auch direkt deben dem Display wohnen soll, also optimal. Vom Code her gestaltet sich das ganze relativ simpel (siehe unten). Das allerfeinste ist jedoch, dass man nichtmal gegen irgendwelche Vorschriften verstösst, wenn man sich anstelle von Variante 1 für einen Rauchmelder der Variante “2″ entscheidet. Denn alle Rauchmelder bleiben so wie sie sind (sprich: Die piepen trotzdem). Nur einen, in dem 433MhZ-”Netz”, muss man dann an den Arduino anklemmen. Der verbaute Standalone-RM120 piept übrigens auch noch – denn genau dafür ist PIN7 gedacht: I/O !


#include
#include

#define SmokePIN 0

int Smoke=0;
boolean mailsent=false;
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192,168,0, 100 };

void setup () {
Ethernet.begin(mac,ip);
}

void loop() {
// Read Smokedetector
Smoke=analogRead(SmokePIN);

// GGf. RESET der Variable mailsent

if (Smoke > 900) {
if (mailsent==false) {
firemail();
mailsent=true;
}
}
}

void firemail() {
// IP des Mailservers
byte mserver[] = {192,168,0,101};
Client Mail(mserver,25);
if (Mail.connect()) {
Mail.println(“HELO arduino.domain.tld”); /* say hello (statement after helo is needed but irrelevant)*/
Mail.println(“MAIL From: et_brennt@domain.tld”); /* identify sender, this should be the same as the smtp server you are using */
Mail.println(“RCPT To: et_brennt@domain.tld”); /* identify recipient */
Mail.println(“DATA”);
Mail.println(“To: et_brennt@domain.tld”); /* identify recipient */
Mail.println(“Subject: Burning down the House”); /* insert subject */
Mail.println(“WARNING – Smoke detected !”); /* insert body */
Mail.println(“.”); /* end email */
Mail.println(“QUIT”); /* terminate connection */
Mail.println();
Mail.stop();
}
}

Args. Was ein pfu. Doch von vorne:

Am Freitag letzter Woche ging es los. Meine gute SmartUPS 1500RM hatte auf einmal Hitzewellen. Woher die kamen ? Keine Ahnung. Entdeckt habe ich das ganze eher durch Zufall, da ich ab und an dann doch mal einen Blick ins cacti werfe. Da sah das ganze dann so aus:Interessant in dem Zusammenhang: Die USV wirft erst einen Alert ab ca. 60 Grad Celsius. Meiner Meinung nach – die sollte sich später noch bestätigen – viel zu spät. Das Rack, indem sich die APC 1500 befindet, hat übrigens direkte Aussenbelüftung – im “Serverraum” waren es also die ganze Zeit über so um die 16 Grad. Bei den Peaks bin ich dann doch mal ‘runter gegangen und hab die Schranktür des Racks aufgemacht, und siehe da: Temp wieder normal.

Am Wochenende stand das gute Stück also erstmal unter Beobachtung. Wie man oben erkennt, war es jedoch ruhig. Pünktlich zum Wochenbeginn fing die USV dann aber wieder an zickig zu werden. Da mir dass ganze (wörtlich !) zu heiss wurde, habe ich mich dann entschlossen das Batterypack (ist in so einer Cartridge) zumindest abzuklemmen. Da die Notstromversorgung Hot (!)-Pluggable ist, also kein Problem.

Sofern die angeschlossenen Geräte in diesem Zustand (Batterien abgezogen / disconnected) noch laufen, sollte man es tunlichst unterlassen der USV den Strom zu klauen. Nicht nur, dass dann alles aus ist – das wäre zu einfach – man bekommt auch keinen Saft wieder auf die USV. Die lässt sich nämlich nur mit angepömpelten Akkus starten (FAIL !!).

Also erstmal Ersatzakkus bestellen. Aber € 520,- für ‘ne Cartridge (RBC24) mit 4 Moppedakkus ? Ja sind die wahnsinnig bei APC ? Das muss doch günstiger gehen. Geht es: Diverse Händler verkaufen die Akkus einzeln zum Stückpreis von € 20,- . Da die Akkus bisher noch nicht eingetroffen sind, spreche ich da noch keine Empfehlung aus

Demontage:

Ansich nett gedacht. Frontblende der UPS entfernen, 4 Schrauben lösen und dann einfach die Cartridge mit den 4 Bleigelakkus rausziehen. Was aber tun, wenn die Dinger aufgequollen sind ? Mit Gewalt ziehen, hat geholfen. Hier das Resultat:

Nun “nur noch” die 4 Akkus aus der Blechwanne entfernen. Haha ! Kein Tutorial, keine versteckte Klammer mit der die Dinger da gehalten werden – nix. Fühlt sich an wie festgeklebt. So war es auch. Jeder Akku ist mit einem dusseligen doppelseitigem Klebestreifen an der Wanne festgeklebt. (2ter FAIL !!) Also auch hier wieder Gewalt anwenden, und die Dinger vorsichtig mit dem Schraubenzieher anhebeln – irgendwann kommen die von alleine Der Sicherheit halber, habe ich die Anschlüsse mal zusammengetaped, isoliert, und mit Nümmerchen versehen. Jeder Platz in der Aluwanne hat dann die korrespondierende Nummer bekommen. Jetzt heisst es warten auf die Ersatzlieferung, und hoffen das der Strom nicht ausfällt.

PS: Vor ca. 6 Jahren ist mir mal eine 750er Desktop-SmartUPS unterm Schreibtisch hochgegangen. War nicht lustig. Die musste ich mit dem Topflappen auf den Balkon befördern… Von daher: Wenn Euch die Akku-Temperatur (Internal Temperature bei APC) komisch vorkommt – lieber heute als morgen die Akkus wechseln.

Kennwort unter Solaris “expired” ?

Beim Login per ssh per key-auth kommt nix, und bei einem su – xxx kommt die Meldung “Password for user ‘xxx’ has expired – use passwd(1) to update it” ? Da gibts eine Loesung:

Einfach auf der Shell (als anderer User) das Tool “login” aufrufen, mit den “alten” Credentials einloggen, und schont kommt der Password-Change-Prompt. Gut versteckt das ganze !

Sehr cool was mit dem Arduino so alles machbar ist. Um es vorweg zu nehmen: Mit dem Ding habe ich eine Ansteuerung eines BetaBrite LED-Moduls via Netzwerk gebaut (also im “Live-Betrieb” OHNE Rechner benutzbar).

Doch vorne angefangen:

Vor ein paar Jahren hatte ich mir bei eBay ein BetaBrite geschossen – Das ist so eine nette Laufschrift, die man zum Leute quälen draussen an seinen Copyshop hängen kann, so man(n) den einen hat. Die Idee war damals die Temperaturdaten meiner Wetterstation und ein paar andere Dinge anzeigen zu lassen. Ist aber nie so richtig umgesetzt worden, da mein “Serverpark” im Keller steht, und die Anzeige dort natürlich null Nutzwert hat. Vor ein paar Tagen bin ich dann auf das Arduino-Projekt gestossen – klang (und ist auch) alles sehr vielversprechend:

Eine simple Plattform incl. Entwicklungsumgebung für die ATMEGA-Microcontroller Serie mit massenweise Zubehör. Wer das Ding nicht kennt, einfach mal bei arduino.cc umschauen. Bezugsquellen sind u.a. watterod, komputer.de oder auch farnell.com, sofern man (bei farnell) denn im Besitz eines Stundentenausweises ist (Die Spareffekte dort sind vernachlässigbar). Der Knaller an dem Ding ist jedoch der Preis. So gibt es den Arduino für ca. 20-28 Euronen incl. Versand zu haben. Der Microcontroller lässt sich über die USB-Schnittstelle (sowohl auf Mac, PC oder Linux) in einer Art C-Dialekt für Kids programmieren (Ist wirklich extremst Easy). Das ganze geht so in Richtung SPS – daher heisst der Dialekt wohl auch “Processing”. Man hat im Template quasi 2 vorgefertigte “Prozeduren”:

• void setup – wird einmalig aufgerufen, wenn der ATMEGA hochgefahren wird und dient zum initialisieren der Ports, etc.
• void loop – wird, wie der Name schon sagt, im Loop kontinuierlich durchlaufen – bei mir kamen da direkt Errinerungen an die Lehrzeit wieder hoch (SPS – Merker setzen und sowas)

Hardwaretechnisch verfügt das Ding über 14 Digitale I/O Pins, von denen 6 per PWM ansteuerbar sind (alles TTL-Pegel), sowie 6 Analoge ein/Ausgänge mit einer 8bittigen genauigkeit im A/D bzw. D/A Wandler. Sämtliche Anschlüsse sind auch für Wurstfinger, wie meine, leicht verfügbar, sodass Löten – wenn man es denn nicht gerade drauf anlegt – ausfällt.

Zurück zum Titel dieses Eintrags. Zusätzlich zum Board habe ich mir noch eine Ethernet-Shield gegönnt. Shields sind sowieso die Erfindung hier uberhaupt. Man kann sich das als “Huckepack”-Platine vorstellen, die bestimmte Pins des Arduinos belegen und dann weiter Funktionalitäten bereitstellen. Das eth-Shield stellt also einen Netzanschluss zur Verfügung, und genehmigt sich dafür 6 Pins. (Eine gute übersicht über den “Pinverbrauch” und verfügbare Shields gibts übrigens bei shieldlist.org). Das Shield selbst lässt sich dann im “Processing” über ein paar Simple Funktionen ansteuern / auslesen.

Problematisch beim BetaBrite war, dass dieses über eine RS232 (vulgo: Serielle) Schnittstelle verfügt, der Arduino aber nur TTL-Pegel verarbeiten kann. Es gibt für den Ard. eine Serial-Library, mit der man aus zwei weiteren Pins einen Seriellen Anschluss “emulieren” kann, aber ohne korrekte RS232-Pegel ist das suboptimal. Was tun ? Mal ein wenig gekramt, und dann ist mir ein MAX232 zwischen die Finger gekommen – quasi genau das was man braucht. Die Schaltung mit dem MAX232 ist mehr als simpel (Einfach ausgedrückt konvertiert der 232 die Pegel). Somit steht das ganze Hardwaremässig schonmal. Ethernet-Shield -> Arduino -> MAX232 -> BetaBrite. Fehlt nur noch die “Software”. Die Ansteuerung der BetaBrites ist schnell im Netz gefunden (z.B. hier, bzw. als PDF direkt beim Hersteller). Der Code auf dem Arduino umfasst gerade mal 2kB (incl. inline-Dokumentation !!!). Falls interesse besteht, stell ich den gerne mal hier ein.

Was kann das ganze jetzt ?

Nun, Der Microcontroller mit Ethernetanschluss “horcht” auf TCP-Port 23. Immer wenn sich etwas connected und eine Zeile schreibt, dann gibt der Controller das an das Betabrite weiter. Serverseitig kann ich nun, aus dem Keller heraus , das BetaBrite ansteuern, wo immer auch Netz verfügbar ist…

Na premium. Setze mich heute morgen an den Rechner, und was sehe ich: Kein Internet !

Dass man Abstriche machen muss, wenn man knapp 2 Jahre lang Kabelmodem verwöhnt war, (Kein nervtötender Reconnect / NULL Ausfälle / Konstanter Up/Downstream etc.) hatte ich mir ja schon gedacht. Nunja, seit ca. 3 Wochen bin ich wieder PPP over Ethernet User (DSL) mit all seinen “netten” Nebeneffekten (siehe oben). Normalerweise reconnected der pppd auch fein nach jedem Disconnect – nur heute Nacht halt nicht.

Die Analyse (siehe Logauszug) ergibt zwei suspekte Dinge:

1. “Rausschmiss” durch den Provider nach 574 Minuten (Normalerweise passiert das nach 24h)
2. Reconnectversuch durch den PPPD, der jedoch mangels Antwort der Gegenstelle ins leere läuft.

Gerade Punkt 2 nervt hier – denn per default gibt der pppd nach 10 Versuchen auf. Nach etwas googlerei habe ich dann doch die richtige Option gefunden, mit der er unendlich “PADI”s schicken soll, um irgendwann dann mal ‘nen Connect hinzubekommen. Einfach ein “maxfail 0” in die /etc/ppp/peers/provider eintragen, und schon versucht es der Router bis zum St.Nimmerleinstag


Feb 1 03:03:04 pppd[530]: LCP terminated by peer
Feb 1 03:03:04 pppd[530]: Connect time 573.9 minutes.
Feb 1 03:03:04 pppd[530]: Sent [ne Menge] bytes, received [noch viel mehr] bytes.
Feb 1 03:03:07 pppd[530]: Connection terminated.
Feb 1 03:03:07 pppd[530]: Modem hangup
Feb 1 03:04:12 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:04:43 pppd[530]: PPP session is 350
Feb 1 03:04:43 pppd[530]: Using interface ppp0
Feb 1 03:04:43 pppd[530]: Connect: ppp0 <--> eth2
Feb 1 03:04:49 pppd[530]: Connection terminated.
Feb 1 03:04:49 pppd[530]: Modem hangup
Feb 1 03:05:54 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:06:59 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:08:04 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:09:09 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:10:14 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:11:19 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:12:24 pppd[530]: Timeout waiting for PADO packets
Feb 1 03:13:29 pppd[530]: Timeout waiting for PADO packets


Wah !

2 Wochen habe ich mich nun mit verlorenen Paketen herumgequält, die interessanterweise nur bei IMAPs Verbindungen vom LAN ins WAN aufgetreten sind. Jetzt hab ich das ganze mal mit Wireshark analysiert. Ergebnis: Lost packets (Ja wusste ich auch schon).

Des Rätsels Lösung: Nie, ich wiederhole, NIEMALS mit der mtu in einer DomU unter XEN herumspielen. Einfach auf “default” lassen. Jetzt geht es wieder !

Das Perl-Modul WWW::Shorten::Bitly als solches bietet die Moeglichkeit URLs, die zuvor mit bit.ly verkuerzt worden sind, wieder zu “expanden” und auch diverse Clickstatistiken auf diese URLs zu fahren.

Leider hat das Modul ein paar Schoenheitsfehler:

1. Beim “Expanden” meint das Modul die Methode “GET” nutzen zu wollen. Die API von bit.ly schreibt hier aber ein “POST” vor. Das ist recht zuegig gefixed. Einfach in der Zeile 257 (Methode “expand” der Version 1.14) aus dem get ein post machen -> Fertig
2. Beim Aufruf der Methode “clicks” auf URLs mit vielen Statistik-Daten (Referrers, etc.) versagt der SAX-Parser auf ganzer Linie. Er quittiert das Parsen mit einer Fehlermeldung a’la: End tag mismatch (nodeKey != nodeValue) [Ln: x, Col: yyyyy]Das Problem laesst sich dadurch loesen, dass man dem XML::Simple Modul sagt, es soll gefaelligst einen Ordentlichen parser benutzen. z.B. den XML::Parser (der zuvor via cpan installiert werden muss (setzt libexpat1-dev vorraus !)). Wir teilen dies dem Bitly Modul nach dem Einbinden von XML::Simple ueber folgenden String mit: $XML::Simple::PREFERRED_PARSER = 'XML::Parser'; … und oh Wunder: Alles funktioniert

In diffs ausgedrueckt sind folgende Aenderungen an WWW::Shorten::Bitly Version 1.14 notwendig:

22a23,24
> $XML::Simple::PREFERRED_PARSER = 'XML::Parser';
>
257c259
< $self->{response} = $self->{browser}->get($self->{BASE} . '/expand', [
---
> $self->{response} = $self->{browser}->post($self->{BASE} . '/expand', [


Ab nun klappt auch das Auslesen mit dem Modul.

Sachverhalt: Zig dilettantisch benannte Dateien mit Leerzeichen und Umlauten in wiederrum zig Verzeichnissen (Windeutsch: Ordner).

Wunsch: umbennen der Files mit einem Schlage

Lösung:

Shellscript:

#!/bin/bash
find . -depth -execdir rename 's/ä/ae/g;s/ö/oe/g;s/ü/ue/g;s/ß/ss/g;s/ /_/g' "{}" \;
find . -depth -execdir rename 's/Ä/Ae/g;s/Ö/Oe/g;s/Ü/Ue/g;s/ß/ss/g;s/ /_/g' "{}" \;


Einfach nur Göttlich

… schonmal versucht Abhängigkeiten grafisch darzustellen ? Am besten noch aus Datenbankcontent ?

Klar, man könnte zu irgendwelchen proprietären MindMap-Tools oder gar zu M$-Visio (oh grauss !) greifen. Dabei geht es mit graphviz in Verbindung mit “dot” soooo einfach. Das Ding ist ehrlich einen Blick wert. Zusammen mit der “Connect by Prior” Clause in Oracle ist das Teil der Knaller schlechthin.

Ein wenig Doku dazu (die original-Doku ist recht schwere Kost) gibt es z.B.

• in der englischsprachigen Wikipedia (der Deutsche Artikel ist lame)
• Im Wiki von “zum.de”
• bei WikiSchool
• das 4Webmaster Tutorial (mit Bezug auf das MediaWiki Plugin)

Das allerbeste ist, dass MediaWiki das Ding von Haus aus unterstützt, und man derartige Graphen direkt per Wiki-Editor in die Artikel einbetten kann…