Guten Morgen! 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. Es soll erstmal folgende Funktion ermöglicht werden: Pro Raum ein Rolloschalter. Dieser verschwindet in einer UP Dose und ersetzt den standard Hoch-Runter-Taster. In die Blindabdeckung soll ein kapazitiver Sensor integriert werden. Es gibt eine Zentrale, worüber alle Rollos gefahren werden. Auch in Abhängigkeit von Licht und/oder Uhrzeit. Die Zentrale soll später erweitert werden um Licht- und Temperatursteueraufgaben auszuführen. Nun bin ich dabei den "Funkbus" zu planen. Die Leistung eines RMF12 (433 Mhz) ist absolut ausreichend (getestet). Nun stellt sich mir die Frage, wie verhindere ich kollisionen auf dem Funkband. Im Netz gibt es genügend Beispiele für eine Peer-to-Peer Funkkommonikation, aber ich habe noch keins gefunden wo ein System mit mehrern Sendern und Empfängern detailiert vorgestellt wird. Es begrenzt sich meistens auf "Funksystem mit mehreren RFM12 und SNAP Protokoll", ohne weiteren Details. Reicht eine unidirektionale Verbindung oder sollte man bidirektional funken? Hat jemand erfahrung mit mehreren RFM12 Funkquellen? Kennt jemand noch eine gute Webseite zu dem Thema? Gibt es eine art Referenzprojekt zur kombination RFM12 + AVR + SNAP? Ich hoffe ihr könnt mir ein wenig weiterhelfen. Danke und Gruß! Sebastian
Sebastian Engel schrieb: > Die Leistung eines RMF12 (433 Mhz) ist absolut ausreichend (getestet). > Nun stellt sich mir die Frage, wie verhindere ich kollisionen auf dem > Funkband. Du kannst sie nicht verhindern, weil du keine Kontrolle über alle Sender in diesem Frequenzband hast. Wahrscheinlich funkt auch der Autoschlüssel des Nachbarn auf dieser Frequenz, uvm. Es gibt Strategien/Algorithmen wie CSMA/CD und CSMA/CA oder auch Token basierte Verfahren. Alle haben ihre Vor- und Nachteile. Thema generell ist "media access control", MAC. Sebastian Engel schrieb: > Es begrenzt sich meistens auf "Funksystem mit mehreren RFM12 und SNAP > Protokoll", ohne weiteren Details. SNAP passt nicht in diesen Kontext. (Ich kenne SNAP als Bestandteil der Ethernet Spezifikation, es dient dazu anzuzeigen, welches höhere Protokoll im Ethernet Frame transportiert wird).
>wie verhindere ich kollisionen auf dem Funkband.
Du brauchst Transceiver-Module. Beim Senden läßt du den Empfang auch vom
"Master" bestätigen.
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
1. Stück Draht (z. B. 17 cm). 2. FS20 ist möglich, wird aber nicht direkt unterstützt. Infos zu 1 & 2: http://jeelabs.org/2009/04/29/rfm12-vs-rfm12b/
Gut zum Experimentieren mit RFM12 bei Haussteuerungen eignet sich diese Platine http://www.shop.robotikhardware.de/shop/catalog/product_info.php?products_id=268 Beinhaltet neben RFM12 gleich den Controller und paßt überall rein. Ich hab damit gute Erfahrungen gemacht, innerhalb des Hauses gibt es keinerlei Funkprobleme, selbst dickste Kellerwände stören nicht.
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...
Hanns-Jürgen "Yogy" Mostert schrieb: > An FS20 gebe ich mich dann mal ran, wenn ich Zeit habe... FS20 würde ich nicht einsetzen, da es keine Rückmeldung gibt.
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...
kopfkratz Also was Du benötigst ist ein eigenständiges Protokoll das Dir eineindeutig die Zugehörigkeit zu Deinen Modulen zeigt. Ich persönlich würde das so realisieren das Du eindeutige IDs vergibst die jedes Modul auswertet, z.B. "MeinHausbusInnerGarage" als Haupttoken und dann die einzelnen Module durchnummerieren. Wenn Du paranoid bist und eine Herausforderung willst, dann verwende eine Verschlüsselung die pro Modul einen eigenen PrivateKey hat und deswegen auch ausschließlich vom adressierten Modul entschlüsselt und ausgeführt werden kann. Ansonsten sollte ein einfaches Handshake reichen, also Master sendet an "MeinHausbusInnerGarage"001 den Befehl "LichtAus", nach einem Timeout von xy Sekunden sendet er wieder und wenn dann das Modul "MeinHausbusInnerGarage"001 dem Master "MeinHausbusInnerGarage"000 zurücksendet "LichtAus" ist es erledigt. Das ist unabhängig vom Übertragungsweg.
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.
> Das ist mir schon klar.. gibt es denn bezahlbare Funksensoren > (Bewegungsmelder etc) mit dokumentiertem, RF12B tauglichem Protokoll? Nicht das ich etwas kenne. Allerding habe ich vor Jahr und Tag in den Weiten des Internets ein Projekt gesehen, bei dem eine vorhandene Hardware (Funktsteckdose) mit einem neuen Funkmodul ausgestattet wurde.
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
Ethersex sendet und empfängt seit neuhesten auch FS20/FHT u.a. über RFM12: http://ethersex.de/index.php/RFM12_FS20
eku schrieb: > Ethersex sendet und empfängt seit neuhesten auch FS20/FHT u.a. über > RFM12: > > http://ethersex.de/index.php/RFM12_FS20 Sehe ich das richtig, dass das Projekt nur für Linux ausgelegt ist? Oder kann man "ethersex" auch unter Windows compilieren?
@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)
> Ich nehme mal an, das funzt alles ganz vortrefflich mit dem AVRStudio > (Windows) Da bin ich skeptisch. Von Windows ist nirgends die Rede: http://ethersex.de/index.php/Quick_Start_Guide/Preparation
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
Hanns-Jürgen "Yogy" Mostert schrieb: > 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 Zum Spass habe ich mir das Ethernet Projekt von github geladen. Stolze 10 MBytes warten auf die Verarbeitung. Zum Beispiel das angehängte Konfigurationsfile. Bleibe skeptisch.
Die Empfehlung der Entwickler ist eindeutig: http://old.ethersex.de/index.php/Voraussetzungen#Windows Unter Windows wird das nichts.
Darf ich mal kurz die Frage zwischenrein werfen, ob die RFM12B-Module ne Funkzulassung haben? Ralf
Die SW (nicht der Compiler) soll doch später auf einem AVR-Prozessor laufen, oder habe ich das falsch verstanden?
Hanns-Jürgen "Yogy" Mostert schrieb: > Die SW (nicht der Compiler) soll doch später auf einem AVR-Prozessor > laufen, oder habe ich das falsch verstanden? Hast du richtig verstanden. Nur versuche einmal aus dem ganzen Wust die Quellen die C-und H-Dateien zu isolieren. Das dürfte - wenn es überhaupt geht - nicht einfach sein. Kein Wunder, dass man im Internet zu Windows & Ethersex nichts findet. Oder anders fomuliert: Wenn es für dich einfach ist, dann freue ich mich, wenn du die Quellen fürs Windows AVR-Studio übersetzungsbereit postest.
Und warum installierst Du Dir nicht einfach ein Linux dafür, ggf. in einer virtuellen Maschine?
R. Max schrieb: > Und warum installierst Du Dir nicht einfach ein Linux dafür, ggf. in > einer virtuellen Maschine? Darum geht es in dieser Diskussion nicht (siehe oben).
Hast Recht, was soll also Deine Bohrerei zu Ethersex und Windows, wo dieser Thread doch eigentlich ein ganz anderes Thema hat?
R. Max schrieb: > Hast Recht, was soll also Deine Bohrerei zu Ethersex und Windows, wo > dieser Thread doch eigentlich ein ganz anderes Thema hat? Natürlich habe ich recht, das bedarf keiner weiteren Erwähnung.
@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)
Hanns-Jürgen "Yogy" Mostert schrieb: > @Hubtau > > sollte Routinen daraus benötigen, kann ich sie dann gerne posten. Darauf werde ich zurückkommen > 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. Am Wochenende werde ich versuchen, die Quellen so aufzubereiten, dass sie mit AVR-Studio kompiliert werden können. > 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. Über FS20 bin ich auch das Ethersex-Proket gestoßen und habe mich dann hier bedient (http://jeelabs.com/products/jeenode). > Also lassen wir doch die müßige Diskussion an dieser Stelle. (siehe auch > rmax) In diesem Sinne. EOT.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.