Forum: HF, Funk und Felder Eigene 868 MHz Geräte (inkl. Protokoll)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 Thomas (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von John B (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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
von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von John B (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ohman, war auch ein blöde Frage.
Das macht natürlich Sinn.

Vielen Dank `:)

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Robert K. (mr_insanity)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
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.

von fchk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Chris K. (deadeye5589)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Chris K. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Thomas R. (tinman) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.