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
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:
*) 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.
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
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/descriptionhttp://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).
