Twilight Module

Details

Geschrieben von Alexander Schulz

Kategorie: FHEM

Veröffentlicht: 24. August 2013

Zugriffe: 40587

• Device
• FHEM
• Twilight
• Lichtmessung

Bei Steuerung der Rolladen kann ein Wissen über die vorhandenen Lichtverhältnisse sehr nützlich sein. Wenn dabei ein entsprechendes physisches Gerät nicht zur Verfügung steht, kann in einigen Fällen stattdessen das 'Twilight'-Modul eingesetzt werden. Damit kann der Grad der Dämmerung für ein definiertes Gebiet errechnet werden. Das Modul liefert eine ganze Menge verschiedenen Schätzungen.

Die Definition des Moduls benötig einige Parameter und sieht in allgemeiner Form so aus:

define <name> Twilight <latitude> <longitude> [<indoor_horizon> [<Weather_Position>]]

Die Parameter für die Koordinaten bekommt man am einfachsten aus Google-Maps (Rechtsklick auf die gewünschte Stelle auf der Karte, Eintrag 'Was ist hier?' aktiviren).

Mit dem 'indoor_horizon' wird die Berechung der Lichtwerte in Innenräumen gestWas bekommt euert. Typische Werte liegen zwischn 0 und 6. Die berechneten Werte sind als grobe Schätzungen zu betrachten.

Der Parameter 'Weather_Position' ist sogenannte yahoo weather id für das gewünschte Gebiet. Damit wird der Einflüss der aktuellen Wetterverhältnisse bei den Berechnungen mitberücksichtigt (z.B. die Bewölkung). Diese ID bekommt man aus der URL, wenn man auf der Seite http://weather.yahoo.com/ die Gewünschte Lokation ins Suchfeld eingibt. Z.B. für Langenhabel lautet diese Zahl 670178.

Beispiel für meine Konfiguration:

define T Twilight 52.481591 9.73296 1 670178
attr T comment Location: Langenhagen
attr T group Umwelt
attr T room 9.02_Steuerung

define FileLog_Twilight FileLog /var/InternerSpeicher/fhem/log/Twilight-%Y.log T:light.*
attr FileLog_Twilight logtype myTwilight:Plot,text
attr FileLog_Twilight room 9.90_Logs

 Folgende Informationen werden geliefert:

Mögliche Lichtwerte

0 - tiefe Nacht, die Sonne mindestens -18 Grad unter dem Horizont
1 - astronomische Dämmerung, Die Sonne zwischen -12 und -18 Grad unter dem Horizont
2 - Nautische Dämmerung, Die Sonne zwischen -6 and -12 Grad unter dem Horizont
3 - Ziville Dämmerung, Die Sonne zwischen 0 and -6 Grad unter dem Horizont
4 - Innenraum Dämmerung, die Sonne zwischen 'indoor_horizon' und 0 Grad unter dem Horizont (nicht benutzt bei indoor_horizon=0)
5 - Wetterabhängige Dämmerung, die Sonne zwischen 'indoor_horizon' und dem virtuellen Wetter-Horizont (abhängig von Wetterverhältnissen)
6 - Maximale tageslicht

Im Tagesverlauf sieht die Werteveränderung ungefähr so aus:

Die Definition für das Diagram:

define w_T_light SVG FileLog_Twilight:myTwilight:CURRENT
attr w_T_light group Umwelt
attr w_T_light room 0.00_Umwelt

Die "myTwilight.gplot"-Datei:

############################
# Twilight-Helligkeit

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'

set title '<TL>'

set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set grid xtics y2tics

set ytics nomirror
set ylabel "Helligkeit"

set y2tics
set y2label "Helligkeit"

#FileLog 4:::

plot "" x1y1 title 'Helligkeit' with lines

Vereinfachte Steuerung der Rolladen könnte damit z.B. folgendermaßen aussehen:

define rollo_auf at *{ReadingsVal("T","sr_indoor","7:00:00")} { fhem "set rollo 100";; }

Weitere Anwendungsbeispiele habe ich unter folgenden Adressen gefunden: http://www.fhemwiki.de/wiki/Twilight_Anwendungsbeispiel, http://forum.fhem.de/index.php?t=msg&goto=55176&rid=0

FHEM Watchdog

Details

Geschrieben von Alexander Schulz

Kategorie: FHEM

Veröffentlicht: 20. August 2013

Zugriffe: 49855

• FHEM
• Watchdog
• FritzBox
• Script
• Überwachung

Die Entwicklung beim FHEM geht recht rege voran, Updates gibt's praktisch jeden Tag. Ich hole mir ständig die aktuellsten Sourcen. So hat man schnell die neuen Funktionen und Fehlerfixes. Als Kehrseite der Aktualität erkauft man den Nachteil der Instabilität. Auch wenn der Server meist sehr stabil läuft, kann es schon mal passieren, dass er mal abstürzt oder 'hängen' bleibt. In den letzten 6 Monaten hatte ich solche Situationen schon paar Mal.

Es ist an sich nicht sehr schlimm, wenn der Server kurzfristig nicht funktioniert, ein Dauerausfall ist aber schon unangenehm. Und so beschloss ich ein Watchdog-Script zu schreiben, der den Zustand des FHEM-Servers überwacht und ihn bei Bedarf neustartet.

Die Funktionsweise ist einfach. Es wird regelmäßig geprüft, wie viel Zeit seit dem letzten Lebenszeichen des Servers vergangen ist. Bei Überschreitung eines definierten Maximums wird die laufende Instanz beendet und eine neue gestartet.

Das 'Lebenszeichen' wird durch die Protokollierung des Zustandes eines extra dafür angelegtes Objektes erzeugt. Folgende Auszug aus fhem.cfg stellt die Definitionen des Objektes, der zugehörigen Log-Datei und der Routine zur periodischen Aktualisierung des Zustandes dar. Zur Vusualisierung wird ein Diagramm (WebLink) definiert. Damit auch die Log-Ausgabe des Watchdogscriptes im FHEM angesehen werden kann, wird diese Logdatei als eine Externe-Logdatei definiert (fakelog).

...
# Definition eines Dummy-Objektes fuer 'Alive'-Meldungen
define NN_TE_DMST01.Server_Heartbeat dummy
attr NN_TE_DMST01.Server_Heartbeat group Watchdog
attr NN_TE_DMST01.Server_Heartbeat room 9.03_Tech
# Protokoliert Zeitpunkt der letzten Änderung (in Objekt-Eigenshaften)
attr NN_TE_DMST01.Server_Heartbeat userReadings lastChange { CurrentTime() }
# Definition der Log-Datei
define FileLog_NN_TE_DMST01.Server_Heartbeat FileLog ./log/NN_TE_DMST01.Server_Heartbeat-%Y-%m.log NN_TE_DMST01.Server_Heartbeat
attr FileLog_NN_TE_DMST01.Server_Heartbeat group Watchdog
attr FileLog_NN_TE_DMST01.Server_Heartbeat logtype myServerHeartbeat:Plot,text
attr FileLog_NN_TE_DMST01.Server_Heartbeat room 9.03_Tech
# Visualisierung mittels eines Diagramms
define 0.wlHeartbeat SVG FileLog_NN_TE_DMST01.Server_Heartbeat:myServerHeartbeat:CURRENT
attr 0.wlHeartbeat group Watchdog
attr 0.wlHeartbeat room 9.03_Tech

# Routine zur regelmaessigen Änderungen des Wertes des Dummy-Objektes
define tickHeartbeat at +*00:01:00 {tickHeartbeat('NN_TE_DMST01.Server_Heartbeat');;}
attr tickHeartbeat alignTime 00:00
attr tickHeartbeat group Watchdog
attr tickHeartbeat room 9.03_Tech
# Log-Datei des Watchdogscriptes verfügbar machen
define FileLog_wathdog FileLog ./log/watchdog.log fakelog
attr FileLog_wathdog group Watchdog
attr FileLog_wathdog room 9.03_Tech

# Visualisierung für Watchdog-Log
define 0.wlWatchdog SVG FileLog_wathdog:myWatchdog:CURRENT
attr 0.wlWatchdog group Watchdog
attr 0.wlWatchdog room 9.03_Tech

...

Das Diagramm hilft ein schnelles Überblick über die möglichen Ausfälle in der letzten Zeit zu beschaffen. Dazu wird folgende Plot-Datei verwendet (myServerHeartbeat.gplot):

# Plot fuer Visualisierung von Server-Hearbeat-log
set terminal png transparent size  crop
set output '.png'
set title ''
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set grid xtics y2tics
set ytics ("" 0, "" 30, "" 59)
set ylabel ""
set yrange [-1:60]
set y2tics ("" 0, "" 30, "" 59)
set y2label ""
set y2range [-1:60]
#FileLog 3:
plot "" x1y1 notitle ls l1fill lw 0.5 with steps

Auch für die Daten aus dem Watchdog-Log habe ich eine entsprechende Visualisierung entwickelt. Da kann abgelesen werden, wie die 'Heartbeat'-Zeiten waren und wann ggf. ein Ausfall registriert wurde.

#
# Anzeige der Watchdog-Log-Informationen
#
set terminal png transparent size  crop
set output '.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Watchdog'
set yrange [-10:300]
set y2label "Zeit (s)"
set ytics ("alive" 0, "dead" 1)
set yrange [-0.1:1.1]
set ylabel "Status"
#FileLog 4:\x20V\x3a:0:
#FileLog 6:\x20S\x3a:0:$fld[5]=~"dead"?1:0
plot "" x1y2 notitle ls l5 lw 0.5 with steps, \
            x1y1 notitle ls l8fill lw 0 with steps

Es sieht dann in etwa so aus (die beiden Ausfälle wurden hauptsächlich durch meine eigenen Basteleien verursacht):

In den Scripten oben wurden zwei Methoden verwendet, die in der Datei '99_myUtils.pm' abgelegt sind:

...
# --- Liefert aktueller Zeitstempel ---
sub CurrentTime()
{
  return strftime("%H:%M:%S", localtime());
}

# --- server heartbeat / watchdog ---
sub tickHeartbeat($)
{
    my ($device) = @_;
    my $v = int(Value($device));
    $v = $v+1; 
    if($v>=60) {$v=0;} 
    fhem("set $device $v");
}
...

 Als nächstens muss der eigentliche Überwachung-Script her. Was dabei herausgekommen ist, kann bei GitHub angesehen werden (watchdogloop.sh)

Ein Starter-Script prüft vor dem Start der Überwachungsroutine, ob eine Instanz davon bereits aktiv ist (runwatchdog.sh).

Damit Watchdog austomatisch anläuft, muss beim Starten von FHEM auch der Watchdog mitgestartet werden. Dafür wird in der Startdatei (startfhem) eine entsprechende Anweisung eingefügt.

Folgendes Script habe ich vollständigkeitshalber erstellt. Damit wird der Watchdog beendet.

#!/bin/sh

killall watchdogloop.sh

Anmerkungen:

Da bei einem Update der FEHM-Server nicht reagiert, muss der Watchdog vor dem Update deaktiviert werden. Ansonsten kann es passieren, dass das laufende Update gewaltsam unterbrochen wird. Eine andere Möglichkeit ist, die Update im Hintergrund durchführen zu lassen. Das geschieht durch ein Attribut (attr global updateInBackground 1) in fhem.cfg. Dabei wird der Server während des Update-Prozesses nicht (mehr) blockiert.

Zuletzt habe ich noch das eigentliche Start-Script /etc/init.d/fhem umgebogen (bei GitHub unter: etc_init.d_fhem_script.txt). Zum Starten/Stoppen werden jetzt startfhem bzw. stopfhem werdendet.

Links

Die letzten Versionen sind bei GitHub zu finden:

https://github.com/hexenmeister/MyFHEM/blob/master/watchdogloop.sh
https://github.com/hexenmeister/MyFHEM/blob/master/runwatchdog.sh
https://github.com/hexenmeister/MyFHEM/blob/master/killwatchdog.sh
https://github.com/hexenmeister/MyFHEM/blob/master/startfhem
https://github.com/hexenmeister/MyFHEM/blob/master/stopfhem
https://github.com/hexenmeister/MyFHEM/blob/master/FHEM/99_myUtils.pm

https://github.com/hexenmeister/MyFHEM/blob/master/www/gplot/myServerHeartbeat.gplot
https://github.com/hexenmeister/MyFHEM/blob/master/www/gplot/myWatchdog.gplot

https://github.com/hexenmeister/MyFHEM/blob/master/etc_init.d_fhem_script.txt

Update:

Ich habe den Benutzer fhem in die Gruppe sudo aufgenommen. Damit will ich sicherstellen, dass der Script in der Lage ist, volle Kontrolle über den FHEM-Server auszuüben, auch dann, wenn dieser unter einem anderen Benutzeraccount gestartet sein sollte.

sudo usermod -aG sudo fhem


Um keine Sicherheitslücke aufzumachen, bekommt dieser Benutzer Rechte zur Ausführung mit sudo nur für ganz bestimmte Scripte. Dies geschieht durch Einfügen einer Zeile in die Datei sudoers (sudo nano /etc/sudoers).

fhem ALL=(ALL) NOPASSWD: /opt/fhem/runwatchdog.sh, /opt/fhem/killwatchdog.sh, /opt/fhem/watchdogloop.sh, /opt/fhem/runfhem.sh, /opt/fhem/killfhem.sh


Beschleunigungssensor MMA7361

Details

Geschrieben von Alexander Schulz

Kategorie: Sonstige

Veröffentlicht: 17. August 2013

Zugriffe: 30547

Auch wenn ich derzeit keine Verwendung für einen Beschleunigungssensor habe, hat es mich trotzdem interessiert, so einen auszuprobieren. Also habe ich ein MMA7361-BreakBoard besorgt und kurz getestet.

Zum Anschliessen werden ganze 9 Leitungen benötigt. Diese sind wie folgt mit einem Arduino zu verbinden:

Außerdem muss die AREF-Leitung an 3,3V angeschlossen werden.

Zur Ansteuerung habe ich "AcceleroMMA7361"-Bibliothek (s.a. Forumbeitrag auf arduino.cc) mit folgendem Sketch (liegt als Beispiel der Bibliothek bei) verwendet:

#include 
AcceleroMMA7361 accelero;
int x;
int y;
int z;
void setup()
{
  Serial.begin(9600);
  accelero.begin(13, 12, 11, 10, A0, A1, A2);
  accelero.setARefVoltage(3.3);                   //sets the AREF voltage to 3.3V
  accelero.setSensitivity(LOW);                   //sets the sensitivity to +/-6G
  accelero.calibrate();
}
void loop()
{
  x = accelero.getXAccel();
  y = accelero.getYAccel();
  z = accelero.getZAccel();
  Serial.print("\nx: ");
  Serial.print(x);
  Serial.print(" \ty: ");
  Serial.print(y);
  Serial.print(" \tz: ");
  Serial.print(z);
  Serial.print("\tG*10^-2");
  delay(500);                                     //make it readable
}

Beim Testen ist mir aufgefallen, dass die Initialisierung des Sensors recht lange gedauert hat (gefühlte 10 Sekunden). Der Sensor hat eine einstellbare Empfindlichkeit (±1.5g, ±6g; 800 mV/g bei 1,5g) und eine Erkennung des freien Fall (0g-detect).

Datenblatt zu der MMA7361 IC fand ich unter folgendem Link: https://www.sparkfun.com/datasheets/Components/General/MMA7361L.pdf.

Mehrere Geräte an selben I2C Bus

Details

Geschrieben von Alexander Schulz

Kategorie: I²C

Veröffentlicht: 12. August 2013

Zugriffe: 32686

• I2C
• Level Shifter

Grundsätzlich können an einem I2C Bus bis zu 127 Geräte gleichzeitig betrieben werden. Es lauern dabei jedoch einige Fallstricke.

Zuerst gilt sicherzustellen, dass keine der Geräte dieselbe Adresse verwenden. Viele erlauben die Auswahl aus mehreren Adressen. Bei einigen sind das zwei Möglichkeiten (z.B. bei BH1750), bei anderen können ganze 3 Bits frei bestimmt werden (also 8 mögichen Adresse, z.B. LCD-I2C Adaptermodul).

Dann ist es wichtig, dass alle angeschlossenen Geräte mit den passenen Spannungen versorgt werden. Nicht nur als Betribsspannung, auch die Ein- und Ausgänge (SDA, SCL) müssen beachtet werden. Die häufig angebotenen Arduino Module auf der basis von 3,3V Chips enthalten einen Spannungswandler zur Versorgung und ein PullUp-Widerstand je Datenleitung zur 3,3V-Schiene zur Begrenzung der Spannung. Das funktioniert nur soweit gut, bis ein 5V-Modul mit eigenen PullUps angeschlossen wird. Dadurch kann die Spannung an den Datenleitungen auf gefährliche Werte ansteigen. Die richtige Lösung ist die Verwendung eines Level Shifters. Mit einem 5/3,3V Level Shifter können mehrere 5V und 3,3V Geräte gleichzeitig betrieben werden. Ein Level Shifter enthält bereits PullUps für beide Teile der I2C-Buses, die Widerstände auf den Modulen werden überflüssig.

Die überflüssigen PullUps können schnell zu einem weiteren Problem führen: durch die Parallelschaltung mehreren davon, wird der Gesamtwiderstand immer geringer. Zunächst führt das zu einem unnötig hohem Stromverbrauch, irgendwann fällt das ganze Bus aus. Also sollten die unnötigen PullUps möglichst ausgelötet werden.