Hallo zusammen, ich überlege schon seit längerem mein Heim zu vernetzen. Leider sind viele der aktuellen Geräte sehr teuer und/oder keine Open Source Protokolle. Daher (und weil ich Technik begeistert bin) wollte ich mir daher eigene Geräte bauen inklusive Protokoll. Das Ganze wollte ich das nach und nach erweitern und veröffentlichen. Ich schildere euch jetzt meine Ideen und würde mich sehr freuen, wenn ihr Vorschläge und Infos beisteuern würdet. Also fangen wir an. HARDWARE: Als empfehlenswert hat sich meiner Meinung nach die 868MHz Frequenz heraus gestellt. Daher würde ich diese benutzen. Nun benötige ich als erstes einen Transceiver, welcher Daten auf Basis der 868MHz Frequenz senden und empfangen kann. Habt ihr hier Vorschläge, welche Chips (Platinen) Preis-Leistungsmäßig zu empfehlen wären? Und worauf sollte man achten? Aktuell ist mir nicht ganz klar, wo ich mein späteres Protokoll implementieren werde/muss. Geschieht das auf dem Transceiver, oder was übernimmt diese Aufgabe? Die fertige Transceiver-Platine soll vorerst (bei mir) auf einem Raspberry PI aufgesteckt werden. SOFTWARE: Das Protokoll wird (so nehme ich an) auf einem Chip implementiert. Hier wird es sicherlich auf eine Implementierung in C hinaus laufen. Folgenden Aufbau sollte das Protokoll besitzen: - HEADER - - HEADER SIZE - - BODY SIZE - BODY - - PAYLOAD - - SENDER ID - - RECEIVER ID - - CHECKSUM Eine genauere Spezifikation wird denke ich nach und nach entstehen. Aber habt ihr bereits jetzt Vorschläge? Da ich selbst Softwareentwickler bin macht mir der Hardware Teil mehr Sorgen. Daher bin ich für jede Hilfe/Info dankbar. Mir ist bewusst, dass es sich hierbei um ein großes Vorhaben handelt, aber ich denke, dass es dennoch kein Unmögliches Vorhaben ist. Daher bin ich für Vorschläge und Kritik durchaus offen. Mit freundlichen Grüßen Thomas
Von der Bauform an sich hatte ich mir sowas in der Art vorgestellt: https://www.rasppishop.de/ENOCEAN-PI-868-Das-868MHz-Transceiver-Modul-fuer-Raspberry-Pi Sprich Aufsteckmodul für einen PI und einer Kabelantenne (um die Bauform kleiner zu halten. Dieses Modul hier klang interessant, ist aber durch die PCB Antenne recht groß in den Maßen: http://de.farnell.com/microchip/mrf89xam8a-i-rm/module-rf-transciever-868mhz/dp/1875307?st=868MHz%20Trensceiver
Thomas schrieb: > Als empfehlenswert hat sich meiner Meinung nach die 868MHz Frequenz > heraus gestellt. Daher würde ich diese benutzen. Es gibt nicht „die 868MHz Frequenz“, sondern das SRD-Band (SRD: Short Range Devices, in den deutschen Bestimmungen „Kurzstreckenfunk“ genannt) ist einige Megahertz breit und alles andere als homogen. Die einzelnen Sub-Bänder haben dabei unterschiedliche Bestimmungen hinsichtlich Bandbreite, Kanalbelegung (Duty cycle) und maximal abgestrahlter Leistung. > Nun benötige ich als erstes einen Transceiver, welcher Daten auf Basis > der 868MHz Frequenz senden und empfangen kann. Ja. :) > Habt ihr hier Vorschläge, welche Chips (Platinen) Preis-Leistungsmäßig > zu empfehlen wären? Ist jetzt die Frage, was für dich „Preis-Leistung“ ausmacht. Typischerweise ist man als Hersteller ziemlich frei, wieviel „Intelligenz“ man hier in der Hardware implementiert, und welchen Anteil man der Software überlässt. So richtig kenne ich mich hier nur mit den Atmel-Transceivern aus (für deinen Frequenzbereich wären das AT86RF212 und AT86RF215), sie implementieren einen guten Teil des IEEE-802.15.4-Standards dabei in der Hardware. Die Software agiert dabei auf der Ebene, dass sie die zu versendenden Frames zusammenstellt und dem Transceiver übergibt. Dieser versendet sie, auf Wunsch auch mit Bestätigung und einer wiederholten Übertragung, falls die Bestätigung nicht eintrifft. Der Empfänger bekommt dann im Erfolgsfall den kompletten Frame in die Software hochgereicht. Um Dinge wie die Synchronisation auf Ebene der HF-Schnittstelle etc. muss sich die Software nicht kümmern. Adressierung und CRC sind ebenfalls in Hardware realisiert, natürlich musst deine Software die passenden Adressen mit im Frame hinterlegen, damit er sein Ziel erreicht. Im Vergleich zu den einfachsten Transceivern bezahlt man halt einen Euro oder zwei mehr für die Hardware.
Thomas schrieb: > Dieses Modul hier klang interessant, ist aber durch die PCB Antenne > recht groß in den Maßen 868 MHz sind 35 cm Wellenlänge. Alle Strukturen kleiner als ca. 10 cm bedeuten daher einen mehr oder minder hohen Verlust in der Abstrahlung.
Ich schlage den Einsatz des Transceivers RFM12B oder RFM69 vor. Die Module sind günstig und können von einem Microcontroller (beispielsweise ATtiny oder ATmega) einfach angesteuert werden. Hier gibt es bereits fertige Lösungen. https://lowpowerlab.com/shop/product/99 Eine Empfängerplatine mit dem gleichen Transceiver auf dem RPi empfängt die Daten, die dann auf dem RPi weiterverarbeitet werden. Dazu eignen sich Node-Red oder Homeassistant. Zu diesen Themen gibt es viele Infos und Projekte im Web.
Vielen Dank für deine Antwort.
> Ist jetzt die Frage, was für dich „Preis-Leistung“ ausmacht.
Ich habe mir mal eben die beiden Chips angesehen. Ja diese liegen
natürlich voll im Preis. Solange ich am ende mit der fertigen
Transceiver-Platine bei ca. 20 € raus komme, ist alles super. Wenn es
was mehr ist auch nicht schlimm.
Ich werde mich derweil mal mit den beiden Chips vertraut machen. Dann
werden bestimmt weitere Fragen auftauchen. Aber schon einmal vielen
lieben dank.
Die RFM69 kann ich auch empfehlen, nutze die für den gleichen Zweck. Da kann man 66 Byte in ein Fifo schreiben und die so am Stück versenden. Eine einfache Adressierung für Netze mit mehreren Nodes haben die auch sowie eine Verschlüsselung in HW. Die Module sind Transceiver, d.h. die können Senden/Empfangen und man kann die Kommunikation bidirektional machen um zB Schaltbefehle bestätigen zu lassen. Auf dme RPi läuft bei mir ein Gateway, die RFM Messages werden in einen MQTT Broker geschrieben und das wird die Brücke zur Softwareseite der Automatisierung/Visualisierung. Da der RPi eine SPI Schnittstelle hat kann man einen einfachen Adapter verwenden: https://oshpark.com/shared_projects/36EsiJqR und die Kommunikation auf dem RPi in Software implementieren. Die Nodes habe ich mit LPC8xx gebaut, es gibt aber auch neben den genannten Moteinos noch JeeLab Nodes oder Projekte auf Tindie.com, https://www.tindie.com/search/?q=rfm69
Johannes S. schrieb: > Verschlüsselung in HW Wobei man das mit Vorsicht genießen muss: der Dreh- und Angelpunkt bei Verschlüsselung ist das Austauschen der Schlüssel. Außerdem ist eine verschlüsselte Verbindung ohne kryptografische Authentisierung ziemlich wertlos, weil dann jeder andere eine simple Replay-Attacke starten kann, ohne das Schlüsselmaterial selbst kennen zu müssen. Wenn man sowas haben will, öffnet man eine Box der Pandora … Kurz die Unterschiede zwischen AT86RF21x und dem RFM69 skizziert:
1 | RFM69 AT86RF212 AT86RF215 |
2 | Modulation OOK, FSK BPSK, O-QPSK FSK, O-QPSK, OFDM |
3 | Datenrate 1,2 … 300 kbps 20 … 400 kbps 6,25 … 2400 kbps |
4 | max. Framelänge 66 Byte FIFO*) 127 Byte 127 oder 2048 Byte |
5 | Adresse 1 Byte 2 oder 8 Byte 2 oder 8 Byte |
6 | Ack/Retry nein ja ja |
7 | Stromaufnahme Rx 16 mA 9 mA 28 (7/16) mA **) |
*) Theoretisch kann man den FIFO natürlich auf einer Seite weiter füllen und auf der anderen bereits auslesen. Ist dann aber zeitkritisch. **) Klammerwerte für "Reduced power consumption mode", dann wird der Empfänger nur gepulst eingeschaltet und erst voll aktiviert, wenn auf dem Kanal ein Signal erkannt worden ist. Der kleinere Wert ist dabei für FSK-Modulation, der größere für O-QPSK.
:
Bearbeitet durch Moderator
Ich finde es wirklich klasse, dass man hier so schnelle und gute Antworten bekommt. Das hat mich jetzt schon ein guten Stück voran gebracht. Ich denke, dass ich vorerst den RFM69CW nehmen werde, da es hier bereits einige Anleitungen im Zusammenhang mit dem Raspberry PI gibt. Mir ist nur aktuell nicht ganz klar, wofür den Microcontroller benötigt wird. Hier wird der RFM69 direkt mit den GIPOs verbunden: https://jeelabs.org/2015/05/20/rfm69-on-raspberry-pi/ Hier wiederum bekommt man eine Platine mit einem Microcontroller und (zusätzlich) dann noch den RF69. Kann mir evtl jemand erklären, was der Unterschied ist bzw. warum der eine einen Microcontroller benutzt und der andere nicht? Beste Grüße
Thomas schrieb: > Mir ist nur aktuell nicht ganz klar, wofür den Microcontroller benötigt > wird. > Hier wird der RFM69 direkt mit den GIPOs verbunden: > https://jeelabs.org/2015/05/20/rfm69-on-raspberry-pi/ Auf dem RPi ist der Microcontroller bereits auf dem Board und der RFM69 wird via SPI aufgerufen. Thomas schrieb: > Link vergessen: > https://lowpowerlab.com/shop/product/99 Ein Moteino wird eher als Sensor Node eingesetzt und der ATmega auf dem Moteino liest die Sensoren aus und übernimmt die Kommunikation mit dem RFM69 Transceiver. Moteino = Sensor Board RPi = Empfängerboard
Ohman, war auch ein blöde Frage. Das macht natürlich Sinn. Vielen Dank `:)
Jörg W. schrieb: > Kurz die Unterschiede zwischen AT86RF21x und dem RFM69 skizziert: Der niedrigere Strombedarf beim Empfangen ist natürlich interessant, aber gibt es die Dinger auch als einfach low cost Module wie die RFM? Habe nur die nackten Chips oder teure Boards damit gefunden. Warum brauchen die eigentlich beim Empfang soviel Strom?
Johannes S. schrieb: > Der niedrigere Strombedarf beim Empfangen ist natürlich interessant, > aber gibt es die Dinger auch als einfach low cost Module wie die RFM? Habe Module nur mit ARM-Controllern gefunden. Mit bisschen Geschick ist das aber auch kein Problem, den Kram mit der Hand zu löten. Du musst aber unbedingt ein Oberwellenfilter draufsetzen, die zweite Oberwelle (dritte Harmonische) ist ansonsten außerhalb des regulatorisch zulässigen Werts. Du kannst dafür den im Datenblatt genannten Johanson-Filterbalun benutzen. > Warum brauchen die eigentlich beim Empfang soviel Strom? Weil da ziemlich viele Schaltungsteile mit vergleichsweise hohen Frequenzen herumklappern. Auch der Baseband-Core braucht, um nach der Sync-Sequenz zu suchen, viel Strom. Das ist das A und O aller UHF-Technik. Wenn man energiesparend empfangen will, braucht man irgendeine Form von Synchronisationsschema.
Jörg W. schrieb: > Habe Module nur mit ARM-Controllern gefunden. um so besser, aber wenn ich das DB von den Chips verstehen will muss ich wohl erst ein Nachrichtentechnik Studium nachholen :)
Johannes S. schrieb: > aber wenn ich das DB von den Chips verstehen will muss ich wohl erst ein > Nachrichtentechnik Studium nachholen Naja, der AT86RF215 ist zugegebenermaßen recht komplex. Der 212 ist viel einfacher. Er wird von µracoli unterstützt (da mach ich mal ein wenig Eigenwerbung :), was dir zwar für den Raspberry Pi nicht direkt hilft, aber zumindest solltest du aus dessen Code Anregungen entnehmen können. Auch bei einem RFM69 wirst du aber nicht umhin kommen, grundlegende funktechnische Zusammenhänge zu verstehen, denn auch bei ihm kann man an ziemlich vielen Parametern herumschrauben.
Wie wärs denn mit MySensors und FHEM auf dem Raspi? MySensors geht auch mit RFM69. Wenn man will auch mit Verschlüsselung und Authentisierung. Billiger und einfacher geht's bestimmt nicht.
Jörg W. schrieb: > Der 212 ist viel einfacher. Er wird von µracoli unterstützt (da mach > ich mal ein wenig Eigenwerbung :) ok, das kannte ich noch nicht, sieht interessant aus. Kann der 212 auch FSK und mit dem RFM69 schwatzen (encryption müsste ja in SW möglich sein)? Das wäre für sparsame Empfänger interessant. Allerdings werde ich nicht so viele Empfänger haben das es sich stark in der Stromrechnung auswirken wird. An Sensormodulen habe ich schon einiges mit dem RFM69 zusammen. Die würde ich hier auch mal in einem Artikel zusammenstellen, habe da aber ein Board mit dem LPC812 gebaut das einige Flickstellen hat und erst nur für einen PIR Sensor gedacht war. Die Platine dafür habe ich in China machen lassen und gleich ein 10er Pack bekommen, die wollte ich nicht wegwerfen und habe die jetzt auch für Temperatur/Feuchtigkeitsensoren SHT15/31, PIR und Erdfeuchte benutzt. Post- und Klingelmelder sind auch einfach machbar. Software sind bisher nur ein paar JS Scripts, FHEM sehe ich mir auch noch mal an. Das arbeitet aber mit PHP? JavaScript wäre mir da lieber.
Thomas schrieb: > Als empfehlenswert hat sich meiner Meinung nach die 868MHz Frequenz > heraus gestellt. Daher würde ich diese benutzen. > Nun benötige ich als erstes einen Transceiver, welcher Daten auf Basis > der 868MHz Frequenz senden und empfangen kann. Schau mal her: http://www.ti.com/product/CC1310/description http://www.ti.com/tool/launchxl-cc1310 Das ist ein kleiner ARM M3, der alles beinhaltet, was Du für einen 868 MHz Knoten brauchst. Ein kleiner Chip für alles. Deinen PI kannst Du daran anschließen, aber der Chip läuft auch ganz alleine. Software und Protokolle gibts von TI fix&fertig. Der Chip hat 128k Flash und 20k RAM und kostet im Zehnerpack 5.20€ pro Stück bei Digikey. fchk
Wie sieht es mit der notwendigen Funkzulassung aus? Stichwort RED und CE. Da du einen Transceiver einsetzten willst, muss also nicht nur der Sender getestet werden, sondern auch der Empfänger. Macht das ganze nochmal eine Ecke teurer. Du kannst auch keine bestehenden Funkzulassungen anwenden, da du ja dein eigenes Protokoll bauen möchtest und man sich somit auch den Duty Cycle ansehen muss. Ansonsten könnte man besser auf ein fertig homologiertes Modul zurückgreifen. Vielleicht was in Richtung LoRa oder Zigbee
Johannes S. schrieb: > Kann der 212 auch FSK und mit dem RFM69 schwatzen Nein, der AT86RF212 macht nur BPSK und OQPSK wie im ursprünglichen IEEE-802.15.4-Standard vorgesehen. Der AT86RF215 kann dagegen FSK, da diese später im 802.15.4g hinzu gekommen ist (mittlerweile in einer neueren Ausgabe des Standards eingearbeitet worden). Chris K. schrieb: > Stichwort RED und CE. Für eine rein private Anwendung würde ich mich hier vergewissern, dass die entsprechenden Anforderungen eingehalten werden und danach mir selbst die Konformität erklären. ;-) Ist bei ordentlichem Layout und Oberwellenfilter entsprechend der Herstellerspezifikation kein Problem, da die Hersteller das ja schon mal beispielhaft selbst nachgewiesen haben. Auch sowas wie Receiver Blocking ist absolut kein Thema. Wir haben für die Firma gerade eine Precompliance-Messung in einem Testlab für den AT86RF215 gemacht, in dieser Hinsicht ist er 20 bis 30 dB besser als die Anforderungen der Norm. Die Duty-Cycle-Anforderungen der Allgemeinzuteilung muss man natürlich einhalten, aber auch das ist ja kein wirkliches Problem.
Ja, in der EU kann man sich durchaus die Einhaltung der Vorschriften selbst ausstellen. Problem, den Nachweiß muss denn noch akreditiertes Testlabor durchführen. Einfach zu sagen, dass passt schon, weil der IC so gebaut ist reicht leider nicht. Wenn dir einer auf die Füße steigt und den Nachweiß sehen will, ist man sofort im illegalen Bereich, wenn der nicht vorliegt.
Chris K. schrieb: > Einfach zu sagen, dass passt schon, weil der IC > so gebaut ist reicht leider nicht. Wenn dir einer auf die Füße steigt > und den Nachweiß sehen will, ist man sofort im illegalen Bereich, wenn > der nicht vorliegt. ist aber irgendwie verkehrte Welt, müsste derjenige nicht nachweisen das mein Teil nicht im legalen Bereich ist? Mir sagte mal ein Anwalt ich muss einen Schaden nachweisen, so gesehen könnte ja sonst jeder kommen...... Hier wird verlangt das man eine ordnungsgemäße Funktion teuer nachweist und nicht das eine nicht ordnungsgemäße Funktion von anderen nachgewiesen wird.
Joachim B. schrieb: > ist aber irgendwie verkehrte Welt, müsste derjenige nicht nachweisen das > mein Teil nicht im legalen Bereich ist? De facto ist es am Ende auch so. Wenn du andere störst, wird man von dir die Konformitätsbescheinigung einfordern, und dann musst du vorlegen, worauf sie basiert. Verantwortlich bist du aber in Europa ohnehin immer selbst, davon entbindet dich auch die Messung in einem Labor nicht. Die stellt nämlich am Ende auch nur fest, dass du zum Zeitpunkt der Messung konform warst. Wenn ich die RED richtig lese, kann man bei durchgehender Anwendung der harmonisierten Normen (dazu wäre man im Zusammenhang mit der Nutzung des 868-MHz-Bandes ohnehin gut beraten) durchaus auch nach wie vor die Konformitätsbewertung selbst durchführen (Anhang II der RED). Will man das korrekt machen, ist es aber ein ziemlicher Papierkrieg, den man dafür dann bereithalten muss (Artikel 21 sowie Anhang V). Ob das für das hier angedachte „Inverkehrbringen für ausschließliche Eigennutzung“ (also ohne Verkauf oder anderweitige Weitergabe der so gefertigten Funkausrüstungen) wirklich machen würde? Man müsste es … https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=celex%3A32014L0053
Jörg W. schrieb: > 868 MHz sind 35 cm Wellenlänge. Alle Strukturen kleiner als ca. 10 cm > bedeuten daher einen mehr oder minder hohen Verlust in der Abstrahlung. Da fragt man sich unweigerlich, wieso so viele 1/4-Lambda Antennen funktionieren können.
Wolfgang schrieb: > Da fragt man sich unweigerlich, wieso so viele 1/4-Lambda Antennen > funktionieren können. Indem sie auf einer Grundfläche von (mindestens) lambda/2 stehen. Tun sie das nicht, ist das tatsächliche Ergebnis „irgendwas“, einschließlich eines verringerten Gewinns. Eine lambda/4-Monopol-Antenne ist weiter nichts als dein lambda/2-Dipol, bei dem eine Hälfte zu einer Fläche „nach oben gezogen“ worden ist.
Thomas schrieb: > Hallo zusammen, > ich überlege schon seit längerem mein Heim zu vernetzen. > Leider sind viele der aktuellen Geräte sehr teuer und/oder keine Open > Source Protokolle. warum nicht z-wave? Nach dem Silabs es gekauft hat, ist die SDK open für alle. Ja, wenn man die Entwicklung fertig hat und verkaufen möchte, dann müssen die natürlich durch die z-wave alliance Zulassung etc., du willst aber nicht verkaufen sondern experimentieren, und das ist ausdrücklich erlaubt/gerne gesehen von Silabs.
Vielleicht noch zur Erklärung, wieso ich das ganze machen möchte. Ich komme aus der Ecke FHEM mit EnOcean Devices. Die Geräte von EnOcean gefallen mir eigentlich sehr gut, da viele Sachen auf Solar aufbauen und daher keine zusätzlichen Batterien benötigen. Ja, mittlerweile hällt so eine Batterie 2-3 Jahre, aber keine Batterie ist meiner Meinung nach umweltfreundlicher. Leider finde ich diese Geräte vergleichsweise teuer. Und auch Geräte die auf ZigBee oder Z-Wave setzen, kosten nur geringfügig weniger. Wenn ich mir jetzt die Kosten der eigentlichen Hardware ansehe, steht das in einem schlechten Verhältnis. Daher investiere ich lieber selbst Zeit in die Entwicklung der der Hard- & Software. Auch wenn ich die Sache mit den nötigen Lizenzen bei einem eigenen Protokoll aktuell nicht so ernst nehme, habt ihr natürlich recht. Daher nehme ich auch gerne ein bereits vorhandenes Protokoll wie Z-Wave. Und für die privaten Gebrauch der Hardware muss ich mich auch nicht zwingend der Allianz anschließen. Bleibt nur die Sache mit dem Bauen der jeweiligen Geräte. Evtl. liefert die Z-Wave Allianz ja ein paar Dokumente, wie man entsprechende Hardware bauen kann. Ich werde mich mal umschauen :)
Thomas schrieb: > > Leider finde ich diese Geräte vergleichsweise teuer. Und auch Geräte die > auf ZigBee oder Z-Wave setzen, kosten nur geringfügig weniger. das stimmt, ein ganzer Batzen der Kosten sind die Lizenzen, egal wie ich mich drehe und wo ich es zertifiziere, es kostet trotzdem > Daher nehme ich auch gerne ein bereits vorhandenes Protokoll wie Z-Wave. > Und für die privaten Gebrauch der Hardware muss ich mich auch nicht > zwingend der Allianz anschließen. genau! > > Bleibt nur die Sache mit dem Bauen der jeweiligen Geräte. > Evtl. liefert die Z-Wave Allianz ja ein paar Dokumente, wie man > entsprechende Hardware bauen kann. nein, die nicht, aber Silabs. Es sind Datenblätter, Schaltpläne, SDK, Schaltplan des Programmers (es reicht im Prinzip usb<->uart adapter) - leicht nachzubauen (auch die Firmware dafür ist verfügbar), Programmer App für Windows, alles was immer unter NDA versteckt war. Allerdings nur für zw500 SoCs, wenn du alte zw0300 nutzen möchtest, muss Du Silabs nach der SDK 4.55 fragen (ja, wird auf Anfrage gesendet). Da zw300 nicht mehr zertifizierbar sind, wird auch die Z-Wave Alliance nicht heulen. Wobei, ich würde es die zw500 nehmen und die fertigen examples, basierte auf application framework (das sind zertifizierte Beispiele, daher werden die kein stress machen mit z.b zway von zwave.me oder Fibaro).
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.