RFM12 Hausautomatisierung - Hat jemand Erfahrungen?

Benedikt K. hat sich um die RFM Module besonders verdient gemacht und 
damit ganze Netzwerke aufgebaut:

Beitrag "Beispielprogramm für RFM12 433MHz Funk-Module"
http://www.mikrocontroller.net/articles/AVR_RFM12

Da ist sicher was für dich dabei.

Tom M. schrieb:

> SNAP passt nicht in diesen Kontext.

Doch, paßt schon...

> (Ich kenne SNAP als Bestandteil der Ethernet Spezifikation,
> es dient dazu anzuzeigen, welches höhere Protokoll im
> Ethernet Frame transportiert wird).

Hier war S.N.A.P. gemeint, das Scalable Node Address Protocol:
http://www.hth.com/snap/

Zum Thema Hausautomatisierung mit RFM12 gibt es unter http://jeelabs.org 
einen sehr guten Blog (+ Webshop).

Hallo Sebastian,

ich hatte vor einigen Jahren ähnliche Anforderungen, wie die von Dir 
beschriebenen. Mein Anspruch war allerdings, möglichst alles bis ins 
letzte Detail selbst zu programmieren / entwerfen, daher wollte ich 
keine fertigen Lösungen verwenden.
Hier im Forum wirst Du viele Informationen zu allen möglichen 
Anwendungen mit den RFM12 finden, schau am besten auch mal bei 
roboternetz.de vorbei, dort sind im Wiki viele der 
Initialisierungsparameter dokumentiert.

Zu Deinen konkreten Fragen: Auf jeden Fall empfehle ich, ein 
bidirektionales Protokoll zu verwenden. Ich habe da einige nervige 
Erfahrungen mit den FS20-Geräten machen müssen. Selbst, wenn man Befehle 
zur Sicherheit mehrfach aussendet, weiß man letzten Endes doch nie, ob 
er nun wirklich angekommen ist. Und das kann je nach Steuerungsvorgang 
sehr schlecht sein.
Bei mir war die Implementierung irgendwann zeitlich aus dem Ruder 
gelaufen, so dass ich (auch im Hinblick auf den WAF-Faktor) dann 
zunächst doch zu einigen fertigen Komponenten gegriffen habe (FS20, 
HomeMatic, IP-Symcon). Nach und nach implementiere ich jetzt eigene 
Dinge, zur Zeit laufen hier immerhin zwei Radar-Bewegungsmelder, die 
über RFM12 an einen PC die Bewegung melden. Am PC hängt ebenfalls ein 
RFM12/AVR über RS232. Das Auswerten mache ich derzeit mit PHP-Scripten 
in IP-Symcon. Es wird dadurch die Beleuchtung in zwei Räumen gesteuert, 
die Aktoren sind allerdings (noch) HomeMatic-Geräte.
Ich empfehle, einfach mal anzufangen, zwei bis drei Testgeräte 
aufzubauen, die Du auch mal z.B. in verschiedenen Räumen aufstellen 
kannst. Dabei wirst Du sicher schon auf erste Probleme stoßen, zu denen 
Du dann hier konkrete Fragen stellen kannst.
Aber ein fertiges, tolles Referenzprojekt, das Deinen Anforderungen 
entspricht, habe ich bislang selbst nicht gefunden. Und meine eigene 
Lösung ist noch nicht fertig, werkel derzeit an der Verschlüsselung.

Gruß, Martin

Edit: Typos

Sebastian Engel schrieb:
> Wir möchten gerne eine Hausautomatisierung auf Funkbasis mit RFM12
> Modulen aufbauen.
> Leitungen ziehen ist leider nicht möglich.
> Darüber hinaus soll das ganze System komplett Rückbaubar sein.

Du musst Dir im klaren sein was das für ein Aufwand (Zeit) bedeutet.
Ich hab z.B. auch ein Mischbetrieb laufen mit Homematic und RFM12B 
Modulen.
Homematic für alle Licht Ein/Aus Aufgaben und RFM12 für Spezialaufgaben 
für alles was es von Homematic nicht gibt bzw. man flexibler mit RFM12B 
ist(z.B. Temperatursensor mit Solarzelle drauf + LI-Ion Batterie und 
RFM12B, Stromzähler Modul mit S0 + RFM12B, Gaszähler Modul mit 
Reed-Switch +RFM12B.......)

Da muß ich auch meinen Senf (in Form von Fragen) dazugeben.

Ich habe mir 4 dieser Transceivermodule (868 MHz) in der Bucht gekauft 
(art. Nr. 140919624451) und will ein wenig damit "rumspielen". Ziel ist 
ebenfalls einen Vernetzung von Sensoren und Aktoren im Haus.

Frage 1: Laufen diese Modülchen so wie sie sind, oder muß ich da eine 
Antenne mit Anpassung dranbasteln?

Frage 2: Mich interessiert irgendwie das FS20 Protokoll, für das es 
fertige Snesoren/Aktoren gibt. Können die RM12-Module dieses Protokoll 
empfangen? Und/oder gibt es andere Billigsensoren auf China, die damit 
empfangbar/steuerbar sind? Falls nicht, auch kein Beinbruch, ich habe 
mal ein eigenes Protokoll spezifiziert, aber dann müßte ich halt alles 
selber bauen. Vorteil wäre: Was nicht veröffentlicht, kann nicht gehackt 
werden.

(Leider ist meine HF Erfahrung mehr als gering... insb. bei über 10 MHz, 
daher hoffe ich mal, daß ich auf der HF Seite nicht basteln muß. )

Ich werde mit den Tests in 3..4 Wochen anfangen können. Meine 
Erfahrungen teile ich hier dann gerne mit.

Viele grüße

Yogy

Danke, super.

Davis schrieb:
> 1. Stück Draht (z. B. 17 cm).

Nicht bei 868 MHz, da ist Lambda rund 35 cm. Eine Lambda/4 Antenne also 
nur ca. 8-9 cm. Gut geeignet für die 868 Mhz Module sind Antennen aus 
alten CT1 Schnurlostelefonen, die Fehlanpassung ist akzeptabel bei den 
paar mW.

Kleines Update: Habe dank der hier angegebenen vielfältigen Links eine 
Datenübertragung (kleiner Test mit zwei Modulen aber nur einem 
Prozessor) im "Standard" FSK laufen.  **happy**

Als nächstes werde ich zwei Prozessoreinheiten nehmen, dann kann ich 
auch die Reichweite testen.

An FS20 gebe ich mich dann mal ran, wenn ich Zeit habe... Im 
Frühjahr/Sommer nehmen mich zumeist Renovierungsarbeiten und Frondienste 
im Garten in Anspruch...

Das ist mir schon klar.. gibt es denn bezahlbare Funksensoren 
(Bewegungsmelder etc) mit dokumentiertem, RF12B tauglichem Protokoll?

Natürlich könnte ich das alles selber bauen, aber: 1. Mechanik (der 
Horror jedes Elektronikers) 2. Stromversorgung (Energiesparend)  3. 
weitere HW und SW Arbeiten mit notwendigen EW-Tools für die 
Controller.... Gut, ich hätte da Tolls für PIC16C/F84 oder für den 
AVR2313 (so hieß er doch??).. Tiny müßte dann auch gehen...

Lieber Kopfkratzer,
danke für Deine Ausführungen.

Ich habe einige Busprotokolle (mit) spezifiziert, zum Beispiel den 
Batteriebus der deutschen Batterieindustrie / ZVEI, der im BiCat 
verwendet wurde oder noch wird (1992) und auch ein 
Hausautomatisierungsprotokoll (1993). Letzteres lief ursprünglich über 
einen "Eindrahtleitung" (Coax), später RS485 und seit 2 Jahren auch über 
TCP/IP. Ist also alles vorhanden. :-)

Mir geht es im Moment mehr ums Spielen und die kostengünstige 
Einbeziehung von Funksensoren.

Hanns-Jürgen "Yogy" Mostert schrieb:

> Natürlich könnte ich das alles selber bauen, aber: 1. Mechanik (der
> Horror jedes Elektronikers) 2. Stromversorgung (Energiesparend)  3.
> weitere HW und SW Arbeiten mit notwendigen EW-Tools für die
> Controller.... Gut, ich hätte da Tolls für PIC16C/F84 oder für den
> AVR2313 (so hieß er doch??).. Tiny müßte dann auch gehen...

Ein paar RFM12B Module kombiniert mit ATEMGA's sind keine große 
Herausforderung. Es gibt auch jede Menge Beispiele dazu in diesem Forum 
und im Web.

Und warum nimmst Du nicht gleich sowas wie Homematic ?

Hi Markus,

viele Wege führen nach Rom. Und sicher ist es "einfacher", auf etwas 
Bestehendes zurückzugreifen.

Der Einsatz von "fertigen" Systemen läuft mir allerdings immer etwas 
gegen den Strich, da ich gerne meine Vorgaben verwirklicht sehen möchte. 
Das ist nur mit offenen Systemen möglich, ob das "Homematic" bietet, 
weiß ich nicht.

Beispiel: Meine Heizung hat drei Heizkreise pus Brauchwasser, die damals 
von einem Landis & Gyr Regler geteuert wurde. Da ich das gerne vom PC 
aus fernsteuern wollte bat ich Landis um Freigabe des 
Schnittstellenprotokols. Dies wurde mir (natürlich) verweigert. 
Daraufhin habe ich die ganze L & G Schei*e rausgeschmissen und selber 
eine Steuerung entwickelt. Nebeneffelt: 15...20 % Öleinsparung durch 
eine nun völlig flexible Steuerung der Anlage. Aber das nur am Rande.

Ich sehe die ganze Geschichte (noch) als Bastelei und Zeitvertreib, 
einen konkreten Plan habe ich (noch) nicht, So habe ich mich in der 
jüngeren Vergangenheit mit Ethernet-Modulen, WLAN Modulen, GSM-Modulen 
und mit TFT Displays beschäftigt.

Viel Grüße

Yogy

@eku Super, danke.

@eku

unter LINUX braucht man einen Compiuler, der unter LINUX läuft, unter 
Winddof einen für Windoof. Der Sourcecode ist (soweit ich gesehen habe) 
in "C", und dem ist es völlig egal, wer ihn compiliert.

Ich nehme mal an, das funzt alles ganz vortrefflich mit dem AVRStudio 
(Windows)

Dem Sourcecode (für AVR) ist es völlig wurscht, wer wann wo und womit 
ihn kompiliert.... Du brauchst nur den passenden (Cross-)Compiler. Bei 
ATMEL kannst Du Dir AVRStudio 6.0 kostenlos herunterladen... Läuft bei 
mir unter WINDOOF 7.  BINUTLS und GCC brauchst Du beim Studio 6.0 
ohnehin nicht mehr zu installieren. Du brauchst nur einen Programmer, 
z.B. DIAMEX für knapp 20 Euros

Die SW (nicht der Compiler) soll doch später auf einem AVR-Prozessor 
laufen, oder habe ich das falsch verstanden?

Und warum installierst Du Dir nicht einfach ein Linux dafür, ggf. in 
einer virtuellen Maschine?

Hast Recht, was soll also Deine Bohrerei zu Ethersex und Windows, wo 
dieser Thread doch eigentlich ein ganz anderes Thema hat?

@Hubtau

sollte Routinen daraus benötigen, kann ich sie dann gerne posten.

Nur, was soll das? C ist C, H ist H. Also, ohne mir das hier genauer 
anzusehen, reicht es doch, die h und c Files in das Studio-Projekt zu 
kopieren. Und natürlich nicht das makefile vergessen. Das wäre dann IMHO 
das einzige, das angepaßt werden müßte.

Aber wie gesagt, ich habe mir das ETHERSEX Projekt (noch) nicht genauer 
angesehen. Und da ich nur Hinweise zu FS20 suche.... BTW: Damit SW 
"meinen" Normen und Vorstellungen entspricht, schreibe ich ohnehin 
üblicherweise alles "neu", ich nutze dann nur die Parametervorgaben und 
die grobe Struktur des Algorithmus bzw. teste sie. Ich nehme mal an, das 
sieht auch wieder jeder anders.

Also lassen wir doch die müßige Diskussion an dieser Stelle. (siehe auch 
rmax)

Falls es interessiert: RFM12B aktuelle Tests

Modul 1 sendet die Daten, aktuell: Temperatur.
Modul 2 empängt die Daten und zeigt sie an.

Innerhalb meines Hauses schaffe ich maximal testbare Entfernung von rund 
17 m vom 1. OG in den Keller (Betondecken). Messung außen von meinem 
ARbeitsplatz (Sendet) durch zwei Wände 10 m innerhalb des Hauses und 
dann noch 50 m freies Feld. Größere Distanz konnte noch nicht getestet 
werden...

Antenne "Stück Draht" 8,5 cm bei 868 MHz.

Die 5-Euro Dinger sind viel besser als gedacht!

Ist zwar keine "Haus"automatisierung, aber eine kleine für die Wohnung, 
alles mit RFM12 433MHz
- Innentemperatur
- Temperatur Fußboden
- Aussentemperatur
- Fensterzustand (Balkontür) / Helligkeit
- Temperaturregelung FBH für das Wohnzimmer / Einschalten der Heizung 
Bad zu bestimmten Zeiten
- Anwesenheitsdetektor per Bluetooth (eigentlich: ist mein Handy in 
Reichweite, wobei die BT Reichweite nicht so toll ist)
- Radiowecker
- Internetverbindung für Abfrage Google Kalender (Weckzeiten, Urlaub, 
Anwesenheit), zentrale Uhrzeit NTP  und vorbereitet für Weboberfläche

Es gibt keine Zentrale, alle Geräte werten die gesendeten Informationen 
für sich aus.
Ich verwende kein Handshake, bis auf die Temperaturfühler aussen/FBH und 
Fenster machen aber alle Geräte "listen before talk".
Die Informationen werden mehrfach gesendet bzw. wenn mal eine Temperatur 
verloren geht dann reicht auch die nächste nach 5 Minuten.
Ich schalte Geräte  Licht  Temperatur mit Elro Funksteckdosen, z.b. 
Licht ab bestimmter Helligkeit, abhängig von der Anwesenheit meines 
Handys ;-)
Bestimmte Standby Geräte werden ebenfalls erst eingeschaltet wenn mein 
Handy erkannt wurde.

Über einen RFM12 USB Stick empfängt ein PC Temperaturwerte / 
Heizungszustand zur Auswertung.

Alles eine nette Spielerei, speziell auf meine Wünsche zugeschnitten, 
nichts professionelles, es macht aber Spaß.

Holger

@holgerw

Sehr interessant..tolle Ideen.

 Habe ich das richtig verstanden? Die Sensoren senden ohne Aufforderung 
"drauf los" und bestimmte andere Module reagieren darauf. Da sind 
Kollisionen zu erwarten. Du schreibst, die Sensoren senden die Daten 
mehrfach... Hast Du ein bestimmtes Verfahren (Zufallszähler) für die 
neuaussendungen? Werden Kollisionen detektiert? In welchen Zeitabständen 
senden die Sensoren? und wie oft/in welchen Zeitabständen wird die 
Sendung wiederholt? Sind Deine Sensoren batterieversorgt? Lebensdauer? 
Prozessor AVR oder PIC oder sonst was?

Ich selber verwende bislang ein verdrahtetes System mit einem Master 
(Zentrale), der die einzelnen Slaves abfragt. Dadurch habe ich kein 
Kollisionen, jedoch müssen die Module Senden und Empfangen können. Ich 
überlege nun, einige Außensensoren (Bewegungsmelder etc) einzusetzen, 
die batterieversorgt sein müssen..

Viele Grüße

yogy

Hallo yogy,

ja das ist richtig, die batteriebetriebenen Module senden ca. aller 5 
Minuten einfach drauf los.
Empfangsroutinen sind dort nicht implementiert.
Kollisionen werden nicht detektiert. Es wird nur gemeldet, wenn ein 
Sensor nicht mind. aller 30 Minuten einmal gemeldet hat.
Alle anderen machen LBT (listen before talk), das gibt eine für mich 
ausreichende Sicherheit.
Wenn ein Modul etwas gültiges empfängt, wartet es mindestens 3 Sekunden 
+ eigene ID in Sekunden bevor es selber senden würde, also der Luftraum 
frei ist ;-)
Die Datendiagramme sind zwischen 5 und 25 Bytes lang, also auch recht 
kurze Übertragungszeiten.

Befehle für die Funksteckdosen werden 3x gesendet, im Abstand von 10 
Sekunden.
Je nach LBT verschiebt sich das auch mal.
Ich habe eine Funksteckdose auch mal umgebaut mit RFM12, allerdings sehe 
ich den Aufwand zum Nutzen noch nicht.
Andere Informationen werden zyklisch abgefragt bzw. gesendet, Zeiträume 
zwischen 5 und 15 Minuten bzw. bei einem Statuswechsel sofort.

Alles basiert auf PICs, hier kommt der 18F25K22 für die 
batteriebetriebenen Module zum Einsatz.
Der PIC ist überdimensioniert, aber für diese Gruppe hab ich die 
Routinen fertig da.
Temperaturfühler ist ein TSIC306.
Mit 4 AA Batterien reichen die Sensoren etwa 8 Monate, gesendet wird ca. 
aller 5 Minuten.
Ich weiss das ist nicht sehr lange, aber ich bin zufrieden damit. Da 
wäre vermutlich noch einiges rauszuholen.
Die Batteriespannungsüberwachung mit dem RFM12 steht noch auf dem Plan, 
so dass man rechtzeitig reagieren kann.

Protokoll hab ich mir wie folgt ausgedacht:
Länge | Befehl | SenderID | n * Nutzdaten | prüfsumme_high | 
prüfsumme_low
Der Befehl kann ein INFO  COMMAND oder ASK sein, danach der Typ (in 
einem Byte verschlüsselt).
So kann z.b. die Temperaturregelung in Abständen das aktuelle 
Datum/Uhrzeit anfordern:
ASK DATUM  und zurück kommt INFO DATUM
Hier fällt mir gerade auf das es doch so etwas wie Handshake gibt, 
bekommt der Fragende kein Datum versucht er es aller 5 Minuten immer 
wieder.

Wenn der PC läuft werden alle Funkinformationen geloggt sowie die 
Temperaturen in ein Diagramm übertragen.
Ist der PC aus werden die Temperaturen im Temperaturregler selber aller 
15 Minuten gespeichert und wenn der PC wieder eingeschaltet ist holt er 
diese Informationen dann ab. Da mir der Speicher im PIC fehlt muss er 
das aller 24h einmal machen, sonst gehen Daten verloren.

Holger

Zur Reichweite mal noch.
Ich hab ein Modul mal so programmiert, dass es jede Sekunde einen 
hochlaufenden Zähler sendet. In meinen 70qm kein Problem, allerdings 
alles nur "Pappwände".
Dann ab ins Treppenhaus und 3 Etagen langsam herunter. Nach 2 Etagen 
wurde der Empfang erst schlechter.
Haus ist 1999 gebaut, vermutlich Stahlbetondecken.

Ich sende auf einer von 433.92 etwas abweichenden Frequenz, aber noch im 
zulässigen Bereich.

Holger

Hi Holger,

danke für die ausführliche Beschreibung. Die Idee, die Modul-ID mit der 
Wartzeit zu verknüpfen, finde ich klasse.

Ich habe von einem früheren Projekt hier noch eine ganze Reihe PIC 16F84 
herumliegen, mal sehen, vlt. veruche ich mal, damit einen einfachen 
Sensor aufzubauen, falls die mit 3,3 V laufen.

Bez. Batteriecversorgung "trüme" ich von einer CR2032-Knopfzelle, die 
das System mind. 1 Jahr am Leben erhalten soll... mal sehen, ich werde 
berichten.

Leider wird das einige Monate dauern, da ich jetzt erstmal andere Dinge 
zu erledigen habe...

mfg Yogy