Firmata und die Türklingel

Details

Geschrieben von Alexander Schulz

Kategorie: Eigenbau

Veröffentlicht: 15. Mai 2014

Zugriffe: 83373

• Arduino
• FHEM
• FIRMATA

Wenn schon etwas automatisiert werden kann, wird man das irgendwann auch automatisieren wollen ;)

So kam es auch, dass ich meine Türklingel an das FHEM angeschlossen habe. Die Idee war, eine Benachrichtigung an mein Handy zu bekommen, wenn jemand an der Haustür geklingelt hat.

Ich habe mich für die Verwendung eines Arduino Nano mit dem Firmata-Sketch entschlossen (USB-Variante). Diese Lösung ist günstig und gut FHEM-seitig unterstützt.

Nach der kurzen Betrachtung der Gong-Verdrahtung (Drahtknolle trift wohl besser zu ;), wurde schnell klar, wie diese geändert werden kann, damit im Heizungsraum (da befinden sich der Hauptverteiler mit dem Klingel-Trafo und auch mein Fhem-Server) das Signal abgegriffen werden kann. Bequemmerweise wurde ein 4-adriger Kabel verwendet, so dass ich keine zusätzlichen Strippen ziehen musste.

Die Schaltung ist denkbar einfach. Die schwarzen Leitungen gehören zu der bestehenden Installation, die blauen Teile im Schema dienen der Erkennung der Spannung an dem Gong und die orangenen erlauben dem FHEM auch selbst zu 'klingeln'. Die kleine Transistorschaltung dient als Invertor, denn Relaymodul low-aktiv schaltet und bei einem direkten Anschluss jedesmal nach dem Einschalten kurz 'klingeln' würde. Die letze Funktionalität habe ich jedoch (nach dem ich sie getestet habe) wegen ihrer offensichtlichen Sinnlosigkeit wieder abgebaut.

Ich bin noch nicht dazu gekommen, die Schaltung 'richtig' zusammenzulöten, daher ist alles noch auf dem Breadboard...

...und mit einer 'fliegender' Verdrahtung angeschlossen.

FHEM-Anbindung ist auch einfach:

# IO-Device
define FIRMATA FRM /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702514E-if00-port0@57600
attr FIRMATA alias Firmata-Controller

# Klingeln erkennen
define KlingelIn FRM_IN 12
attr KlingelIn IODev FIRMATA
attr KlingelIn alias Türklingel
attr KlingelIn stateFormat {"zuletzt: ".ReadingsTimestamp('KlingelIn','reading','')}

# Auf das Klingeln reagieren (Meldung versenden)
define n_tuer_gong notify KlingelIn:reading:.*on {sendMeJabberMessage("Tuerklingel am ".ReadingsTimestamp('KlingelIn','reading',''))}
attr n_tuer_gong comment Versand von Nachrichten beim Klingeln an der Haustuer

# Relay-Steuerung (Klingeln)
define KlingelOut FRM_OUT 11
attr KlingelOut IODev FIRMATA
attr KlingelOut stateFormat value

Zum Meldungsversand wird eine Funktion namens sendMeJabberMessage verwendet. Wie die Jabber-Integration vorgenommen wurde, werde ich evtl. ein anderes Mal beschreiben. Es ist aber wirklich nichts schwieriges. Bis dahin sei auf die Dokumentation des Jabber-Moduls verwiesen.

Der nächste logische Schritt ist natürlich die Anbindung einer Kamera. Damit weiß man nicht nur, dass jemand vorbei gekommen ist (dies ist an sich ja noch nicht wirklich hilfreich), sondern kann auch sehen, wer das eigentlich ist.

UPDATE:

Ich hatte schon seit Längerem vor, etwas Ordnung in meine Installation zu bringen. Die Sachen sollen in den Verteiler auf die Hutschiene. Also habe ich die Firmata-Technik in ein passendes Gehäuse eingebaut. Der lose USB-UART-Controller ist noch ein Provisorium und wird später ausgetauscht.

Die Beschriftung darf genausowenig fehlen, wie die LED-'Beleuchtung' (ich stehe auf Mäusekino ;-) )

Und hier die Innenansicht. Zugegeben etwas wild, aber eine 'richtige' Platine wegen eines eines Exemplars zu entwickeln, ist mir zu viel Aufwand.

TinyTX - Wireless Sensor Nodes

Details

Geschrieben von Alexander Schulz

Kategorie: Eigenbau

Veröffentlicht: 30. Januar 2014

Zugriffe: 45310

31.01.2014

Da ich gerne mal auch selbst Hand anlege, bin ich gerade dabei ein Funk-basiertes Sensor-System aufzubauen.
Hardwarebasis ist von hier: http://nathan.chantrell.net/tinytx-wireless-sensor/
Empfang z.B. mit einem JeeLink. Die Firmware habe ich leicht angepasst, an einem FHEM-Modul bin ich gerade dran.
Temp/Feuchte (DHT22) läuft prototypmäßig schon jetzt.

Die Module sind recht günstig (ca. 10 Euro), sparsam und zuverlässig. WAF ist jedoch (im aktuellen Zustand) noch nicht wirklich gut

Weiterhin in Planung: Luftdruck (BMP085), Licht (bh1750), Ultraschall-Distanz (hc-sr04), Bewegung, Bodenfeuchte, Regen etc.

Aber wie gesagt, das ist eher was für Bastler.

Vorerst ein Paar Bilder zu meinem aktuellen Projekt:

Der Prototyp läuft bereits und liefert Daten. Zum Testen habe ich daneben meinen Wandthermostat HM-CC-TC gelegt (untere Graphiken). So kann man die Werte gut miteinander vergleichen. Es zeigt sich, dass mein Tiny-Sensor wesentlich schneller reagiert und deutlich besser aufgelöste Daten liefert. Der Batterieverbrauch gibt allen Grund zum Optimismus ;)

05.03.2014

Outdoor-Prototyp (zusätzlich mit einem Lihtsensor, jedoch noch nicht in der Firmware implementiert)

Habe beide Prototypen daneben gelegt. Nach einer Weile waren die Module auf die gleiche Temperatur. Danach lagen auch die Luftfeuchtigkeitswerte sehr dich daneben.

06.03.2014

Der Einsatztest im Garten war seht ernüchternd. Die Reichweite blieb unter allen Erwartungen zurück. Interessanterweise funktionierte mein erster Prototyp bei einer noch größerer Entfernung weiterhin einwandfrei.Das ist ein deutlicher Hinweis auf die Antenne, denn der Rest ist weitgehend baugleich. 

Irgendwo im Netz habe ich gelesen, dass ein Wendel mit einem Durchmesser von 6mm, Länge von 20mm und 9,5 Wicklungen eine gute Antenne für 868MHz wäre. Dies ist die Antenne von dem zweiten Gerät. Der Erste verwendet eine Lambda/4 Antenne (86mm). Kürzung der Antenne bei dem Zweiten hat den Empfang verbessert. Ich werde weiter testen...

31.07.2014

Mittlerweile laufen bei mir mehrere dieser Module. Sehr zufriedenstellend.

Zum Empfang der Werte benutze ich einen JeeLink mit einer leicht modifizierter Standard-Firmware:
https://raw.githubusercontent.com/hexenmeister/FHEM_Sensor/master/GSD_TRX/GSD_TRX.ino
(Da wird lediglich dafür gesorgt, dass ein Funk-Paket mit einem bestimmten Marker extra ausgezeichnet wird.)

Dann die Firmware für die Module. Ich habe welche für DHT22-Sensor.
https://raw.githubusercontent.com/hexenmeister/FHEM_Sensor/master/GSD_DHT22/GSD_DHT22.ino
Ist auch weitgehend die Version von Nathan.
Die Modul-Adressen im Sketch sind für jeden Sensor einzeln zu definieren:

#define myNodeID 01       // RF12 node ID in the range 1-30
#define network 210       // RF12 Network group
#define myUID 01          // device id

Network soll überall gleich sein (und auch am JeeLink), myNodeId kann für alle Sensoren gleich sein. myUID muss eindeutig sein.
Ich arbeite auch an Erweiterung für Licht- und anderen Sensoren, komme aber aus zeitgründen nicht wirklich dazu...

Und nun das FHEM-Modul:
https://raw.githubusercontent.com/hexenmeister/MyFHEM/master/FHEM/36_GSD.pm

Die FHEM-Konfiguration:
Der JeeLink benötigt zusätzliche Attribute zum Erkennen von GSD-Clients:

define myJeeLink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A702GA5B-if00-port0@57600
attr myJeeLink Clients :GSD
attr myJeeLink MatchList {'6:GSD' => '^GSD'}

Die Sensoren werden beim Empfang automatisch in FHEM angelegt und erzeugen Einträge in der Form:

define GSD_1.1 GSD 1.1

Dabei ist 1.1 die Kombination aus myNodeID und myUID.

Steckbrett-Arduino

Details

Geschrieben von Alexander Schulz

Kategorie: Arduino / ATMEL

Veröffentlicht: 11. Januar 2014

Zugriffe: 40450

• Arduino
• Atmel

Das Herzstück eines Arduino, unabhängig von dem Modell, ist ein ATMEL-Microcontroller. Aktuelle Boards enthalten meist einen ATmega328p oder ATmega2560. Alles andere auf dem Board ist mehr oder weniger nebensächlich.

Mit einer DIP-Version (also nicht SMD) eines µC kann leicht ein Arduino-Clon auf einem Steckbrett aufgebaut werden. Man kann dies natürlich auch auf einer einegentwickelten PCB aufbauen, was eine kleine und günstige Schaltung ermöglicht.

Es muss ja nicht immer gleich ein ATmega sein. Manchmal reicht auch ein viel kleinerer Microcontroller, z.B. ein ATtiny84A. Ein ganzes Board ist es zwar nicht, aber mit etwas Vorarbeit doch ein 'echter' Arduino.

Bei diesem Microcontroller handelt es sich um die weitgehend kompatible Weiterentwicklung des ATtiny24. Der Baustein wird im Format DIP-14 mit folgender Pinbelegung gefertigt:

Auszug aus der Beschreibung des Herstellers:

• 120 Powerful Instructions – Most Single Clock Cycle Execution
• 32 x 8-bit General Purpose Working Registers
• Up to 20 MIPS Throughput at 20 MHz
• 8 K Bytes of In-System Self Programmable Flash
• 512 Bytes In-System Programmable EEPROM
• 512 Bytes Internal SRAM
• Write/Erase Cycles: 10,000 Flash/100,000 EEPROM
• One 8-bit Timer/Counter with Two PWM Channels
• One 16-bit Timer/Counter with Two PWM Channels
• 10-bit ADC
• USI – Universal Serial Interface
• Pin Change Interrupt on 12 Pins
• Low Power Idle, ADC Noise Reduction, Standby and Power-down Modes
• Internal Calibrated Oscillator
• 12 Programmable I/O Lines
• 1.8 – 5.5V Operating Voltage
• 210 μA at 1.8 V and 1 MHz (Active Mode)
• 33 μA at 1.8 V and 1 MHz (Idle Mode)
• 0.1 μA at 1.8 V and +25°C (Power-down Mode)

Umgemünzt auf die Arduino Pins egibt sich folgende Belegung:

Im Unterschied zu einem ATmega wird bei ATtiny wird kein Arduino-Bootloader benutzt. Die Programmierung erfolgt nicht über USB, sondern mit Hilfe eines Programmers.

Hier musste ich feststellen, dass mein Programmer (USBASP) nicht mit diesem µC kompatibel ist. Auf diese Idee kam ich aber erst nach etlichen Versuchen und Prüfungen/Austausch aller Kabel. Dann musste eben ein Arduino Mega (mit ArduinoISP Sketch) in die Bresche springen.

Die Verkabelung (Für UNO oder MEGA):

Bei der Verwendung des internen Oszillators werden keine weitere externe Bautele zum Betrieb des µC benötigt! So sieht es dann in etwa aus (LED ist natürlich zum Programmieren nicht notwendig, sie war jedoch nützlich für den ersten Test):

Bevor man anfangen kann, muss die ArduinoIDE für die Benutzung von ATtiny vorbereitet werden. Unter http://code.google.com/p/arduino-tiny/downloads/list lädt man die neueste Version des Plugins und installiert diese entsprechend der Anweisungen. Nach dem IDE-Neustart kann in dem Boards-Menü ein Eintrag für ATtiny84 ausgewählt werden. Mit dem Menüeintrag 'Bootloader installieren' wird der Chip für die erste Nutzung vorbereitet. Ein Bootloader wird dabei zwar nicht installiert, es werden jedoch die notwendigen "Fuses" gesetzt. Danach kann ein eigener Sketch auf den Microcontroller geladen werden (wieder mit dem ArduinoISP).

Zum ersten Test habe ich den Blink-Sketch verwendet. Jetzt habe ich einen HiTech-Blinklicht ;)

Läuft wunderbar auch mit einem Akku (tagelang):

Selbstverständlich kann ein Steckbrett-Arduino auch mit einem ATmega328p aufgebaut werden, wie auch bei einem UNO, Nano, Pro Mini etc.

Dieser µC in DIP-28 Form besitzt folgende Pinbelegung:

Dieser µC soll auch mit einem Bootloader versehen werden, dabei werden (je nach Boardauswahl) Fusen gesetzt. Bei einem 'richtigen' Arduino wird ein Crystal-Oscillator ('Quarz') verwendet. Aber es geht auch mit dem internen Taktgeber (8 MHz). Für den ersten Fall wählt man als Boars z.B.einem Arduino UNO, oder Pro Mini. Damit es mit einem Internen geht, muss dieses Modus der IDE bekannt zunächst gemacht werden (s. http://arduino.cc/en/Tutorial/ArduinoToBreadboard).

Verbindung zum Programmer:

Tests mit dem internen Taktgeber und mit einem 'Quatz':

Raspberry Pi: System überwachen mit SYSMON

Details

Geschrieben von Alexander Schulz

Kategorie: FHEM

Veröffentlicht: 06. Dezember 2013

Zugriffe: 55166

• Raspberry Pi
• Überwachung

SYSMON

Weil ich mit den RPiUtils nicht glücklich wurde und SYSSTAT nicht alles liefert und Installation eines zusätzlichen Perl-Moduls erfordert (Raspberry Pi: System überwachen (RPiUtils und SYSTAT)), habe ich beschlossen ein eigenes Modul zu erstellen.

Herausgekommen ist ein Modul, das eine Reihe von Systemstatistiken erfasst und zur Verfügung steht. Es liefert diverse Informationen und Statistiken zu dem System, auf dem FHEM-Server ausgeführt wird. Es werden nur Linux-basierte Systemen unterstützt. Nicht alle Informationen sind auf alles Systeme verfügbar. Bis jetzt getestet auf Raspberry Pi (Debian Wheezy), BeagleBone Black, Cubieboard 2, FritzBox 7390 und einigen anderen.

Weiterhin gibt es entsprechende Plot-Dateien zur grafischen Aufbereitung.

Installation und Nutzung

Das Modul ist mittlerweile ein Bestandteil der offiziellen FHEM-Distribution. Die aktuelle Beschreibung ist unter http://fhem.de/commandref_DE.html#SYSMON zu finden.

Diskussion zu dem Thema in FHEM-Forum: http://forum.fhem.de/index.php/topic,17201.0.html

Links

https://github.com/hexenmeister/MyFHEM/blob/master/FHEM/42_SYSMON.pm

(https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/42_SYSMON.pm)

Plots unter: https://github.com/hexenmeister/MyFHEM/tree/master/www/gplot

(https://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/www/gplot/)