Hallo
Da ich zur Zeit mit der Entwicklung eines eigenen Empfängers für EnOcean
Sendermodule zu tun habe, wollte ich mal die Ergebnisse hier posten.
Untersucht wurden das STM110, PTM200 und PTM230 mit und ohne Repeater.
EnOcean hat sich viel Mühe gegeben die Daten zu verschleiern. Die Bytes
werden in zwei Nibbles unterteilt, die dann mit 5 Bits unterschiedlich
verschlüsselt werden (siehe Anhang). Dabei verwenden sie drei
unterschiedlich lange Telegramme.
Nur das STM110 sendet vollständig alle Daten. Die beiden Anderen senden
nur das Nötigste. Auch wenn der Repeater diese Daten weiterschickt,
werden sie nur ein wenig vervollständigt.
Ich habe jetzt noch ein Problem. Das STM und die weiter geleiteten PTM
Daten haben eine vernünftige Checksumme.
Aber die Daten direkt von den PTM haben eine 5 Bit Checksumme, die ich
nicht verstehe. Kann mir da jemand helfen?
Gruß
Ferdi
sieht interessant aus. Ich bin auch gerade dabei, mit Enocean zu
arbeiten. Habe Fenstergriffe von Hoppe und (bisher) einen
Siemens-Raumthermometer.
Ich habe auch schon überlegt, mal selber einen Enocean-Sender zu bauen,
aber das Protokoll wird ja nicht offen gelegt. Und zum Nachforschen in
den 868MHz-Rohsignalen hat mir bisher noch die Zeit gefehlt.
Gruß
Martin
Ich hätte da mal 'ne advocatus diaboli Frage: es sieht aus,
als wäre da weder replay-Schutz noch Verschlüsselung dabei!?
Ist das dann nicht ziemlich mutig, Sensoren und Schalter
einzusetzen?
VG,
Hans
ferdiflachmann schrieb:
>Da ich zur Zeit mit der Entwicklung eines eigenen Empfängers für EnOcean>Sendermodule zu tun habe, wollte ich mal die Ergebnisse hier posten.
Ich habe mir die Dokumente durchgesehen und kann nur sagen:
SUPER LEISTUNG diese Code-Tabelle aus den Rohdaten herauszuextrahieren!!
Wie sind die eigentlich HF codiert? Wie bist Du vom Funksignal zu
Blatt 2,3,4 gekommen?
>Aber die Daten direkt von den PTM haben eine 5 Bit Checksumme, die ich>nicht verstehe. Kann mir da jemand helfen?
Vermutlich ist es eine CRC, ich habe nach Pfingsten Zeit mir anzusehen,
ob das vielleicht die USB-CRC x^5 + x^2 + 1 oder die Bluetooth CRC
x^5 + x^4 + x^2 + 1 ist.
VG & Danke,
Hans
Hi
Das Hf Signal ist glaube ich ASK. Darum brauche ich mich zu kümmern. Ein
TI MPS430 HF Modul soll es Empfangen können. Das macht dann aber jemand
Anderes dem ich bei der Decodierung geholfen habe.
Zu Empfang habe ich erst nur ein RCM benutzt. Die Datenpakete an ein
Terminal Programm und von Pin 14 die Rohdaten zu einem Logiganaliser.
Das RCM gibt diese Rohdaten aber mit sehr schlechten Flanken raus. Um
die wirklichen Bitlängen zu messen muß mann eine extrem kurze Abtastzeit
wählen was dann zur Qual wird. Ein Telegramm ging dann über mehrere
Seiten und konnte auch nicht gedruckt werden.
Ich habe mir also an jedem Modul die Daten vom Processor abgegriffen.
Danach sahen die Telegramme wie im Anhang aus.
Der Rest war dann Knobeln. Am STM habe ich mit den AD Kanälen die
einzelnen Bytefolgen erzeugt und im Telegramm gesucht. Mit dem Repeater
fand ich das veränderte Statusbyte (RP Zähler). Die IDs kannte ich ja
von jedem Modul. Die mußten dann auch zu finden sein.
Ich brauchte sehr viel Papier und habe Unmengen von Streifen mit
Telegrammen Ausgeschnitten um sie aneinander legen zu können. Zum
Schluß, als alles begann sich aufzulösen, machte es dann Spaß.
@Hans
Es wäre klasse, wenn du mir bei der PTM Checksumme helfen könntest.
Wenn jemand noch weitere Modultypen untersuchen könnte wäre das
natürlich auch prima.
Gruß
Rainer
Hallo Rainer,
> Aber die Daten direkt von den PTM haben eine 5 Bit Checksumme, die ich
Nach Deinen Dumps sind das aber 8 Bit Checksum/CRC? Sollte "8" da
stehen!?
Dann ist mein Post mit den USB und Bluetooth CRCs natuerlich
Schmarrn!
VG,
Hans
OK, Du meintest das letzte Sheet (Seite 4)?
Im Dump steht fuer CS ein 0xEE. Das erste "E" muss nach Deinem
Dekodier-Sheet Seite 1 ein "D" sein!?
VG, Hans
die Prüfsumme z.B. beim Telegramm vom PTM230:
0x61 + 0x00 + 0x01 + 0x24 + 0x0e + 0x20 = 0xb4
davon die Quersummme:
0xb + 4 = 0xf ==> checksum
bei allen Telegrammen in den Diagrammen stimmt dieses Schema jedenfalls.
LG,
Erwin
Guten Abend,
ich beginne gerade mein Praxis-Semester und mir wurde zur Aufgabe
gestellt, mich mit dem EnOcean-Protokoll auseinander zu setzen. Ziel ist
irgendwann einmal das Ansprechen einer Lampe z.B. via eines
Accesspoints, dem ich über ein IPhone Befehle sende.
Wie auch immer - ich habe eure Diskussion mit Interesse verfolgt und
noch ein paar weitere Quellen gefunden.
Und mit neuem Wissen entstehen auch immer neue Fragen ;)
Wenn ich mir unter
http://www.wago.com/wagoweb_china/public/750/ger_manu/modules/m064200d.pdf
Seite 16 unten die ORG-Feld Beschreibung ansehe, beist sich das mit
deinen ausgemessenen Werten. Für mich hat das den Anschein, wie wenn
deine 2 PTM's SMT's wären (1 Byte Daten Telegramm und die 6 vorneweg
...) und wie wenn die 5 im ORG-Feld auf ein PTM hinweißen würde :D
Natürlich hab ich hier am wenigstens Ahnung von allen - aber wie lässt
sich das unter einen Hut bringen???
Eine weitere Frage wäre, ob es denn jetzt überhaupt eine verbindliche
Protokoll-Form gibt? Ich dachte eigentlich das EEP sei genau das, wonach
ich suchte - jetzt stelle ich aber fest, dass EnOcean an sich nochmal
verschlüsselt (warum eigentlich?) und wenn ich später mal mit dem IPhone
irgendwas steuern will, muss ich mich ja dann an deine Entschlüsselung
halten oder?
Das ist wie ihr sicher merkt gerade eine ganz neue Welt für mich und
Verwirrung greift um sich ;)
Für eventuelle Hilfestellungen wäre ich sehr dankbar!
Liebe Grüße!
Hallo
Du darfst hier das EnOcean Funktelegramm auf der seriellen Schnittstelle
(!) nicht mit dem Protokoll auf der Luftstrecke verwechseln.
Gerade die PTMs mit ihren Piezo- und Spulengeneratoren haben zu wenig
Energie, um alle (auch die bei diesen sowieso nicht genutzten) Bits zu
versenden.
Daher sind die Telegramme auf der Luftstrecke sinnvoll gekürzt (nicht
verschlüsselt). Aber das wurde noch nicht von EnOcean öffentlich
dokumentiert.
Wir haben das Protokoll jetzt schon erfolgreich auf einem CC1110
nachgebaut. So können wir zwei Protokolle (EnOcean und unseres) parallel
auf einem Empfänger unterscheiden.
Gruß
Rainer
Hallo Rainer und Rest,
ich hab das ganze Thema immer noch nicht so ganz erfasst.
Die Kürzung der Telegramme macht natürlich sinn, aber wie oben
beschrieben weißt doch die 0xX5 auf ein PTM und die 0xX6 auf ein STM
hin, oder?
Vielleicht ist das für meine Problemstellung auch irrelevant, das kann
ich bisher nicht beurteilen, da ich mich bisher nur mit der
Protokoll-Frage herum geschlagen habe. - Ist das EEP nun DAS Protokoll
für alle EnOcean-Geräte?
Und dann würde ich gerne noch einmal nachfragen, ob irgendwer eine Idee
für eventuelle Geräte zu meiner Problemstellung hat. Im Prinzip brauch
ich 1-2 Schalter, 1-2 Relais um damit später über den Schalter
Glühbirnen schalten zu können und eine mir noch total ominöse "Box" (<-
gibt es so etwas überhaupt?), die die EnOcean 868MHz Signale empfängt
und über einen AccessPoint ins WLan weiter reicht - den AccessPoint
könnte man auch über eine Ethernet-Schnittstelle separat hinzufügen.
(Ich habe mich in der Hoffnung das Protokoll-Problem EnOcean-Bauteilen
zu überlassen mal auf die Hardware-Suche gemacht -> wäre es mit diesem
Bauteil möglich mein Problem der ominösen "Box" zu erschlagen?
http://www.batterielos.de/shop/EnOcean-Funktechnologie/Kommunikation/Empfangseinheiten/Thermokon-SRC-Ethernet::1447.html
)
Und hier liegt auch der Hund begraben zur Protokoll-Frage -> Es kommt
ganz darauf an, was diese ominöse "Box" mir an Protokoll rausgibt (?!) -
soll heißen: Falls es diese Box gibt, dann reicht sie hoffentlich das
EEP weiter oder?
Fragen über Fragen eines Neulings ;)
Über Antworten würde ich mich natürlich sehr freuen, ansonsten wird der
Chef nicht sehr erfreut sein über MICH, wenn ich einfach anfange zu
bestellen ;D
Liebe Grüße und Danke, Jan
Und noch ein kleiner Nachtrag:
Ist es überhaupt möglich, ein IPhone (kann man ja so direkt nicht
einlernen oder?) als Sender für die Regelung einzusetzen?
Lg
Ja der Plan ist ja ggn später eine App auf dem IPhone zu haben, mit der
ich den AccessPoint via WLan erreich und darüber meine Befehle schiebe.
Es ist halt die Frage, ob das prinzipiell überhaupt möglich ist, da sich
ein IPhone ja nicht direkt einlernen lässt oder? :/
Ne da mussu ne App für basteln, und die kann man glaub nur mit Developer
Lizenz aufs Gerät bringen. Oder halt den Weg über einen Jailbreak.
Evtl ne Android Geärt nehmen oder halt erstmal über ne html/php request
steuern. Das geht dann ja übern Browser.
Hallo Ian,
Ich werde demnächst vermutlich ziemlich genau das selbe "Problem" haben.
Direkt kannst du das iPhone nicht einbinden, außer du kriegst Steve Jobs
überedet dir da so einen Chip einzulöten. Also direkt geht nicht. Es
gibt aber sehr wohl schnittstellen zum LAN, zum WLAN gibt es soweit ich
bisher herausgefunden habe keine. Das iPhone müsste dann nur via tcp
o.ä. ein Protokoll versenden, aber wie gesagt noch bin ich nicht ganz
drin
:) Ich glaub wir reden grad ein bisschen aneinander vorbei -> hier noch
einmal der Masterplan, der sich bei mir so langsam herauskristallisiert:
Ich möchte auf meinem IPhone eine App schreiben (das wird in der
To-Do-Liste jedoch relativ weit am Ende stehen) - Dev-Lizenz usw. kein
Problem das ist hier alles vorhanden (hatte auch schon ein wenig mit der
IPhone-Programmierung zu tun).
Auf jeden Fall ist der Plan dann über WLan mein EnOcean-Code/Protokoll
auf meine ominöse Box (kann das funktionieren? Diese eine hier ist
gemeint "Thermokon SRC- Ethernet" - Link zum Produkt siehe oben) zu
bringen und diese soll mir das dann über das "Luft-Strecken-Protokoll"
zu z.B. einem RCM110 senden -> Licht An/Aus und u.U. Dimmen (das wäre
dann nur noch eine Spielerei).
Parallel dazu soll die selbe Funktion von einem PT200 übernommen werden
- als Vergleich sozusagen.
Mein erster Schritt wäre nun erstmal das Ganze ohne IPhone zu aufzubauen
und hoffentlich zum laufen zu bekommen (wie gesagt -> bin mit EnOcean
total neu und habe immer noch nicht so die Ahnung wie das genau zusammen
arbeitet - falls mir hier noch jemand bessere Lektüre/Tipps hat dann
bitte immer gerne her damit!). Harmonisieren RCM110, PTM200 und
"Thermokon SRC-Ethernet" ?
Das Einlernen muss dann vermutlich über das "Thermokon
SRC-Ethernet"-Bauteil erfolgen oder kann sich das die Konfiguration auch
vom RCM ziehen? Ich seh schon, da sind noch viel zu viele Bäume im
Sichtfeld gerade ;)
>Harmonisieren RCM110, PTM200 und
"Thermokon SRC-Ethernet" ?
Du hast ihn schon selbst gefunden ;-)
Sie sollten es zumindest, sonst wäre das ganze System müll, wenn es
nicht geht, aber mit sicherheit kann ich es dir nicht sagen.
Der Thermokon SRC-Ethernet frisst aber ganz normales EEP über seine
Lan-Schnittstelle oder? x) ich seh schon wir 2 werden noch jede Menge
Spaß mit einander haben!
Also einen RCM und einen PTM auf einander einzulernen sollte eigentlich
kein Problem darstellen. Verstehe ich das eigentlich richtig, dass der
SRC-Ethernet ankommende Daten einfach nur weiterreicht? Er also:
a) eine Protokoll-Umwandlung vom Luft-Protokoll ins "Leitungs"-Protokoll
(demnach EEP, oder?) vornimmt und
b) diese dann über seine Schnittstellen weiterleitet (geht er bei
ankommendem Funk-Befehl NUR aufs Lan oder arbeitet er auch mehr oder
weniger als Repeater nebenher und jagt es auch wieder ins Funk-Netz
raus?) ???
Weil wenn ja, dann würde ich langsam ein wenig Sonne sehen ;)
Offensichtlich werden die Daten aus dem Funk Netz nur auf LAN umgesetzt
und per TCP/IP oder UDP verschickt. Eine Repeaterfunktion ist den
Angaben nicht zu entnehmen.
Die Halten aber auch massiv hinter dem Berg mit ihren Infos.
Mal sehen nächste Woche entscheidet sich, ob wir dort einsteigen oder
nicht, und dann hab ich auch den ein oder anderen Euro zur Hand, dann
hoffe ich werden die Informationen mehr
Guten Morgen,
kannst du oder irgendwer anderes mir vielleicht noch kurz die versteckte
Frage beantworten, ob der SRC-Ethernet die über Lan erhaltenen
EEP-Protokolle selbst umwandelt in Luft-Strecken-Protokoll, oder
benötigt der SRC-Ethernet AN SICH schon das Luft-Strecken-Protokoll?
Gut das mit der Repeater-Funktionalität wär auch eher ein
nice-2-know-Fact gewesen ;)
Und noch eine letzte wichtige Frage, bevor ich Richtung Chef laufe und
versuch mir die Hardware zu besorgen:
Der SRC-Ethernet an SICH lernt nichts ein bzw. muss nirgendwo eingelernt
werden, oder? Hierbei handelt es sich ja weder um einen Sensor, noch um
einen Aktor - er soll ja nur Information weiterleiten - sehe ich das
richtig???
Mérci und Grüße, Jan
^^ wir hatten einen kleinen Fehler bei uns - brauchen Bidirektinalität
-> also ein STC!
(siehe http://www.thermokon.de/DE/easysens/stcethernet.html)
So wie es aussieht gibt es das aber nicht zu kaufen ;) finde zu genau
diesem Artikel keine Matchs über Google ...
Aber werd mir auch hier jetzt mal die Software- und
Konfigurations-Beschreibungen zu Gemüte führen.
Hallo,
@Rainer:
Du hast eine erfolgreiche Registerconfigurartion für den CC1110?
Ich arbeite auch gerade daran, allerdings sieht die empfangene Bitfolge
noch nicht wie gewünscht aus...
Könntest du vlt. die Settings mir bzw. der Allgemeinheit zur Verfügung
stellen :-)?
Vielen Dank vorab,
lg,
Benjamin
